This week a huge flaw in one of the key underpinnings of electronic commerce was discovered. For the last two years the Debian GNU/Linux version of OpenSSL has produced extremely weak keys. This was a classic case of the right hand not knowing what the left hand was doing.

A bit of background in cryptography is necessary to understand the problem. In order to create public-key cryptographic keys, a strong source of entropy is needed. OpenSSL uses uninitialized data (random bits in memory) as part of its pseudo-random number generator (PRNG). When Debian audited the OpenSSL code for memory management bugs the use of uninitialized data was flagged as a potential defect. The Debian package maintainers simply commented out the line of code causing the warning and moved along without realizing the full implications of their actions.

Unfortunately for users of Debian, without this uninitialized data the only entropy used by the OpenSSL PRNG is the process ID, essentially crippling it. This change limited the entire key space to 32,767 (2^15), instead of 2^1024 in the case of a 1024-bit DSA key.

Whoops.

Hackers have already generated all possible valid keys for x86 and have automated the task of brute forcing SSH. According to HD Moore “It should be possible to try all 32,767 keys of both DSA-1024 and RSA-2048 within a couple hours…”

There are two main points to bring away from this:

1. If you are running a Debian box it’s time to update your OpenSSL package and create new keys. Do it now. Do not pass go.
2. You shouldn’t take reports from auditing tools at face value. These are tools to point you in the direction of problems but they are prone to false positives. You should look into the “problems” pointed out by these tools but they don’t always necessitate major changes. In Debian’s case the appropriate action would have been to add a comment explaining the purpose of that line of code rather than deleting it. This would have both made the code more readable and saved me a couple of hours earlier this week.

Picture courtesy of xkcd.com

There is an old saying that says, “To survive a bear attack you don’t have to outrun the bear, you just have to outrun your friend.” This analogy can also be applied, to some degree, to the Internet as well. In some instances, you don’t have to completely secure yourself from hackers, you just have to be more secure than the next organization. Hackers go after low hanging fruit because it gives the most bang for their buck. This year it appears that client side attacks represent that low hanging fruit. The modern web browser is an incredibly complicated piece of software with a large attack surface. Throw on some third party software like ActiveX controls (most of which are chock full of buffer overflows) and you have a hacker’s playground. To make matters worse, all modern day browsers contain JavaScript interpreters which give attackers the ability to obfuscate their attacks in an infinite number of ways. Luckily there is a method for users to fight back against the majority of these JavaScript- based attacks: No Script (Firefox) and Trusted Sites (Internet Explorer).

These methods take the same approach to security: Enumerating the good. Instead of playing whack-a-mole with all the new type of attacks that appear you allow the list of sites where JavaScript is allowed to come from. To do this with Internet Explorer you must first disable active scripting for web sites in the “Internet” zone and then add trusted commonly access pages to the “Trusted Sites” zone. This change can be done through Active Directory and pushed out to all computers in your organization. To achieve the same effect in Firefox you must install the No Script extension. By default this plug-in will block all JavaScript, java and flash (no more flash ads) content. You can then enable this content on a per page basis or import a list of trusted sites. By using either one of these method you will be able to block the vast majority of browser- based attacks.

NoScript: http://noscript.net/

Using group policy to manage the list of trusted sites: http://support.microsoft.com/kb/816703