VulnHub - Kioptrix 5
by purpl3f0x
The final box in the Kioptrix series is here! This one was the hardest by far, and every bit of advancement came only after a fair deal of research, head scratching, and frustration. Getting the initial foothold took many steps, some of which I've never done before, but getting root was extremely easy by comparison.
Scanning and enumeration:
As always we start with an nmap scan to find open ports and their versions so we can start poking around.
The only ports open are ports 80 and 8080, with the second port just being an alternative web page on the same server. The web page on port 80 wasn't anything exciting, it was just a blank page that said "It works!" When trying port 8080 I get a "403 FORBIDDEN" error. I move on and try using gobuster to find any hidden directories, but that didn't turn up anything either.
Moving on to the Niko results, it appears that this server may or may not be vulnerable to a mod_ssl exploit. I tried two differen't exploits for this version of mod_ssl but neither of them worked. I figured that since these weren't working, this probably wasn't the way in.
I'll admit that at this point I got pretty stuck. I had no idea where to go. I had already looked at the source code for the port 80 page but nothing had stuck out. My fault for not actually reading every line, because the answer was right there.
That comment, that stands out from everything else in bright green, has a url in it. I feel kinda stupid for not seeing that sooner and wasting upwards of half an hour using gobuster and dirbuster looking for other pages.
Initial foothold:
Looks like it's some sort of chart drawing program. I looked at a few of the tabs and didn't see anything of interest, so I looked up "pChart 2.1.3" and found that it has a directory traversal vulnerability that allows the viewing of system files.
https://www.exploit-db.com/exploits/31173
Following what I found, I decided to use the example given to look at the passwd file.
Looks like the vulnerability is present on this installation. I don't see anything particularly interesting here, but it's usually a good idea to look at the passwd file on Linux targets.
Here is where I got stuck again. I wasn't entirely sure what I should go looking for on the system. For lack of a better idea I wanted to go looking at the web server files, there's usually something hidden there. There's a problem though. This isn't Ubuntu or Red Hat, it's FreeBSD, and the files for apache aren't in their usual place, so I have to go looking for some hints on where those files are.
https://www.freebsd.org/doc/handbook/network-apache.html
This is a good place to go look first, as I had remembered that there was an unexplored page on the server, one that was blocking me from accessing it. The httpd.conf file would give some clues as to why.
As I was scrolling down I found this little bit of potentially useful information, so I make note of it and keep scrolling.
Then I find exactly what I was looking for. The page hosted on 8080 is blocking me because my "user-agent" isn't set to "Mozilla4_browser". To test this out, I turn on my FoxyProxy Firefox add-on, and use burp to intercept and modify my http GET request like so:
I replaced everything in the User-Agent field with "Mozilla/4.0 Mozilla4_browser", then clicked "Foward", and switched back to my browser.
It worked! It let me in. But there's a problem. Every link I click just takes me right back to the "403 FORBIDDEN" error page, and trying to intercept and modify every packet I send can be annoying. I look up how to modify Firefox to change its user-agent and found a way:
Making a simple modification to the "about:config" file allowed me to manipulate how Firefox presented its user-agent information. After I ddi this I was able to browse the forbidden page without using burp anymore.
Again I find another application I don't recognize, and I don't really see anything of interest here that I can abuse, so off to google I go for the 30th time!
Turns out that "phptax" is vulnerable to command injection that could lead to executing system commands on the victim.
https://www.exploit-db.com/exploits/21665
I followed the directions here and didn't have any luck. I was able to open ports on the target, but my netcat wouldn't connect. Using nmap, I found a strage phenomenon occuring. The ports was showing up as "filtered" instead of closed. I assumed there must be some sort of local firewall enabled on the target, so I tried a reverse shell, instructing the target to connect back to me on a specific port, but that didn't work either.
Now, I try to avoid using Metasploit when I can, but in instances like these, it seems that it's the only way in.
I found a metasploit module named "exploit/multi/http/phptax_exec" that can exploit the vulnerability in the link above, but with better results.
Where things got confusing is when I tried to set the payload to a bind shell or reverse shell. Metasploit would report that the exploit was completed but no shell was caught. This was another point where I got stuck for a while, but then I discovered that if I ran the exploit without specifying a payload, it would automatically chose a payload for me, and this payload worked.
At long last, after all this struggle, we have a shell on the server as the user "www".
Privilege Escalation
The priv esc on this box was super easy. I found my way in running what is usually the very first thing I run during post-exploitation recon:
It's always worth it to look up OS versions for vulnerabilities, but personally, I usually save that for last, as I'm not always comfortable running kernel exploits. In the real world, a kernel exploit gone wrong could knock a box offline, and you don't want to do that to a client. I try to treat these challenges like the real-world if possible, so I ended up spending 45 minutes exploring other priv esc routes before I finally circled back to this.
https://www.exploit-db.com/exploits/28718
The very first google result was this reliable-looking exploit. I tried to compile it on my attacking maching, but it was a no-go, it was giving lots of errors. Given that FreeBSD is old, I'm guessing the code for the exploit is old. I checked to see if the victim had "gcc" installed, which is a utility for compiling C code, and it did. So I copied the source code over to the victim:
On the left is my attacking machine of course, and on the right is the target. On my box, I set up netcat to listen and send the file to anything that connects to it, and used netcat on the target to connect to my box, and pipe whatever it receives into a file named 28718.c (it doesn't have to be the same filename but keeping it consistent avoids confusion.
Now that it's on the victim I compile it with a very simple command, "gcc 28718.c -o pwn", which compiled it into an executable. Running the binary resulted in a full compromise:
Summary:
This one was a lot more complicated than the rest, and most of the work went into just getting that initial shell. As a mercy, root was so easy that it would have been effortless, had I not wasted time looking for alternative methods. All in all, I liked it still, and how it taught me how to bypass restrictions on web pages to get to previously inaccessable directories.
There are tons of challenges on Vulnhub, so I'll be taking on something more challenging over the weekend! At the time of writing this I have 6 days to go until I take the OSCP exam, so I need to crank up the difficulty to get myself in the right mindset for the exam. Thanks for viewing!
tags: Pentesting - VulnHub