Security Summer School

User Tools

Site Tools

session:extra:heartbleed-poc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
session:extra:heartbleed-poc [2014/07/31 11:37]
vladum [Information Leak Attacks] 		session:extra:heartbleed-poc [2020/07/19 12:49] (current)
Line 1: Line 1:
-= Extra - Heartbleed PoC+====== 0x0Cb. Heartbleed Proof of Concept ======
  
-== Information Leak+===== Information Leak =====
  
 In the context of binary exploitation, information leakage attacks are based on bugs such as integers overflows, or unchecked bounds, and can be used to leak the memory contents of a process. Using this kind of attack we can overcome some protection mechanism that we just studied. We could leak stack canaries and then use them to successfully overflow the stack, or we could leak addresses from the stack or other structures, thus defeating ASLR. In the context of binary exploitation, information leakage attacks are based on bugs such as integers overflows, or unchecked bounds, and can be used to leak the memory contents of a process. Using this kind of attack we can overcome some protection mechanism that we just studied. We could leak stack canaries and then use them to successfully overflow the stack, or we could leak addresses from the stack or other structures, thus defeating ASLR.
Line 13: Line 13:
   * personal identifiable information (e.g., credit card numbers)   * personal identifiable information (e.g., credit card numbers)
  
-This section will walk you through a Proof-of-Concept that will let us leak a normal user's session cookie. +This section will go through a Proof-of-Concept exploit that will enable us to leak a normal user's session cookie for a vulnerable server (localhost). 
-== Environment Setup+===== Environment Setup =====
  
-We are going to setup a minimal vulnerable environment to experiment with the exploit. We need a vulnerable OpenSSL version and a webserver. We also need to configure a basic website that will just serve a static page.+To setup a minimal environment, we need a vulnerable OpenSSL version and a webserver. We also need to configure a basic website that will just serve a static page.
  
-=== Download Nginx & OpenSSL+==== Download Nginx & OpenSSL ====
  
   * [[https://www.openssl.org/source/openssl-1.0.1f.tar.gz|OpenSSL 1.0.1f Source]]   * [[https://www.openssl.org/source/openssl-1.0.1f.tar.gz|OpenSSL 1.0.1f Source]]
   * [[http://nginx.org/download/nginx-1.6.0.tar.gz|Nginx 1.6.0 Source]]   * [[http://nginx.org/download/nginx-1.6.0.tar.gz|Nginx 1.6.0 Source]]
  
-=== Compile Nginx & vulnerable OpenSSL+==== Compile Nginx & vulnerable OpenSSL ====
  
 <code bash> <code bash>
Line 51: Line 51:
  
 **Continue from here if your Perl version is older than 5.18.X.** **Continue from here if your Perl version is older than 5.18.X.**
 +
 +Note that we are only building Nginx, which will take care of running ''make'' in the OpenSSL directory for us.
  
 <code text> <code text>
Line 70: Line 72:
 </code> </code>
  
-=== Basic SSL website+==== Basic SSL website ====
  
 Prepare a self-signed certificate: Prepare a self-signed certificate:
Line 118: Line 120:
 sudo chown vladum: /usr/share/nginx/www sudo chown vladum: /usr/share/nginx/www
 echo “Hello” > /usr/share/nginx/www/index.html echo “Hello” > /usr/share/nginx/www/index.html
 +</code>
 +
 +Start the server:
 +
 +<code bash>
 +~$ ~/vuln/sbin/nginx
 </code> </code>
  
 You should see the page live at https://127.0.0.1:11443. Ignore the certificate warning. You should see the page live at https://127.0.0.1:11443. Ignore the certificate warning.
  
-== Vulnerability+===== Vulnerability =====
  
 General information about this vulnerability can be obtained from [[http://heartbleed.com/|this website]]. General information about this vulnerability can be obtained from [[http://heartbleed.com/|this website]].
  
-The TLS Heartbeat protocol extension (see [[http://tools.ietf.org/html/rfc6520|RFC 6520]] specifies a keep-alive functionality between a TLS client and server that uses 2 messages: a request and the response. The RFC mandates the following:+The TLS Heartbeat protocol extension (see [[http://tools.ietf.org/html/rfc6520|RFC 6520]]) specifies a keep-alive functionality between a TLS client and server that uses 2 messages: a request and the response. The RFC mandates the following:
  
 <code text> <code text>
Line 172: Line 180:
 If the attacker sends a ''payload'', but a bogus, big, ''payload_length'', the vulnerable routine will copy past the end of the buffer and leak memory contents. Since the ''payload_length'' field is represented on 2 bytes, 64KB can be leaked. If the attacker sends a ''payload'', but a bogus, big, ''payload_length'', the vulnerable routine will copy past the end of the buffer and leak memory contents. Since the ''payload_length'' field is represented on 2 bytes, 64KB can be leaked.
  
-== Exploit+===== Exploit =====
  
 A TLS channel is established after the initial handshake part of the protocol. Since the Heartbeat RFC specifies the a Heartbeat Request can be send at any time, we simply have to initiate a TLS connection with a ''ClientHello'' message (first step of the handshake), and the send the bogus Heartbeat Request. A TLS channel is established after the initial handshake part of the protocol. Since the Heartbeat RFC specifies the a Heartbeat Request can be send at any time, we simply have to initiate a TLS connection with a ''ClientHello'' message (first step of the handshake), and the send the bogus Heartbeat Request.
session/extra/heartbleed-poc.1406795862.txt.gz · Last modified: 2014/07/31 11:37 by vladum

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki