Happy SSL Vulnerability Day

We are living in the age of the Internet. It seems like everyone has a presence on the Internet these days. People can now perform research online, read books online and even shop online. Large amounts of sensitive information flow through the veins of the internet on a daily basis. In order to protect this data we turn to our dear friend known as SSL (Secure Sockets Layer).

SSL is a protocol used to protect sensitive data flowing over the Internet from unauthorized parties. SSL verifies that the site claiming to be XYZ Bank is really XYZ Bank, and then encrypts the information traveling between the user and XYZ Bank. SSL is used when you buy the newest book from Amazon, or when you win that newest item on e-bay. SSL has become a cornerstone for protecting most sensitive data that is sent over the Internet.

In light of the fact that SSL is so important to Internet security, it is odd that vulnerabilities related to SSL implementation are found in many organizations. I have performed many vulnerability scans and it is amazing to see the amount of vulnerabilities, related to SSL. In honor of the many SSL implementation vulnerabilities I continue to find on a daily basis, I figured that this would be a good time to talk about a couple of them.

The first vulnerability I would like to discuss is the use of SSLv2. SSLv2 has many security flaws, but I am going to focus on the ability to downgrade the encryption used to establish SSL connections. Generally encryption negotiation of SSL connections works as follows: Suppose that a web server supports LOW, MEDIUM and HIGH levels of encryption. A user needs to connect to the server to perform some kind of action (such as online banking). The user supports SSL connections using LOW, MEDIUM and HIGH levels of encryption. In most cases the server and user will choose the highest form of encryption both of them support. Therefore the server and user will connect using HIGH encryption since both user and server support this level of encryption.

SSLv2 has been found to have a Ciphersuite rollback attack (Page6: http://www.schneier.com/paper-ssl.pdf). This attack works as follows: Suppose that a web server supports LOW, MEDIUM and HIGH levels of encryption. A user needs to connect to this server to perform some kind of action. The user supports connections using LOW, MEDIUM and HIGH levels of encryption. An evil hacker sits between the user and the server. The evil hacker intercepts the user’s SSL request, and modifies the request in order to make the server think the user only supports LOW encryption. Although both the user and the server support HIGH encryption, the connection between them is established using LOW encryption.

In most cases it is trivial to disable SSLv2. On new versions of Microsoft Windows SSLv2 can be disabled by modifying the underlying system’s registry. SSLv2 can also be disabled in Apache by making small changes to the httpd.conf file.

Disable SSLv2 in Windows: http://support.microsoft.com/kb/187498
Disable SSLv2 in Apache: http://apachehacker.com/kabir/security/disabling-weak-ssl-v2-support-in-apache-server.html or http://adamyoung.net/Disable-SSLv2-System-Wide

The second vulnerability I would like to rant about is the availability of weak encryption settings on a server, which could be used to establish SSL connections. It is not uncommon to find weak encryption settings enabled on a server. One such weak encryption algorithm is named DES. DES stands for Data Encryption Standard and only uses a 56-bit key to encrypt data. In April of 2006 DES was broken in nine days at a cost of $10,000 in hardware costs. Within a year the average time needed to break DES encryption was reduced to only 6.4 days (http://en.wikipedia.org/wiki/Custom_hardware_attack#History). It is important to note that when using DES encryption the possibility exists that an attacker may be able to see what you are sending in only 6.4 days. This is a rather scary thought! If an attacker were able to find your credit card or social security number in 6.4 days would you be concerned? The answer in most cases is a resounding YES!

The majority of weak SSL encryption vulnerabilities can be fixed rather easily. Most versions of Microsoft Windows can have weak encryption disabled by simple registry changes. Apache can disable weak encryption through simple changes in the httpd.conf file. In order to protect consumer data it is vital to disable support for weak encryption.

Disable Ciphers in Windows: http://support.microsoft.com/default.aspx?scid=kb;EN-US;245030
Disable Weak Ciphers in Apache: http://qaix.com/java-programming/487-339-ssl-server-supports-weak-encryption-vulnerability-read.shtml

Unfortunately I cannot address all SSL vulnerabilities in a single post. Time would fail me if I were to talk about Self Signed Certificates, Signature Verification Failure, X.509 MD5 Signature Collisions, Improperly Used Certificates, or Expired Certificates. To summarize SSL is a critical protocol used to ensure Security on the Internet and I have found it to be broken in many implementations. Now I ask you. How will you help defend the integrity of the Internet?

-Gary McCully