As many are aware (as it’s now become national news), a vulnerability was recently discovered in OpenSSL dubbed Heartbleed. The attack centers around the implementation of the Heartbeat extension in OpenSSL which causes a server to return the contents of memory that should be protected. This blogpost by Troy Hunt describes the vulnerability in detail: Everything you need to know about the Heartbleed SSL bug.
Being packet geeks, naturally we wanted to get a capture of the Heartbleed attack in action. To do this, we ran a Heartbleed attack against a CloudShark server that we configured to be vulnerable to this attack and used a slightly modified version of the Heartbleed Test to attack it.
You can view the Encrypted packet capture of the attack in CloudShark here:
https://www.cloudshark.org/captures/42cb5bf2ed80.
You can view a Decrypted packet capture of the attack in CloudShark here:
https://www.cloudshark.org/captures/f54b25932509.
We’ve included our analysis in the packet annotations.
First examine the Encrypted Heartbeat message we sent which causes the server to return sensitive information. Look at the Decrypted SSL Record in the Encrypted Heartbeat message. The first byte here (0x01) indicates the type of Heartbeat message, in this case a Heartbeat request. The next two bytes (0x03fd) indicate the length of the Heartbeat messages payload. In this case we have set this to be 1021 bytes, however, this is larger than the actual length of the payload we are sending.
Now examine how the server responds to this message. In the Heartbeat response the server must return the message that it received in the request. Our server is responding with a Heartbeat payload with 1021 bytes in it. We said we were going to send 1021 bytes but our message was actually smaller. What is the server sending to make up for the difference?
When you examine the decrypted SSL record our server sent you can see that it responded with the payload we sent, plus the HTTP headers from a user that logged in completely independent of this SSL session. This includes the login and password that was used to login and the session id! In this case we can see that the admin user is logging in with the default cloudshark password.
That’s all there is to it. We figured people might be interested in seeing an actual capture of the issue and the attack.
Want articles like this delievered right to your inbox?
No spam, just good networking
