Getting Started with Ethical Hacking -Practical Cyber Security: THM “Advent of Cyber” Writeup
Step by step guide to applying your cyber security knowledge practically with TryHackMe’s Advent of Cyber Challenge
There are many people who are familiar with the concepts of cyber security but are not aware about how to use that knowledge practically. I, for example learnt a lot about security concepts from the university but was not much aware of how to apply them. So I started learning about them myself and came across CTF(Capture The Flag) competitions which encourage ethical hacking to learn more about cyber security. I am writing this article to beginners in CTFs who know the concepts but don’t know how to use it. I chose the Try Hack Me’s Advent of Cyber challenge for this so that we can start from the very basics and learn how to work on practical cyber security applications. I will introduce you about how to think and which tools you can use when you come across a cyber security challenge.
This challenge consist of 25 challenges with one for each day. First 5 are focused on setting up the environment, which you can follow on your own. Let’s start from task 6.
Task 6: Inventory Management
Once you go to the page localhost:3000, you will be presented with a Login page. Your first question is finding the name of the cookie used for authentication. To checkout the cookies used for that webpage, you can press F12 in Google Chrome to Access Chrome Dev Tools. Then goto Applications tab -> Cookies sidebar and select the current website. You will see that there are no cookies stored yet. This is because you have not logged in yet. Once we have a look, we can see that there is a Register page as well. So I registered using the credentials
email:email@example.com, password:abcd and successfully logged in. Now if you check your cookies, you will get something like in the following image.
You will be able to see that there is a cookie with the name authid. Voila! We have found the answer to the first question.
For the next question we have to decode the cookie. My cookies is
authid: dGVzdHY0ZXI5bGwxIXNz The cookies are usually encoded using base64. So let’s use any online decoder tool to decode the value of the cookies. When we decode the cookie we get the value as
testv4er9ll1!ss . We can see a familiar part in this —
test . That is the first part(also called local part of the email) in the email I used to register
firstname.lastname@example.org . So we can safely assume that cookie is created by
base64encode(local part+v4er9ll1!ss) . Thus the fixed part of the cookie is
v4er9ll1!ss which answers our second question.
Now to the last part. This is a bit trickier. You have to find what the user
mcinventory requested after logging into his account. To do this we have to log in to his account. But how? This needs a bit of knowledge about cookies. Basically cookies are used to store some information of the user. Here we are authenticated using the cookie. So what really happens is that when we log in using the credentials, we are given a cookie and after that we use the cookie to authenticate ourselves. What if we could use
mcinventory ‘s cookie? We should be able to identify ourselves as
mcinventory 😉. So how do we do this?
This is how. We know a cookie is created using the function
base64encode(local part+v4er9ll1!ss) . We can assume the local part of his email address is
mcinventory . So let’s try
base64encode(mcinventory+v4er9ll1!ss) . Now you get
bWNpbnZlbnRvcnl2NGVyOWxsMSFzcw== . There is a trailing
== , which is used for padding and sometimes you can safely ignore it. Now let’s go to our cookie tab in Dev tools and set the new cookie value and refresh the page. And you are in McInventory’s account! Oh yeah! Now you can see he has requested a
firewall which answers our last question. 😃😃😃
Task 7: Arctic Forum
This one is pretty easy if you know the right tool. One of the main thing we do in a web security challenge is identifying the hidden URLs/ directories. When only a few URLs like
/home, /login are visible to the user, very important URLs like
/admin,/backup will be available in a server which have higher privileges or important information. While these are not visible to the user, these are visible to the owners or the maintainers of the server and they are often not secured enough.
We can use a simple brute force search to identify such URLs. DirBuster is my go-to tool for this. Let’s fire up DirBuster and set the configurations and start brute forcing. Each wordlist in DirBuster contains a most common list of URLs/directories used in a server. It send requests to each of these URLs and records the result. By looking at the result we can identify the hidden URLs/directories easily.`
The ones with response
200 gives us the available pages in the server. I tried
/login, /Login and found out that they lead to a regular login page. We are redirected to this page when we go to the
http://10.10.88.131:3000/ anyway, so this is not hidden. We can see that there is a
/sysadmin link which is not visible to the user. So let’s go to
http://10.10.88.131:3000/sysadmin . And we get the admin login page!
What we have to do now is crack the admin login and we get complete control of the server. Pretty amazing right?
Another important thing to try is inspecting the source code of the page. You can use Chrome Dev Tools again for this.
There is message saying “Admin portal created by arctic digital design — check out our github repo”. Let’s go to this repo and check it out.
Here they give us the username and password for the admin login. In real world, nobody would be laying out credentials publicly like this. But the task shows how you can follow breadcrumbs to find simple security vulnerabilities.
Now you can login using the given credentials and find the answer to the third question is EggNog and that completes the challenge.
Task 8: Evil Elf
This task provides us with a network capture file to find some information. WireShark is the most popular tool for working with network capture files. So let’s open up the packet with WireShark and goto packet 998 as we need its details. From the Destination column you can get the answer for the first question. You can right-click the packet 998 and go to conversation filter and apply TCP to track the conversation between the selected source and destination adresses.
Next right-click the packet 998 and go to Follow and select TCP stream. This will give us the conversation between them.
We can see in the first line that the word
ps4 has been added to
christmas_list.txt . So this is our second answer.
Then we can see the
/etc/shadow file of the system has been opened. This file stores the information of the users of the system. When we go down the file we get the information of the user
The line relevant to
buddy:$6$3GvJsNPG$ZrSFprHS13divBhlaKg1rYrYLJ7m1xsYRKxlLh0A1sUc/6SUd7UvekBOtSnSyBwk3vCDqBhrgxQpkdsNN6aYP1:18233:0:99999:7::: . You can read more about the format of this line from here. From the format we can see that
$6$3GvJsNPG$ZrSFprHS13divBhlaKg1rYrYLJ7m1xsYRKxlLh0A1sUc/6SUd7UvekBOtSnSyBwk3vCDqBhrgxQpkdsNN6aYP1 is the hashed password of the user. More about this format can be read from jpollard’s answer here.
$6$ - represent that this password is hashed using SHA-512 algorithm
3GvJsNPG - Salt used to hash the password
ZrSFprHS13divBhlaKg1rYrYLJ7m1xsYRKxlLh0A1sUc/6SUd7UvekBOtSnSyBwk3vCDqBhrgxQpkdsNN6aYP1 - hashed value
Obtaining the original value from this value using HashCat is well explained in the Challenge’s resource materials here: https://docs.google.com/document/d/1ZVsOtW7mM-4neZZ4QtYCEp__exiMrvlUCXTxhB-zyxk/edit
Please note that encrypting and hashing are two different things. You can decrypt and encrypted string but you cannot decrypt a hashed string. The only way to get original value from a hashed string is to get a wordlist hash each word with the same protocol and configuration and check whether the generated hash is equal to the hashed string we have with us.
As the article is getting too long I will stop part 1 from here. Let’s continue the rest with part 2… 😃