Breaking the Giants With Application level Denial of Service Attacks

okay um hello everybody and welcome to beside childhood this is ali khabib and today we will be presenting breaking the joints with application level denial of service attacks so before we start let's uh look at some who am i i'm a computer science and engineering student at the german university in cairo i have been a bank hunter and a security researcher since 2014. my research interests mainly revolve around privacy web application security and network security i'm especially interested in business logic vulnerabilities and logic-based vulnerabilities in general um i have been speaker besides las vegas this year as well as i triple e lcm um you can find me on the social media at logicbreaker on twitter and kabil online

so let's kick in with some motivation regarding our topic so our topic is breaking the giants with application level denial of service attack so let's break this cycle up into smaller pieces just to get a hold of it so the first thing is breaking the joints and by the giants here we refer to gigantic companies examples like facebook google snapchat and those um big companies with huge infrastructures and so on and let's then go to the second part which is application level reliable service attack so before we dive into the application level denial of service attack it's important to make sure that everybody here would understand what a ci atrial is so the cia triad is like the golden

standard set by information security professionals they are like the goals that any system should aim to achieve just to be called secure and actually it consists of three main parts the first part which is the c in the cia which is confidentiality so what we mean by confidentiality confidentiality means that whichever information which is considered secret stays within the system it doesn't go to any um unintentional malicious uh or adversaries it doesn't go outside in general it doesn't have to be a malicious person um an information that's meant to stay within the system should stay within the to be called confidential otherwise the confidentiality of the data is not guaranteed the other part which is the eye in the

cia refers to integrity and what we mean by integrity is that the data is unaltered and it's not changed or manipulated with so what's an example of that so for instance if you have an account like an account on facebook for instance imagine that you are logging in and you say that your name is changed for instance your data integrity have been affected somebody maliciously altered your data your data is not authentic it's not the data that you save that is meant to be in the service or the system so here we know that there is an integrity problem so we say that the data is integral if nobody altered this and it's cost hampered and finally we go

to our target the target of denial of service attack which is availability or va in the spi atria so what do we mean by availability the service or the server or with the system um is set to be available it's able to serve its customers to service users users are able to utilize this system so imagine that you go to our site and then you are trying to log in and whenever you are trying to use the website is giving you an error or it's timing out it's not working the system is not available and maybe the system is under attack or it is in maintenance mode or something but it's not available and the system that's not

available is actually system that's useful imagine that the website is not available for you so even if it is the most confidential and the best integral outside that ever existed if you can't use it it's more useful um so before we go into application level denial of service effects let's go into the more conventional way of design of service effects and talk more about developer service effects so design service effects refer to the attacks that aim to disrupt the availability of the system whenever we talk about the line of service attacks we talked about the attacks that make this intimate system unavailable maybe it makes it may aim to make the system completely unavailable or it may aim to make the

system uh partially unavailable or make the customers incur huge penalties so imagine you are visiting your website and it takes like three to four minutes to load so you just close the website because it's not useful to you anymore it's not that responsive that you use um this website may be under the line of service attacks aiming to make the users or the benign and legit users not be able to use the system so how was this done in the past so in the past people used um brute force to do that they used what would we call a high volume denial of service effects high volume attacks mainly aimed to send a huge amount of

requests to the target server or to the target system um so the server and system will be very busy handling those requests and it won't have enough time um to handle the design users requests so when the nine users request or by meaning here legit uh will not be able to be handled promptly so uh for instance if a server is made to handle like 100 requests we are sending like 1000 requests so now the server can't withstand this amount so some of the requests will timeout and the others will just incur huge delays making the system unavailable to the legislators um actually this was uh usually done using what we call the distributed denial of service attack so a malicious

user or the malicious attacker will just um get control of a huge amount of computers either using malware or otherwise and use them to launch the attack it's not just a single computer it's more of a distributed network of computers or distributed network of devices and actually this still exists and it was proven to cost companies billions of dollars because one day um if foreign but this begin to change the question is why did they change wasn't it effective no it was effective but the idea is the rise of intrusion detection systems and solutions like cloud fair for instance um made denial of service attacks less harmful so you need to be extremely brutal when you conduct the

nanoserious attack to a staggered system also attacking something like for instance as big as facebook you won't be able to send enough requests to get facebook servers down because at the end of the day you won't be having enough computational capacity to do so a huge amount of servers a huge elastic databases that will not easily get taken down so brute force is not useful in both situations and we are beginning to change to the modern uh application level attack that we will be tackling in a second um so before we move to the application level of text let's take two examples for the high volume uh conventional access so we have the send flood attack

and the payment flow effect so the same cloud attack refers to a vulnerability that existed in the tcp protocol so whenever you are attempting to connect to a computer using the tcp protocol you send a send packet the server will reply with a send act packet and then the connection will be established once you reply with an acknowledgement so it's called a three-way handshake you send the thing you get a sync and then you send an app so if i'm an attacker what i will do i will just send things requests there are server reply with simac and will wait for acknowledgement packets but they will never get them because i will never send that management packet so what happen is

the server has a connection capacity an amount of connection that the server can maintain or can withstand without actually going down what i'm doing is i'm consuming this capacity i'm sending send requests the server open the connection and he's waiting uh for me after sending a sale actually just send him an act but i'm never doing that so i'm ultimately using the connection capacity of the server and this will not allow the nine users to connect if i ultimately manage to just fill all the connection capacity on the server the other thing is the ping slot attack and the claim cloud attack is an icmp protocol attack simply whenever you send the thing attack the

server receives this so this actually consume the incoming bandwidth from the server because i'm sending a request the incoming that which is being consumed but there is something that's even worse um you send the paying packet and then the server will have to reply with what we call an echo paying packet so you are not only continuing the incoming bandwidth but also the outgoing bandwidth because the server will have to be busy serving your echo paying packets so you are consuming both the incoming of the outgoing this will ultimately cause a system to not be having enough time or resources to serve benign users and will make the system unavailable to them causing the line of service

um so let's go into our topic application level denial of service attacks and that starts by health theory from our friends at west and port sweger so what application level do not observe that has so what we have been covering so far is related to the network layer usually we are targeting the network part of the application either using uh something like a thin attack or a bank slot or otherwise but we are targeting the network layer the application level level united services that refer to a class of vulnerability that exists in the application the attacker are targeting vulnerabilities in the application layer of um the service it is the application itself so whenever the attacker found a

vulnerability in the application that may cause the server to go unavailable to user this is an application level behind certain attacks it is something related to the application itself and it's very unique that it can be served from application to an application it is not just like a semi-flood attack which can happen anywhere using tcp application level require users uh or require uh security researchers to dig very deep to find those vulnerabilities to exploit them or even to patch them so they are not easy to find and not easy to patch because they vary from one place to another and a very famous example is what they call the resource blocking non-failure so what is the resource

talking on failure so the resource stopping on failure is a vulnerability that may occur because whenever a server hit an error instead of just releasing the resources that were used by the user to cause the failure the server will lock those resources so let's clarify this point imagine that you are doing some calculations on any server and then for instance you cause some failure by dividing by zero for instance so the silver has a failure but you were using some parts of the server uh to do some calculations so the logical thing that can happen is that okay we will just go on and release those resources so that they can be used by other people

and so on but this doesn't happen the service will say okay failure happen so this part of the server will not be utilized and people cannot use it so what happened here is an application vulnerability which is something like dividing by zero it's not a vulnerability it's just a failure dividing by zero caused the server to make some part of it unavailable it's locked in the failure nothing can happen nobody can use this so if i'm malicious i may induce the failure that will cause the system to ultimately lock all of its resources into failures so the system resources will be logged into failures nobody can use them the service is ultimately unavailable for anybody

um a nice class of application level united service attacks and one of the known ones is called the second order service attack so what is the second order of service attack before we answer this question let's take a step back and look at something like a second order crosstalk scripting attack or second order exercise second order here refers to the fact that it is stored second order crosstalk scripting payloads are usually stored in databases or something and whenever a user visits a certain page in which the information is rendered uh this information gets ran uh retrieved from the database and the payloads fire so the idea here is that the data using the attack is stored

inside a database or inside the application itself and denial of service attacks or second order director's effects are no different we appear here through the fact that the data used to launch the microservice effect will be on the server it will be a part of the database stored in a database it will not cause the denial of service attack until we do some action that triggers the denial of cell phone behavior so let's take an example to understand what we need here imagine having something like space then where you can create random pace imagine that placement has no methodology that limits the amount of space that you can create so you just create unlimited amount of space you

create 10 000 10 million or whatever amount you want to space and then they are stored in the database first of all you are selling the database with garbage because simply you have you have automated the process it's not real pace nobody is using those space they are just garbage so are you are consuming the database maybe it's a cloud database and then you are consuming money um but there is another problem here imagine that now you go into account and then you go to the face tab and you want to see your face what happens is the server will go to the database and ask it to retrieve all details that this user has and this user has 10 million

pays for instance so what happened is the server attempts to retrieve 10 million records from the database this is the huge amount of resources required it retrieves this amount of information it's also a huge amount of time so imagine receiving 10 000 records that's insanely big um what happened is one of two things will happen the first is the server will limit the amount of data retrieved so for instance i will only receive you the first 100 and this is the correct way to do things because if the server doesn't bound it here we have what we call a linear time operation on the data so we have 10 million records and we are retrieving them it's expected

that if we have 20 million records the time will double because let's say that the record will be retrieved in approximately constant time so the idea here is we should never allow the user to induce some kind of linear time operation or complex time operation in general something that's not off one or not constant time on the data otherwise whenever the user will attempt to retrieve this data simply the user will render the server unavailable due to the huge amount of resources consumed to serve the user reference um taking it from here let's take a little bit on some of the case studies one of them will be about the second-order genealogy attack that we

just discussed and using snapchat developer portal and the other will be about fooling snapchat api to achieve targeted demand of service it's not related to second order denial of service attack but it's related to application level united stands attack that we discussed before so let's go into the second order design of service attack on snapchat so snapchat had developer portal you have an organization you can add developers and so on and so forth um and the idea here is that you can add applications into this organization so you can simply create an application within the organization and there was no limit on the number of applications that you can create you can create 7000 applications a million applications

whichever number you see in addition you can add anybody to your organization without any kind of authorization they won't authorize you you just type in their email they already added into your organization and there is no way that they can get out of the organization actually there was no leave organization button so this is insult to vulnerability you are being able to ask people forcibly to your organization which may be offensive to them but this is just a part of our problem the other part is actually the unbounded amount of applications let's say that i created 10 000 applications and added my victim to the organization what will happen when the user is logged into the developer portal once the user

logs into the developer portal the server will attempt to retrieve all the organizations of the user and all the applications to load them just to make his life easier never navigating their site so what will happen is the server will go and tell the database okay load all the applications and there is ten thousand applications so what snapchat did to avoid that unbounded linear time operation is that they cause a timeout so whenever the data is huge instead of just retrieving the first 100 for instance they will just climb out of course they have a timeout of like 15 seconds and 10 000 application would not be loaded in 15 seconds so whenever the user log into his developer account it

will just tell him that the server is not available simply because the server can't load his data and this will not only deny him from accessing our organization he never meant to ask our organization it will deny him from accessing his wall account he can't navigate his account he can't use it at all the developer's account is useless for him whenever he uses 500 server is not available i'm sorry and the victim account is now useless he will have to contact for instance the support or something and tell him his problem maybe it gets sold and maybe not and once it gets sold we can just re-add him and again his account will be closed so just

by knowing the victim email we can do this attack we can even automate it on many number of users by just using random emails for instance or if we have a way to enumerate emails that will even boost the effects of the attacks so this is the first attack and how we were able to deny people from exiting their development account let's move on to the other interesting attack which is how you're able to deny people from actually their business accounts on special so the business account which is actually linked with the developer account but they are two separate accounts and then today um it has a nice feature to invite people and now snapchats were

a bit smarter and they allow people to accept or reject invitations so whenever you send an invitation they can accept and reject they will not be added automatically so what happened is you can send somebody an invitation and whenever you send him an invitation if you are using something like a proxy like verb suite or something whenever you send the invitation the request coming up for the invitation aim to assign a role to the user so it aims to just make the user have a new role or something in the organization maybe you assign him a developer an organization admin or whatever but what i thought about what will happen if the user has no

role at all we just drop the request what's happened is whenever the user logged in you see our invitation but then whenever he clicks on that invitation and attempt to join our organization he won't be able to join us and his accounts will be locked forever why because this is how the api functions the api will look into the user account are you a part of this organization which is the attacker's organization or my organization in this case and the answer is yes i'm a part of this organization they accepted our invitation but then the second question is do you have any role in that organization are you a developer or organization admin or something and the answer is no you don't

have any roles so what will api do instead of just denying him from acting our organization which makes sense the api closed the whole account it say okay i'm sorry this is not allowed you are not right to get into your account so all the functionality is within the account where rendered not available you will just see a stream telling you i'm sorry you are not a surprise even his own organization he will not be able to access them this is because the api was not functioning incorrectly and that's how we denied the users somebody would say okay i see you but um you have said that the user needs to accept the invitation this is not a real

click attack okay you are right um but if we move the step back i told you at the beginning of the story that the developers account was linked with the business account luckily whenever somebody is added as a developer they are added automatically to our business account without any kind of acceptance so how did i just escalated that further you go to the developers account add somebody to your organization as a developer and then you navigate to the business account they are added automatically there is no need for the invitation no need to accept it and now whenever he logs in he can't access accounts without touching the invitation or accepting this so this is how we

escalated it from something that needs the user to accept our invitation to something that needs absolutely no user interaction um so this summarize the api pulling and how we were able to deny the users from accessing their business accounts finally i would like to share some final thoughts regarding the topic about how to find and exploit application level denier services on their bases and the main way to find those is to actually look at previous vulnerabilities those are just like business logic they are not easy to find but um they happen to be similar between applications having similar businesses so for instance if you find a way to do that in social media applications and

just look the same way in other social media applications because maybe you'll find them also there are some clusters or classes of application level denial service effects like the second order service attack and then you can just look for it the same way you look for second order derivatives as for a second order crosstalk scripting and so on so it's not really that hard but uh the main thing i will tell you you will have to understand the application to understand the application technology how is it functioning and how can you render exceptionally long delays in it this is your way to find and exploit those vulnerabilities um about my future work actually i'm now

working on studying the attacks regarding microservice networks which is an emerging system architecture i'm working on understanding the architecture more and looking into how to find unique delight of service attacks within that architecture and i'm working on doing that in the moment um so finally i would like to thank y'all chambok chambox was my mentor uh in my first ever talk and without him i wouldn't have do it here uh i would also like to thank simbian timo and ligo and that fear matrix and those people mentored me at my start and actually without them um i wouldn't have gone that far so i'd like to thank him and i would like to urge you to follow those people

on twitter because they usually share things about security and you are probably going to learn a lot from them um i would like to finally thank you all for attending and i'll be happy if you have any questions to answer them thank you everybody