HTB: Oopsie Walkthrough (Linux)

Oopsie is a retired Linux HTB machine, it was fun and fell quickly, I didn’t take the best screenshots along the way but I’ll fill in most of the blanks as we go. As usual, the machine is retired on HTB and any flags are now refreshed.

Initial Recon showed just TCP:80 and TCP:22 open, so a small surface area to play with, I decided to go straight in with GoBuster using the common.txt file included with the Seclists package on Kali.

Another scan using a different wordlist from the same Seclist package I came across the cdn-cgi directory, naturally, I aimed gobuster with common.txt again.

Now we know there’s an admin page, time to get the browser and Burp on the go

So, we have a nice admin logon page to play with, as usual I tested it for SQLi bypass and simply because this is HTB and the machine name 😉 I checked for password re-use and struck gold!

The username is admin, the password is one that has been used on other HTB machines, I’m not going to share the password, we can’t upload as admin, I didn’t capture the page but we’re told to be superuser.

Looking at the Account page you can see the Access ID for the admin account, but there’s no superuser or any other account listed. Going to burp history we can see that the attempt to open the page included a cookie with user(the Access ID) and role (admin) values.

Let’s have some fun with Burp Intruder, see if we can find the superuser access ID.

We now have the uploads page and upload a reverse shell.

With the shell uploaded we need only browser or Curl to it.

Netcat catches it for us as usual and we have a foothold as the www-data account; python fixes the tty for us…check my other articles for how that’s done.

After a little digging around we find db.php which helpfully contains plaintext password and account name for MySQL.

Given my previous success with password re-use on the admin portal. I tried the new user and password combo against the SSH service and bingo, password reuse at it’s finest.

Next up is PrivEsc

We can see Robert is in the “bugtracker” group, checking for what this group has access to provides a single binary in /usr/bin/

Checking out the attributes of “bugtracker” we can see it’s owned by root; so Robert’s membership of the “bugtracker” group provides permission to run the bugtracker binary which executes as root.

Using strings against the binary reveals the “cat /root/reports/” command it’s going to execute.

The issue here and route for us, is that the “cat” command is being called without an explicit path “/bin/cat”, instead it relies on the PATH environment variable. We can exploit this with some simple path tampering (in the Windows world this is loosely equivalent to unquoted service paths), all we need to do is create our own “cat” and manipulate the PATH variable to force the Bugtracker app to use our “cat”.

Share this:

Related