← All talks

Breaking the Giants with Application-Level Denial of Service Attacks

BSides Liverpool · 202217:5019 viewsPublished 2022-01Watch on YouTube ↗
Speakers
Tags
About this talk
Application-level DoS attacks exploit vulnerabilities in application logic rather than network capacity, making them effective against even well-defended infrastructure. This talk examines second-order DoS techniques, resource-locking failures, and real-world case studies on Snapchat and other major platforms, demonstrating how attackers can amplify damage with minimal computational resources.
Show transcript [en]

and today we will be seeing breaking the joints with application level denial of service attacks um so let's start by some who am i i'm a computer science engineering student the german university in cairo i have been a bug hunter and security researcher since 2014 and my main research interests revolve around privacy with application security network security um and logical vulnerabilities in specific i have been a speaker besides las vegas 2021 and i triple e lcn 2020. um you can find me on social media at logicbreaker on twitter and i'll be on linkedin so let's start by some motivation and um let's break our title into two parts so our title is breaking the giants with

application level denial of service attacks so the first part is breaking the giant what do we mean by the giants here so the giants are gigantic companies like snapchat facebook google and so on that have huge infrastructure and are multi-billion dollar companies in general and the other part is application level developer service attack and because this word is a bit complicated um we will start by giving some background information about what is a denial of service attack in general before we define the line of service attacks um just to make sure that everybody here understand what the cia trial is so a cia triad is like the golden standard defined by information security experts it would define

a system to be secure in general so it consists of three main parts the first of them is confidentiality a confidentiality refers to the fact that whenever information um is considered a secret or is considered to be um not public information in general it should stay within the system that means that this information should not be leaked anyway to malicious adversaries or even two third parties that are not intended to have this information when the information only stays within the system and is only accessed by the authorized personality can say that this information is confidential or the confidentiality is not affected the other part which in the eye in the cia which is the integrity refers to the

data integrity which means that the data is not altered is not tampered with nobody changes data the data is the real data the authentic data in the system so for instance if you have a facebook account and you log in and you see that your name is changed for instance um this may say that the integrity of the data has been violated you haven't changed your name this is not the data you stored the integrity of loom variation but if everything is just like what you did nobody altered or changed the data we say that the data integrity is high or that the system is integral and the last part which is our target here is the availability and the

availability of the system is the ability of the system to serve its users service customers to be usable um imagine having the most confidential system in the world with the best integrity ever but the system is not usable nobody can access the system it has low availability the system is completely useless and this is the target of denial of service attacks so the line of service attacks are a class of attacks that aim to disrupt the availability of the service it's aimed to make the service not available to its customers to its users to deny users uh in the past this was done using uh brute force so adversaries just launched what we call a high volume derived

service attacks um those are attacks in which the adversary just sends billions of requests directly to the server aiming to make the server unavailable to its religious or benign users um the idea here is any server has some kind of capacity if you consumed all this capacity with fake or bogus request the server cannot withstand or cannot handle further requests so what they did is that usually adversaries distributed malware or something that allowed them to get control of a huge computational power or a huge number of pcs or a huge number of uh computational devices in general and then use those devices uh to launch denial of service attacks or what we call distributed denial of service

because it's launched from both nets and a huge network of connected computers launching the attack at one time not just from a single machine um so this was very effective and it has proven to cost uh millions and millions to companies um but this is starting to change this attack fight is starting to change and there are two main reasons here the first reason is that it requires a huge computational power the attacker needs to have access to a huge competition power to inflict enough damage um even with this amount of computational power it's really unlikely that you can target something like facebook or like google or like those gigantic companies with huge data centers um

it's really unlikely that you can target them using conventional derive service attacks that aim to just jam the traffic so that my users cannot use it they have huge computational capacity that you won't be able to withstand the other reason is the advances in intrusion detection system and in cloud solutions like cloud fair uh cloudflare that now aims to migrate those device service attacks are becoming very popular and are becoming very smart using machine learning algorithms and ai algorithms and so on uh the idea here is that heavy load or high volume demand of service attacks cause a huge increase in the number of incoming requests to the server or the server um raises a lot of alarms so any

intrusion detection system will know we are under the null of service attack imagine that you usually handle 10 requests now you are facing like 100 requests without any good reasoning for that so it's definitely a denial of service attack in that case and then we can work on the mitigation faster because we know that that exists um so before we move on and see how this changed let's take a few examples uh regarding high volume attacks the first of which is the send float attack so the same float attack exploit the vulnerability that exists in the tcp protocol so the tcp to initiate a connection with the server you do what we call the tcp

three-way handshake so the first thing the user will send a sim packet to the server and then the server will reply with a send ack packet finally the user should reply with an ack packet to complete the connection but what a malicious attack would do would be the following the attacker will send the same packet and then the server will reply with the same act packet but the attacker will never reply with an acknowledgement packet the idea is any server has certain number of connections that can withstand for instance server can withstand ten thousand connections at the time if the 1001 connection attempted to connect it won't be able to do so because the capacity of the server

is exceeded so what we are doing here is that we are initiating connection with the server we are not completing the connection so the server is waiting for us to complete the connection we are consuming that but we are never connecting so we are virtually consuming those and usually the timeout period of tcp handshakes are a bit large so with enough computational capacity we can just fill the whole connection pool and then deny users will not be able to connect to the service or to the system um another famous example is the pink flood attack and the paint slot just utilize what we call the iscmp protocol and there are two parts to the hashtag

the first of which the attacker will just send pink packets the very famous twin packets to the target system and this actually consumes two things the first of which is the incoming bandwidth of the system whenever the pink packets are sent to the system they consume the incoming bandwidth because we have a huge amount of ping packets so incoming user requests are very much delayed because of that but there is another part to it which is the outbound request because whenever a server receives a payment packet it would have to reply with what they call an echo paying packet uh this would result in eventually the server not being able to serve the right users because it's

incoming request is being jammed ping packets and it's outbound request or it's outbound uh bandwidth is being jammed with the equipping package generated as a reply which means that the online users will not be able to utilize it so let's go into a bit of details of what is application level denial of service attack from a theoretical point of view so from a theoretical point of view according to what some portfolio application level denial of service attack is a class of denial of service attacks that aim to target the application layer of the system the application layer here refers to whichever vulnerabilities that can be found in the application layer or the application itself that causes the line

of service attack it's not really to the network layer like the high volume attacks we just explained it's related to the application and the application level vulnerability and the very famous example of that is what we call the resource locking on failure what do we mean by that so imagine that you are using the server to do some computations and then for instance any failure happen because you're divided by zero for instance so what happen is the system will go into a failure state and ideally the system will release all its resources used for the computations you were just doing so that other users can do it but some systems mistakenly will just lock the resources on failure

so once we fit into a failure this part of the system or this part of the server cannot be utilized by other users and cannot be utilized by you so if you are a malicious person you can think okay what if we call the huge number of failures so that all the server capabilities will be locked or all the server resources will be locked on multiple failures and the reliant users will not have any part of the server list to do their computations and so on so this is a very famous attack in which the application level is the problem here because the application level should release the resources so moving further we have here a case study

on what we call the second order denial of service attacks so before we talk about the second order of service attacks let's just remember what is a second order uh cross-site scripting is so the second order crosstalk scripting is a class of crosstalk scripting vulnerabilities where the payload of the crossfire scripting is stored in the database and then it's later rendered somewhere in the application and boom the payload fires second order the universal attacks are no different the amount of data that will cause or the thing that will cause the demand service attack is stored in the database and that's why we call it second order because the data is stored in the database and later when we do some

action it triggers the denial of service attacks so there are two factors for this attack the first of all is the missing laser limit on data creation imagine having something like uh paste bin and then you found out that there is no limit to creating number of pages so you just created the vote and created 10 million pages for instance um okay so now you the first part of this attack is that you are jamming um jamming the server or the database with unneeded data with garbage data because nobody is utilizing it but this is not the worst part of it the worst part is then you go to your account and then attempt to view your paste what happens

if the server will go to the database ask him what is the taste of this user and it will tell you okay we have 10 million pastes and then the server attempts to retrieve them if the server doesn't put an upper bound like for instance i will just receive the first 100 space what will happen is that the server will be hugely consumed to retrieve 10 million pages imagine this number being received from the database the time is huge and as the number increases the time increase that's what we mean by linear time as the number of data or the size of data will increase the operation will cost more time eventually rendering the system in the amount of

service state because the service would be very busy doing this bogus operation of uh getting back our data um so let's see some case studies one of them focus on second order nine of seven attacks both are on snapchat so the first is a zero click second order denial of service attack on the snapshot developer portal and the second will be fooling snapchat api to achieve what we call a targeted design service attack so let's dig deeper so snapchat has what we call a developer portal in which you have organizations and then you can invite developers actually you can add developers without any invitations which involves a problem you just type the developer email and they are added

automatically to your organization the idea here is you can create a number of applications so there is something that's called applications inside the organization you can create any number so i thought okay what about creating ten thousand applications once i created ten thousand applications my account got blocked i couldn't access the account whenever i exit i got like 500 internal server error and so on so i thought okay now i got a self-deniers attack congratulations what can i do with that and then i thought okay but i can add others to my organization now the thing is you create a huge amount of applications anybody in your organization who will attempt to log into their account

the app the server will automatically try to retrieve this ten thousand application so their accounts will not be used it's not an attack on your developers it's a attack on any developer just by knowing their mail even if they are part of other organizations you just add them whenever they log in automatically this data will be sectioned a timeout will occur because snapshot didn't allow you to fetch 10 000 records so the 10 000 record will take for example 3 minutes the only time out after 15 seconds so they will give you internal server error because a timeout will occur so whenever a developer try to log into their account they will not be able to do so which

means that they are denied from accessing the server and they are logged out of their account or their account are not usable anymore um let's move further into the api fooling part and also snapchat had what we call a business account this account is linked with the developer account so whenever somebody is added as a developer they are as automatically as um as a part of the business so the idea here is that the business account was some kind clever they had invitation so people will not be added automatically but just keep in mind that whenever you add somebody to the developers account they're automatically added um to your business account this information will be used later okay so

you just send somebody invitation and then i intercepted the traffic using proxy and found out that the request after sending the invitation is assigning a role to the person so the person is assigned a developer and an organization admin and so on so i thought what will happen if somebody's a part of an organization and they have no role in it so i just dropped the request now you i sent an invitation that person has no role and then i went to my test account and just accepted the invitation what happened is boom the account just blew away it was got locked what happened here the api looked at it and say are you a part of organization x and the

answer was yes i'm a part of the organization x you have any roles there and the answer is no but how you are a part of an organization and you have no role something might be wrong so i will just close the world account this is not the normal api behavior but it was a bug in the api itself instead of just denying the user from accessing my organization it denied it from acting any organization whenever you just log in okay you are unauthorized but i haven't done anything but you are unauthorized why because we manipulated the api somehow to target people but then you might say okay the user has to accept an invitation this is not a

zero click attack but i will tell you i just said that whenever you add somebody to the developer um account they are a business account so you just go to the developer account that has no verification no invitations add their email they are added automatically with no role and boom whenever they access their business account they are completely denied from accessing it which is an application level gravity because it's an api problem the api here derived the user from accessing his account and it's actually the kind of denial of service attack that you might expect to find in a huge company like snapchat because there is no chance that you will have a computational power that can actually

bring the amount of service that snapchat has down so usually this is the kind of value that you should focus on um so sharing some final thoughts about how to find and exploit level uh application level united service vulnerabilities um usually i would suggest that you look at previous reports on something like hacker one and so on um dig deeper into an application understand this further because usually they are uh logical probabilities that arrive to business develop service attacks focus on things like uh second order service attacks and other known application level because they usually occur now and then so just like you are looking for second-order cross-site scripting search for second-order service attacks uh the same way

so about my future work and next i'm currently looking into attacks regarding the line of service from microservices which is an emerging architecture and trying to do some emulation and simulation to automate those attacks and to understand their behavior and so on so this is what i'm doing right now finally i would like to thank a chambox he was my mentor as my very first top uh without him i will be here today i would also like to thank bien seymour at ligo and the tear matrix those people mentored me at some part in my life and i'm still learning from them so i would urge you to follow them on twitter they usually share very useful stuff

regarding security that you will definitely benefit from finally i would like to thank you all for attending and i would be happy to address any question that you might have thank you everybody