Tuesday, March 1, 2016

Jumping on the Bandwagon with the SSLv2 "drown" vulnerability.

It has been a while since we've seen a truly newsworthy vulnerability in SSL but we got one today in CVE-2016-0800, more affectionately known at DROWN. The tech news media is sure to be writing very exciting and largely redundant articles about this particular beast. So, I figure why not add to the fray with my own little post.

Last time we saw something this newsworthy was the renown Heartbleed vulnerability way back in 2014. That one had IT shops scrambling to patch systems and executive up at night worrying that something was missed and the hackers would get into their businesses. Scary stuff for both groups.

But, enough background, what does this new vulnerability really mean?

If you have a server that allows the use of SSLv2, then an attacker can use it to figure out what is called a "session key". A session key is the encryption key used to secure the communications in transit between a client and a server. How bad this could be for your business depends on how sensitive the information flowing between your server and your clients.

In the worst case, you are communicating highly sensitive information that falls under strong government regulations or industry compliance standards like personally identifiable information, health care data, or financial transaction data.

In the best case, it represents an embarrassment to the company and the need for customers to change their passwords.

The Good News

This new vulnerability is a variation on one from March of 2015 (CVE-2015-0293) and is much harder to exploit. As a result of that previous incident, organizations that were concerned about that (older) vulnerability should have already disabled SSLv2 in order to protect themselves and their customers. Unless they have re-enabled SSLv2 this should not be a major concern today.

In order to take advantage of this vulnerability an attacker is going to have to make many thousands connection to a  vulnerable server. Any organization with a good intrusion detection system at their perimeter should be able to pick up on this to identify potential attackers fairly quickly.

The Bad News

One server that is vulnerable to the DROWN vulnerability can be used to obtain the session key for another server provided that both servers are using the same server certificates. More specifically the same RSA private keys within those certificates. They don't even have to be the same type of server as long as they use the same certificate. A public facing mail server could be used to obtain the session key for a secure web server in such a case.

Most bigger organizations choose to purchase wildcard certificates for their public servers. This lets the organization purchase one certificate and use it on multiple servers instead of having to purchase (and manage) separate certificates per server. While this simplifies server certificate management, it increases the risk of exposure in this case. A server that would be considered a lower priority could end up being used in an attack against a higher priority server.

Another potential problem arises network appliances. Particularly those whose vendors don't tend to provide patches promptly. These may go for years without a fix even available. The consumer market will be a particular problem in this case.

Conclusion

When this hits the major media news, we will probably see some more sleepless nights for executives and IT staff. It shouldn't be nearly as severe as Heartbleed was because anyone who has been paying attention to their information security should already have SSLv2 disabled all their servers.

The best course of action I can think of at the moment is to do a thorough review of all public facing servers and network equipment and confirm that SSLv2 is disabled. This needs to include even the low-priority systems because one server can be used by an attacker to compromise a different server. With SSLv2 disabled on every server, organizations can take their time and patch systems properly.

References:


No comments:

Post a Comment