You make my heart bleed, baby…

A write-up about one of the most critical vulnerability in SSL/TLS architecture

SSL or TLS, which stands for Secure Sockets Layer and Transport Layer Security respectively, is the architecture around which the security of the majority of web was built. Before these protocols were developed, most of the communication over the internet was not very secure, that is, it was mostly carried out in clear text. So insecure infact that anyone with a packet sniffer or packet capturing device, could easily capture the little data-transporting vessels and tell what communication is being carried out among the parties. Sounds scary, right? It was. And thus, the SSL was born, with its public (asymmetric) key encryption and CA issued certificates. It sounds fancy, so it must be the answer to our security woes. Not quite!

This article intends to explain why that was not the case. I believe in the power of trilogies, thus this article is divided into 3 parts:

• First part gives a brief introduction about how SSL/TLS works
• Second part gives a thorough explanation of the vulnerability
• Third part gives a bit of an intro into how the vulnerability can be exploited

Disclaimer: I do not, absolutely, directly or indirectly, actively or passively, or any -ly that I do not have knowledge about or mentioned here, endorse, support or intend the use of this knowledge for any criminal, malicious or otherwise ill-meaning activities. This is strictly for educational purposes only!

For the purpose of simplicity, I will be using SSL/TLS interchangeably in this article (though they are a little bit different)

So now we have that out of the way, lets dive in!

Part 1: What the hell is SSL/TLS?

Now, as I told you that the pre-SSL era was pretty much all clear text communication. And one more issue was that how the receiving party be sure that the message is sent from the actual sender? Thus, the Secure Socket Layer protocol was developed to guarantee the following 3 things:

• No one has read the message (Ensuring confidentiality)
• No one has modified the message (Ensuring integrity)
• The verification of the identity of the sender (Ensuring Authenticity)

The first iteration, SSL v1.0, was developed in 1995 by Netscape. However, owing to the plethora of security vulnerabilities, it was not released to the public. Thus, SSL v2 and SSL v3 released (in consecutive years) which were not riddled with the same issues and bugs and were “safe enough” to release.

Fast forward to a couple of years, and TLS 1.2 was the first large-scale and a relatively secure protocol to be used by several parties and organizations around the world. The current version of TLS is v1.3, which was released in 2018. Most of your day-to-day websites, including Facebook, Twitter, Gmail support either TLS 1.2 or TLS 1.3.

Thus, SSL/TLS are somewhat the same thing. Even through the several iterations, the basic principles on which they function, remained the same.

Okay, I get what is SSL/TLS, but how do they work?

Good question.

So before we can discuss about exchanging information using TLS, there is a process called “handshake” which is done between the client (the device initiating the connection request) and the server (the machine where the website is hosted). Before going into the specific steps of that handshake, there is one thing that needs explanation and that is public-key encryption.

Public Key Encryption or PKI

Behind the scenes, SSL/TLS uses “Public Key Encryption” for encrypting and authenticating the messages to and from the client and server. Thus, it is important to get a bit of understanding how it works.

Consider 2 people, Alice and Bob. They both have a pair of keys, called “public” and “private” respectively.

Now Alice wants to send some information over to Bob securely, such that no one other than Bob can read it. So what does she do. She asks Bob for his public key (and Bob hands it over without an issue, since its public anyways!)

Finally, Alice “encrypts” the information she wants to send Bob with his public key, such that only Bob can “decrypt” that information with his private key

So this is the basic principle of public-key encryption. You encrypt with the public and you decrypt with the private (mostly).

Back to SSL/TLS

In the context of SSL/TLS, Alice can be considered as the client, and Bob can be considered the server.

So lets go through the steps of the handshake:

1. Client Hello: The client sends the things it supports (protocols, encryption standards, version of SSL/TLS, etc.) to the server. This is important since some clients are running old software, which support old standards and older version of SSL/TLS, and some are running newer, updated technologies. Thus, the client needs to tell the servers what its supports.

2. Server Hello: The server decides which algorithm and which version of TLS will it use to communicate with the client, and it lets the client know.

3. Sever Key Exchange: The server sends its public-key (in the form of a certificate) to the client. A certificate is just a formal document, that is signed by a Certificate Authority (so as to certify that the public key belongs to the website). This is how the client knows which key to encrypt the data with.

4. Server Hello Done: Server tells the client that it is done sending the information to the client and is waiting on the client to send some info to the server. You can think of this step as a soldier saying “Over!” after finishing what he has to say while communicating over a walkie-talkie.

5. Client Key Exchange: The communication up until this point was clear-text. But now, the client and the server need to communicate a single (symmetric) key using which they will encrypt and decrypt all the data beyond this step. This master key will be sent from the client to the server, encrypted with the server’s public key.

Reason for using a single key or symmetric encryption is that it offers faster encryption time than public-key encryption (which is significantly slower). Thus this whole process was just to securely exchange this secret, master key between the client and the server (process known as the Key-Exchange)

6. Change Cipher Spec: Now both the server and the client shift the communication from the plain-text, unencrypted channel, to encrypted channel.

7. Encrypted Handshake: This steps verifies that the key exchange process has taken place successfully, and the master key is correctly communicated between the client and the server (since they are able to encrypt and decrypt each other mesgs)

Once this is all done, a padlock will appear before the website name as shown below:

Part 2: Oh man! Enough about SSL/TLS! I need my vulnerability!!

Now that we have a basic idea of how SSL/TLS functions, lets move on to discussing the actual thing everyone is interested in, and that is “HeartBleed”

Background

In order to provide web servers and browsers, the ability to use SSL/TLS while communicating, the developers of the application use an implementation of the SSL/TLS protocol. Usually, this implementation is in the form of a library. The most common library is the OpenSSL. An open-source, cross-platform and community driven library used for implementing SSL functionality in a web-server. HeartBleed was a vulnerability in this library, specifically OpenSSL v1.0.1 and some beta releases of v1.0.2.

As mentioned, this vulnerability was not a vulnerability of the protocol, rather the implementation. This existed in a single feature of the OpenSSL library, known as Heartbeat (so now you know where the name came from).

Heartbeat allows an SSL session to remain active even when there is no data exchange taking place. It achieves this by sending a specially crafted request between the client and the server, after a set interval of time. This request can be initiated at either the server or the client end and also generates a response, and thus can also be used to check if the peer at the other end is up and running, or not.

As with all requests, heartbeat consists of 2 things:

• Request Header
• Request Payload

The request header contains information such as source IP address, protocol used and the request payload size information.

The request payload includes the actual data that is being transferred between the parties.

Below is the screenshot of a non-malicious heartbeat request

Now when this request is sent to the server, it generates a response with the same payload that came with the heartbeat request.

Vulnerability

Now, the vulnerability that existed is that whenever OpenSSL received a heartbeat request, it sent back the response payload equal to the size of payload that is mentioned in the request header. It did not verify the actual size of the payload. Thus, a possibility exists that a heartbeat request is sent, in which the actual size of the payload is quite small (lets say a single byte) and size of payload in the request header is specifed to be significantly larger! (e.g. 65535 bytes)

In response to this request, OpenSSL v1.0.1 will generate a response with a payload of 65535 bytes instead of a single byte. Now, we know that the request payload only contained a single byte. Thus, where the remaining 65534 bytes come from you ask? They come from the machines memory!

Now these 65534 bytes could contain anything from username/passwords, to secret keys of other people communicating with the server. And the best part? The attacker can launch several requests in a row to get as much secrets as they want, and the server will happily oblige with their requests!

HeartBleed, is listed in the Common Vulnerabilities and Exploits Database as CVE-2014–0160. According to a safe estimate, this vulnerability affected around half a million servers all around the globe.

Now the fix is seemingly simple. To verify that the size of the request payload matches with the size mentioned in the header.

Part 3: Damn! That was scary af! Now, can I exploit this somehow hmmm…

Well, since this vulnerability was identified in 2014, and it had such a large impact, thus the developers were quick in rolling out a fix and the vendors and service providers quickly upgraded their systems, to patch this vulnerability. Thus, majority of the large scale service providers such as Facebook and Gmail have already fixed this vulnerability well before this article was written.

However, nowadays you can find free scanners online that will run tests against the website to test if its vulnerable to HeartBleed.

One such example is this scanner from Norton (https://safeweb.norton.com/heartbleed) which will check the website for the vulnerability and report back if the vulnerability exists.

If you don’t trust the online scanners (for valid reasons) then there are a plethora of scripts available, in several languages including Python, Go, etc. to test the vulnerability. This one (https://github.com/mpgn/heartbleed-PoC) is a comprehensive script written in Python that offers several helpful options.

I ran it against Facebook and it gave me the following result:

Nmap, a popular tool for reconnaisance, port and vulnerability scanning, includes a LUA script for testing with its base installation by the name of ssl-heartbleed.nse. You can run the script using the following command:nmap -sV -p 443 --script=ssl-heartbleed.nse 192.168.1.1

If the scanned website is vulnerable, it will give output in the following format:Nmap scan report for mediacentre (192.168.1.5)
Host is up (0.0059s latency).
Not shown: 992 closed ports
PORT STATE SERVICE VERSION
443/tcp open ssl OpenSSL (SSLv3)
| ssl-heartbleed:
| VULNERABLE:
| The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption.
| State: VULNERABLE
| Risk factor: High
| Description:
| OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
|
| References:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
| http://www.openssl.org/news/secadv_20140407.txt
|_ http://cvedetails.com/cve/2014-0160/
Service Info: Host: firefly003; OS: Linux; CPE: cpe:/o:linux:linux_kernel

If we run the script against an invulnerable server (such as Facebook, Gmail, etc.) , it will give the following output:Starting Nmap 7.60 ( https://nmap.org ) at 2020-05-27 16:31 UTC
Nmap scan report for www.facebook.com (157.240.13.35)
Host is up (0.00056s latency).
Other addresses for www.facebook.com (not scanned): 2a03:2880:f10c:283:face:b00c:0:25de
rDNS record for 157.240.13.35: edge-star-mini-shv-02-sin6.facebook.comPORT STATE SERVICE VERSION
443/tcp filtered httpsService detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.95 seconds

You can also code your own script easily in Python. All you need is some basic scripting knowledge and some knowledge about crafting request with Python (just google requests library python)

Conclusion

So this was a small rundown on the vulnerability that impacted half a million servers. Mind you, this was not the only large-scale and high-impact vulnerability in the SSL implementations. Some such examples include:

• ShellShock
• POODLE

I will try to cover these vulnerabilities in my future articles! For now, thank you so much for reading!!