TryHackMe - Advent of Cyber 2024 - Day 12 Walkthrough
Hello and welcome everyone, I am Tib3rius and I'll be walking you through day 12 of TryHackMe's Advent of Cyber 2024 event. If you're already participating this year I really hope you're having a lot of fun and learning some new skills. However, if you're new and wondering what this is all about, let me take a moment to explain. TryHackMe is an online learning platform for cyber security with a huge amount of content aimed at all skill levels, from complete beginners to seasoned experts.
Every December, they run the Advent of Cyber event, where a new beginner level challenge is released each day, starting on the 1st and ending on the 24th, Christmas Eve. All the challenges are 100 percent free to play, and every question you answer correctly gives you a raffle ticket for the prize draw at the end of the event. This year there are over $100,000 worth of prizes to be won, and if you complete every single task by December 31st, you'll be entered into the grand prize draw, with a chance to win tickets to DEF CON plus accommodation. If you enjoy this video, please give it a like, consider subscribing to my channel, and leave a comment with your thoughts. Without further ado, let's dive right into day 12. Okay, so we're on task 18, web timing attacks, day 12, if I can't steal their money I'll steal their joy.
So this part of the story reads as follows. Wareville's bank had a huge turnover this year, and expected a massive profit before the holiday season. They were eager to disclose this news to the townspeople during the SOC-mas celebrations. However, to their surprise, things went the other way around. After completing the annual calculations, the accountants were shocked to see a considerable loss.
They observed discrepancies in the account balances. The bank called McSkidy to help investigate these users' fraudulent transactions. Upon analyzing the bank's website's transactional logs, McSkidy found some interesting transactions. Users, including the Mayor's team, initiated multiple transactions from Wareville's reserve accounts at once. Surprisingly, all these transactions succeeded, despite exceeding the user's current balance.
Glitch was already aware of the critical vulnerability that Mayor Malware and his alliances exploited. So today we do need to start the AttackBox and we also need to start a VM. We can start the VM down here by clicking start machine and that should start up momentarily. And then if we scroll to the top of the page, we can start the AttackBox by clicking this button. Okay so the AttackBox is running and it's in this side view so what we can do is we can come down here and click the view in full screen button and it will launch a new tab and that just gives us a little bit more room.
Now we're going to be using burp suite which you can find under the web folder in the applications menu and just click burp suite community edition. When that loads make sure temporary project in memory is selected. Click next. We can just use burp defaults, that's fine. And we'll wait for the project to start. Okay, once burp is loaded we can head over to the proxy tab.
Turn off the intercept here and click open browser. And we do need to allow burp's browser to run by going to settings, burp's browser, allow burp's browser to run without a sandbox. So let's do that right now.
Settings. burps browser allow burps browser to run without a sandbox. Okay, let's just close that. And then we can open the browser again. And here it is.
All right, let's maximize that. Okay, if we go back to the walkthrough, we can actually copy this web address. And we can paste it in using the clipboard here. So you just have to paste anything there.
And then we should be able to just paste it here. Press enter and we get the login screen. If we go back to burp and click on the HTTP history, we can see we're getting requests sent through. All right, let's go back to the walkthrough and what we can actually do here is we can click exit split view and that should allow us to just view everything on one page and we can switch back to our AttackBox using the tab at the top. Okay, so let's scroll down to the walkthrough.
Okay, so we see we can log in with the account number 110 and the password tester. So let's do that right now. And it looks like it worked.
If we go back to Burp Suite, we can see the post request to the login. So what we can do, we can actually transfer money to another account number. So let's transfer some money to account 111. We're going to transfer 500 and if I click transfer, We see that worked, transferred 500 to account 111. The balance of our account is now 500. We started with 1000, we transferred 500, so that makes sense.
So if we were to go back to Burp Suite, we can see that there's this post transfer request, and if I send it to repeater, I'm just right clicking and clicking send to repeater, we can see that this is a post request to slash transfer. It uses account number 111 and the amount is 500, right? 500. If I were to resend this request, it will work because obviously we still have 500 in our account.
However, if we tried to send it again, It would fail. TryHackMe have provided us with the code for the transfer money functionality. So let's review it now and see if we can find any potential vulnerabilities.
Okay, so the first thing that the code does is check if the balance of our user's account is greater than or equal to the amount of money being transferred. As long as that check passes, the rest of the code in this block will execute. The first part of this code block uses an SQL statement to increase the balance of the target user's account by the amount of money being transferred.
And then the commit function is called to ensure this is actually executed on the database. The second part of the code block uses an SQL statement to decrease the balance of our user's account by the amount of money being transferred, and then the commit function is called again. Now, there's no bypassing the initial balance check. However, there is a vulnerability with the way the SQL statements are executed. Since two separate statements are used and there's no locking or synchronization being performed, there is potential for a race condition to occur.
In this scenario, a user only has one account balance stored in the database, but a web server is designed to handle multiple requests that may arrive in quick succession, and the web application code will be executed concurrently for these requests. Since every line of code has an execution time, and I/O operations like database reads and writes generally take longer than CPU operations, like logical comparisons and calculations, it's possible for the following to occur. A user with a balance of 500 sends two requests, A and B, in quick succession to the web server. Both requests try to transfer 500 to another user, and because they arrive at approximately the same time, they are processed concurrently. The processing for request A reaches the balance check, and since the user currently has a balance of 500, and request A is asking to transfer 500, the check passes. The first SQL statement to update the target account's balance is then executed.
Since this takes time, the processing for request B may start. It reaches the balance check, and the user still technically has a balance of 500, because request A hasn't changed the user's balance yet. So this check also passes, and request B starts executing the first SQL statement.
Meanwhile, request A has finished executing the first SQL statement and it starts executing the second, which does update the user's balance. Request B finishes executing the first SQL statement and starts executing the second. Meanwhile, request A finishes execution entirely and shortly after, so does B. If we track the balance of the accounts throughout this sequence of events, the user sending the money ends up with a balance of negative $500, and the user receiving the money ends up with $1,000 more than they started with. Remember, although no money has been created here, the application's safeguards trying to prevent users from sending more money than they have were defeated, so this is still a vulnerability in the application.
I used two requests here for simplicity, but there's no reason why this couldn't work with more. The only limiting factor is time. As soon as one of the requests updates the user's balance to a value lower than the amount of money being transferred, all subsequent requests which hit the web server are going to be rejected. So, to pull off this attack, it is important to set it up so that all our requests reach the server within as small of a time frame as possible.
In HTTP 1. 1, there are a couple of ways we could do this. Sending all the requests concurrently, or using a technique called last byte sync. So what I want to do is show you the difference between sending, let's say, 10 requests via just concurrent threads versus the last byte sync technique. And the way we're going to do that is we're going to go to extensions, and then the BAP store, and then we're going to search for Turbo Intruder.
And there it is. Scroll down here, click install. Okay, and that's installed. Now I'll go back to the proxy, and what I'm going to do, I'm just going to get this rather innocuous request here, get dashboard, send it to repeater, and I'm just going to turn it into a post request by right clicking, change request method, and I'm just going to do, x equals one.
Click send. Doesn't matter if the method's not allowed, we don't actually really care about the response in this case. All we care is that we have a request that we can send to the web server.
And what I'm also going to do is open up Wireshark. You can do that by going to Applications, Internet, Wireshark. We'll maximize this. And I'm going to start listening on this ENS5 device here. Okay, excellent. I'm then going to apply an HTTP filter, and we're going to go back.
I'm going to right click this request. extensions turbointruder send to turbointruder. And that should spawn a window. And turbointruder just uses Python scripts, but it does everything concurrently. We need to change a few things here. Concurrent connections we want as 10.
Requests per connection we want as just one. And then all we really need to do here is basically just say for i in range 10. then we're going to go engine. q. All we need to do here is q1 target request.
We don't care about any of this and we also don't care about it being interesting. We can just delete a few there and that should be fine. I think that's going to work. Let's click attack and hopefully what that will do is send 10 requests in quick succession.
There we go. 0 to 9 and if we go back to Wireshark, we should see, here are all these requests. So we get the first one I think is there, the second one is there, third, fourth, fifth, sixth, etc. And if we check the time, so the first one was sent 73 seconds, dot 424, 426, 435. So, realistically, all within a single second, but in terms of the actual fractions of a second here, there is obviously some difference. Now what happens if we use last byte sync? So if we go back, we're going to use last byte sync now.
So what I'm going to do now is create a group, tab group in repeater, call it group one. And we're going to add request two to it, tab two. This is the request that we sent using Turbo Intruder. If I create that group, now what I can do is I can hold down, I can click in this group, hold down control and then R and it's going to send it another request, basically identical to the same group. So if I do that eight more times, now we have ten requests in this group one and they're all the same, okay? But now what I can do is I can go to this drop down here and I can say send group in parallel last byte sync. And if I click that, there we go.
Let's go back to Wireshark, and if we scroll down now, these are the requests that were sent using last byte sync, and if we look, they're all sent within the same second, but not only that, the fraction of the second, right, the milliseconds here, all 36, all this one 37, but all extremely close. Much, much closer together than the previous example, right? So a lot of these Sent 42, 43, 44, 45, etc. Okay, so these were all sent extremely quickly.
And they all arrive at the server roughly the same time. And there's a good reason for this, and we can actually investigate this. So let's click this first one. And I'm just going to expand this a little bit. And we can see that it says, actually let me, let me expand this up slightly. So we can see this says two reassembled TCP segments.
Okay, previously, if we go back to one of the ones sent using Turbo Intruder, this was just one packet. Okay, one single TCP packet, that was it. The entire request is contained within this one TCP packet. We go down here.
to the first one sent using Last Byte Sync, two TCP segments. Basically two TCP packets. This is true for all of them. And you might notice something here, and this is why it's called Last Byte Sync. This first packet had 779 bytes in it.
This second packet had one byte. And if I actually click this first packet, it will select on the right pane, everything that was sent within that packet. Now unfortunately, if you transfer your cursor over, it sort of messes up. So if you click this, and then we sort of go up and above and around, and then scroll down, you'll see absolutely everything is selected, apart from that last byte, that one. All right, you can just see it. So if I move my cursor over here, there's that one.
That's the one byte that was not sent in that packet. And it was sent in this one. If I click this packet here, it selects that one byte. And that's true of absolutely every single one of these requests. And that's how LastByteSync works by sending absolutely every single byte of the request, except for the last one.
of every single request it wants to send at the same time, it waits for all of those packets to be sent, and then it sends those 10 remaining single byte packets at once, or as quick as it can. It's understanding the fact that the web server is not going to start processing any requests until it receives the full request. And so the web server is just holding all of these first packets in memory waiting for the final byte that it knows is coming, and then it receives the final byte of all 10 requests at roughly the same time, because obviously it's much quicker to send a single byte than it is to send 779 bytes, right? We're talking fractions of a second still, but it is definitely quicker to send one byte than it is to send 779 or 780 total. And so that's why the attack works so well, is because you're almost guaranteeing that those last 10 bytes of all of these requests is going to hit the server at the same time and then all the requests are going to be processed as close as they can to each other. Okay, now that we understand the last ByteSync attack, we can actually use it against our account on the application.
So we're going to go back to repeater to this first request that we used to transfer 500 to account number 111. And what we're going to do, we're going to add this to a new group, Group 2, and I am going to hold ctrl and press R nine times. Okay, and if I then go to send group in parallel, last byte sync, and click send, wait for them all to go through. Now let's refresh the page here, and yes, we now have a balance of negative four thousand five hundred dollars. So we started with a balance of five hundred dollars, we tried to send five hundred dollars ten times, it looks like it worked, and that's the last byte sync attack in action.
So what we need to do now is use account number 101 with the password glitch. Attempt to exploit the vulnerability again by transferring over 2, 000 from his account to account number 111. So we'll log out, and we'll log in to account 101 with the password glitch, and we'll attempt to transfer over 2, 000 to account 111. So let's start by doing 1, 000. Okay. Go to burp suite, proxy, scroll down to this, this is the transfer request, 111, 1, 000, right click, send to repeater, and then we will create a new tab group, group 3, gonna collapse that one, and again, control R, 9 times.
Send group in parallel. And if we go back and refresh. There we go. We have a balance of negative 9000. And we have the flag. We can copy this.
And then we can complete the room. And if you enjoyed this task, there is a race conditions room that you can go to and learn more about race conditions. Thank you for joining me for day 12 of TryHackMe's Advent of Cyber 2024. I hope you learned some new things about race conditions, the last bite sync attack, and why it's more reliable than using pure threads. If you enjoyed the video, please give it a like, subscribe to my channel, and let me know in the comments how you're enjoying this year's Advent of Cyber so far.
I'll be providing a walkthrough for another day this year, so make sure to keep at it, and I will see you soon. Happy hacking!
2025-01-02 12:47
