HeartBleed - TryHackMe

go back / p4p1

---

Created on sat. 02 May 2020

---

---

Today I completed the HeartBleed room of tryhackme. I remember back in 2014 hearing about this vulnerability and always wanted to exploit it so here we are!

The Vulnerability

This room is particular it has an awesome section explaining the HeartBleed vulnerability, I will try and do my best explaining it as well. Being a big fan of C programming I am going to explain the more technical side of this vulnerability using the works of Sean Cassidy. His write-up was so helpful to me and I recommend you reading it as well.

To begin let's analyse how the packet was saved inside of memory after the server received it:

          
            typedef struct ssl3_record_st
              {
                int type;               /* type of record */
                unsigned int length;    /* How many bytes available */
                unsigned int off;       /* read/write offset into 'buf' */
                unsigned char *data;    /* pointer to the record data */
                unsigned char *input;   /* where the decode bytes are */
                unsigned char *comp;    /* only used with decompression - malloc()ed */
                unsigned long epoch;    /* epoch number, needed by DTLS1 */
                unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */
              } SSL3_RECORD;
          
        

We have to shift our attention to the 2nd and 4th variable. They are what's important to us currently. The length is supposed to be the length of the data we send, data is where we have the string that contains the data. The maximum length for a payload is 65535. If we provide to the server a packet of length = 65535 and a data = "\0"; so an empty data. The server will try and copy the response back like this:

          
            // payload: is the length of the data -> 65535
            // pl: is the heartbeat data from the user -> "\0"
            // bp: is the data that will be send back -> ?
            s2n(payload, bp);
            memcpy(bp, pl, payload);
          
        

Understanding this we can clearly see that the server is copying memory into the packet that is bigger than the size of our actual data. Using this we can dump the machine's data.

Reconnaissance

As per usual after deploying the machine I started with an nmap:

          
            #[p4p1@computer thm/]$ nmap x.x.x.x

            Starting Nmap 7.60 ( https://nmap.org ) at 2020-05-01 23:58 CEST
            Nmap scan report for ec2-52-16-103-211.eu-west-1.compute.amazonaws.com (x.x.x.x)
            Host is up (0.023s latency).
            Not shown: 996 closed ports
            PORT    STATE    SERVICE
            22/tcp  open     ssh
            25/tcp  filtered smtp
            111/tcp open     rpcbind
            443/tcp open     https

            Nmap done: 1 IP address (1 host up) scanned in 2.07 seconds
          
        

Seeing that https is open on port 443 I decided to see what I could do. The HeartBleed exploit is known as CVE-2014-0160 and on the exploit db page there is some source code provided! After downloading it and running dos2unix on it (to remove those shitty ^M). I was able to see the basics of what I previously explained above. A heartbeat packet is send with a bigger size that it should be:

In orange I highlighted the size of the fake hello packet, so 0x4000 or 16384 in decimal. I then decided to run the exploit to see if this approach would work.

Exploit

Running this python script I had an output like this:

I did cut out a lot of the output because it is such a mess looking at all of it and so I don't give you the answer so easily :P.

---

Thank you so much for reading! This room was a lot of fun for me and I loved geeking out over how the HeartBleed exploit works. Please share this page and look into my other posts you might find something cool.