OpenSSL is an open-source implementation of the SSL and TLS protocols. It’s a technology that’s widely used by almost every websites to encrypt web sessions, even the Apache web server that powers almost half of the websites over the Internet utilizes OpenSSL.
Heartbleed and Openssl vulnerabilities
Even with a large number of organizations using OpenSSL, OpenSSL vulnerabilities and security was mostly overlooked until the heartbleed vulnerability which was disclosed in April 2014.
Unlike other vulnerabilities in the past, heartbleed attack can steal the private/secret key of an SSL certificate without having any privileged access to the server. Keys stolen with the heartbleed vulnerability could be used to decrypt all encrypted communication between the server and client. This led to a lot of panic since any stolen private keys could be used to decrypt communication even after patching the affected openssl version/server. As a result of this, all certificates(installed on affected servers) had to be re issued with a new private key.
Audit and resolution::Heartbleed
Heartbleed vulnerability can be check from various online resources such as http://safeweb.norton.com/heartbleed .
If the server is found to be vulnerable, upgrade openssl version in the server using the corresponding package management tool, restart all services linked to openssl and re issue SSL certificates(since there is a strong possibility of the private key being stolen). It is strongly recommended to reset all credentials(that could be transferred to the server) since the data transferred during the time the server was left vulnerable can no longer be considered to be secure.
After Heartbleed
After the heartbleed vulnerability, various forks of openssl such as BoringSSL from google and LibreSSL(meant to be a drop-in replacement of OpenSSL at some point) from OpenBSD came into existence. With the prominence of OpenSSL after heartbleed, a few more openssl vulnerabilities also surfaced. These include the POODLE(Padding Oracle On Downgraded Legacy Encryption), FREAK and Logjam vulnerabilities which were caused due to vulnerabilities in older protocols(such as SSLv3) and cipher suite.
POODLE
With POODLE attack, an attacker could decrypt the content transferred over an SSLv3 connection. POODLE attacks make use of the web browsers’ and servers’ fallback to SSLv3 in case of issues with negotiating a TLS session and the attacker could in turn exploit the vulnerability in SSLv3
Audit and resolution::POODLE
POODLE vulnerability can be checked directly from a Linux/Mac terminal by verifying SSLv3 support with the following command.
openssl s_client -connect <IP/Domain_name>:-ssl3
<IP/Domain_name> = IP address of the server or domain name
= SSL port(default https port is 443)
A host that has SSLv3 disabled will return an error with handshake failure in it.
With the vulnerability being linked to SSLv3, disabling SSLv3 will take care of POODLE. Steps for disabling SSL3 varies depening on the application and can be found from https://poodle.io/servers.html
FREAK
FREAK vulnerability is the result of a bug in TLS clients which causes them to accept export-grade keys(weak 512 bit keys сайт omg). This in turn helps the attacker to recover the key and decrypt the secure communication.
Audit and resolution::FREAK
Freak vulnerability can be verified from https://tools.keycdn.com/freak .
Updating openssl version in the server to the latest version with the package manager will apply the patch FREAK patch along with all available security patches.
Logjam
Logjam attacks are similar to FREAK attacks and affects any server which supports DHE_EXPORT ciphers. Logjam attack allows an attacker to downgrade TLS connections to 512-bit export-grade cryptography which in turn allows the attacker to manipulate the data over the connection.
Audit and resolution::Logjam
As with FREAK attacks, logjam attacks also depend on server and client. Logjam vulnerability can be verified from https://weakdh.org/sysadmin.html
In order to patch an affected server::
1. Generate a 2048 bit DH key and set DH parameters manually
2. Specify supported cipher suites explicitly
The steps mentioned varies depending on the application being used and can be found from https://weakdh.org/sysadmin.html
