Securing Python: Race Condition Vulnerabilities

Speaker 1 [00:05]

yeah thanks for coming and today's topic is about one kind of vulnerability which is it's not obvious enough when you research it or when you test it so if you have evadeness of the vulnerabilities then you are in a good shape because if you understand what kind of vulnerabilities you can have have, then you can mitigate or at least prevent it early. So today's agenda is a little bit about me and what do you need for this tutorial, how to understand the vulnerabilities, and we are going to have a live hacking session, three live web applications that we are going to hack, attack, if it's possible to say. And then I'm going to show you some kind of very naive and simple Python Flash code that in essence is quite simple, but it can lead to some kind of vulnerability. And then we are going to explore in the real world how the other professional pen testers or security engineers found and get bounties, specifically for the race conditions. My name is Shako. I'm a senior software engineer at NordVPN, and specifically I work in threat intelligence team where we are trying to understand the available threats for our users. I live in Vildar, Brandenburg. It's a bit far away from Berlin, but it's green, nice, silent place that I love my place. And I also am a board member in Azerbaijan partner user community. We constructed the community in 2015, and monthly we are doing some meetings and answering to people's questions day to day. Well, I'm not a security engineer, and I'm not a security research engineer either. I'm not a pentester. I have no direct access or abilities to day-to-day hacking. What I am doing in daily life, we all love Python, and we write Python code. But also I propose to change a window from where we look at the code and add a bit of pepper and salt of the security notions. So how to be more informed about the security and about the vulnerabilities. So this is me. What you don't need. So no need for any installation. No need for any coding. No need for distraction. No need for the pain. But usually, for example, what I faced also, if I ask some installation and half of the like auditory is failing to install something and they're jumping around and so not for that. I just focus and ask questions about what you see. You need to have just an interest in security topics and it starts from simple steps. to understand vulnerabilities so if it's if you go back like 15 years ago there were a little and little resources to understand and read about the vulnerabilities you need to be a member for example a closed group or factors and okay they do you a favor and give you some pdf to read but not not it's the case now so if you go to amazon for example for searching for the books and there's plenty of the books that you can read and it's easy to read so it's not a heavy uh here are books that you you are not going to understand the first one is for example bike mount to boot camp and the second one real world bike hunting um is also um so basically how those books are written you read about the vulnerability then they gave a sample then you can possibly find the same thing, or at least understand that this is an existing vulnerability. Resources to practice, this is also my rate of resources, but I like these four of them. So Pentester Lab, especially the code review section. So if you don't hear about that, specifically when you do a code review, there's a different notion of the code review. It's called security code review. So imagine that somebody with a security focus does your code review day-to-day. It's a different notion of the feeling. So one thing is, for example, your unit test passes. I don't know, you have a CI pipeline all green, but then somebody comes and says, yeah, this is not a good, for example, approach or flow because I see a kind of vulnerability here. It's a bit painful, but still it's informative, and you learn a lot. So Pentester Labcom is really good at code reviews and API hacking sections. TryHackMe is beginner-friendly, and they have a plethora of free rooms. What I mean by free rooms, for example, you are interested in SSRF or XSS attacks, right? And you search for XSS. They give you free rooms to check. They walk through basically CTF style, and then you understand, oh, this is the case. Okay, if the XSS, I understand what is it, then that means that I need to learn more GS, and this is go on. So you understand the vulnerability, you want to prevent it, you learn more. The Potswiger, this is a company behind Burp Suite. it. This is the software that, I don't know, most open testers are using for all kind of tests and attacks. And it is, they have a presence of real scenarios with explanations you can go and explore. And one more I really like, the TCM Academy, they have high quality courses. So they have a lot of things. For example, I don't know, privilege escalation in the Linux. So if it's not for you, you want to understand the mobile vulnerabilities and you go for the mobile hacking. If you want IoT, you go for IoT. So it's kind of where you see the code, then that means that there is some kind of vulnerability in that. That's the basic steps you can do to understand the vulnerabilities. to the race condition. There's an advanced talk about smashing the state machine. This is a really, really like, I watched it three times, but still it's a bit hard to grasp. But it's the most advanced talk so far about the race condition, I see. Let's just explore one link. So this resource link is important. It's explaining the race conditions. And I'm going to go through the basic ideas, so let's just close this. So race conditions is also categorized as business flows. So business flow vulnerability, but also it's considered as a vulnerability of, for example, failing or synchronization primitives. It's called your application, your taste, your application, You wrote your application as single thread, and then you failed to test it in a multi-threaded environment. This is also a type of, I don't know, different kind of stories that you need to read more. And we will talk about more in the later. So basically, what we look at when we talk about the conditions, that the business logic flows. There's something wrong with your business logic. And then somebody comes and try to, for example, submit a discount code several times. And OK, if it's a single set, he is going to submit some kind of discount code one time. And then second time, you say that, oh, this, for example, discount code is already used. But how about if it's, for example, update the status, the discount code in a database. And this is a millisecond of the time frame. So it's called this lag. The time frame is the race window. You can run. And this is basically where the attacker looks for you. So you understand your critical sections of your application. For example, if it's e-commerce, you add a basket. And then you push, for example, to apply a discount code. And this race window, if it's not properly synchronized, that can lead for the race condition, in a simple essence. But yeah, again, one more time, as I'm not a security engineer and not a domain expert at all, the whole scenario is, what I really look is try to minimum understand the vulnerability and then act against it. So at least some preventive actions. This is more important than, you know, imagine that you got hacked and then you fix this. But it's better to harden the life of the attacker. This is the most important thing as a software engineer. But again, if you have a proper security flow, checks, and other things, you need to have a different team. And also, they will help you on this. So this rates window, we spotted, right? But it's also the application where there are a lot of, plenty of them. And for example, as a blog post says, that it's like redeeming a gift card multiple times, rating a product multiple times, I don't know, reusing the single capture, transferring cash, bypassing some kind of rate limits. Also, you can see, for example, file upload vulnerabilities with the race conditions where they check. For example, they first get your file, store it somewhere, and then running for some kind of checks. And during this time window, you can attack and upload an arbitrary file, for example. We will see in a, let's say, simple life hack. And basically, when you talk about the vulnerabilities, and if you have a web application, and basically think about that, what is your critical sections in your application? And what we mean by critical section, it's a business valuable critical section. So where, for example, there is a transaction, the money transaction, or I don't know, there's a critical check that is some kind of update to the database. You spot these places beforehand, and you understand that, okay, it looks like somebody can use it in this time window and in this time frame. Then you try to localize the issue. So you have a big scope, then you add the defense layers. You go backwards to the inside, and you have several defense layers. And, for example, one of the layers is against the race condition. But obviously, this layer is not going to fix all of your vulnerabilities. Yeah, this is about the race condition. So, in a nutshell, it's not a comprehensive guide. Yeah, let's explore the one scenario. So, it's called Web Shell Upload via Race Condition. It's a quite simple idea, and, yeah, basically, let's just fire up this lab and try to go through. Yeah. Gosh, how I can hide this? Okay, let's see, if I don't forget my password, yeah, okay. No, it takes so long. Probably, yeah, let's wait. OK, so we have a web application. And we need to go back to our attack machine. And let's explore what is this. So basically, if you see, this is a full functional web application, right? And then it's a blog. And you can view the post. And then it has a My Account. And it has a user, basically. And when you hit the user, and here the user can update an email, but it has also the upload functionality. So it tries to upload probably its avatar, right? And then if you go to the website, and it's intercepted your request, basically. And when you hit the post login, for example, It's a POST request. And you can see what kind of request is sent. So basically, it sends a username and a password and a CSRF token. And then in the response side, there's nothing, basically. I'm not sure why. But yeah, probably it's just redirects directly. So this is basically how you intercept user requests. So this website has professional edition and also community edition so you can directly download the community edition at least try to understand what you sent and what you got and what kind of data is a flow and then you can add an extra checks for example one one more thing here for the talking about request response yeah you need to have a decent contract between between your third party or internal applications. So you expect exactly this field, and you send exactly this request. There's also preventive actions, so no more extra things, no more different kind of flows. Yeah, let's just upload something. I'm trying to understand how it works. So it doesn't mean that you directly hit the web application and try to attack. You need to understand the usual case. And if you spot the usual case, then you can find, for example, the unusual case. And if we hit an upload, let's just see if it uploads. Cool. No. Method not allowed. OK. But it's here. Yeah. Wait one more time. OK. The file avatars mountains has been uploaded. explore what kind of upload it is. So it's sending the post request to my account avatar with the data, probably it's multi-part. It's some kind of form data, yeah. And the file name is mountains.jpg and it sends the content type and then it requests back the file avatars.mountains.jpg has been uploaded, yeah. So we got a success. It's also good. Let me apply this as well. And I'm going back to my account. And you see that it's uploaded and it's shown. Then one more thing that we detect that, OK, it stores it in the files, avatars, mountains page. This is a pass of the avatars. So when you access the dashboard, It just gets a request and gets this file for you to show. Okay, the next step, we understand this thing. And as the name of the lab says, okay, we need to find some kind of vulnerability in the file upload. And this is a shell. And in PHP world, usually it's like some kind of one-line PHP file that you need to upload and see. So what's the shell? The shell for us in a simple... Let's see, like, what was the first attack? Yeah, so exploit is just the single PHP runs that I need to get a contest of Sir Carlos Secret. Quite dangerous, so when we upload, when we manage to upload some kind of file and it got run by the web server, as soon as your web server has an access to different places in your machine. That means through this shell you can manage the machine. So basically this is how the web shell works. Let's just upload this and see what's going on. Where's my browser? Yeah, here. And basically I need to go to repos and um it was yeah here and the first attack and exploit php and if we upload it okay sorry only jpeg and png files are allowed um yeah we it's we expect such kinds of things that there's an extension check there can't be a content type check i don't know they can be mind check and other stuff but basically okay we see the the we see the validation the one thing we can do now is try to bypass the validation or try to shift the window and try to race find a race condition on this what does it mean um so basically if you spot the the window that you post the content of what was that just a second so you post the content of exploit php right and then you get it and if there is a race condition that means that I upload the exploit PHP and before hitting the extension validation this time window, this time frame, I just can't read it. Because this files avatars pass is publicly readable. So this is the vulnerability that hits here. And let's just do this. So I'm going to send to the repeater this guy and also I'm going to send this to the repeater, yeah. And here you can create a group. So the notion of the race conditions that it should run simultaneously, concurrently, or say in a parallel. And if you create a group, and now let's see. So I try to upload exploit PHP, and immediately I try to get this file. And before hitting the extension check or validation, I can... So this file gets contents, will get back to you as Carlos secrets it. Imagine that this is some kind of shell redirect to some port and it gives you a shell access. So just imagine this. And now the same idea. So I upload, but before the validation check, there's a time window. So it's not atomic. There's kind of veiled action behind this validation. And I can just run a race and win, basically. And if you go for the send, let's just go, for example, send group in a sequence, right? And if we run in a sequence, probably, and understandable, we get here's a validation error. So sorry, only JPEG and PNG files. Because it's sequential, it first uploads and then tries to get the file. But if I run this in a group, in a parallel, and a single package attack, let's see what's going on. One more time. I trust you. Wait. Yeah, OK. Wait, wait. This is a getting, right? And how about duplicating this, for example, 10 times? And send group in parallel. Nothing happened. My POC failed. Interesting. wait we post it right sorry I'm not mountains exploit PHP yeah thanks that was good catch so I don't need this and I need exploit yeah it's always happening when you do life then yeah probably here we will succeed okay you're not funded okay it all changed that means it's something that catchable interesting files avatars we upload it and then okay let's just now increase the now duplicate the thing and send group in parallel okay so what now we succeeded so this is a It's a try and error, so you see that it's kind of you have a chance to get this race condition, but it's also high chance that you're going to fail on that because you need to spot exactly the time frame, synchronization frame, like time window. Here we spot that the file is uploaded, but until the validation there is a tiny millisecond And the race condition run between these milliseconds, and we win. OK, question can come that how to prevent this. So basically, I have a validation for extension content. I did everything, but something wrong again. Make it atomic. So uploading and checking should be in a single unit. So not like uploading, then checking. It's like single chunk. imagines that this is a single payment processing transaction. If it fails, if it fails. So there's no window to inject to race run. I guess this simple example is quite, I don't know, informative, you know? But you see how it's critical. It's a different window. It's not like error getting, oh, you uploaded not a JPEG file. It's more business flow. OK. No questions so far, right? OK. Then cool. Yeah, we are done this lab. So I'm just stuck on watching what I'm doing. So the first scenario is to find a time window small enough to inject and run a race condition. We are done with the first scenario. The second scenario is limit overrun race conditions. So here in this lab, it's a bit different idea. It's applying some kind of discount code multiple times. This is also a usual case, right, when e-commerce or in any website, they give you a discount code. And you want multiple times, obviously, to use it. But most of the time, it's only one time. Let's just run this. And in this case, just also read the lab's description. It's also important. So this lab's purchasing flow contains these conditions that enables you to purchase items for an unintended price. So unintended price, probably like that It means there is a $1,000 laser jacket, and by applying the discount code, you want to buy it for $50. So your ambition, right? You define your goal. And yeah, let's just access the lab and try to understand what's going on. One more time, we need to understand the usual case. Then for the race conditions, you also try to support this race window. It's important. Waiting. OK. This is a shop. Going back to our bookseed, I'm going to clean. Can I close the door? Close. Anyway, let's just hit it here. But we need to clean the history. Try to understand what is this. OK, going here. If we go to the My Account, and probably it is the same username. But where's, ah, OK. So if we go to the basket, so it's empty. And for 20% off, we need to use this promo 20. Let's just go for, I'm interested in understanding how they usually, this application acts. And they usually like, if you view the detail and add this to the cart, and if you go to the, OK, now it shows the discount form. So that means that somehow this application understands there is something in your basket and shows you different kind of stuff so these interesting things to spot in when you when you look at the application or when you build the application and then the usual case I'm going to apply this one more time okay it gives you well this is a decent amount of discount I would say but still we have 50 you know and we need we need more so this is your ambition right now and okay I applied it then we go to the website and try to understand how it's applying works so it's it sends a post request to the cart coupon and what kind of data uh it sends a csr yeah csrf token and then the coupon name and then if it's applied it returns back the message that it's coupon applied. How about one more time? I just want to see what's going on. If you apply one more time, okay, coupon already applied. That means there is some kind of check. We are sure that there is some kind of check. So it's not as easy as we expect. If we go back, so we send one more time, and we get back a coupon already applied. This also, yeah, I didn't suspect anything right now, but I dig it more, yeah? And to dig in more, let's just go, for example, what I want here is I have a card and I have one lightweight leather jacket there. If I refresh this, no, not this. Oh, no, sorry. It just removes it. Like, removes the coupon. I don't want applying. Let's see what is this also. So it sends coupon name to where. So it sends post request to cart coupon remove, and basically nothing returned, like informative, just removes the coupon. But I still have the laser jacket in my cart. I just refresh it to try to understand how also it gets the data. So if we get sent to the repeater and try to understand, okay, let's just send one more time. And if we explore down, you see there's a cart and one addition. What I would like to understand, how it understands that this specific item belongs to me, to my cart. This is an interesting part of that. And for that, I'm just trying to remove the session token. Let's see if it understands somehow. Okay, no, zero. What we can predict from here, the cart and the item inside it is somehow associated to our session token. And I suspect that when I apply also discount count, it's somehow related to the session. And when it's related to the session, there's some kind of database update, must be, as I understand, behind it. that, okay, this is a this user, this is a session, let's just go and update the status of this coupon for this user. And we have a time frame, so, you know, a window. Before checking the database, you can run it multiple times before hitting the database check. So this is, I don't know, in essence, like if we put it in a simple way. If we get back the session token one more time run we can see that the item is back okay to support our our initiative let's just one more time apply coupon and and get the card this is a importance so apply and get yeah I'm going to get this coupon one more time and try to apply and then I need to go to the proxy and get this post and send it sorry and send it to the repeater I'm gonna to repeat this action but before that I need to remove it right and before that I need to remove and then yeah public it's first to create a group and then it was to duplicate it I don't know how many times just duplicate 20 times to see what's going on if we duplicate 20 times so we are trying 20 time apply the the coupon here and try to sports a race window this time frame and if we yeah if we go to yeah you just send it in for example seeing in a sequence but the separate condition I'm just curious what's going on so coupon applied coupon already applied so you see first is applied and second is already applied because it is synchronized so it's like in a separate synchronized POTS requests that means I need to go back as I have already applied and I need to remove it let's just ice it's still stacked on somewhere or I suspect no no not here that's interesting so if I refresh okay so interesting it tries to apply in a it somehow queue, which is I don't understand why. Yeah, let's just remove one more time. It's interesting, getting more interesting. If we refresh, if we refresh, yes, some kind of it you see usually this is a such a simple mistake that we just don't give it attention and then we because we don't think that somebody is gonna run in a parallel or run in a sequence like hundred times of the things and this is a single threaded mind so that that's a problem okay interesting how when it's gonna finish I guess it's finished okay now so if we go one more time to this crazy coupon side so we have thousands yeah and 50 okay nothing changed I was thinking that maybe it's also deducted or give it some kind of credit more credit you know as a side bug but no it just run in in a single package parallel so I'm interested in what's going on okay let's just go back and refresh it okay we get more so but it's not still not enough because we are 50 so it's It's getting interesting. I need to remove it and then refresh it one more time, try. Not succeeded. No. Okay. Let's remove. Refresh. Yeah. Yeah, I believe we can do it. And okay, this is a chance, it's non-deterministic also. But you see that we got 500 and something. I need to just be sure that we got below the 50 to buy this jacket. Yeah, I want this jacket. This is usually how it's happened, but then you realise that you don't want it because you have no money. And then, please, no. that's a good point okay let's do so you mean ten more right okay and then try to Can you write a program that tries a request and if it's not enough, it tries again? We can write, yeah. But I didn't write it, yeah. Yeah, we. So it decreases to like five, because it could be that, like you said, all the requests kind of overlaps. Probably, so. Decrease it, you can see there's a change. Decrease it to five? Yeah. Okay, let's do, that's interesting. Oh gosh. But wait, there can be a problem because we are applying only the coupon, but not getting the coupon. I want to understand this. Yeah, the question was if we can decrease, not question, but advice was if we can decrease the request size to the five. I need to repeat the things from the auditory. You know what? I'm going to close all tabs and then do a different thing. Let's just send this to repeater, but also the get request to the repeater. And, yeah, for the same session. And then I create a group. No, creator, where is the creator group? Ah, here. Create a tab group, and I add this with a nice color. And can we, for example, this is a get request. I want 10 times this request. And I also want 10 times this request. Just in case. Just an idea. and then I would like to send a group in a parallel interesting where no it's not let's see what happened nothing yeah I probably didn't remove it okay and then yeah we got more okay so if we have increased also the getting the cards details so one one post request for applying the coupon one get request for the getting the card data either there's some kind of logic flow or collision but Now you see the flow, right? I don't want to try more. So you already understand what the heck is going there. So it's quite dangerous. And to fix this, it's already easy. So one more time, think about your critical sections as a single unit. So what we mean, if, for example, I have a check for the session, I have a check for the coupon, I have checked that if it's applied or not. All those kind of things needs to be synchronized. So it's one single shot. You just lock it, do the hack, and get back the results. So we are going to briefly talk about the synchronization primitives. But it's the oldest topic in computer science, like topics in literature. It's also related to distributed system. I don't know, consistency control, concurrent control, consistent models, and other stuff. So it's like a lot of theory here. But practically, this is what it looks like. And the logic behind this is totally different than when we are searching, for example, for XSS or SSRF or any kind of other SQL injection and any kind of other attacks. So you need to understand the business flow somehow. And usually, if you are in a team, You understand already what you are building. And then you can ask correct questions if you have a security team. So I suspect, for example, this is something wrong here. Could you please help? Be kind, and you will get a reply. So any questions to this thing? No? OK. Then I continue. So I hope it's not boring so far. and also like personally when I attend to the conferences I really go to the topics where I don't understand anything because I want to hear something new so this is a different kind of like mindset and I see also the people it's also okay that I use for example these things that just listen to the same topic which I use but it is not for me it's not informative I want to hear so here For example, if you first time see such kind of attacks and you go to your team and then, oh, there is some kind of flaw, maybe we can check or double it, just learn more and all this stuff. Yeah, good. The third scenario, it's a lot of scenarios that you can bring, but this is called single endpoint race conditions. and itself a vulnerability is this labs in email change feature contains a race condition that enables you to associate an arbitrary email address with your account quite cryptic right it's a love description but in essence what is it so you want to change your email but you won't also change others emails and the confirmation of the email change comes to you so not imagine you change your email the confirmation comes about X person you won't also change his email to you so this is a vulnerability there's the race condition and yeah let's just go for go for it and so Bay's idea is identify erase conditions that that lets you claim an arbitrary email address, change your email address to Carlos, as this Carlos is poor always for this labs. The winner is successful guys, and Carlos is who get hacked every time. I don't know why access admin panel and they let the user Carlos. So you see the simple task, but if I could change the others' emails, I would just hide myself and leave with it for a long time that I got a lot of things to do. So there's no need to delete Carlos and immediately say, I was here, until that is not your enemy. But yeah, anyway. Then there is a kind of email specifically for this lab, and we are going to access it as well. So let's just access this lab and see what's going on. And things getting dangerous and dangerous. It was a simple web shell upload and you lose all the money for the coupon and now you lose your users. So it's like one more. I'm going to one more time to our Poop Suite and just group this back but I need to already clear the history. I don't need this guy and okay. They sell the caution sign. Must need it. If we go to the Wiener and the Peter, so we have also the email client. Let me zoom in a bit to others, probably. I had to do it before, but sorry. So basically, your email address is this, and then your inbox now is empty, obviously, but let's just change it. What I would like also change is to change the same. So I don't want to change my email address for now, but I want also to change, to see how the update email functionality works, so usual case, as we say. Please click the link in your email to confirm, okay, cool. If I refresh my email so I got the confirmation to confirm your email change, click here to confirm. Let's just click here. email has been successfully updated nothing dangerous right it's quite usual so you confirm you change your email all good until some guy come until the the you spot a race window this is important and let's just explore how the requests working we send the post request for the email change and and yeah so it has a sister of token it has an email as a body and what else nothing special right And you'll have a session. Now, I would like to do this the same, like second time, to understand the uniqueness of the link. So, you know, you update your email several times to understand what happened behind. And then if you send to repeater, and I just want to send it directly, probably it works and we got back wait I don't need it and we got back to our email and it refresh okay so now to confirm your email change and let's do one more time I just interest it's interesting how it acts so we have a three and we clicked it it's already confirmed right but how about this guy this link is invalid so but how about the newest one okay the newest one is succeed so I suspect it only stores the last email so the last unique token for the email confirmation and it invalidates the others so instead of probably appending the request it just updates the database and during this update or before is a time is a race window right time time time window before getting updated I can send multiple offices emails and with different and with different data it sounds cryptic yeah it's just wait I'm I'm interested in, OK, let's just duplicate this 10 times, just a case. And create a group email. Let's just give well-deserved name. And then purple. It's purple or red. And then I just want to duplicate, OK, just five times. let's just duplicate five times to make it easy and keep Savina then then I also want for example to make it test one like to make it test to manual work that to make it test 3 and test 4 and then I don't know test 5 and directly let's just send it as a as a parallel no let's just say that in a sequence as a a separate connection let's see what's going to happen with our email confirmation so I just send it in a group and go back to our okay if we explore and one more time so we sent five right right, test5, okay, we got test5 for test5, we got test4 for test4, so it's aligned, you know, test4 sends for test4, test5 sends for the test5, yeah, I really suspect that if I send it in a concurrent manner, it will send test5 to test4 for the confirmation. information. Let's just see if it's true. If it's true, then we can update others' email to ours. I don't know. Have fun with that. So send in group. Let's see. Oops. Yeah. Refresh. So we got test four, we got a test three for test five. So this is also, you see this is a simple step, you just send the confirmation email, how dangerous it can be. But now it's turned out, okay, if you didn't do this atomic, or you do this as a, and give the type frame or time window, you can get others email confirmation to your email. So test 3 was, for example, me, and test 5 was you, and you got updated my email, and you're happy, my account. So it's account takeover. I don't know, you owned, you know, this hacker's terminology. Yeah, that's crazy. And I would like to click here to confirm. Okay, this link is invalid, but still, it's a dangerous vulnerability. So you expect, what to expect to the email confirmation? It's also related to these MFA, you check for the code of the second factor authentication and your defence layers. It can be related, for example, you have an API rate limit but you didn't check the rate limit atomically, you just get back an immediate response or you have 100 requests left and I just boom you if it's a race window between the check and use your API for, for example, 1,000 times. So I just overrun the limit. This is this kind of attack. Yeah, there's quite dangerous things that we talked about. But as you see, it's a lab. And probably not all of our applications falls under poor condition like this. But it's important to get how it tastes. This is the thing. This is the core logic behind my talk. So just understand, okay, there is some kind of problem with my code, but I don't know where. It's also okay. So you spot a problem, but you can't understand what is a problem, but it's a first step. You are going to explore, research, understand. And this problem, these conditions hit Facebook badly in a couple of years ago. There was such a condition that they gave a blog post that it took eight months to understand what was going. So you are not, I'm not sure if it took six months or eight months, but I'm not pretty sure the length. But there's a blog post from the Facebook engineer. You can also search for that. So it's quite dangerous. No questions so far from the auditory. Not from Solido. It's crazy. Either the topic is...

Speaker 2 [56:41]

Okay, I think we have something on the studio now.

Speaker 1 [56:43]

Should I continue or you ask a question?

Speaker 2 [56:50]

Yeah, just continue.

Speaker 1 [56:50]

Yeah, just. continue yeah just continue okay so we are done with all scenarios but I also prepared some kind of I don't know don't show this quote to anybody but it's a naive way of getting the race condition in a simple actions and we can explore it right away so and what's it so basically mimics that we are trying to for example we are trying to update an email right as before and here we have a storage of the email so you user one has an email user one and user two has an email user too and basically I put just the time sleep one to give a window no race window manually but imagine this a network like I don't know a cheetah or a database like anyway but here it's simplest because it's synchronized I know that there is a window I know that there is a second set I can run into but the important part of spots is window in a real world but usually people is findings is also so I'm just sending an email with with a multi-sided environment I am trying to update their first email to new email one and the second email to new email two and basically if it's properly synchronized that means that one and two is updated synchronized but how about I need to run this let's just run first our application right and this is a flask with all kind of I don't know China stuff this is a main pie but wait yeah yeah yeah okay so it's correct email change to new email to for the user one and email changed for new email two for user two we just updated both of the users email with the same user so it was the same thing that not not the same thing but it's closer right the same logic you expect your update function of the email to be used as a single thread that you didn't check it in a multi threaded environment you just write your code right and you didn't expect okay somebody will hit your update email hundreds of times and that's why you are not prepared this is a problem so be prepared this kind of stuff and if for example here this temporary email storage accessing the email getting an email and updating an email was a single transaction like single logic unit there is no time frame to inject in the middle it's just you are secured yeah it's a It will wait until, for example, one is updated, then it's second. So that's called a synchronization. If you read about multithreading, multiprocessing, and in the literature it's called synchronization primitives, and you read about semaphore, I don't know, lock, thread lock, why it's called synchronization? What we synchronize. We synchronize access to some shared state. This is the essence of the problem. critical section we spot a critical section for us the critical section is update an email right we defend it and we exclusively lock it for example right and we synchronize the access we don't allow um um i don't know multiple set of concurrent access to the my critical section it's the same as with the database if you read about the database internals there's also like consistency models, how to make the database consistent. If you have 100 million accesses to the same row, how your database ensures that the data corruption is not like fire. This is the same logic. So the people over decades trying to solve this problem, but we understand that it's needed in distributed systems. We understand it's needed, for example, in a database. but nowadays also we need to understand this needed for the web applications so you can hit badly by this vulnerability okay cool no questions and we are go

Speaker 2 [61:27]

All right, perhaps we have some questions. We have questions.

Speaker 1 [61:29]

That's a tough question.

Speaker 2 [61:29]

Yeah. All right, so...

Speaker 1 [61:32]

Is it hard

Speaker 2 [61:45]

So it says have you seen any attack vectors that make use of very high request latency of HTTP requests?

Speaker 1 [61:55]

higher latency this is a this is a problem not also the HTTP but TCP itself so basically what this boob sweet guys did if you if you spot the attack thing so you see there's a single package attack. What they support that in HTTP2, you can stack in one single TCP package a multiple HTTP2. I need to pick the proper terminology, but imagine that you have a single TCP package injected a multiple HTTP and until there's also like synchronization inside the package until the last bit it gets TCP doesn't understand that it's done so this is kind of also a problem. These guys solved this by inventing this in attack vector but it can be really hard without this tool. But maybe you can use this latency. But I didn't see. Mostly the latency is problem when you try to spot this, spot the race window. So it's non-deterministic. One time it's five seconds, for example. One time it's one second. It's really hard to where to inject Yeah, I'm not sure that I have answered this question, but I did my best.

Speaker 2 [63:39]

Okay. All right. The next one is how would you start to implement security checks in your code reviews?

Speaker 1 [63:45]

Um, sorry?

Speaker 2 [63:46]

How would you start to implement security checks in your code reviews?

Speaker 1 [63:47]

How? called reviews? That's a good question. So one thing is automated checks for the standard vulnerabilities. So it's kind of imagine there's thousands of kinds of standards, known vulnerabilities, right? And you need to add this as your pipeline or as your strategy of the check. There is a free tools, paid tools, but you can start to add those static analysis of your code And plus the runtime checks that, for example, I could support some kind of vulnerability because this library contains this vulnerability. And this also heads to the supply chain problems of the things. If you have a lot of dependencies and you didn't check the vulnerabilities for these dependencies in your project, if one of the dependencies get vulnerable, that means you are in a danger. So supply chain check, static checks. All this stuff are already, how to say, done by us. You need to use the services of this. Plus, if you have, like, security team, you can inject them as a process of their software development. This also can be important. For example, you have a PRD doc. You need to collect the requirements, and you ask for the security research engineers, could you please check the requirements and my implementation plan? Basically, they will add, okay, for example, your API accepts some kind of JSON, but you didn't check the size of the JSON, for example, right? You didn't check, okay, you checked the contracts, what kind of fields you accept, But you didn't check also what type of data you, for example, accept. And this thing is a different window. The security engineers will put in this talk, and you understand, oh, okay, add this check, add this check, add this check, add this check, and you have created that. So you have 15 changes, and all related to the security. And out of box, you have already covered most scenarios.

Speaker 2 [66:17]

Can a slow internet connection to a server be used to prevent risk condition attacks or make the attacks more difficult?

Speaker 1 [66:26]

Yeah, as I said, that unstable, so you need to probe, and then you need to probe. So you need to check where the, this is a hard part of the RAISE conditions, that where exactly this time slot, like the rates window. And the network jitter or network problems that say the TCP problem, HTTP problem, I don't know, connection and latency, can be some kind of, I don't know, I lose your, so if attacker loses the appetite, that means, okay, this time you are lucky. But that doesn't mean that somebody is not going to gain more appetite against you and come back one year later. So it's not a preventive action, no.

Speaker 2 [67:15]

All right, there's another one says, how does Bobsuit compare to tools like Wireshark and Fiddler?

Speaker 1 [67:22]

Wireshark is a network package sniffer, so it's like you analyze a network package. The burp suite is for penetration of the web application and an API. It has different purposes, so it's different. I can't see that how, for example, burp can replace the Wireshark. There's also over Zap is a candidate to the book. So it is also free. But either way, there is also free of charge web scanners that you can inject it to your CI pipeline. So it's just out of box, just in a case. Also, there's kind of automated excesses checkers. I don't know, automated secret checks. This is also important topics that you don't accidentally push the secrets to the court places and then, because there are a lot of companies that constantly getting these secrets.

Speaker 2 [68:26]

For a pen tester testing a set of attacks to a black box target software, how to decide that the attack won't succeed and I have to move to the next attack? I think this is more for a pen tester or something.

Speaker 1 [68:45]

something yeah I know I can I can reply for this so you know basically imagine that you are a pen tester in a company and you you got a request of okay I have API with I don't know 10 endpoints and I need to check it right and you you need a decent plan on okay what is the outcome so not output but outcome of of the process so why I need to check for example some API version 1 and slash something because I need for example it's business critical this need to be secured this there's a kind of requirement security requirements against this endpoint and then you read it and you just pass all over and create a report for example okay during my exploration for this endpoint this requirement but it's failed and then you have a clear outcome and it affects a business directly then it has a severity high and people jumping and trying to fix it so it's just a chain of the process not a not a single sure

Speaker 2 [69:50]

Do you know any examples of the limitless discount hack for big amounts of money? What? Sorry? Is there like an example? Have you experienced any kind of example concerning this discount kind of hack? Yeah, sure.

Speaker 1 [70:07]

Yeah, sure, sure. My next slide is all about this. Okay. So real hacks. Okay. How people did it and got the money. So I'm going to show it.

Speaker 2 [70:16]

All right, thank you

Speaker 1 [70:18]

I was expecting this.

Speaker 2 [70:22]

Do we have any other questions from the audience here?

Speaker 1 [70:26]

Are you happy? Okay. So there is a special GitHub repository for top-raised condition found vulnerabilities, and the people got money, bounty, so it's real hacks. And you see a lot of them, so it's not like toy, as I did, it's not a toy project to hack. that people really got hacked and lose a massive. Let's just read one by one. So I just bring three of them because I think they are important. So race condition allows to redeem multiple times gift cards, which leads to free money. So is this the answer to the question? I guess yes. And it has a severity of high. Let's just zoom in. And the weakness is called business logic errors. So it's important to read also categories for these reports. You understand, okay, race condition, you hit in a business logic. This is most critical thing. If you have a flaw in a business logic, you're going to lose money, reputation, I don't know, any kind of stuff, right? And I have found race condition vulnerability, which allows redeem gift cards multiple times. This is how she, he can easily buy stuff just buying one gift card and redeem it over and over again. Let's see to the screenshots. So this guy buy a $25, but also use it as $175. Yeah? This is the ambition of this. One gift card and seven times more. You can see that he is also showing the succeeded responses. also from Burp Suite, and also you see that, no, not this one. You see that like a box and 175 boxes instead of 25. So this guy's got hacked, and the reverb.com, it was in 2019, not too old, so it's usual, and disclosed in 2020. Disclose that means it's fixed and there's no vulnerability anymore. And here you can read the discussion. It's also important to read the discussion why. For example, I am an attacker or bug bouncer, right? I found this thing. I filled the report. But it's important also to read the response from other side, from the security team of this company, how they react. react so it is there's a lot of plenty information that they try to explain otherwise you hit it it's also critical or why they think for example it's not critical and they don't give you a bound to and other stuff but usually if you spot a race condition it can have a higher higher vulnerability a higher severity the second one the second one is medium but it's also category the very importance the concurrent execution using shared resource with improper synchronization this is it like has a definition of the race condition for this for this company or for this team so race condition for them at this moment is somehow there's a shared resource but it's not properly synchronized the access to this and that leads to vulnerability race condition in performing performing great tests are those duplicated payments you see they lost one more time in the money you duplicated the payment that's important and here for example this guy observes that 500 payment was sent from hack one two weeks ago. An impact is given that this went, in two weeks they lost a lot of money until they disclosed and closed this vulnerability. So basically the logic is, if this guy clicks retest payment, so what is a retest payment? So you have found a vulnerability, right? And you got a bounty, for example, $5,000, and another side, the company fixed the vulnerability and now requests a retest from your side. So you should confirm that it's fixed. So this is a retest payment. And they pay extra for the retest because it's not a part of your original bike. It's already fixed and you need to get extra money. And then you request several times the payment and then you get the payment and, yeah, instead of 100, you get 500. And then they resolved, it was 2018, and it resolved immediately, one day. No, not one day, no, wow, it's two months. Anyway, they live with that a lot. Probably, I don't know, I'm not sure why it gets, for example, what they can prevent, they just temporarily close the retest payment until they fix it, because it's not an original payment. It can be closed, for example. I'm not sure how they mitigate it. So you see that it's a concrete execution using shared resource with improper synchronization. Amazing. The third one, the third one is interesting. Also, race condition leads to undeletable group member. Imagine you have some members that you cannot delete in your application. And OK, it has a severity law, I guess. Why? Because you need to be a valid member anyway. So it's not an account takeover, or it's not a true hack. But I am a member of your company, but I add myself as a non-divertible member. So you cannot remove me. This is funny. And this is a discussion. OK, there exists a race condition, which is a user can add themselves twice to a group, which will make them unrecoverable from group. And when first time, imagine that you're as a software engineer or developer, and you read it, report. How? Your first question, how? How you did? Because you were not prepared, or you are not aware of such kind of things. This is important, like being informed of something. And it's closed pretty late, but I'm not sure they give a bounty for it. And time of the weakness is takto. It's called takto, time of check, time of use. Basically, if you search for that, it's a simple thing that, OK, at the time of the check and the time of the use, there's a kind of window, and I can run the race there. This is important. Yeah, so good so far. No questions? No. OK. I have 10. OK. Yeah, cool. I have time. And a few things that, OK, you understand what is this, and you also want to dig deep on the topic. But I would suggest, for example, try to understand the documentation about the concurrent execution. So the concurrent execution, concurrent models, consistence of models and other things that are related. So you can read the literature, understand the core problem, and then you act. And then you see that it's a primitive, for example, lock objects. Just read what is a lock object. Now the synchronization is clear. What is a synchronization, right? We synchronize the access. And the lock is a primitive, lock is a synchronization primitive that is not owned by a particular thread and lock. And each language has its own implementation. So concurrent model of Python can differ from the concurrent model of the Java or of the C Sharp or Golang. So you need to, okay, I'm not suggesting to read Java and to understand their concurrent model, but if you are interested in this thing, in the topic, you can compare the implementations and understand both what's going on behind this is one thing it's important also there's a special research areas called as I said concurrence control consistency models under the umbrella of distributed systems so if you read about distributed systems nearly all of those topics are related to synchronization so how to make for example 5000 machines to talk to each other without breaking each other and then this goes and starts there's a lot of books you can explore what is it yeah I'm pretty much done for this tutorial and the talk and this is me thank you very much for coming and is my contact let's cut contact on