HTB-Writeup

Initial Enumeration

Open ports (22, 80)

Port 80

Find the /writeup/ subdirectory

Landing page:

/robots.txt:

/writeup/:

Cannot brute force for other content

The web app has a DoS filter in place, which bans your IP address if it causes too many HTTP 40x errors. I ran into this problem several times when attempting to bypass the filter. It meant I couldn’t search for subdirectories or subdomains.

The /writeup/index.php page, for example, has a ?page parameter which might introduce a LFI vulnerability, but I wasn’t able to enumerate possible payloads because my requests after so many failed attempts got blocked.

/writeup/admin requires a HTTP basic auth prompt

I tried a few default credentials, but no luck.

Local user

The web app is vulnerable to SQLi which reveals login credentials ( jkr:raykayjay9)

The site is using CMS Made Simple:

I found an SQLi exploit for version <2.2.10, which gives us a user hash:

I cracked the password using Hashcat and the rockyou wordlist, ensuring my hash was of the format hash:salt:

Because that was the format the exploit was assuming:

Those credentials work with SSH to access as jkr

SSH into the machine using jkr:raykayjay9:

Obtain user.txt

(Screenshot taken after a successful root, which has caused the different shell prompt)

Root user

Enumeration

We can write to /usr/local/sbin (among others)

Our user jkr is in the staff group (id = 50) which gives us writeable permissions (-perm 020) to some unusual files:

Among those writeable files are /usr/local/sbin and /usr/local/bin, which usually hold binaries that are executed by user or system processes. If root runs something that calls upon a binary within one of these two directories, we can edit those binaries to perform something malicious.

Alternatively, if root’s PATH includes one of those directories at the start, or early on, and root executes a binary without specifying where to find it, there’s a good chance we can have a malicious version of that binary executed instead, by placing it within either /usr/local/bin or /sbin.

A cron job is running cleanup.pl as root

Its running /root/bin/cleanup.pl:

We don’t have read access to cleanup.pl so we can’t see whether it runs a binary that we could edit.

The PATH variable for cron jobs is set to have /usr/local/sbin first, which means any binaries mentioned (like cleanup.pl) are looked for within /usr/local/sbin first. That, however, doesn’t necessarily mean that the same setup can be said for the root user.

I tried writing test copies (which logged messages of whether they were run to a test log in /tmp) of various system binaries (eg cp, touch, mkdir, ls) into both /usr/local/bin and /usr/local/sbin in the hope that the cleanup.pl script uses one of those binaries which will cause one of my custom binaries to run, but I had no success. This option might not be variable.

Root executes a binary run-parts in /usr/local/sbin

When SSH’ing into the machine, the run-parts binary is executed by root (UID=0) without the full path for that binary being specified. Following that, the environmental PATH variable, which will be used when finding the run-parts binary, is specified, and it starts with /usr/local/sbin, which we can write to (on the left is output from pspy64 - which logs running processes):

Because our user has write permissions to that directory (/usr/local/sbin), and because run-parts path is not defined, we can write a malicious run-parts binary to /usr/local/sbin which will be executed by root when we SSH into the machine again.

PATH exploit

Create a malicious run-parts within /usr/local/sbin

Having SSH’d into the machine as jkr, I create a run-parts binary, stored within /usr/local/sbin, which enables the SUID bit for the /bin/bash binary. This will allow any user to start a bash shell as the owner - which is root.

I list the current permissions on the /bin/bash binary:

Then I SSH into the machine in order to cause root to execute the command which contains the run-parts binary. Because the PATH is set to look inside /usr/local/sbin first, root will execute my malicious run-parts binary which enables the SUID bit on /bin/bash.

I list the permissions on the /bin/bash binary to show that the SUID bit has now been enabled.

From here, I can execute /bin/bash with the -p flag, which allows me to inherit the privileges of the owner of the file (root). You can see that, whilst my uid is still 1000 (jkr), my euid (effective uid) is 0 (root):