University web CTF

Introduction

This was my university CTF during my Masters' degree in Cybersecurity, we compeeted in team and I was paired with one of my university colleague and friend and we completed all the challenges. At that time I was at the start of my journe in the Cybersecurity field, even if now theese challenges seels really easy at during that period was enlighting and they tought me many things about web and web security.

This writeup is written in a way to show not only the solution but also my process and my thinking behind and action. I believe that learning skills is relatively easy thanks to various resources available for free but the hardest part is to have the right mindset to approach the challenges.

Level 1 - Password validation

The URL of the first level was given as the starting point:

http://eth-lab.di.uniroma1.it:55001/eishohwohpahxooy/

As stated during the Web Security Challenges lectures, the first thing to do when trying to hack a web page was to actually use the web page as it was supposed to be used. So, in other words, you simply do what the web page asks you to do.

Therefore, we first tried to log in by inserting a random username and password, as requested from the web page itself.

As we expected we received an error:

Then, we tried to dig further inspecting the web page’s source code.

We observed in the form above that on clicking Submit we actually call a function named verify.

So, we started looking for a function called verify in the Console section (right click - inspect element).

As seen from the picture above, we found the function Verify. Now jumping into the definition of the function, to check in detail what was the Verify function supposed to do.

I was in plaintext in the if condition highlighted in red, the password and the username needed in order to access the web page.

Level 2 - Stop!

Once solved the Level 1, the URL of the second level was found:

http://eth-lab.di.uniroma1.it:55043/zeitaeveishiidef

This was how the Level 2 looked like:

In this level there was only the possibility to insert a password, there was no username. So, let’s try to insert a random password.

Well, wrong password! As done in the previous level, we tried to look further by analyzing the source code.

Reading the first lines we could clearly see that there was a function implementation, the function seems to encrypt the text inserted in the password field, with MD5 function. The first idea was to decrypt what seems to be a ciphertext in the if condition.

After using numerous MD5 online decrypters without success, we decide to keep on reading the source code. While having a closer look at it, we noticed two images references in the inspector section: one was a reference to the picture in the home page “kitten.jpg” and the other one was a picture with a hidden parameter “srct.png”.

Putting the cursor on top of the reference scrt.png a window popped up with a text.

The text on the picture was the right password to insert in order to solve the level.

Level 3 - Password verification

As usual, in the previous level, we found the link to access the next one:

http://eth-lab.di.uniroma1.it:55208/bahjeighahveerae/cgi-bin/index.php

As tried before, as a first step when trying to relate to a new web page, we tried to follow the natural instructions of the web page itself, this time trying to insert a username and password. We decided to try with some random and basic combination of username and password (e.g. admin:admin).

As we expected, we received the following error message:

So, we analyzed the source code once again.

In the source code, we found a hidden parameter with a “False” value, we inspected the web page source code proceeded by changing the value from False to True, and submitted the form.

After applying the above-mentioned changes, we finally obtaine the page with the URL of the next level.

Level 4 - Secure Browser

This was the URL for the Level 4:

http://eth-lab.di.uniroma1.it:55192/ogheucaiheikohhi

This level consisted of verifying our browser in order to have access.

Only connections from Kevin Browser Rocks were accepted.

What we had to do was to pretend to be using the browser “Kevin Browser Rocks” by changing the headers in our browser. In order to do that we useded an extension (Simple Modify Headers, on Firefox) that modifies the header and we set it up to do it during the requests.

As we can see we modified our browser user-agent to Kevin Browser Rocks.

Nice! Now the page accepted only connections from Russian (.ru) websites. We have our extension and we can also use it to simulate Russian connection by changing our browser referrer.

By applying this new change, we could finally get the URL to access the new level.

Level 5 - Headers

This was the URL obtained to access the fifth level:

http://eth-lab.di.uniroma1.it:55051/iengohquoochieza/

The first thing we did was to analyze the source code.

“Never show secret.txt to the users”, this caught our attention so we searched for the file called: secret.txt, in the current web directory. As we knew the URL was nothing else than a path to a file in a webserver, and we added secret.txt to the urr to the URL in order to find it.

At this point, we needed to find the secret at cgi-bin/getsecret.js and referred to ourselves as di.uniroma1.it/supersecurepage, which could be done with the Firefox extension as done in the previous levels.

After having done this, we were able to find the URL to the next level.

Level 6 - Your personal secret

The URL for the level 6 obtained by solving the level 5:

http://eth-lab.di.uniroma1.it:55005/oaxiweitheerohra

Here we applied the usual method of trying one of the most common combination of username and password (admin:admin).

Digging in the source code and reading it did not reveal anything. So, we turned our attention to the URL, and we found a reference to a PHP script with the field uid exposed userinfo.php?uid=0.

The field was set to 0 which was our current user’s ID, so we tried to change it with 1 and we were sent to another web page, Angelo's web page. Then we started to change the value of uid until we found the user with the secret at uid=6.

Level 7 - Password protected

The URL found by solving level 6:

http://eth-lab.di.uniroma1.it:55215/shieduekecometha/

As stated in the picture, in order to log in we need an e-mail and the username.

So, we tried a fake and random email and a random string as a password. At that point, we noticed that the site check if the username was an e-mail just by checking if the username string contained the character @.

We could try to insert any kind of random email for instance admin@admin or even teacher@something but we always received the same kind of message. After having tried some standard types of email, we thought that we could try by inserting a real teacher’s email address.

Our first attempt was to try with course main teacher’s email but it was not the right solution. Then we tried again with our laboratorys teacher’s email and finally, that one was the key solution for the next level because we were able to log in as a teacher and consequently obtain the link for the next level.

Level 8 - Your persona secret pt.2

Let’s start with the URL obtained from the previous levels:

http://eth-lab.di.uniroma1.it:55493/zangiepaegaizeex/cgi-bin/index.php

Our first attempt was as usual the standard combination of admin:admin as username and password.

And we noticed a code in the URL which should be the ID of the current user.

We tried to figure it out why the current user (admin) has that precise value, and we also noticed that the string admin and the string nqzva had the same length, so we started to match the characters from the first string with the ones from the other string hence a=n, d=q.

We immediately notice that the distance between the characters was 13, so we tried to ROT13 the string admin and the result string was nqzva.

After many random tries, our attention was captured by the sentence “Page created by MessyAdmin” present on the first page of the level.

So, we decide to ROT13 the string messyadmin which resulted in zrfflnqzva which has been copied and pasted to the URL instead of nqzva and we ended up with the MessyAdmin’s page where we found the link to the next level.

Level 9 - Password protected pt.2

URL obtained from the 8th level:

http://eth-lab.di.uniroma1.it:55413/eereezeighohfeim

The first thing we do was to try the admin@admin:admin username and password combination but without success. Then we investigated the source code looking for some information and we found a comment that said “Never show the sessions.txt file”.

As usual, we proceede to change the URL trying to open the sessions.txt file.

After having seen the information in this file, we immediately understood what we had to do because we already knew about an attack where if you can steal a user session you can log in as that user.

While this session was saved in the cookie, we proceeded to open the cookie and change the value. To obtain the cookie we had to log in as a Guest user.

Once in the page, we check if we received the cookie.

We notice that the value of this cookie was different from the value found in the sessions.txt file.

So, we proceede to change it, and our new cookie was:

After reloading the page, we end up in the administrator’s page and logged as him, where we could find the link for the next level.

Level 10 - Bytestream

The link obtained from level 9:

http://eth-lab.di.uniroma1.it:55255/leighaghuuzasaex/

As usual, we tried the same combination (admin:admin) without any success.

Then we tried many random combinations of usernames and passwords, for instance, we used some teachers’ usernames just in case we could get it correct, but it failed every time.

The last attempt was to analyse the source code of the web page where we found the following script:

Inside the script, there was a variable called password_hashes which contained the correspondent encrypted password for each user.

The first thing that came into our mind was MD5, so we proceeded to decrypt the hash with an online tool haskiller.co.uk (this site does not exit any more). It resulted in a very good website where it was possible to encrypt and decrypt by using various algorithms.

In addition, you could also download their wordlist in case you need to proceed with an offline hash cracking.

Obviously, we took the hash of the user admin and try to log in with the new credential admin:qwertyuiop and we succeeded in proceeding to the next level.

But it did not end here because after decrypting the hash we notice that the function checkPassword does not decrypt the user input in order to access the admin page.

So, we tried to reverse the function to understand its logic.

The function follows these steps:

We followed the script steps in order to solve the level.

In fact, we can access the right page by adding 62aa4dcf.html as the script was doing.

Level 11 - Brutus system

We started from the following URL:

http://eth-lab.di.uniroma1.it:55025/eepugeighovoorou/

The first attempt was to use a few commonly used numbers such as 0000, 12345, 1337 but without any success.

As usual, we proceede to analyze the source code where we found a script like the previous levels and our attention was caught by a function called checkPassword.

As we can see the if statement checks if the number was between 1 and 1000000 excluded, if it was NaN (empty form) and if it hah at least six digits.

So, we supposed that a valid code could have been a number between 1 and 999999. Then the function hashes the code with MD5 with the salt localsalt and checks if the result hashing was equal to 4d1ea4c067daa4dec768540bbcfe80b2.

The first idea was to decrypt the hash to retrieve the right value but due to the lack of an online tool we proceeded to hash with salt all the passwords from 1 to 99999 and check which one matched the string: “4d1ea4c067daa4dec768540bbcfe80b2”.

In order to do it we wrote a Python script.

And this was the result produced by the script.

As expected, the code worked fine.

Level 12 - PHP

The URL obtained from level 11:

http://eth-lab.di.uniroma1.it:55528/ithochexephizoof

In this case, there was no form or text box where to write so we proceede by analyzing the code where, as usual, we found a script and we focused on a portion of the code.

Here, we can see that the script creates a new link concatenating two strings to complete the URL.

These strings were: “cgi-bin/users.php” and “?filter=”, after which a value was concatenated, but we didn’t know which kind of value could follow the string.

We decide to copy and paste the strings to the URL to complete it ourselves and append something in order to execute an XSS since it was JavaScript.

We tried several times but for some reason, no one of our attempts worked (in addition, we were not really good in JavaScript!).

Then we noticed what the home page was prompting: daemon, root, and mysql, things that reminded us of Linux users so we tried to execute a simple Linux command instead of a JavaScript one.

Once find the files in the directory we could try to open secretusers.txt with the command cat.

And the file contain the link for the next level.

Level 13 - Bash Envirorment

The starting point was the URL obtained from the previous level:

http://eth-lab.di.uniroma1.it:55277/neifeesuopheeghu/

The first thing we did was to write something in the text box to see what happens and we tried many different kinds of values to check how well it validated the input.

As usuals we proceede to analyze the code in search of information or scripts to reverse. In fact, we fpund a script, and in particular we focused our attention on the function “getenv”.

In addition, we saw the sanitize function on the user input which removes the illegal character from the input: that was the reason why it did not generate any kind of error.

Also, here we could see the making of the URL like the previous levels so we attempted the same method as in the level 12 without any success.

The response was “no variable found” and also when we put an input it prints a “TESTENV” which recalls something similar to the bash environment variable so we decided to do some research to see if there were any vulnerabilities with the bash in the past or something similar.

The first thing we found was something called “Shellshock”. The document explained what and how to exploit this vulnerability providing the string to use in order to execute remote shell commands.

The string was: () { :;}; echo “NS:” $(</etc/passwd).

Digging more into the topic we found a PDF where the shellshock vulnerability was explained alongside its syntax.

So again, we tried to remake the right link appending cgi-bin/env.php?filter= and tried to copy and paste the string suggested but for some reason, no one of the strings were working.

During the laboratory lessons, we were suggested by the teacher to use Burp so we tried again with it.

The first thing we did was to copy and paste the payload found on the internet on the link like we did with the browser but without any success.

After a few research and random tries, we figured out that we have to encode a few characters and substitute the spaces with +.

So we encoded the “:” and “;” with “%3a” and “%3b” following the guide in this link, and our resulting payload was ()+{+%3a%3b}+/bin/ls but still did not work for some reason.

Then we remembered, after a lot of struggle, a file called “user.php” on level 12 which has a particular comment.

The referrer was disabled for that level and maybe it was enabled in this one, so we tried to add the referrer in our level URL.

Which works perfectly, and we succeeded in listing the directory content.

The next step was to read the secret4uou0.txt with the command cat and we sent the payload with a different command /bin/cat+secret4uou0.txt where we found the link for the next level.

Level 14 - SQL Injection

The starting point was the URL obtained from the previous level:

http://eth-lab.di.uniroma1.it:55424/aetiasaeghongohx

At the beginning of this level, we had no idea what to do, we try to register a user, we try to log in as admin:admin but nothing, then we remembered our Lab class on XSS attack and we try to do it but without success.

Only after few days later we had a class on SQL Injection then we tried to do so.

First of all, we had to find where the vulnerability was, it could be in a form, since it was very common to find them, or we could perform an injection from the URL.

We checked all the forms by writing inside the “ ’ ” character to see if we would get any query error, and we found it on the page “new user” on the field “username”.

Since the class material was not published yet we used a friend presentation about the JSQL Injection from GitHub.

So, our first attempt was to find the number of columns, by doing the queries until we reached the 6th.

And saw where were the leaks:

Once found that leaks were on row 1, 3 and 4, we tried to find the schema names with the following query.

The schema found did not help us.

The result shows a lot of names of tables but we were looking for something particular where it was possible to find users information.

The “users” table seemed to perfectly fit our case, so subsequently it was possible to retrieve the column names.

Due to a bad query without the “WHERE” statement it shows all the columns on the database but luckily, we managed to find the interested columns.

At this point we have all the necessary information to try to retrieve the credentials of the users.

Also, this query gives us as result few credentials (username and password) but we had to choose only two of them.