sowatt@home:~$

TryHackMe - Advent of Cyber 2 Part 1


TryHackMe room write-up: Advent of Cyber 2 (days 1 - 6: Web Explotation )



Well this is the second time that I missed the Advent of Cyber event on TryHackMe, but that doesnt mean I can’t get prepared for the (hopefully upcoming) Advent of Cyber 3! I’ll seperate the daily challenges by the challenge category starting with web exploitation, lets jump in!

Day 1: A Christmas Crisis



We begin with a well written and concise description of many web based fundamentals, always good to refresh and reinforce those concepts. I have the machine running and the first step is to check out a webpage the machine is serving.



So it looks like we have a login prompt. As instructed, I created a user and password. The first question asks what is the name of the cookie stored for this webpage. To locate this, open the developer tools in in firefox (by pressing f12) and look under storage:



The next question asks us what encoding scheme is used for the cookie. I guessed by looking at it that it wasn’t base64 encoded (which I think it was for the original advent of cyber) so the next scheme I tried was hex. Passing it through a online hex decoder resulted in the following:



So the cookie is just some hex encoded JSON, huh. Oh hey, thats the answer to the next question! Since we know the encoding scheme, we should be able to: 1.Copy the decoded JSON
2.Change the value of username to match “santa”
3.Encode the new JSON and we should have the answer to what Santa’s cookie is

And now that we have Santa’s cookie, we can update the value of our cookie to that and successfully log in as santa.



Now we turn the production lines back on and finish out the day one challenge.

Day 2: The Elf Strikes Back!



This days challenge involves taking a look at GET Parameters, the structure of URL’s, and file uploads which have the potential to create a reverse shell. I knew filtering file uploads was an obvious best practice but I was unaware of the actual methods that are deployed to accomplish this, you learn something new everyday. I put the machine IP in to my browser and was served this webpage:



We were given an ID at the beginning of the room, lets append that GET parameter to the end of the url and we should have access. That should also be the answer to the first question.

Now the second question is to learn what file extenstion is allowed when uploading a file. I would usually open up burpsuite and brute force the file extensions (or write a python script with the requests library to accomplish the same thing) but I noticed that it already tells us which extensions are accepted in the webpages source:



So if it accepts Image related extensions, we could try and upload a file with an additional non-acceptable extnesion (the dossier referred to this as a double-barrelled extension) and upload a reverse shell. After getting a successful upload message, I checked the three main common upload directories that were mentioned in the dossier (could have brute forced them with gobuster too).



it appears to be uploaded in ‘/uploads/’, I used netcat to listen for any connection on the port I specified in the reverse shell annnnd:



Nice, we are now the apache user on the machine and can read the flag.txt file.

Day 3: Christmas Chaos



Day 3’s challenge takes a look at authentication and how default credentials are a big no-no. This days description pointed to the following resource https://github.com/danielmiessler/SecLists/ which will be very handy in the future ( <– note to self). This room appears to be pretty short, here’s what we have to do:

1.Capture a login request using burpsuite.
2.Send the request to burpsuite intruder and add the provided Username/Password list to the payload sets.
3.Make sure we are using the “cluster bomb” attack type and run the attack.



Sorting by length we can see that “admin” : “12345” is different from the other attempts, I used these credentials to log in and get the flag.

Day 4: Santa’s watching



This day’s challenge is split between working with gobuster (which I have used quite often in the past) and wfuzz (which I have never used, and after completing day 4’s challenge am surprised because it’s kind of awesome). I ran gobuster to see what directories I could find with the following extension:

gobuster dir -u http://{Machine IP} -w /usr/share/wordlists/dirb/big.txt -x html,php,cfg



I found the /api directory, navigating to it revealed the file “site-log.php”. Now its time to fuzz the date parameter in the format YYYYMMDD. Here is what my wfuzz command looked like:

wfuzz -c -z file,wordlist -u http://{Machine IP}/api/site-log.php?date=FUZZ 



While most of the results returned nothing, we see that the value “20201125” has a word on it that is 13 characters long which sounds an awful lot like a flag to me:



NOTE: We could have added “ –hw 0 “ to the wfuzz command to filter out all of the empty logs. Either way, we found the flag!

Day 5: Someone stole Santa’s gift list!



This day has us taking looking at some SQL injection attacks. The first question asks us to find what Santa’s secret login panel WITHOUT brute forcing directories. I had to look up the hint on this one, it states that the answer is found in the question. I tried the directory /santapanel and that worked.

I used:

' OR 1=1 --+ 



as my username in order to gain access to the webpage. Then I guessed at a simple UNION query which dumped the info I was looking for:



In order to answer the final two questions, I captured a request in burpsuite and saved it to my tmp folder. I then used the following sqlmap command to dump the entire database:

sqlmap -r request --dbms=sqlite --tamper=space2comment --dump-all



All of the parameters necessary for this were located in Santa’s notes to himself (yay for documentation!).

Day 6: Be careful with what you wish fon a Christmas night



The final topic in the Web Exploitation section of this Advent of Cyber is Cross-site Scripting! This room was pretty short, there are two xss vulnerabilities on this website. The reflected one is part of the GET parameters in the url, the stored xss is accomplished by adding a malicious js payload instead of a “wish” and it will fire every time the webpage is loaded.

This concludes the “web explotation” category for the advent of cyber 2!