 Today I will do the present to you, the foot of our research, kill them all. DDoS, protection, total annihilation. First of all, now I'm working in Laszka, a company. You can do any research you want. In here, we have our many talented people. He is inspiring us. Let me have many creative ideas I can share today. I will show you how we try to bypass all the long solution, all the DDoS mitigation solution and service provider. First of all, thank you for Laszka first, because they sponsor us, so we organize, let's let that information sharing and analysis center and we can come to here to share the information. Some information, you will interesting. Some information, it is sensitive. First of all, here is our agenda. I will spend around five minutes to give up to give the background and the motivation. After that, we're talking about the authentication in here, because all the authentication we show in here is the most accurate and effective 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 your guys to prove that what we've done need to be boring. First of all, the attack size now is much more large, because the internet coverage now, every guys, they will have the computer, but their security sensors still same, so the botnet, that means they can have much more, we have much more zombie. The result is that the size become much more large. Another one, the frequency of the attack, actually, I will say the attacker, he only will attack you in your P-hour. Give an example that happened in Hong Kong, one of the store exchange, they are under DDoS attack. The result is that the whole Hong Kong stock market is stopped at that date. Another one, the capacity of the attack, because the benefit attack is expensive, so the result is that they try to make the attack much more competitive. Give example, I use the tanking attack to terminate some service, but now we just use maybe 2 Mbps, the latest attack, we already can do it. After that, the result is the cost is talking about USD 6 million per hour. So, let me introduce the attack known today. First is a volume metric attack. Just use one sentence, they only focus the attack size, no matter it's TCP, UDP, ICMP, what kind of the medical, they only focus the size. Another one is a symmetric attack, maybe I use another term, protocol base, application base, they are attacking the witness of the protocol. Give an example, GATFAT, slower, lower attack, they are attacking the HDD protocol and TCP protocol. Now, they are focused on the application level. Application level, that means maybe they are attacking the database API. The last is the banner attack. The banner actually is the idea, use the one DDoS attack to hide another DDoS. Give example, 30 gate of the SYNFAR is attacking you. In the same time, they will send the AR7 attack, but this AR7 attack, maybe just one Mbps per second, but this cumbersome attack will crash your server because it confuses you. All your focus is, oh, the graph is all your level graph is the SYNFAR, something like that, but you misunderstand it because they use the application attack to attack you and crash you. First of all, we have the matrix in here to show you. The matrix is summarized as a characteristic of the very major attacker and the embedded attack. The SSS represent the attack complexity. The YSS represent the attack size. In here, we see some mitigation we can use in here. Oh, it's the basic mitigation, but the most important aspect of the mitigation is start with detection. So, we can add lot this one because if we cannot detect that, how we mitigate it? And then we have the detection in here. The main thing, we can classify it in free time. Ray measurement, base lightning. There's a use of the Ray base and flow base. In here, they will show you the level graph, for example, the packet per second, B per second, and what kind of protocol they're attacking you. Another one is protocol sanity tracking and protocol behavior. Protocol sanity is the focus on tracking the map for the protocol. Protocol behavior, this one is focused on the traffic utilization application lock. Actually, maybe it will give you some hints under DDoS attack. So, if we combine all together, we will become the big data analysis. So, this is our tools, QDM, or actually, we have the free session. I will show you how we attack to bypass all the detection I showed you before. First of all, I will focus on the TCP ocean and HTTP ocean. Last year, we were talking about the authentication bypass. Something, we are doing automatically, give an example. We have the traffic pattern simulation, just like the traffic behind the policy, I will explain detail in the data. Another one, we have the HTTP header simulation. So, the result is that the attack traffic is seen as the normal traffic. If you drop the attack traffic, that means you drop the normal traffic. So, how we do it? First of all, we use the policy in here. At the program, in the same connection, we will use the same user agent. When we send the attack out, just like the traffic behind the policy. So, in this one, when we send out the attack, you will try to analysis it. You just see that all the attack just like come from a policy. This one can empower the attack. Another one is HTTP header simulation. In this case, because the HTTP header, we will change during the request. Give an example. The first request we send to get an app page in the HTTP is access sync slash sync. That means we didn't know what we need to take. After that, the server will reply to you. So, the second request we will show you just in here, access image GIF, image JPEG, image something. So, in our tools, we automatically to do this one, just like the real traffic. Because the GIF now always same the pattern. Our pattern will change as same as the normal traffic. After that, we will focus on the TCP ocean and power. First of all, the TCP ocean design is against the detection. And then we try to empower the attack power. At last, we will use a QS string. Let me show you. This is one of the examples how we use the TCP option against the detection. In here, we can fully control every TCP's data. This one is an example of a slow lawless attack. In here, you will see that after freeway hand shift, we can hold it. After a period of time, we send the first push at. Why we do this one? Because after we hold that connection, that means we can know the limitation, the barometer, the detection they say. After we send the first push at, the ad is replied. We also hold it again. Because this one, just how we extend the TCP established status. Because if we try to extend this one, the attack power will be much more strong. Because how to say this one? It is because if all the active connection is spent much more resources, just give you a compare. This is an old fashioned HTTP attack, but send, send, add, push, add, after the add, finish, add, and close the connection. This kind of attack, you can see the result is that there are several just high CPU. And then you will keep the constant of the number of the connection. But your server has no impact. Just high CPU is still can come here and the HTTP 200 replied. Nothing. So how we do it? If we wish to attack, we need to do it like that. First of all, with freeway hand shift, push add, the first request. After that, don't close the connection. We keep send the push at. I mean the HTTP request. The result is that this time, the server with high memory, they were high, not just the high CPU, because the one they crashed your server is high memory for will not have a CPU. Another thing is that because we try to keep the connection, so the connection will keep increasing. The result is that maybe after five seconds, 10 seconds, your server is HTTP 503 service unavailable. This one is never common. Another one we will do, we force no cache. How we do it? Just easy. We just use the curious string, a question mark. After the question mark, I have a random call because for the palm of the wheel of the server or the low balance of the policy, every this kind of the curious string, they will think that it's a new request. So they will not cache it and then let you bypass. The result is that just the example I show you, I tried to download a large PDF and then use the curious string. The result is that your bandwidth will use the up. After that, we will go through the source holds verification one by one. All the obligation in here actually is the last, also is the death line that we are trying to mitigate the attack. First, I'll show you the TCP sync obligation, the TCP reset. That one, they authenticate based on the favorite 100, the TCP layer. First, we send the same. He will not let you pass the intercept you. After that, we will have the same ad. He will reset you. This one is the mitigation device. We try to pull our active calls. Reset is different to finish. Reset, that means I think that the collection have problem. I will terminate it. After that, when we try the same, we will bypass it. So that is the TCP sync. Another one I will want to show is TCP out of sync. This one, they will need to be cheeky. When I send the sync, here we put the sync ad. The sequence number is wrong. What will happen if the sequence number is wrong? This time, the client will reset the connection. After that, if you see your, see you, the source IP is seen, you come again. He will think, oh, you are the real IP and then you will let you pass. So what is the difference between the TCP reset and TCP out of sync? Actually, when we handle the DDoS attack or the sync fuck, what really happens when we send the sync, sync ad, and then we will send the reset because we use the spoof IP. What's mean by the spoof IP? That means you will not add, you only send one sync in this case. So the result is same. But why they decide like that? Because the efficiency handle I really use is totally different. Give you an example, the TCP reset, if we add all the packet together, just mention, two to length is different to the packet size because the header length always turns itself over. Here you will see that the TCP reset is 180. And TCP out of sync, we just use the bandwidth around 140. So in here, we will find, oh, the TCP out of sync is better. Is it really better? I will show you another one. Actually, we can bypass easily, use the spoof IP. I use the spoof IP can bypass the TCP sync authentication. In this case, we try to use the same source IP, send the sync. When he, no matter he replied the sync ad or not, we just send the reset again. And then we send the sync again. Use this kind of the methodology, 33% of the attack can bypass it. I mean the spoof sync can bypass the TCP sync authentication. But actually, the traditional sync file, they are 40 bytes. They are missing something. Maybe you are not hard to find some news to show you, oh, I can mitigate 100 gig attack. I can mitigate 200 gig attack, something like that. Because they haven't shown you something, some secret. Because if the TCP sync is 40 bytes, we can drop it by the ISP directly. Actually, TCP will not 40 bytes. Because according to the RFC decide, the TCP sync, he will leave the TCP option. Because the first thing, he will try to let you know what a significant example, the maximum segment size, he will tell you how many segments I can use it. So when we try to simulate a real sync traffic again, I will suggest in the IPDR piece, randomize the TTL. Because the attack now all is 255, it's boring. You just see the strict line, oh, this is attack. I dropped by the TTL. Another one, please randomize your window size. Window size just will tell you what is your OS. Give you an example, maybe window 555, something like that. This one also need to give you an example, maybe I spoof the XP, window MT, or window 7, something like that. And then we need to add the correct option. Because if we add this one, the ISP cannot drop yet 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, he will redirect a path. If your client can redirect that, he will, and then he will redirect you back the first path you wanted to go. The result is that you can pass it. So what is the key to bypass HTTP redirect? First of all, we need to find out the detect the HTTP V02. Because when you capture this one, that means they have the HTTP redirect. You need to do something. The second thing is you need to, in the same time, you need to make sure they have a location, hdba.c.com. So if we find the C02 and location, that means they have the HTTP redirect. In this time, we just loop the script until they come back HTTP 200. That means bypassed. So easy. Because just a simple program like WGAS, CURL, also can do it. So we enhance it. We show HTTP cookies in this time. This time, not just redirect, we add the cookies if the client, he can add the cookie and reply it back. He will redirect you back to the page you want to grow. The result is that this time you can pass it. And why this you? So what is the key to bypass the cookies? First of all, we need to detect set cookies, the key word is. If they have the set cookies, that means they have our fan code. You need to copy it. And another thing you need to make sure is the expire. Because the expire, it is the sense to tell you how to set it with authentication. Because now the authentication, he will use time base or traffic base. Give an example. Maybe you authenticate it. After five minutes, you need to authenticate again. So this time, we told you the Churchill you need to set. So sometimes, if you're in the first HTTP redirect request, you saw this one, delete it. That means back luck. Why? Because that means every time, you change the cookies. So you need to do the obligation every time. We also have the enhanced one. The HTTP cookies use the header token. In this case, you will see that he will use HTTP header. It's not common. This time, they use HTTP code. Maybe in our case, we use X-heather, something. Other things, it seems as the cookies authentication. But this one has the problem, the policy dependency behavior. Why we have this problem? Because if you wanted to develop the header token, that means you need to use the API, HS, and XHR tool. But the problem is that this time of the tech lead till now is not comparable to all of the bouts. The result is you can, the render cannot fully use all the functions. So we just simulate the traffic flow. We can bypass it. And then we have the JavaScript actually, this one is most challenging now. Again, we send a get. It will give you a hint. It will give you a JavaScript. And then it will ask you to calculate something this time. If you can calculate and post the result, it will direct you back to the index page. So it will wireless you and you can pass it. The key to bypass the JavaScript is that, first of all, JavaScript is client-side program. What does it mean by client-side program? That means you just open your WildShark, HTTP watch, you can find the path and download it. JavaScript is human, can understand. That means you can read it, analysis it. After that, we can use a different algorithm to bypass it. First of all, after that, we can calculate the result, just simulate the traffic flow and bypass it. All the guys doing this one now. Another one is that we use the client deployment mode and server deployment mode to cover the method. Actually, we use the auto bypass. I will show you because our program is just one megabyte. What is the client deployment mode? In this case, we will add the JavaScript engine inside the bot. But this one has the limitation because we just can run something. It's purely JavaScript only. It's no WVC, DOM, I mean maybe some parameter inside HTML and then you need to call it back in the JavaScript. Cannot. In other case, we use the application bundle, in this case, the server in here. So whenever the CNC server asks the bonnet to attack, the bonnet will communicate to this server. He will send back, he will seep the file and send back to the server and then he will show a calculation by the server. After that, he will give back to the client and then to bypass it. Actually, this one I will say is the most effective and accurate, but the problem is that the user experience may be poor because sometimes people also cannot understand the capture. Again, just seem as the JavaScript authentication. This one, he will use the after you fill in something and post it and then we redirect back and then you can pass it. So what is the key to bypass the capture? I have something wrong, but never mind. First of all, we need to find out the path of the BMP, I mean the orphan page, just the capture page because if you can download it, that means you can use some algorithm to bypass it. After that, the challenge is that embedded the capture engine in the bonnet, we will use the same method as the JavaScript. Just simply the traffic flow, use the current deploy model or use server deploy model. But actually, if you come to DevCon, you will find that have many capture engines, we can download it and then can use it and add it in our program. So this is the summary of the source host of replication. First of all, they will verify your launch booted soft IP or not. After that, HTTP redirect and cookies, they will verify, is it HTTP compatible appliance of not. Now JavaScript, they will verify you are the real browser or not, the capture, you will try to verify your real human or not. After we bypass all of them, we can attack directly. So Tony bring out and very important points that in today's detection mitigation techniques, we have to rely on the source host verification. And once we can bypass these verification, we can get to the back end directly and they attack all to the back end. 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 will success. And the third authentication, we are just for sure, make sure it is correctly put our IP into the right list, for example. And also to make the attack and authentication more like a real user, we will have a true TCP IP behavior handled by the operating system TCP IP stack directly. And 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 wide list, if you don't have the cookie in the subsequent attack, you might be blocked. And also the JavaScript, we are implemented using something like a spider monkey or a JavaScript engine. Currently, we don't have a DOM implemented in that included, but this is just a matter of time. And finally, how about the capture? As you can see, or in the coming video, you will see how this screen comes from. The design is that to make our attack tool sending a correct capture back to the mitigation device. The design is that we first convert the color image to a black and white and maximize the contrast. And then apply the medium filter to filter out the noise and then segment the word into individual characters and find out the boundary of each of the characters. Finally, we simply calculate the pixel difference. You might think that this is very, very rough implementation, but it can successfully break the capture by more than 50%. In fact, if you want a higher rate of capture authentication, you need a capture library. I think DevConnet presented a lot on this, no matter in this year and past years. After bypassing all the authentication, now comes to the attack. In the attack, we have the TCP options and also the TCP options. What TCP options talking about is control the timing of the TCP connections. We can control the number of connections established to the back end server. Why back end server? Just because we bypass it. And we can hold the connection for a certain amount of time. This, as Tony mentioned, this benefits for the slower attack. And also, we can handle the connection idle time out after the last HTTP request. And we can control the connection interval so that to avoid something hitting the threshold of the meditation device. For the HTTP options, it actually is that within the TCP connection, there is a period of sending multiple requests. This request, each HTTP request is an HTTP connection. We can control the number of connections and also the intervals of each connections. And now we are showing the video. Let us see how it runs in real examples. First of all, we look at HTTP redirect. That means you can see in the left part of the user interface, the first checkbox. From our testing, the left side is the client side. As you can see, the client launched our QDEMO tool. And the right side is the server side. As you can see, the web server log. On both sides, we have a packet capture. One side is capturing the packets. When we start launching the attack, you can see this is the authentication part. You can see because the first time, this one returned a real tool. So it redirects authentication. And you see subsequent 200 OK for three times because, as I said, we are doing the authentication for three times for sure. Now let's see what's next. After authentication, you can see from the primary test, we hold a few seconds and then send four requests. This is the first one you can see from the query string. Started with E and then the second one started with N, etc. And the four requests are all going to the back end. As you can see, both from the server side and both the server web server log. 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 back the cookie. And also you can see four different requests going to the back end. Yes, in the testing environment, we use four. But in the bottleneck environment, I don't think you in your server, you will receive four too little because you will have so many bots. Let us pick one of the attack HTTP requests. You can see, as I said before, the authentication cookie is carried to the attack. There is a cookie view in this attack packet. Now goes to the JavaScript authentication. This one 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 embedded in it. And from the right side, you can see the server side. You can see the four attacks. You can see the four attacks are all goes to the back end server after we bypass the JavaScript. Let us take a look at this one. And as you can see, even if this is JavaScript, it also has a cookie cookie view there. And the cookie clearance means that we are successfully bypassing the JavaScript. And lastly, we are showing about the capture authentication. This one will be the same. And you can see from the authentication phase, the mitigation device has the capture image, the bitmap sent back. And then we have the four subsequent attack goes to the back end. And we are interested in whether it is really bypassing a correct capture image. So we pick up a packet about the after we recognize the bitmap and send it out. And you can see this is WMGK, which matched the original bitmap. So this is our tool, kill them all, integrating both the authentication and the attack phase. As you can see from the video, our tools simulate the true TCP IP behavior through the OS TCP IP stack. And we have a believable HTTP header so that no matter it is a mitigation device or 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 not bulky, it is lightweight. And also, we have our capture solving capability. And to maximize the successful rate, we randomized the payload, including HTTP header such as user agents, and also tunable post authentication timing and traffic models. In conclusion, this is all these settings making it indistinguishable from human. How indistinguishable is this? You can see. We get from our testing, the date of our testing you can see from the slide. We try for, this is the CDN, we try it for 11 times, each time we have four requests. So you can see 44 requests. And from what the CDN portal, we can see that all are regular traffic. No bots, no threats. 44 is a small number. In real life, you will receive 44 million. So it comes testing environment. For the device, that means for the four authentication, some are doing on the device, some are doing on the CDN. This is the setting that against the device and against the cloud, we put the server behind the mitigation device and the client side on the other side of the Internet. This is the result and summary. And I'm not intended to talk about here, but you can see we do a lot of testing to make sure it is all bypassed. And the attacks are successful. These are all as well. 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.