In the present handshake AES-256 was negotiated as the block cipher and SHA (SHA-1) was negotiated for the HMAC. N is the length of the HMAC key (which is at the time of writing for all cipher suites the length of the HMAC) and P is the length of the key for the block cipher. In TLS 1.1 CBC the key_block is chunked as follows: The first N bytes are the client_write_MAC key, the next N bytes are the server_write_MAC key, the next P bytes are the client_write key and the last P bytes are the server_write key. You can imagine the key_block as some PRF output and both parties knowing which parts of the output to use for which individual key. This key_block is then chunked into the individual keys. Both parties derive these keys from the " master secret" as the key_block. This is a good indicator that this bug might play a role in this challenge.īut what is this key_block thing we got from the incident response team? TLS 1.1 CBC uses 4 symmetric keys in total. The bug causes a buffer over-read on the server, causing it to reflect parts of its memory content in return to malicious heartbeat requests. The heartbeat extension became surprisingly well known in 2014, due to the Heartbleed bug in OpenSSL. However, the Server sent ~64000 bytes instead. The client/attacker sent 3500 bytes, the server is supposed to decrypt these messages, and reflect the contents of them. The size of the exchanged HeartbeatMessages is highly uneven. If you pay very close attention to the handshake you can see another weird thing. We can also see that the ServerRandom is: 1023047c60b420bb3321d9d47acb933dbe70399bf6c92da33af01d4fb770e98c (note that it is always 32 bytes long, the UNIX time is part of the ServerRandom). This reveals that this is indeed a TLS 1.1 connection with TLS_RSA_WITH_AES_256_CBC_SHA, no compression and the Heartbeat Extension negotiated. In the ServerHello message the server selects the parameters for the connection. Since we cannot read a lot from the messages the client is sending (in Wireshark at least), we can look at the messages the server is sending to get a better hold of what is going on. If we click at the first flight of the client, we can also see some ASCII text fragments in its messages.įurthermore we can assume that the message sent after the ChangeCipherSpec from the server is actually a TLS Finished message. Usually it transmits its ClientKeyExchange message here, then a ChangeCipherSpec message and finally its Finished message. The same is true for the second flight of the client. Usually the client is supposed to send a ClientHello in the beginning of the connection, and not encrypted handshake messages. When looking at the individual messages we can see that the message exchange looked something like this: So looking at the IP address and TCP ports we see that the attacker/client was 127.0.0.1:36674 and was talking with the Server 127.0.0.1:4433. TT TT TT TT TT TT TT TT 56 C6 D8 3A TT TT TT TT (Flag is inside of the attackers' secret message).ĦB 4F 93 6A TT TT TT TT TT TT 00 D9 F2 9B 4C B0ĢD 88 36 CF B0 CB F1 A6 7B 53 B2 00 B6 D9 DC EFĦ6 E6 2C 33 5D 89 6A 92 ED D9 7C 07 49 57 AD E1 Can you help Evil-Corp to analyze the exploit the attacker used? However they were unable to retrieve much information from the RAM, what's left is only some parts of the " key_block" of the TLS server. Without the knowledge of the secret backdoor other servers are at risk as well! The incident response team has a full packet capture of the incident and performed an emergency cold boot attack on the server to retrieve the contents of the memory (its a really important server, Evil Corp is always ready for such kinds of incidents). The hacker used some secret backdoor to bypass authentication. Somebody broke into the main server of the company, bricked the device and stole all the files! Nothing is left! This should have been impossible. You were called by the incident response team of Evil-Corp, the urgently need your help. The challenge was only solved by one team (0ops from China) during the CTF. The challenge mostly requires you to know a lot of details on how the TLS record layer and the key derivation works. I was informed that TLS challenges are quite uncommon but nevertheless I thought it would be nice to spice the competition up with something "unusual". Since I work a lot with TLS it was only natural for me to create a TLS challenge. For this years CTF I felt like creating a challenge.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |