I’m back with another great vulnerable boot to root. This time it’s once again one from my favorite site, HackTheBox. If you’re here I’m assuming you already know what HackTheBox is but if you don’t know, it’s a gamified site that gives you free (or paid) access to a massive vulnerable network. That network has a ton of hackable machines of varying difficulty. It’s a lot of fun and I’ve been a user of it for years. Can’t say enough good things about them.

Today I decided to take a crack at a machine rated at a medium difficulty titled “Faculty”

Faculty was an interesting machine. If I had to rate it on realism I’d say that there was nothing in here that I rolled my eyes at. You won’t find anything like `exploit.php` baked into the machine. It does require you to have some working knowledge of PHP, SQL, researching CVE’s and Linux. Nothing crazy though. I did go down a rabbit hole somewhere near the middle of the machine but I eventually worked it out. Definitely a great machine to crack.

Defining the Attack Surface

Like usual I start with my nmap scan.

nmap 10.10.11.169 -p- -sC -sV -oN full_nmap_output

What this command does is it scans every port 0-65535. Every port that it finds that is open it will run an enumeration script against as well as look for the Version of any services running. Finally the last command there -oN dumps the normal human readable output to the file full_nmap_output – If there’s one thing that I’ve learned since I started going down the path of infosec it is _DOCUMENT EVERYTHING_ no matter how trivial, no matter when it comes in, document it. Take a screen cap, pipe it to a file, whatever, don’t lose it. Otherwise you end up running the same commands again and again.

I can see that there’s a service running on port 80 and on port 22. I probably won’t have creds yet to log in so let’s checkout the webserver

When I open the path http://10.10.11.169 in the browser I’m immediately redirected to faculty.htb which obviously doesn’t exist, so we need to add it to our hosts file in /etc/hosts

Now we can see that the URL resolves and we are given a login screen.

While I navigate the site in the browser, I also like to run scans. So I kick off a nikto scan

nikto -h http://10.10.11.169

Breaching the Fence Line

Since we have a single input with no other links I try and put some values in. Also something to note is I always have burp running in the background and the browser proxied to it. So this way if I come across anything, I capture it the first time I see it.

Looks like a pretty straight forward request. Naturally I send it over to repeater and start feeding it garbage values to see if I can break the API

Passing a single quote in appears to cause some type of explosion which looks like a SQL Exception. Could we possibly have a SQL Injection exploit?

YUP!

I head back to the user input and attempt our injection to gain access

' OR 1=1#

We’re in….

Enumeration….

Next up we need to define everything we can access and everything that’s out of reach. This is a huge task even for a small application. Every input, every script, especially when talking about SQL Injection, can be your money shot. So, you can’t let anything go.

I kicked off dirbuster and almost immediately discovered the admin directory.

Navigating there reveals another login page

I decided to roll the dice and see if we had another vulnerable login with Burp

Sure enough it looks like there is another SQL Injection exception here

~GREAT SUCCESS~

Hitting the Wall

So here’s the shitty part. I got stuck here for a few hours. I tried more enumeration and developed some fun ways to expose all of the pages available to me using wfuzz

Unfortunately, this for the most part wasn’t useful until later on after I got a shell into the box.

I dug through every single freaking input on this box. I ran dirbuster against every single directory, every file format extension I could think of … everything ….

Then, what made it worse was I fell down this completely useless rabbit hole of SQL Injection. I was convinced that this was the path forward so I tried everything I could think of. I referenced every site I could find about SQL Injection and as a last resort, I even cracked open the tool SqlMap. I was convinced that this was the way to get access, so I hilariously spent hours using every flag on it.

If you’re interested, I dumped all of the tables as you can see here.

(tried to crack that hash about 50 different ways to no avail)

Getting a Shell

Finally, I turned my attention to the download PDF button…. Ohhhhh pdf buton, what a deceivingly simple little bitch you are….

At first I thought maybe there was some hidden info in the PDF metadata itself. So I pulled it down.

Hmmmmm mPDF 6.0 I wonder if that’s useful…

Yes it turns out it is… I guess there is a vulnerability in that pdf generator that allows you to execute a local file inclusion exploit. Essentially what’s happening is that library takes an encoded string (which is passed to it from the client in this case) and converts it into a PDF file on the server, then returns it to the client. The problem is, you have the ability to embed a file link in it that points to files on the local machine. If the owner of that process has access to the file, then you can actually include it into the PDF and return it to the client, exposing all types of sensitive information.

In order to exploit this, we need to first figure out the encoding of the PDF string being passed to the server API. Thankfully since I always have burp running, I’ve already captured this.

Just highlight, right click and send it over to decoder

This takes a little prerequisite knowledge if you’re not used to looking at encodings, but I could tell right away that the string was Base64 encoded. Once I ran that decode, I could see it was URL encoded. Finally, it needed URL decoded once more time. Too easy, now we know how to encode the payload to the API. Next we need the actual payload

This can be retrieved from the bottom of the link posted above explaining the exploit. I decided to target the /etc/passwd file to start since it should be readable by all users

<annotation file="/etc/passwd" content="/etc/passwd" icon="Graph" title="Attached File:/etc/passwd" pos-x="195" />

Next you encode it doing the reverse of what we did above to decode the pdf payload. First you URL Encode it twice and then you base64 encode it.

I fired that off to the server and in response I got a file link…

The PDF that comes back is empty but you can see on the left under the attachments that there’s a file called passwd

Click it to download it

SHAZZAM! It worked

(I intentionally block out some of the data going forward as to not ruin the challenge for HTB since this is still an active machine that people are scoring points against)

Okay now we have our usernames, we need to find our password. I bet using the same local file inclusion exploit, we can find something in those php files. They’re obviously accessing a database somehow. Maybe there’s a set of creds in there that align with our passwd file.

I start with a path I know. In the begining when I first discovered the SQL Injection issue, there was a file path leaked

I retrieve that file using the PDF Exploit

It looks like it’s pulling its creds from another file called db_connect.php . So I guess I need to go grab that one next.

YEAH BOIIIIII sched:<redacted>

Now of course I tried to SSH in with those creds first but they didn’t work. However, what did work was starting at the bottom of the /etc/passwd file and seeing if they worked with any of the other users. Which one of them did.

Unfortunately, it’s not the root user, so we’re going to need to figure out how to elevate our user privileges.

Privilege Escalation

Privilege escalation used to be my least favorite thing to do but honestly now I enjoy it the most I think. It’s fun to run the different tools that people have spent time building and sniffing around operating systems. I find it almost as enjoyable as hammering on web api’s personally.

This box was actually pretty easy to elevate privileges on. Especially using my tool ShinobiShell (which I just discovered a bug in and currently only works with python2.7 which thankfully is installed on the target machine)

ShinobiShell is a client server model shell and has a bunch of great tools prebuilt into it. Many of which are used for your initial enumeration of a linux operating system. Things such as linenum, suid3num and more. It also makes downloading exploits from the web and from your attacking machine very simple as well as exfiltrating data back out over an encrypted tunnel.

The first thing I do is install ShinobiShell on the target box and connect back to my shinobi server.

Right away I grab the machine info

And I install suid3num

and run it

:-O

….No way…

And that’s all you do for privilege escalation lmao!

Conclusion

I had a great time working this box. That PDF thing was bullshit but I guess it was just as realistic as anything else on this box. SQL Injection is a real attack vector as well as outdated libs with known vulnerabilities that were never patched. I can’t say it was fake in any way there.

This is a good box to practice on. Hopefully you don’t fall down the same rabbit hole I did haha

Leave a Reply

11 + three =