A Brief History Of OpenSSL Vulnerabilities

OpenSSL has been around since 2002 and like all software in existence, it’s had its share of bugs and vulnerabilities. In this blog, we give an overview of OpenSSL, then walk through some of the major OpenSSL vulnerabilities that have affected it over the years.

Broad Overview of OpenSSL 

The business world and personal communications world depend heavily on OpenSSL and encryption technologies. Anytime there’s a major vulnerability, it affects millions, potentially billions, of users worldwide. Company assets may be vulnerable and confidentiality also becomes compromised – this happened more than once within the last 3 years.

Major OpenSSL Vulnerabilities

OpenLogic pays very close attention to OpenSSL and we are always keeping our eyes out for vulnerabilities in the platform. Below you will find some of the major CVEs for OpenSSL through the years, including info on Heartbleed, Bar Mitzvah, POODLE, Logjam, and FREAK.

Heartbleed

In April 2014, the infamous Heartbleed bug (CVE-2014-0160) was discovered. This exploit targets private keys which utilized TLS v1.2. Attackers used the exploit to retrieve data in application memory by requesting up to 64KB per attempt until a full private key, user login information, or any other confidential data was identified. This exploit can be utilized on OpenSSL clients or servers and should be treated as critical given the fact that private keys can be compromised. Patching OpenSSL to the most recent version at the time solved the issue, but for some organizations this is easier said than done. The site heartbleed.com provides a detailed analysis of the vulnerability. This vulnerability was fixed with OpenSSL 1.0.1g, and none of the previous branches were vulnerable.

Bar Mitzvah

Also in 2014, it was discovered that a 13-year-old vulnerability in SSL/TLS allowed attackers to sniff credentials and other information during SSL sessions, giving the attack the name of Bar Mitzvah Attack. The availability and the relatively weak RC4 encryption algorithm allowed attackers to repeatedly request encrypted data until a weak key pattern allows recovery of bits and pieces of plaintext information. The remediation for this vulnerability was to remove RC4 ciphers from your TLS configuration. It was also cited that many servers default to RC4 for performance reasons, despite researchers having pointed out the vulnerabilities as far back as 2001. The full paper titled “Weaknesses in the Key Scheduling Algorithm of RC4” is available online.

POODLE

In October of 2014, Google researchers Bodo Möller, Thai Duong, and Krzysztof Kotowicz discovered a vulnerability which allowed man-in-the-middle attackers to exploit a software client falling back to SSL 3.0 and weaknesses in RC4 to leak data repeated in the encrypted stream, such as secure cookies. Server configurations needed to eliminate the use of SSLv3 altogether to patch this vulnerability. Aptly named POODLE (CVE-2014-3566), which stands for “Padding Oracle On Downgraded Legacy Encryption”, it was not considered as serious as the Heartbleed bug. Shortly after this vulnerability was discovered, a similar exploit was discovered in the TLS protocol as well. Mozilla wrote a great blog about the attack and also provided the community with an SSL configuration generator to help people make sure their own configurations were secure.

Logjam

It was in May of 2015 when tens of thousands of HTTPS protected websites, mail servers, and other internet services were discovered vulnerable to a new type of attack dubbed Logjam. The flaw was found in the Transport Layer Security protocol used to establish encrypted connections with servers and clients. The vulnerability was in legacy support for small and weak key sizes in the Diffie-Hellman key exchange, normally used to increase security by updating keys in the middle of an encrypted session. US Government export regulations in the 1990’s restricted encryption key sizes and strength in software to be used outside of the US, making it within the realm of possibility to break the encryption used by foreign entities. The combination of legacy support for the ability to use these weak key sizes and increases in processing power has made them relatively easy to decrypt, if a connection can be forced to use weak keys as in the Logjam attack. Ars Technica wrote a detailed piece containing more context than we have room for in this post. The vulnerability was patched in OpenSSL 1.0.2b, 1.0.1n, 1.0.0s and 0.9.8zg.

FREAK

Just months prior to Logjam being disclosed, it was discovered in March 2015 that Android and iOS devices had a flaw over a decade old that made it possible for attackers to decrypt HTTPS traffic traveling from the Android/Apple device to millions of websites. The vulnerability called FREAK (CVE-2015-0204) forced the mobile devices to drop down to a lower grade of encryption when negotiating communications with websites, which made decrypting the traffic much easier for the attackers. Similar to Logjam, this attack was enabled by the weak “export-grade” encryption previously required by the US government in the 1990s, but with the RSA algorithm instead of the Diffie-Hellman algorithm involved in Logjam. The impact of this vulnerability showed that both the users and servers were impacted due to weak “export” encryption required by the US government. The fix for this vulnerability actually came from the companies of browsers like Chrome, Firefox, and Internet Explorer. Users were encouraged to upgrade their browsers as soon as the vulnerability was discovered and the browser had put out a new patched version.

CVE-2016-0701

It didn’t take long for the newest vulnerability to be discovered in January of this year. The OpenSSL team and maintainers have recently fixed a high-severity vulnerability (CVE-2016-0701) that made it possible for attackers to obtain the SSL key file used for decrypting communications over the transport layer. The vulnerability requires a variety of conditions to be met in order for the exploit to work, but if those conditions are met, the potential impact is high. Fortunately, the vulnerability only affects the 1.0.2 branch of OpenSSL but that does not make it any less dangerous to organizations.

The vulnerability is once again caused by a flaw in the Diffie-Hellman key exchange. Applications that use this key exchange are forced to use groups based on the digital signature algorithm to generate ephemeral keys. The default settings use the same private exponent for the life of the server process. Because this never changes, it makes the key vulnerable to a recovery attack. This vulnerability occurs in any server using a static Diffie-Hellman cipher suite. Attackers begin by sending large quantities of handshake requests to the server/client. As these requests are processed, partial secret values are revealed and the Chinese remainder theorem can be used to reduce the work in finding the rest of the decryption key.

Final Thoughts

The biggest take away we want our customers to get from all of this information, is that it is extremely important to not only keep your OpenSSL packages up to date, but to also understand what ciphers and levels of encryption your server is using. Only a properly tuned SSL configuration can protect you from all the vulnerabilities that come with OpenSSL. As such an important tool for all organizations, it deserves the same level of respect you give to securing your own home or possessions.

Mozilla has created an SSL configuration generator that you can use for free to generate a hardened and secure configuration of your servers. You can also see if your own server is vulnerable over at www.ssllabs.com/ssltest, just be sure to check the box that prevents your results from being posted publicly. If you don’t wish to use such a public tool, there’s also a nifty BASH script you can use over at testssl.sh that will allow for a more discrete internal test.

Get Guidance on OpenSSL

And remember, your friendly Architects at OpenLogic are always here to help with all your OpenSSL needs.

CONNECT WITH US

Co-authored by:

John Saboe

John is an enterprise architect on the OSS Support team at OpenLogic. John has over 10 years of experience working in technology, including software development, application security, embedded and real time software, networks and protocols, software architecture, training, R&D, and technical leadership. His most recent focus has been on enterprise Java applications, open source messaging frameworks, and security.

Andrew Pomponio

Andrew is an associate enterprise architect on the OSS Support team at OpenLogic. His areas of specialization include networking, Linux, network security including OpenSSL and operational troubleshooting. He has been working in the industry for three years and is acquiring new skills every day.