competition where everyone can be a hacker

All requests that the browser sent when opening the page are visible to us in their entirety – both the raw HTTP request with all fields and headers, and the raw response from the web server.

We look around. sitemap. First, let’s go into every nook and cranny of the website to understand what you can do on it.

Having archived the page, we delete it here. Our goal is to pierce all the buttons in the web application and interact with the site in every possible way.

Burp, meanwhile, records all requests that are sent to the server during our actions. We can scroll through them on the same Proxy → HTTP history tab, but there is also a more convenient view to cover the whole picture.

Let’s look at the Target → Site map tab.

Here, Burp has collected all the addresses that the browser accessed into a convenient tree structure – as if these were not separate requests and API endpoints, but a folder structure on disk. On one screen, we see the entire device of the web application under the hood and can view the details of specific requests. For example, we see how the /api/last_archives handle gave the browser a JSON with a hateful link.

We try to break. repeater. In the sitemap, you can see that the /api/delete_archive endpoint is also available to us. We pulled it when we deleted a page that we had just archived ourselves. It takes an archive ID, and we know the archive ID of the cringe post link (dmzvwk9d75).

For someone else’s archived page, of course, we will not be shown the “Delete” button, but let’s outwit the web application and send a manual deletion request.

Wherever an HTTP request is visible in Burp, it can be sent from the right-click menu to Repeater, a tool for manually editing and sending requests.

In the repeater, we can change the request as we like, and immediately send it to the server and see the response. In the heat of manual testing, instead of clicking on the orange Send button, the combination “Ctrl + space” saves time.

Alas, the server recognized the substitution. Instead of the 302 Found response that we received when deleting our own archive, we received a 500 Internal Server Error when trying to delete someone else’s, and the archive remained on the server. It turns out that here the application checks the passed ID.

Now let’s pay attention to another API handle – /api/user, which is used when looking into your profile on the site.

Firstly, it accepts some ID from the client, we have 12. Secondly, in addition to the data that we see on the page, the server also returns a password in response, more precisely, its hash. Judging by the 32 hex characters, this should be the MD5 algorithm.

Indeed, there are many results that this is the MD5 hash of the password 12345678, with which we registered. Looks like we’ve found the first vulnerability in the app! It can be attributed to Information Disclosure – the server sends the browser more information than it needs to display, including a hash of our password.

Now let’s remember about the parameter to this request, which we had equal to 12. Let’s see what happens if we send another number.

Wow! We changed the user number, and the server gave us someone else’s data: someone else’s e-mail, name and password hash. We found a vulnerability Insecure direct object referenceIDOR: the server does not check if we have the right to request user #11’s data, and easily gives it back.

Just by using the site in a browser, we would not have come across this error: when viewing a profile, the request is always sent with our own ID. But as soon as we started sending requests manually and seeing how the web server would respond to unexpected data, it turned out that at this point the developer forgot to check whose profile we are requesting.

By the way, if we were able to remove the cringe post by substituting its ID, this would also be an IDOR vulnerability. However, in that API handle, the developer took this into account and added a check.

We enumerate users. intruder. We are only the 12th user, and, in principle, it would not be difficult for us to manually substitute the previous numbers in the ID parameter and request data from other accounts. But let’s ask Burp to do it.

Just like any request can be sent to the Repeater, the Send to Intruder item is always available on the right button – an automation tool that sends many requests. The ones we need.

On the Positions tab, we set up a place where the data will change from request to request. You can configure several such places in the query text, each is framed by §paragraphs§.

We now need to change only the ID. Press Clear § to reset all automatically placed places, if any. Select our number 11 in the request and press Add §. The number will be framed in paragraphs, which will mean that it is he who will change.

Now, on the Payloads tab, we configure what will be substituted for this place. Burp Suite can take values ​​from different places (Payload type), but we need the simplest type – Numbers. For example, let’s iterate over ID from 1 to 100. From: 1, To: 100, Step: 1.

All settings are ready, you can start – Start attack.

A list opens, which Burp populates with responses to automatically generated HTTP requests. We can sort the results by the length of the answer or just scroll through them in a row – and user number 5 will be the one we are looking for cringe_catcherwhich archived the ill-fated link.

The server gave us his mail cringe_catcher@gmail.com and the password hash: 64d1d1b4028f97e9d5648532ec21ffad.

Now, only ignorance of his password separates us from logging in as this user and finally deleting the archived post. We know the hash, but to enter you need to enter a password that matches it.

Cracking the MD5 hash. Unfortunately, this hash is not googled – it seems that the password is more complicated than 12345678. You will have to crack the hash yourself.

A hash can only be cracked by brute force: trying to hash many different passwords until we guess. A good tool for quickly iterating over different hashes is − hashcat. Let’s use it.

To iterate a little smarter, we’ll do a dictionary attack with rules. Take a very popular password dictionary rockyou.txt, which contains 14 million common passwords from the 2009 leak, and the dive.rule set of rules that comes with Hashkat is applicable to it. Each rule will be applied to each password from rockyou, mutating it a bit. So we can quickly try not only the passwords that someone already used in that leak, but also their adequate variations.

Run: hashcat 64d1d1b4028f97e9d5648532ec21ffad rockyou.txt -r rules\dive.rule -O

Literally in a second, hashcat came across a password that matches the hash – kucing33. By the way, it really was not in the dictionary itself, the rules helped.

You can also try to find the hash on different sites that make up the databases of matching hashes with passwords. You can google them, for example, on md5 lookup online.

One of those from the first page of Google’s search results actually knows our hash.

A paid service is also useful cmd5.org, in which it is convenient to check whether it is realistic to crack a certain hash at all. If the service immediately offers to buy a result from it, then the password is not too complicated and you can try to choose it yourself or search on the sites.

We reach the goal. So let’s put it together. We found two vulnerabilities, due to which the server prompted us with cringe_catcher@gmail.com mail and the user hash, and were also able to successfully find the password corresponding to this hash: kucing33.

We go to the site, knowing the login information.

We are inside and we have user rights cringe_catcher!

It remains to press a couple of buttons to remove the cringe page and receive a flag in gratitude.

What else is important to know about IT’s Tinkoff CTF

If the task seemed interesting and you want to participate in the competition, we will share the details.

How difficult will the assignments be? As we have already said, there will be two leagues in the competition: the Novice League and the Experienced League. For each of them there are 30 tasks of different difficulty levels – from simple to complex. For those who have not yet played in the CTF, we advise you to register in the Rookie League. If the tasks seem too simple, you can go to the League of Experienced, but it will be impossible to go back.

Who can participate? Teams of 1-3 people. If you still don’t know who to play with, you can look for teammates [в нашем чате.]

What prizes will the teams receive? There will be three prizes in the Beginners’ League and the Experienced League. We will give cash prizes to the winners.

Rookie League:

1st place: 180,000 ₽ per team.

2nd place: 150,000 ₽ per team.

3rd place: 120,000 ₽ per team.

Experienced League:

1st place: 360,000 ₽ per team.

2nd place: 240,000 ₽ per team.

3rd place: 180,000 ₽ per team.

Can I participate offline? Yes, we have organized offline platforms in the following cities:

— Voronezh;

— Yekaterinburg;

– Izhevsk;

— Innopolis;

— Minsk;

— Nizhny Novgorod;

– Novosibirsk;

— Omsk;

– Ryazan;

– Samara;

— St. Petersburg;

– Saratov;

— Sochi;

— Chelyabinsk.

At the sites, you will be waiting for communication with other experts, board games, quizzes and even horizontal bars, where you can warm up in between tasks. Specify your city during registration, and we will send an invitation.

That’s all. Register, compete and win! Good luck.