This write-up is the second part of the HackThis Main Level challenge solutions, which includes Levels 7-10. For the first part, which includes Levels 1-6, please follow this link.
Let's continue from where we last left off.
Main Level 7
Again and again, I started this level by looking at the source code. However, this time everything was as usual, and there were seemingly no hints within the source code to hack the username and the password.
I also tried entering a random username and password, for testing the response of the website to a wrong credential. Again, no help.
This time, I decided to use the Show hint button to get some clue on how to proceed. The hint was quite helpful:
The password is again stored in a txt file. This time however it is not as straight forward as viewing the source.We even can't find the .txt file, which stores the password, by using a search engine?! Because search bots have been excluded??! Alright, this is the way to go. There must be a way to tell the search bots exclude something within the website.
You wouldn't even find the page by using a search engine as search bots have been excluded.
Have you ever heard of robots.txt? There lies our answer.
Robots.txt is the file, which is put in the root directory of the website, that tells search bots not to index some parts of the website. And good news is, since it should be seen by the search bots, it is a public file; so we can easily reach that!
Now, I navigated to https://www.hackthis.co.uk/robots.txt. This is the file we would like to see:
User-agent: *
Allow: /
Disallow: /contact.php
Disallow: /inbox/
Disallow: /levels/
Disallow: /levels/extras/userpass.txt
Disallow: /users/
Disallow: /ctf/8/php/*
User-agent: Mediapartners-Google
Disallow:
Sitemap: https://www.hackthis.co.uk/sitemap.xml
As seen, robots are disallowed to index some parts of the website. For our purposes, we seek for a .txt file among them. Can you see that? Our candidate is /levels/extras/userpass.txt.
Let's visit https://www.hackthis.co.uk/levels/extras/userpass.txt. We encounter the following .txt file:
48w3756
u3qh458
It seems like the first line corresponds to the username, and the second line to the password. Trying this combination, we complete the level!
Lessons Learned: Using robots.txt is a way to hide information within a website from the search engine bots. However, it is not wise to put this information; since it shows the locations of potentially precious information to the hackers! Moreover, it is the choice of the search engine itself to whether comply with the rules identified in robots.txt or not; so it may be of no value for some search engines!
Main Level 8
Again, and again, and again... I started by looking at the source code of the webpage. Searching for the keyword Username gave an important result in this level, similar to Main Level 4:
<input type="hidden" name="passwordfile" value="extras/secret.txt">
So, our target is to reach the location extras/secret.txt. Navigating to https://www.hackthis.co.uk/levels/extras/secret.txt, we get the following:
This seems like a binary-encoded username and password pair. We should decode this binary to text format. There can be various binary representations, so it is not as straightforward as to put the numbers into a decoder, and get the result. Each different binary representation would yield to a different text.
However, partitioning the binaries as nibbles (i.e., 4-bits groups) seems like a hint to me. The first thing comes to my mind is the possibility that these binaries representing hexadecimals. To the readers who are unfamiliar with these terms, I recommend you to Google about binary numbers, hexadecimal numbers, and binary-hexadecimal conversions.
At this point, I tried to convert each nibble to its hexadecimal equivalent. This yields a very good candidate for the username and password combination:
Username: b00b
Password: feed
However, this combination fails. Before giving up on the idea to convert to hexadecimal, since this looks like a good candidate, let's try them in capital letters, as both lowercase and uppercase characters can be used to represent a hexadecimal:
Username: B00B
Password: FEED
Voilà! This is the answer!
Lessons Learned: Storing the user credentials in a publicly accesible file is a terrible idea, even if different representations are used. In this level, decoding from the binary format was relatively easy; but even if there was a complex and unknown decoding algorithm, someone can eventually hack and solve it --not maybe today, but definitely tomorrow.
1011 0000 0000 1011
1111 1110 1110 1101
This seems like a binary-encoded username and password pair. We should decode this binary to text format. There can be various binary representations, so it is not as straightforward as to put the numbers into a decoder, and get the result. Each different binary representation would yield to a different text.
However, partitioning the binaries as nibbles (i.e., 4-bits groups) seems like a hint to me. The first thing comes to my mind is the possibility that these binaries representing hexadecimals. To the readers who are unfamiliar with these terms, I recommend you to Google about binary numbers, hexadecimal numbers, and binary-hexadecimal conversions.
At this point, I tried to convert each nibble to its hexadecimal equivalent. This yields a very good candidate for the username and password combination:
Username: b00b
Password: feed
However, this combination fails. Before giving up on the idea to convert to hexadecimal, since this looks like a good candidate, let's try them in capital letters, as both lowercase and uppercase characters can be used to represent a hexadecimal:
Username: B00B
Password: FEED
Voilà! This is the answer!
Lessons Learned: Storing the user credentials in a publicly accesible file is a terrible idea, even if different representations are used. In this level, decoding from the binary format was relatively easy; but even if there was a complex and unknown decoding algorithm, someone can eventually hack and solve it --not maybe today, but definitely tomorrow.
Main Level 9
This time, a slightly different screen welcomes us. There is a link, Request details, below our username and password form. This link seems like the way to go.
Upon clicking the link, we see a different form, asking for an email. Let's inspect this email form:
<form method="POST">
<fieldset>
<label for="email1">Email:</label>
<input type="text" name="email1" id="email1" autocomplete="off"><br>
<input type="hidden" name="email2" id="email2" value="admin@hackthis.co.uk" autocomplete="off">
<input type="submit" value="Submit" class="button">
</fieldset>
</form>
<fieldset>
<label for="email1">Email:</label>
<input type="text" name="email1" id="email1" autocomplete="off"><br>
<input type="hidden" name="email2" id="email2" value="admin@hackthis.co.uk" autocomplete="off">
<input type="submit" value="Submit" class="button">
</fieldset>
</form>
Have you seen the interesting part? Let's look at that closely:
<input type="hidden" name="email2" id="email2" value="admin@hackthis.co.uk" autocomplete="off">
We again encounter a "hidden" field, and it apparently has the email address of the administrator. What about tampering with this information as we did before?
To solve the challenge, I changed that email address to an artificial email address I own, say darkvanilla@vanillasec.net, using the Inspect pane of Google Chrome. Moreover, I entered the same email address, darkvanilla@vanillasec.net, in the input field of the form. Clicking the Submit button, it's done!
Lessons Learned: Again, hidden HTML fields are not hidden! And again, users can always change client-side code; so the server-side should always check against any tampering.
To solve the challenge, I changed that email address to an artificial email address I own, say darkvanilla@vanillasec.net, using the Inspect pane of Google Chrome. Moreover, I entered the same email address, darkvanilla@vanillasec.net, in the input field of the form. Clicking the Submit button, it's done!
Lessons Learned: Again, hidden HTML fields are not hidden! And again, users can always change client-side code; so the server-side should always check against any tampering.
Main Level 10
This is the last Main Level of HackThis. Again, I started by viewing the source code of the webpage. Searching for the keyword Username again gave an interesting result:
<input type="hidden" name="passwordfile" value="level10pass.txt">
We again see a "hidden" HTML field. This field points to the passwordfile, so it's our target. Let's navigate to https://www.hackthis.co.uk/levels/extras/level10pass.txt. I was able to guess this link directly since I saw the directory extras in the preceding levels. However, it is also possible to do a Google search within the website with the name of the .txt file.
Google can easily find the file, since it is not included in robots.txt. By the way, there is no point to ask; "What if it was included in robots.txt," right? :)
Reaching to the text file, we get:
This seems like the credentials, stored in an encrypted format, with colon, i.e., ":", being the delimiter separating the username and the password. At this point, we need to decrypt this to pass the level.
Inspecting the format of the encrypted output for both the username and the password, we see that they are of the same length, and constructed with the same character set. In particular, they are both 64 characters long (you can run the command echo X | wc -c, where X is the hash above, to count the number of the characters on Linux Terminal, i.e., Bash; or can use an online source), and each character ranges from 0-f (apparently, hexadecimals). Since each hexadecimal (one character) is represented by 4-bits, we see that each encrypted output has length 256-bits. Any guesses for the encryption, or should I say hashing?
Noticing that passwords are generally stored as hashes, and seeing that each hash in this case is of 256-bits length; our number-1 guess for the hashing algorithm is SHA-256, which is the most popular hashing algorithm of 256-bits length.
Okay, we have a guess for the hashing algorithm; so what can we do to decrypt?
Well, there is no decryption process for hashing. Hashing is a one-way function, i.e., we cannot predict the text version from a hash. So, what can we do?
The only chance we have is to guess. We can write a script to guess many options, and try to match the hash of our guess, and the hash we have to get the answer. However, in most of the cases, this is infeasible --unless we have a very common username and password.
For our purposes, let's simply use an online service. Searching in Google for the keywords "SHA256 decrypt online" will lead to such an online service (this is one of such a service). Entering our hash strings above, the decrypting website gives us the answers:
Username: carl
Password: guess
So, we are lucky that the credentials are from the common words and easy, since they are included in the online database. Moreover, we are lucky that the website doesn't use salts for their hashes; which makes it even harder to guess.
Entering the credentials above, we are done!
Lessons Learned: Again and again, hidden fields are not hidden! It is not a good idea to put passwords file within the website directory. Moreover, even if encryption/hashing is used to protect information, they can be broken. In addition, for the security of users, long and complex passwords should be mandated by the website, and passwords should be stored as salted hashes.
Thank you everyone for reading my blog! Stay tuned for more write-ups!
site:hackthis.co.uk filetype:txt level10pass
Google can easily find the file, since it is not included in robots.txt. By the way, there is no point to ask; "What if it was included in robots.txt," right? :)
Reaching to the text file, we get:
69bfe1e6e44821df7f8a0927bd7e61ef208fdb25deaa4353450bc3fb904abd52:f1abe1b083d12d181ae136cfc75b8d18a8ecb43ac4e9d1a36d6a9c75b6016b61
Inspecting the format of the encrypted output for both the username and the password, we see that they are of the same length, and constructed with the same character set. In particular, they are both 64 characters long (you can run the command echo X | wc -c, where X is the hash above, to count the number of the characters on Linux Terminal, i.e., Bash; or can use an online source), and each character ranges from 0-f (apparently, hexadecimals). Since each hexadecimal (one character) is represented by 4-bits, we see that each encrypted output has length 256-bits. Any guesses for the encryption, or should I say hashing?
Noticing that passwords are generally stored as hashes, and seeing that each hash in this case is of 256-bits length; our number-1 guess for the hashing algorithm is SHA-256, which is the most popular hashing algorithm of 256-bits length.
Okay, we have a guess for the hashing algorithm; so what can we do to decrypt?
Well, there is no decryption process for hashing. Hashing is a one-way function, i.e., we cannot predict the text version from a hash. So, what can we do?
The only chance we have is to guess. We can write a script to guess many options, and try to match the hash of our guess, and the hash we have to get the answer. However, in most of the cases, this is infeasible --unless we have a very common username and password.
For our purposes, let's simply use an online service. Searching in Google for the keywords "SHA256 decrypt online" will lead to such an online service (this is one of such a service). Entering our hash strings above, the decrypting website gives us the answers:
Username: carl
Password: guess
So, we are lucky that the credentials are from the common words and easy, since they are included in the online database. Moreover, we are lucky that the website doesn't use salts for their hashes; which makes it even harder to guess.
Entering the credentials above, we are done!
Lessons Learned: Again and again, hidden fields are not hidden! It is not a good idea to put passwords file within the website directory. Moreover, even if encryption/hashing is used to protect information, they can be broken. In addition, for the security of users, long and complex passwords should be mandated by the website, and passwords should be stored as salted hashes.
Thank you everyone for reading my blog! Stay tuned for more write-ups!
