Heartbleed, Running the Code - Computerphile

Key Takeaways

so on the 8th of April 2014 a security advisory was released on the Internet by people at Google and other places that they discovered a bug in a package called op SSL one problem with a package like op SSL is that being so pervasive if a bug does get into it then it'll filter out onto lots and lots of machines so to understand this heart bleed bug we actually need to understand in detail how the heartbeat protocol works so let's move into the office and actually understand how heartbeat works like all internet protocols these are defined in the request for comments or rfc's and if you look down here there'll be a link to where you can download this one and you can go from there to find anyone there's a heartbeat request which we send out and there's a heartbeat response which comes back from the other side they're made up of three or four things we've got this type field and this can either be a value of one which means request a heartbeat or a value of two which means I'm sending a response to a request that you've actually sent we then have this payload and this can be anything the person requesting the heartbeat likes it's just some unique value doesn't even have to be unique but it helps if it is that they send to the server and the server when it responds sends back exactly the same response there finally we have what's called some padding and this is at least 16 bytes of random data which just bulks out the actual message that's sent it's ignored by the other side but it's there as part of the protocol what this means though is that even though we know how big the message is we don't know how big the payload is unless we actually send over the length of it because we don't know how long the padding is either so we also send over before we send the payload two bytes which gives us the payload length which means a payload can be anything up to 65,536 bytes in length and that all gets send as part of the request and the server's job is to copy that payload create a response message around it and send it back to me to tell me that it's met that response and if we just look down here at the bottom it says if the payload length of a received heartbeat message is too large the received heartbeat message must be discarded silently what that means is if I send you a message where the payload length doesn't make sense for example it's greater than the actual length of the message then the server is meant to ignore that message M completely not try and presses it and send a response because it doesn't make sense and it's that handling of that situation that causes the heart bleed bug in op SSL op SSL is written in C and so we're going to look at the code here but I'll walk you through it so if you're not familiar with the c language we should be able to follow it without any issues so I've opened up a file here called T1 lib which is the file that contains the implementation of the heartbeat extension if we scroll right down to the bottom of the file we find that there are a couple of functions that implement the heartbeat protocol first one I'm going to look at is this one called TLS oneor heartbeat which is actually the responsible for sending the messages out over the connection it does some checking to check there's no heartbeat already being sent and then we come to this bit of code which actually generates the message there's no problem with this code it's generating the message in the way that makes sense it's allocating memory here of the right length it's putting in the relevant bites it's saying it's a request message this is how big the pay Lo is it's 18 bytes long it's generating the payload and it's sending its random padding bytes out over and then we can see here it calls SSL 3 right bites to send that out over the netcor connection to the other side so that's all fine there doesn't seem to be any problems with that if we scroll up a bit we come to the code which processes the heartbeat and that's in a function called tls1 process heartbeat and what this does it gets sent a message that's been received from the other side and it starts pressing that to see whether it's a valid heartbeat request and if it is it will generate the response to the other side so it reads in from the package the heartbeat type and it also extracts out the payload length from there now one of the things you have to do when dealing with network protocols is that there is a defined method for how data is sent over the network and that is what's called a big endian way of transmitting things PC computers tend to be little endian and so on so you sometimes have to convert between it so that's why we have this function Network to short here which does that conversion for us so we get the length of the payload there's then some more code which does some test and then we say if we've got a heartbeat request message we're going to process that and so it's going to generate the response so the first thing it does is it allocates memory for the response message and so that's one bite for the type in this case it's it's a heartbeat response two bytes for the length of the payload then however many btes are required for the payload and remember it's read that from the actual packet that's come in and it then creates its padding in this case it's going to generate 16 bytes again so allocates that memory and assuming that gets allocated properly it starts to fill in those details so it's saying here that I want a response message and so it says that's the type and it sets the payload in there again and again it's having to convert it from the computer's type into the network type so it's in the standardized format so it's putting payload byes in there so that's the value it read in and then it uses this function here mem copy which just copies a block of memory from one location to another to copy payload number of bytes from the original message which had the payload in it it then adds the padding and sends the data out over the network well what's the problem with that that code works and it works fine providing the packets that are sent are standard the problem comes the heart bleed Burg as it is comes if the packet that we send isn't standard is is crafted maliciously and in particular the key problem is this payload length that we use to copy the btes from one memory location to another we read that in from the packet that we sent and so if we create a packet that has a p Lo say of 64k 65,536 bytes but only actually provides say 8 bytes of data when it starts to copy things it's going to copy those eight bytes of data but this M Copy instruction here is going to carry on copying for another 65528 worth of bytes now where are those extra bytes going to come from well they're going to come from whatever follows on in memory in the computer's memory that's there if we're lucky that data will be meaningless it'll be garbage that's been left in there it doesn't make any sense but it could also be details of previous requests usernames passwords and if you're really unlucky it could be the actual security certificates used to actually encrypt the data fixing this was really easy they just added checks like it described in the RFC that the payload length made sense in the context of the length of the actual message but let's actually see what happens if we take a server that's still got the old version in see what data we can collect if we run this heart bleed bug I've set up a virtual machine running open BSD using a version that's still got the heart bleed book so if I open a new web window here I can pop to the web server this is running on the local machine and if I switch now to my command line I've also got a piece of code that I downloaded off the web and now we're not going to give you a link to this one that will actually exploit heart bed and slurp 64k of data from that server and we'll be able to look at it in the window here it's written in Python and we're going to attack the server that we've got here don't worry this is a local IP you won't be able to connect to it and if we just run that we can see the data that we've got now the data that we get back is completely random it depends where when the server received that message it put it in it own computer's memory so in this case we've not got anything interesting but if we run it again so this time when we've run it it's actually given us some useful information so what have we got here well at the top we've got some details about what's going on it's tell us that it's connected to the server that it sent some data it sent the Hello message and so on which is setting up the TLs and that it sent the heartbeat request and it's received our response now this heartbeat request has been formatted in a way that it's sent a very small amount of data but asked for a large amount of data or said it's a large amount of data so won't get sent back is about 64k is worth of memory it's then dumped this memory out to the screen so we can see what's going on so on the left hand column here we've got its position within the data its return so we start off at zero and we're increasing in hexadecimal down here so we've got 16 32 48 and so on all in hexadecimal down here up to 256 along here we have the heximal values of each of those bites and on the right hand side the asy values of them what those character is actually mean so in this bit we've got part of our heartbeat response at the top but as we look down we've actually started to get some interesting information out of the server in this case we can see what the referring URL was what encodings is accepted and we can start to see earlier things that I've been doing when I was testing this so I started to set up WordPress so we can see that someone tried to access that so it's a bit like panning for gold we stick our metaphorical save into the mud and we pull out things and we're shaking it about and occasionally all we pull out is mud just random data that we can't decipher but occasionally we pull out and we start to get that and we get those gold nuggets that were're interested it we get the passwords we get the server certificates and so on which we can use to do the various things if we were so inclined now of course you wouldn't necessarily want to do this by hand but it'd be very easy to write software that could look for these patterns and just sit there continually fetching data undetected until it found what it was looking for and everybody was going to click on that one well it turned out that um the video behind that was a person talking about the fight