Web Security: Exploiting Race Condition Vulnerabilities - Armend Binaku

Um hello again and thank you for coming today in this session. My name is Armed Bino and today we'll be tackling and on revealing concurrency flows in modern web applications. But uh before we start a quick introduction to myself. I currently work for many years in code labs as a offensive security specialist where I do the standard penetration testing red teaming and in my free time I try to do as as much as possible in certifications and in of course CTFs. In this session uh we will cover different topics with the most important being what are race conditions the impact they have in real world the concurrency problem and how they occur of course the we will also expo explore

a coupon adaption exploit which we will explain later we will also mention some tools which could help us to find more complex array conditions and of course in the end we will explain some other attack scenarios which includes two-phase bypasses, attack account takeovers and brute force attacks and in the end we will try to get some suggestion in regard to race condition vulnerabilities. So we will explore some mitigation strategies. Uh before we start it's important to know what are race conditions. Race conditions are a type of vulnerability which uh goes in the subcategory of time of check time of use vulnerabilities which are a subcategory of business logic vulnerabilities. So race conditions are um vulnerabilities where

um uh par parallel requests are handled in a not a safe way. So basically why these vulnerabilities matter? Uh many companies like Apple, GitLab, uh Apache, Topcat, EMD and Hacker One um has some kind of race condition vulnerability or even uh has had in the past which um in most of the cases was a critical vulnerability. That's why um it's not recommended to overlook the risk condition vulnerabilities as u many modern webs can have these kind of exploits or vulnerabilities. Basically how they occur in websites are when uh we process our requests concurrently without adequate uh safeguards. uh this can lead to multiple distinct threads interacting with the same data at the same time resulting in

that collision that we sometimes call a race window. We also need for a race condition to uh create that carefully timed attack to cause intentionally that collision and exploit um it for malicious purposes. Let's say uh a normal um request uses one thread and for the other endpoint we use another which most of the times would be a safe um implementation of request handling. But imagine one thread doing all the requests simultaneously like in the image below. If the end point is a critical endpoint then we potentially can find a race window or even a collision for exploitation. In this example I will be explaining um a race condition where we try to limit overrun a certain

feature or endpoint. In this case, we have a coupon redemption exploit where we try to limit uh the the end point with many components so we can exploit that feature. Before we start, let's say we have an e-commerce site uh which should uh um handle the request in this way. So uh it should handle uh the request by checking that the code has uh hasn't been already used. Uh we apply the discount code and then the database updates uh that discount code to our total order. This should uh be a normal request. But what happens if uh at the race window where uh the coupon gets validated, we sent multiple requests. Uh so to to be able to detect and exploit race

condition vulnerabilities, it's first important to identify a single used or rate limited endpoint. In this case, we has we have a 20% uh 20% coupon code which we can only use one time. If we try to use it multiple times, it will say code already used. Uh so uh the goal is to overrun that limit and to use multiple um coupon codes so we can get a product uh for very cheap or even free. uh to do that we need to probe probe for clues. Uh in this case uh how we probe for clues are we use a technique called benchmark. Uh the technique identifies how the endpoint would behave in normal conditions. To do that it is recommended

to add a group in the repeater tab. Uh so basically for this attack we are using burp suite and so we have an easier testing form we group uh 20 requests which are uh normal postcer request and we uh group them in a tab. The reason is to see how to behave and to test if pontestly the endpoint is vulnerable. But before we move on, um Burp speed offers um three sending methods in groups which are uh for group one to send it in a sequence. That means that all of the requests will be sent one by one and so on to test if the connection is handling the request in in the same manner. So let's say we send

out 20 requests and all of the requests um have the same response time and the same number of bytes in the response time. So that's basically for testing the behavior of the coupon code. We also can send for testing purposes in separate connections. So let's say it will be sent request one then the request will be closed then uh request two will be sent and so on to test what would happen if different users would use the that uh feature and the uh third feature which is the most important is the send group in parallel. This feature allows us to send all the requests in a single time window which also enables race condition vulnerabilities.

So to do that it's pretty easy. We just uh send the group in a single single connection. So let's say in the group we have a 20 coupon codes all of the are the same. It should only validate only the first one because this kind of grouped requests are not meant to find race condition vulnerabilities but only to test them. So uh when we see the responses of each group, we can see that uh this endpoint is potentially vulnerable as many of the responses have the same number of bytes and the same almost the same um number of response times in milliseconds which both are 123 and 121. So we can determine uh that the single endpoint is

handling the requests with a similar response time which has which is a big indicator of your race condition vulnerabilities. Now to test to actually prove that this endpoint is vulnerable we can uh try to send the group in parallel. So meaning we can try to send 30 of the same coupons at the same time in the same window. And uh we can see that uh the application actually processes the apply coupon code in the API which is postcard coupon and uh it validated every one of them leading the discount to be applied multiple times even though the uh coupon is the same for every request and it should only validate the first one. It validated all of them because we did a

limit overrun. um exploit where we send the group in parallel and uh of course as we can see the product from being $1,400 went to only $20. Um there are many kind of variation of this vulnerability not only in gift cards. So we can also rate a product multiple times. We can also withdraw or transfer excessive amounts of money. We also can use or reuse a capture solution and we of course can bypass anti brute force rate limiting solutions. Um there are other tools that help us send requests in parallel not just uh burp speed repeater tab in a group. We also can use turbo intruder which allows us to do more complex uh race condition attacks.

The reason is uh because an enemy of race conditions or the network architecture and the jitter which can add an unintended delay and to make our attack more difficult. That's why it's important that uh we use turbo intruder as an extensions. So we can add manually our scripts and we can also add manually delays and stuff like that. So we can exploit multiple endpoint race conditions. Race conditions also can be used not only for um couponion but also for two-phase bypasses. Let's uh consider a a white box penetration testing where we have the password but it's the account is logged by two. Uh a way we can bypass that is to send um in parallel all the

OTP codes of the 9digit uh two factor authentication onetime password and um in most cases uh if we would try to brute force attack this we have only 10 seconds to find uh the combination which is unrealistic. But if we send with a single packet uh multiple requests uh we can uh find the time window and within uh 12 seconds or 10 seconds we can find the onetime password code of the two and therefore bypassing the this security measure. Other attack scenarios include but are not limited to brute force login. Let's say we have a rate limiter or a web application firewall and um we cannot do too many uh requests. What we can do is

group our all our brute force attacks in a group and we can send it in a parallel. What will happen is um bird seed would would send that uh all the requests as a single packet and the web application firewall would count it only as one request therefore bypassing uh uh rate limiting. Other more complex attack scenarios uh happened uh in a company known as GitLab which was a multiple endpoint race conditions which didn't happen in the first endpoint but in the second. So GitLab had a password reset function which um still modern web apps use this similar functionality. Let's say we forgot our password and we are a legitimate u user of the platform um we could um under

certain circumstances uh um reset our password which then gitlab would give us a one one time password a static password uh for generating the reset password link but what happen is uh the uh session or the OTP P of the reset password link would be static and easy guessable which um which if we would attempt to reset another user's password we would have uh we would need the same token which is used for our account and we would do a race condition where we would send multiple uh requests with the same token but to different email addresses and send them in a parallel. What then what happen is the first request hits the password update

logic which uh checks the provided static token and um the second actually hits the logic and the vulnerability where that token can be used for every email and the race condition. uh then would send for every email we provided the reset password link in our email address resulting in spoofed local host or account takeover. So basically um the first endpoint which was to generate the static password was used for uh every email we provided in our group and the second thread which was the actual password link that was sent to the email was uh used as a race condition where we sent uh 30 emails or more in a parallel request and then uh we would have

everybody's uh email because we found found that in your race condition actually um there is cases where it's difficult to find the race conditions because some of them can be find uh via source code but some need actually to be tested as it can get complex. X and because of network architecture and jitter and lag it can be difficult to find but most of the times mitigating or preventing these vulnerabilities can be done using mixing data from uh avoid avoiding mixing data from different storage places and storing sensitive endpoints make static changes atomic by using the data store concurrency features and also and other in-depth measure would be taken advantage of data store integrity and

consistency features like column unex uniqueness and constraints and uh of course it is recommended to not use data storage layer to secure another one also it's important to ensure that session handling frameworks keep sessions internally consistent and in some architectures it should be avoided to use server side states completely to avoid of course race condition vulnerabilities. Some processes uh and operation requires recording and a resource limit. So that can be also used as a a defense mechanism or a bypass technique. That would be it from my side in regards to race condition vulnerabilities. If anybody has uh questions, feel free to ask them. Hopefully, I will know.

Hey Armen, great presentation. I have one thing I quite didn't understand in the parts where you would send multiple packets like so mult multiple payloads simultaneously. >> Okay. uh so there like >> yes >> would that be caught by simple let's say like if the thing is on AWS or the thing is in some cloud provider service where the load balancing is not housebuilt >> so there would like denial of service attack prevention prevent you from doing that that's what I'm trying >> in most cases no it race conditions can al be also be used to do denial of service Some um uh VAF or web application providers um provide a way to detect this and block this but they

are never enabled by default. So uh because we are sending a limited amount of requests for uh it can be detected for some cases where our brute force attack or denial of service attacks but not in this case for a limit overrun because we only are using 20 packets and then we are sending them in a very short period of time. So uh most of the time it's not uh by default detected. uh uh it uh sometimes it it is needed also to add uh restricted in the source code via um additing threading to the endpoint. So uh it's not recommended to use uh one thread for many endpoints but to separate them because that automatically

would add a delay. Hopefully that answered it question. >> Thank you. That answered it perfectly. Anybody

else? No, >> thank you very much. Thank you.