Tip:
Highlight text to annotate it
X
>> TONY MIU: Today I will present you with the fruit of our research, Kill 'Em All - DDoS
protection and annihilation. First of all, I'm working in (inaudible),
a company. You can do any research you want. In here, we have our many talented people
who is spoofing us. I have a lot of creative data. I will show you how to bypass all the
solution, or the DDoS mitigation solution, and service provider.
First of all, thank you for letting us discuss this. We can come here to share the information,
some information. Some information is sensitive. First of all, here is our agenda. I will spend
about five minutes to give the background and moderation. After that, I will talk about
authentication because the authentication I will show here is the most accurate nowadays
if we can bypass it. That means we can hit the server directly. After that, we have the
live demo. We show the evidence to you guys to prove what we've done.
First of all, the size now is much larger because the Internet coverage now, the secure
system, the botnet, that means they can hack much more. We have much more. The result is
it has become much more large. Another one, the frequent attack actually I would say the
attacker only attack you in your peak hour. To give you an example of what happened in
Hong Kong, one of the stock exchange, they are under DDoS attack. The result is the whole
Hong Kong stock market stopped that date. Another one, the complexity of that attack,
the (inaudible) is expensive. So the result is that they try to make much more ‑‑
let me to give an example. I use an attack to terminate the service. Now we use 2 megabytes
per server. After that, the result is the cost ‑‑ the cost is talking about USD6 million
per hour. So let me introduce the volumetric attack. Just use one sentence. The only focus
is size. TCP, UDP, they only focus on the size.
To use in other terms, protocol‑based, application‑based, they are taking the routeness of the portal.
They are attacking the HTTP protocol and TCP protocol. They are attacking the database
API. The last one uses a DDoS attack to hide another DDoS attack.
This server may just be one megabyte per second but this attack will crash your server because
they confuse you. Your only focus is all your graphics. But you misunderstand because they
use the application attack to attack you and crash you.
First of all, we have a major thing here to show you. The matrix is the volumetric attack.
It represents attack complexity. The (inaudible). In here we see some mitigation we can use
in here. Only the basic mitigation. The most important aspect of the mitigation starts
with detaching. Because if we can ‑‑ how do we mitigate you? And then we have the
detaching here. The mainframe (inaudible). They use a ray base and full base. In here,
they show you the example. The packet per second, bit per second and what kind of attack.
Another one is protocol tracking and protocol behavior.
Protocol tracking you have to track the malware from the protocol. Protocol behavior, this
one is focused on the traffic utilization application lock. (inaudible) under the DDoS
attack. If we come together we will become the packet data analysis.
Actually we have a session. And we will show you how we attacked to bypass. First of all,
I will focus on the TCP (inaudible). We were talking about authentication bypass. I will
give an example. We can ‑‑ with the traffic pattern simulation, just like the traffic,
I will explain it later. Another one, we have the HTTP simulation. So the result is that
the traffic is seen as the normal traffic. If you stop the traffic, that means you stop
the normal traffic. First of all, we use the posse. At the program, we use in the same
connection the same user agent. When we send it out, just light, the traffic behind the
posse. In this one, when we send out the attack, you try to analyze it. You have seen the other
attack come from the posse. This one can empower the attack. Another one is actually ahead
of simulation. In this case, we show the request. I will
give you the example. The first request we send in HTTP is SS (inaudible). That means
we didn't know what we need to take. After that, the server (inaudible). The second request,
we will show you just in here. So in our tools we mitigate to do this one
just like the real traffic because the pattern is always the same. Our pattern will change
the same as the normal traffic. After that, we will focus on the TCP and power. First
of all, the TCP is against the detection. And then we try to empower. Let me show you.
How we use a TCP (inaudible), this one is an example of a slow Lotus attack. You see
after it has shipped, we send the first push ad. Why we do this one? Because after we hold
the connection, that means we can know the limitation. After we accepted the first push
(inaudible) because this one just how we extend the TCP establish status. Because if we try
to extend this one, the power would be much more strong because ‑‑ how do I say this
one? It is because if order spends much more resources. Just give you a compare.
This is an old‑fashioned HTTP attack. This kind of attempt, you can see ‑‑ the result
is that high CPU and then you keep the constant of the number of the connection. The server
has no impact, just high CPU. Can still come here. Nothing.
So how we do it? If we wish to attack, we need to do it like that. First of all, if
we ship, push out the first request. After that, don't close it. We keep sending the
push ad, I mean, the HTTP request. The result is that this time the server with high memory,
not just the high CPU, because the request of your server is high memory, high CPU.
Another thing is because we try to keep the connection, the connection keeps increasing.
After ten seconds, five seconds, your server, HTTP, server unavailable. This one is common.
Another one, we force low cache. How we do it? Just easy. We use the query string, a
question mark, after the question mark, after the (inaudible) this type of the query string,
there is a new request so they will not cache here. I try to download a large PDF and use
a Q string. The result is your bandwidth is used up.
After that, we will go to the resource authentication one by one. Authentication is the last ‑‑
we try to mitigate the attack. First I show you the TCP authentication, the TCP reset.
That one they authenticate on the TCP layout. They intercept you. Then we send an ad. This
one is the mitigation‑wise. We try to active call you. Reset means, I think the connection
is proper and I will terminate you. Other than that, we (inaudible). This is TCP
send. Another one I want to show is TCP out send. This one is a little bit tricky. When
I send a send, this is a send ad. It is wrong. What happened if the (inaudible) is wrong?
This time the (inaudible) reset the connection. After that, if you see yous source app, you
think, you are the really I.P. and now I will let you pass. So what's the difference between
the TCP reset and the TCP sync? Actually when we handle the DDoS attack we send a sing.
Because we use the spoofed I.P., what does it mean by the spoofed I.P.? That means you
will not add ‑‑ you will only send one send in this case.
The result is the same. Why they decide like that is because the officials
that use the real handlers ‑‑ to give you an example, all the packet together ‑‑
just mention, the length is different packet size because the header length, you will see
that the TCP reset is 100 (inaudible). We use bandwidth around 140. In here we find
that oh, TCP is better. Is it really better? I will show you another one.
Actually we can bypass easy to use the spoof I.P. I used a spoof I.P. Can bypass the TCP
authentication. In this case, we try to use a sing. No matter, we just send a reset again.
You send a sing again. Use this kind of methodology. 33% of the attacks can bypass it. The spoof
I.P. can Bypass a TCP authentication. The traditional ones are missing something. You
have to find some news to show you. Oh, I can mitigate 100‑gig attack. I can mitigate
200 attack, something like that, because they haven't shown you something, some secret.
Because if the TCP sing is 40 bit, we can bypass the TCP directly. TCP is not 40 bite
because the TCP sing ‑‑ because the first thing, he will try to let you know what ‑‑
I will give you an example. The SM size, he will tell you how many. So when we try to
assimilate real thing traffic again, the spoof 55 is spoiling. I drop by the TTL. Another
one, window size just will tell you what is the OS. Give you an example, make 5535, something
like that. This one also need to spoof, give an example. I spoof the Windows XP or Windows
7, something like that. If we add this one, the ISP cannot track you
easily this time. So another authentication I wish to show is HTTP redirect authentication.
In this one, we will focus on the layer 7 when the first get we send will redirect a
path. If your client can redirect that, he will ‑‑ and then we will redirect you
the first path you wanted to go. The result is dead. You can pass it. So what is the key
to bypass HTTP redirect? First of all, we need to find the attack HTTP tool because
when you capture this one, that means they have the HTTP direct. You need to do something.
The second thing, you need to ‑‑ in the same time you need to make sure to have a
location. If you find the tool, that means they actually redirect. In this time, you
just load the script and HTTP 200 means bypassed it. Because just a simple program also can
throw you. HTTP caucus in this time, this time is not
just direct. We add the cookies if the client, he can add the cookie and repipe that. He
will redirect back to the place you want to go. This time you can pass it. So what's the
key to bypass the cookies? First of all, we need to detach set cookies. If they are set
cookies, that means (inaudible). You need to copy it. And I don't think you need to
make sure ‑‑ you need to make sure they are expired. Because they are expired, now
the authentication is time based. I will give you an example. Maybe you authenticate it.
After five minutes you need to authenticate again. So this time the threshold you need
to set. (inaudible). Why? That means in time you change
the cookies so you need to do the authentication every time. You also have the enhanced one.
In this case, you will see that he will use ‑‑ HTTP header is not common. This time they
use HTTP ‑‑ in this case they use header, colon something.
But then one have the problem. It depends on the behavior. Why do we have this one?
Because if you want to disrupt a head your token, that means you have to use the API
address XHL tool. This problem is the lead is not compatible. The result is you can.
We just simulate the traffic flow. We can bypass it. And then we have the JavaScript ‑‑
actually, this one is most challenging now. Okay. We send a get. It gives you JavaScript
and it tells you to calculate something this time. If you can calculate and post a result,
it will direct you back to the page. So you can pass it.
The key to bypass the JavaScript is that, first of all, JavaScript is kind side program.
That means (inaudible). You can find a path and download it. JavaScript is human to understand.
That means you can rig it. After that, we can use a different algorithm to bypass it.
First of all, after that we can calculate a result, simulate the traffic flow and bypass
it. Another one is that we use the current department
load. Actually, we use the auto bypass. I will show you because ours is just one megabyte.
In this case, at the JavaScript engine, there is a bot. But this one has a limitation. It
is JavaScript only. You need to call it back in JavaScript and you cannot.
Another case, we use the application bundle, in this case the server in here. So every
time the CS server asks to attack, the botnet will communicate to the server. It is sent
back to the server. And then will show the calculation by this server. After that he
would give back to the (inaudible) and bypass it.
The CAPTCHA, this one I would say is the most effective and accurate. But the problem is
that they are used in every report. Sometimes people also can't understand the CAPTCHA.
Again, the JavaScript authentication, this one you use after you finish something and
post it and then we redirect that and then you can pass it.
So what is the key to bypass the CAPTCHA? I have something wrong. But nevermind.
First of all, we need to follow the path of the BMP, I mean, the auth page, just the CAPTCHA
page. Because if you can download it, that means you can use some algorithm to bypass
it. After that, the challenge is that embedded CAPTCHA and the botnet, we will use the same
method as the JavaScript. Assimilate traffic flow. Use the (inaudible) model or the (inaudible)
model. Actually, if you come to DEF CON, you will
find that there are many CAPTCHAs you can download and use in our program. So this is
the source host of our verification. First of all, (inaudible). HTTP direct and cookies
verify is it HTTP compatible? Now, JavaScript verifies you are the real browser or not.
They will try to determine if you are a real human or not. After we bypass them, we can
attack directly. >> WAI-LENG LEE: So Tony bring up very important
points that in today's detection and mitigation techniques, we have to rely on the source
host verification. And once we can ‑‑ once we can bypass these verification, we
can get to the end directly and the attack all to the backend.
So our proof of concept tool is trying to bypass these authentication. First, we try
three times because the first time expected TCP authentication, it will fail because it
will reset you or it will send a wrong sequence number to let you reset.
So the second authentication, we suppose it was a success. And the third authentication,
we are just for sure ‑‑ make sure it is correctly put our I.P. into the whitelist,
for example. And also to mitigate ‑‑ to make the attack
or the authentication more like a real user, we will have a true TCP/I.P. to apply to the
operating system, TCP/I.P. sent directly. Also, from the PoC tool, especially the cookie
authentication, the HTTP cookie will be carried on the following attack packets. Because even
you are putting into the whitelist if you don't have the cookie in the subsequent attack.
You might be blocked. Also, the JavaScript we implemented using
something like Spider Monkey or JavaScript Engine. Currently, we don't have a doom included.
But this is just a matter of time. And, finally, about the CAPTCHA, as you can
see, or in the coming video, you will see how this ‑‑ how this screen comes from.
The design is to make our attack tool sending a correct CAPTCHA back to the mitigation device.
The design is that we first convert the Kali application tool to black and white and maximize
the contrast and then apply to view out the noise and then insert into individual characters
and find the boundary of each of the character. Finally, we simply calculate the pixel difference.
You might think that this is very, very rough implementation. But it can successfully ‑‑
it can successfully CAPTCHA by more than 50%. In fact, if you want a higher rate of CAPTCHA
authentication, you need CAPTCHA library. I think DEF CON presents lots on this this
year and in the past years. After authenticate, after bypassing all the
authentication, now comes to the attack. In the attack, we have the TCP options and also
the HTTP options. What TCP option is talking about is control the timing of the TCP connections.
We can control the number of connection established to the backend server. Why the backend server?
Just because we bypass it. And we can hold the connection for enough time. As Tony mentioned,
this benefits for the slowest attack. And, also, we can handle the connection idle time
out before ‑‑ after the last HTTP request. And we can control the connection interval
in order to avoid something ‑‑ hitting a threshold of the mitigation device.
For the HTTP options, it actually is ‑‑ within the HTTP connection, there is a period
to sending multiple requests. This request ‑‑ each HTTP request is a HTTP connection. We
can control the connections and also the intervals of each connection.
And now we are showing the video. Let us see how it runs in real examples.
First of all, we look at HTTP direct. That means you can see on the left part of the
user interface the first check box. From our testing, the left side is the client
side. As you can see the client launch our demo, too. The right side is the server side,
as you can see the Web server lock. On both sides, we have a packet CAPTCHA. It is capturing
the packets. When we start launching the attack, you can see this is the authentication ‑‑
this is the authentication part. You can see because the first time this one returned a
302, so it redirected. It is a redirect authentication. So ‑‑ and you see subsequent 200 okay
for three times because as I said we're doing the authentication for three times for sure.
Now, let's see what's next. After authentication, you can see from the (inaudible) we hold for
a few seconds and send fourth request. This one you can see from the query strong. It started
with E. The next one started with N, et cetera. And the four requests are all going to the
backend. As you can see both from the server side, both the servers are Web server lot.
Next we are going to the HTTP cookie authentication. For the same setting, the testing environment,
you can also see the redirection because it requires you to send to the cookie. And also
you can see four different requests going to the backend. Yes, in the testing environment,
we use four. But in the bot environment, I don't think you in your server you will receive
four because you will have so many bots. Let us attack. One of the attack HTTP requests,
you can see, as I said, the authentication cookie is carried to the attack. There is
a cookie for you in this attack packet. Now, it goes to the JavaScript authentication.
This one we are ‑‑ this one we are using ‑‑ we are using a CDN to test. As you can see,
the JavaScript is quite sophisticated. It holds your authentication for some time. And
then it also has a cookie embedding it. And from the right side, you can see the server
side. You can see the four attacks. You can see the four attacks all goes to the backend
server after we bypass the JavaScript. Let us take a look at this one. And as you
can see, even it is a JavaScript. It also has a cookie there. And the cookie clearance
means that we are successfully bypassing the JavaScript.
And, lastly, we are showing about CAPTCHA authentication. This one be the same and you
can see from the authentication phase, the mitigation device has the CAPTCHA image, bitmap
send back. And we have the four subsequent attacks to the backend.
We are interested in whether it is really bypassing the correct CAPTCHA image. So we
pick up a packet about ‑‑ after we recognize the bitmap and send it out. You can see this
is the WMGK which match the original bitmap. We are integrating both the authentication
and the attack phase. As you can see from the video, our tools simulate
the true TCP HTTP (inaudible) through the OS TCP stack. And we have a believable HTTP
header so no matter if it is a mitigation device or it is a cloud CDN environment, it
believes our HTTP headers are true. And, also, we have embedded JavaScript Engine so that
it will not ‑‑ so that it is ‑‑ it is not bulky. It is lightweight. And also
we have our own CAPTCHA solving capability. And to maximize the successful rate, we randomize
the payload including HTTP headers such as use agents and also iTunes Apple authentication
timing and traffic models. In conclusion, this is ‑‑ all these settings
are making it indistinguishable from human. How indistinguishable it is, you can see.
From our testing, the data of our testing you can see from the slide. We said we try
for ‑‑ this is the CDN. We tried for 11 times. Each time we had four requests.
So you had 44 requests. And from what the CDN portal, we can see all our regular traffic.
No bots. No threats. 44 is a small number. In real life, you will receive 44 million. So it comes to our testing environment
for the device, that means for the full authentication. Some are doing it on the device. Some are
doing it on the CDN. This is the setting against the device and
against the cloud. We put the server behind the mitigation device on
the client side, on
the other side is
the Internet. This is the result and summary. I'm not able
to talk about here, but you can see we do a lot of
testing to make sure it is all bypassed and the attack is successful. These are the two secure CDNs. So
it comes to the end
of our presentation. And
you can check out our new version of
tools here. Thank you. (Applause)