Global companies aren't quick to patch “high” severity flaw in OpenSSLFriday, May 27, 2016
Yet another Padding Oracle flaw (CVE-2016-2107), allowing decrypting TLS traffic in a MITM attack, remains exploitable on the most popular web and email servers.
An official patch for another Padding Oracle security vulnerability in OpenSSL was released at the beginning of the month. According to the OpenSSL advisory, the vulnerability has a “high” severity and is described as “a MITM attacker can use a Padding Oracle attack to decrypt traffic when the connection uses an AES CBC cipher and the server support AES-NI”.
The bad news is that support of the AES CBC cipher is widely recommended for compatibility reasons, required by TLS 1.2 RFC and recommended by NIST guidelines. AES CBC cipher is also considered the strongest cipher for TLS 1.0 and TLS 1.1.
Another interesting detail is that the vulnerability was introduced as part of the security fix for Lucky 13 padding attack (CVE-2013-0169).
We made a quick and non-intrusive research to see how widespread the vulnerability currently is, and analyzed Alexa Top 10’000 most visited websites, e-commerces and social platforms for presence and exploitability of this security vulnerability.
We used our free SSL/TLS server test to automate the following checks for each company from the Alexa list:
- Website HTTPS test (port 443)
- Email server SSL, TLS and STARTTLS test (hostname/port):
|mail.company.com||25, 110, 143, 465, 587, 993, 995|
|smtp.company.com||25, 465, 587|
To our surprise, quite a lot of the most popular resources of the Internet were discovered vulnerable. Here are the results:
- Not vulnerable: 6258 (62.58%)
- Not exploitable: 1913 (19.13%)
- Vulnerable and exploitable: 1829 (18.29%)
Taking into consideration that the vulnerability can be exploited on practice and allows stealing user data, credentials, financial and personal information, such results are pretty disappointing.
We remind that the vulnerability can be easily fixed by updating your OpenSSL library and by rebooting your server afterwards.
You can test if your web or email server is vulnerable to CVE-2016-2107 here.