Category Archives: Vulnerabilities

The big DNS issue

Filed under Vulnerabilities

I won’t ramble on about the DNS vulnerability discovered by Dan Kaminsky this week…plenty of other blogs and news sites are covering it. Yes…it’s important, groundbreaking and all that jazz. However, if you want the real scoop especially if you need to convince your employer that this needs to be addressed quickly…then I point you to Rick Mogull’s web site (specifically this post) and listen to the podcast over at the Network Security Podcast which has a good interview with Dan Kaminsky.

Oh yeah..Dan has a cool “DNS Checker” on his web site where you can test your own DNS servers to see if they are vulnerable.

Stumbling upon Security Issues

Filed under Vulnerabilities

Seriously…I don’t go looking for web site security issues or vulnerabilities but sometimes you do “stumble” upon them. 😛

Several weeks ago I was looking for an online schedule of events at one of the local community centers where I live so I did what anyone would do and typed in the URL of the city’s web site into my browser, but without typing “www” first. The actual URL starts with “www” but many times just by typing the URL without “www” will take you to the web site. So to my surprise instead of getting the main index page of the city’s web site I get a web form prompting for login credentials to what looked like an HVAC system attached to the Internet! The header of the page had some information about a system version so I did what any other security guy would do and launched a Google search to find out more details about this system. Yep, it was an HVAC system alright. So I thought no big deal right….out of curiosity I hit the ‘enter’ key thinking that there was no way that there was an anonymous login on this baby…low and behold, it logged me in! I was able to view the HVAC system configuration and potentially manage the HVAC for not only the community center but the city hall and other facilities. Looked like I could have caused some mischievous outages like changing the temperatures and even shutting down the HVAC system. At this point many scenarios entered my head, including why someone would put an HVAC system that should be on the company “Intranet” on the “Internet” with an anonymous administrator level account…nahh…I’m a pen tester so this isn’t shocking to me at all!

Being the ethical person that I am I emailed the city that manages this domain letting them know of the issue…today a received an email that said they were looking into the issue and it should be resolved shortly. So here are the questions. What would you have done (put your non-evil hat on please…yes, methodically messing with the temperature in the mayors office would be a blast…)? Do you just forget that you stumbled upon this vulnerability or do you believe in more of a full disclosure policy to the people running the web site? In talking to some others…attempting to contact the site owners is the best option (which I agree with) yet some others may take a different approach. Some “grey-hat” hackers might even resort to causing havoc with the HVAC system just to prove a point, then disclose the vulnerability the right way. Thoughts from the community?

Debian and Ubuntu OpenSSL Vulnerability

Filed under Vulnerabilities

<%image(20080517-debian-girl.jpg|137|103|Debian Girl)%>

I won’t go into all the details since every other security blogger on earth is covering it….however, as a reminder this issue is pretty serious if you had generated any keys on affected Debian or Ubuntu systems. The best summary I have found of the issue with links to all the “toys” that have come out to attack this vulnerability are on HD Moore’s web site. Here is a summary from HD:

“All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected. In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL’s PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.

Ugly vulnerability is right for an OS that changes you….