I have the web application which is
here and there are
many incoming requests many
actually concurrent incoming requests.
To this web application and this
requests are about to transfer $10
from one account to another account. This
is exactly what I presented to you in
the demo. So this is my multifred attack
actually, right?
And now I've got the money transfer requests
and let's assume that the for
example free requests have
already been accepted. Okay, so I've
got free money transfer requests that have
already been accepted and let me explain to you what it actually means.
So when you've got money transfer requests, then
the web application has to check whether you've
got enough money to you know, make this financial
transaction and if you've got enough money, then
the money transfer requests are gonna be
accepted. So these three guys and they are
waiting to be processed. Okay. So this is what I mean by
saying money transfer requests
that are accepted.
Okay, but what more we're gonna
have in the story is we're gonna have the fourth request
as well.
Let it be the four request here. And this
request here is where the financial
transaction is actually being made. So
what we've got is the requests there
are that are accepted and there are waiting to
be processed and we've got one request
here that has already been accepted but this is
actually where my financial transaction is
being made. So this is a kind of distinction between
this guy and this free guys
here, okay.
So far so good.
So what's gonna happen in in my attack?
Is that the balance
sooner or later will go to zero. My
attack is about sending
ten dollars and ten dollars
and so on many times right 10 dollars
ten dollars from one account to
another account. So sooner or later the balance
indeed will be zero. Now. Let's
assume that once this guy is
a processed. So once this financial transaction
is being made then the
balance is updated and the
balance is actually zero. Okay, let's assume something
like this. So when the balance is
zero here, we've got some really interesting condition
here because
the balance is right now zero, so
it basically means that well, I cannot
send more money from my
Sound because the balance is zero.
But please notice that there are
free money transfer requests that
have already been accepted.
So we've got really strange situation from
one point of view. The balance is zero. So no more
money should be you know, we've run
or transferred from my account but on the
other hand.
Free and Money Transfer requests now have
already been accepted and this guys will
be processed even further because they have been accepted
before the balance went to
zero and this three guys here.
Are actually responsible for stealing more
money from a bank. This is
actually how race condition works. Now. Let
me tell you one why we've got a race condition here.
Well indeed, we've got the race because the question
is like this how many threads are
gonna be accepted right
how many money transfer requests are
gonna be accepted before the balance
goes to zero. That's the question and the more
money transfer requests gonna be accepted before
the balance goes to zero the more money the
attacker can still from the bank,
right? This is how it works. This is a race who's gonna
be faster, right? And the number
of money transfer requests that
are gonna be accepted before the bonds goes
to zero. Well is is dependent on
many different things. That's why this attack
is non-deterministic what I mean,
Here is that the network performance has an
impact on this attack the performance
of the machine where the web application is hosted.
It has also, you know impact on
this attack think about swapping right when we've got
a swapping on the machine where your web application
is hosted. It also has an impact of on this
attack and this attack is about concurrency multi-threading
and fractions of
milliseconds. So you see that this is indeed a
race.
And yeah, now this is this is
how it works and I believe that this is clear for you.
But let me also tell you how to prevent it from
happening because this is also interesting. Well, what
we should do is we should
never accept the next
money transfer request before the
money transaction
request. The previous one is being finished.
Okay. So first what we should have is
this guy should finish then
the balance should be updated. And once
the balance is updated then we should accept
the new
Incoming money transfer request right?
And then we are guaranteed that
race condition will not happen. So one
thread at a time when you
are here making a transaction then let's
do it. Let's finish it. Then let's
update the balance then check
the balance and then allow or
disallow the next fret the
next and Money Transfer request. Okay. So one
fret at the time only in the system would
prevent this attack from happening.
So I believe that this is clear for you. And if you
gonna implement this country measure then I
recommend you to implement actually the transactions
in the databases because this is gonna solve
your problems, okay?
So I believe that this is clear for you.
Let me right now go to the slides and let
me wrap up what I presented here.
So I used many concurrent requests.
To transfer $10 from one
account to another account and I
presented to you that the
race condition happens when money
transfer requests are accepted
faster than financial transactions
are being made, right? This is what I
actually try to explain to you on the Whiteboard
and when the balance goes
to zero, there are still a
few money transfer requests already accepted
once that are waiting
to be processed. So this is how
we can actually still money from
a bank via race condition. And finally
I presented to you, you know,
a kind of high level overview of the Canter measure for this
attack because you definitely don't
want this attack to have an impact
on your own systems. So I also
Question transactions and how to fix the the problem
that I discussed here. Okay. So I believe
that you really like this case and you see the
power of race condition exploitation. So we
are right now done with this case and in
the next one in the case number
two, I will dive even more into race
condition exploitation and we're gonna have even more fun
with this kind of attack. So yeah, we
are done with this case. So let's right now jump to
the next one.