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