HTTPS may not be as safe as it once was

Proper encryption is seen by many as the linchpin to the Internet's current and future success. Everything from online banking to private email correspondence needs to be kept out of the hands of cyber criminals, and as such encryption methods were implemented into many of the world's modern data transfer systems. However, it would appear that HTTPS encryption has a vulnerability that could quickly get out of hand if it isn't nipped in the bud. 

A new attack strategy dubbed DROWN (Decrypting RSA using Obsolete and Weakened eNcryption) has essentially broken an older form of encryption that many servers still use. The implications of this vulnerability are far-reaching, and show the importance of constant diligence when it comes to cyber security. 

Where does this vulnerability come from?

The entirety of this debacle spawned from SSLv2, an outdated protocol used for encryption that was originally implemented in 1995. With more than twenty years to poke around for vulnerabilities, it isn't surprising that hackers finally found a way to exploit this relatively ancient system. Even so, SSLv2 wasn't that strong to begin with.

This protocol relies on a 40-bit key, a particularly weak form of  encryption. Although the 2⁴⁰ unique keys contained within this may sound like a lot to the average person, a 40-bit encryption system can be broken in a few hours through a brute-force attack. The reasoning behind SSLv2's implementation of such a poor form of security has to do with a battle over encryption that looks a lot like one going on today. 

Back in the 1990s, the explosion of the Internet called for some means of safe data transfer. As such, encryption experts began to come up with some inventive ways to scramble messages. However, the U.S. government decided that allowing this trend to grow beyond control could be a threat to national security, so a ban was placed on exporting encryption that used anything more than a 40-bit key, according to a Congressional report on the matter. 

While this had the intended effect of decreasing the amount of communications the government couldn't read, it also unintentionally worked toward weakening encryption as a whole. International communications that required a high-level of security were forced to use 40-bit, which is why older systems like SSLv2 still rely on this kind of key. Although the U.S. government has since loosened it's control on encryption, the effects of this action are still being felt today. 

In a sense, this is a lot like the current discussion surrounding encryption that came out of the security battle between the FBI and Apple. The FBI and many other Americans feel that heightened encryption allows terrorists and other dangerous individuals to hide their plans from governmental agencies in a trend that's being referred to as "going dark." On the other hand, technology experts from all over the world argue that weakening encryption – or even giving the government a key – could result in attacks similar to DROWN. 

So what did hackers do to decrypt private information?

First, the criminal behind this operation needs a man-in-the-middle standing. This is where the hacker acts as a relay between the two systems attempting to make a connection. Although neither know this person is intercepting messages, the hacker still can't read the content due to the fact that it's been encrypted. Once this position is accomplished, the hacker must target a server running SSLv2 and attempt multiple connections to brute force the system to give up the encryption key. After that, the cyber criminal has the ability to decrypt any of the messages he relays. 

While this process requires quite a lot of cyber security knowledge, it isn't exactly difficult to pull of in terms of money spent. Researchers from multiple countries used the Amazon Elastic Compute Cloud for a DROWN attack, which allowed them to decrypt a TLS handshake in under 8 hours. This ended up costing the team $440, well within the price range of many nefarious cyber criminals. 

How many servers are at risk?

Perhaps the worst part of this whole ordeal is just how widespread this problem is. In order for a server to be vulnerable, it has to either support SSLv2 requests or use a private key that links up with another system that supports SSLv2. All told, one of these two conditions can be attributed to around 17 percent of HTTPS servers. 

While that may not seem like much, it also doesn't take into account key reuse. Recycling keys allows for a more efficient system, but it also opens servers up to a DROWN attack simply due to the probability of communicating with a server that supports SSLv2. Once this variable is accounted for, the number of vulnerable HTTPS servers jumps to 33 percent. 

This is why the DROWN attack is such a huge problem for current cyber security measures. A system with an incredibly sophisticated encryption protocol can still be compromised if it communicated with a server that supports SSLv2.

What does this say about open source?

The reason that hackers were able to discover vulnerabilities in SSLv2 had to do with the fact that the protocol is contained within the OpenSSL software library. SSLv2 is open sourced, which means anyone can look at the source code and tool around with it. This is great for educational purposes, as it allows encryption experts to comb through lines of code to help plug holes. However, it also means more nefarious individuals get the chance to root around and discover vulnerabilities they could then exploit. 

A great example of open source gone awry is the Heartbleed vulnerability found in SSL-TLS encryption. Trend Micro security experts have spent a good deal of time analyzing this exploitation and have concluded it to be a major problem. Heartbleed also relied on the open sourced nature of OpenSSL, with hackers utilizing bugs in vulnerable versions of encryption software to access a system's memory. If done correctly, this allowed the cyber criminal to gain access to logins and passwords contained on the server. 

However, the worst part of this whole debacle was that Heartbleed gave hackers the ability to intercept encryption keys, thereby granting the capability to decrypt traffic. The fact that this whole transaction doesn't even leave a trace only compounds an already frightening situation, and goes to show that completely open sourcing encryption methods may not be the best idea. 

Open source is a fantastic educational too, but it needs to be done with hackers in mind. Auditing the content given to the public is an absolute necessity when it comes to encryption. Heartbleed and the more recent DROWN attacks show in no uncertain terms that letting hackers review a piece of software can only end in the discovery of exploitations. 

What can IT administrators do? 

Although the entirety of this situation may seem overwhelming, there is an extremely straightforward way to mitigate the risks of a DROWN attack on encryption within your system: don't support SSLv2. This protocol is old and obviously broken, and as such administrators need to recognize what kind of risk they run if they decide to support it. Users of OpenSSL 1.0.2 and OpenSSL 1.0.1 should upgrade to 1.0.2g and 1.0.1s., respectively. 

What's more, IT officials need to make sure that keys aren't reused by servers that once supported SSLv2. This runs the risk of using a key that has already been compromised by a hacker, therefore defeating the purpose of using newer forms of encryption. There are obviously certain advantages to reusing keys within a system, but the ever-present possibility of a cyberattack is infinitely more pertinent than any of them. As such, it's best to simply avoid the problem altogether and stick to completely unique keys. 

Encryption is too important to simply hand the keys over to cyber criminals and other nefarious parties. Server administrators need to take an active role in defeating techniques like DROWN in order to cut the problem off at the source. 

from Trend Micro Simply Security http://ift.tt/1MuNzYv
via IFTTT