Stapler — Vulnhub

So this is why you been so late on your TPS reports? Stapler from Vulnhub is a good box for somebody with a good handle on the basics, but it’ll test your ability to remain patient. Don’t be afraid to take your time! There’s a lot of information to keep track of before you find your way in. Here’s how I did it.

I throw out the tendrils of NMAP to see what they stick to, and oh my goodness there’s a lot of information to parse through! That’s the theme really for Stapler—there’s a ton of information. It’s a good idea to get in the habit of taking notes if you’re not doing that already.

I begin with FTP. It allows an anonymous login, so that’s the lowest hanging fruit.

Punching in, I find a little note to Elly. Something about a payload… I guess I’ll find out more inside.

I also make note of two more names: John and Harry.

On a hunch I try Elly’s name backwards to authenticate into FTP and it actually worked! The working directory of FTP is directly in the root of the file system. There are so many things to look at, it’s hard to pick a direction to go! I decide to loot all the things! It turns out to be largely useless to take so many files to look through, but the passwd file is sitting there just waiting to be picked up. Alas, the shadow file isn’t as friendly and shuns my grasp.

If you want to know what not to do, I also picked up vsftpd.conf, php.ini, rc.local, mysqli.ini, mysqlnd.ini, mysqld.cnf, environment, magic, ports.conf, envvars, apache.conf, apache2.conf and the default-ssl.conf files. None of them yielded much in the way of beneficial intelligence, But it was good practice to slow down and absorb the information I was looking at.

Before moving on, I make a .txt file of the names I find in the passwd file I snagged during my FTP adventures. This will come in extremely handy.

I check out SSH briefly and see a name which isn’t in the passwd file. Barry’s name takes its place among my notes.

Since there are already quite a few names on the list already, I feel pretty comfortable using Hydra to start brute forcing SSH. It’ll take some time to go through so many iterations, even with my trimmed down passwd file (rockyou-15).

 I unshackle Hydra and send it at the locked gates of SSH before continuing my way around the perimeter of the system. Onward to the HTTP services!

Going to the first webpage is underwhelming. But that is a recognizable Apache server page. I use Dirb and Nikto to illuminate any subdirectories.

"Dirb, I want to talk to you about your search results. You can do the bare minimum, or... like, uh..."

Enumerating the HTTP service on port 80 is also initially lackluster. Dirb returns bupkiss. Nikto tells me doodly-squat. But there’s still port 12380!

Launching Dirb and Nikto at HTTPS gives me some material I can work with.

 There’s some good intel here. /announcements is a cryptic message that isn’t immediately useful but could turn out to be. The /phpmyadmin page catches my eye. I’ll make sure to come back to that. Nikto comes back with two results that are of immediate interest: /blogblog and /admin112233.

I waltzed right into the /admin112233 snare!

The subdirectory /blogblog turns out to be a Wordpress blog with a few entries. It doesn’t fall prey to any DOM XSS, but I didn’t expect it to.

That means it’s time for a good old fashioned Wpscan! Remember when Wordpress vuln scans were handmade by the finest old world artisans in Anytown, USA? 

Wpscan is a little sticky getting started. 

A simple option switch to ignore TLS will get it going. 

It comes back with some great information, chief among that is a list of usernames!

I add it to a separate list of names in case I feel like brute forcing the WP login.

Moving on to /phpmyadmin, I try default credentials on the login form page but they have no effect. I can feel the urge to hunker down on this but I move on to other ports and services with the intention to come back later for a deeper investigation.

There’s still SMB to look at! Enum4linux comes back with a fair amount of information and a couple of open shares for me to explore.

 NMAP --script=smb-enum-vuln-* also shows me two possible vulnerabilities, one of which may actually useful in this context (note: it’s not). 

I take everything I can out of Kathy’s folders. 

I also take the LS file out of the TMP folder.

 IPC$ is non-responsive so it doesn’t look like I can go much farther in that direction.

In the files I can see that there’s a backup for the blog and a vftpd files that matches looks like the one I already have. There’s also a todo list that doesn’t appear to be all that useful.

The LS file is all kinds of cryptic. Looks like a timesync service in the systemd directory. If I recall, Elly wasn’t able to get there when I was cruising around FTP. It might be worth looking into when I get my initial foothold.

I’m curious how my SSH brute force is doing and I’m rewarded for checking it out. 

I have two hits for SSH credentials!

At last, I have a decent foothold.

There’s no user flag that I can see and hopping out into the home directory there’s a bunch of subdirectories for all the users. 

Before I go through them, I decide to check out what kind of system I’m dealing with here. Stapler is running Linux Kernel 4.4.0-21. 

There just so happens to be an exploit for that kernel! Or at least so I thought. Before running off down the primrose path of kernel exploits I quickly look through the home folders and find nothing of note.

Using that exploit ended up being more trouble than I had expected. Right off the bat I get a worrisome compiler warning. 

It doesn’t bother me too much at first since I’ve seen compilers throw warnings before and the exploits are fine in execution.

Okay. It didn’t work. But I seem to convince myself that I’m on the right path. So I spend an hour modifying the code. I try getting rid of the error messages during compilation or different ways of communicating assert(!getuid());. Nothing works.

Five iterations of the C code and one hour later...

Finally it comes to me that I’ve been trying to force an x64 exploit into a x32 machine and simply changing the functions isn’t going to work. I’d have to do some reverse engineering of the kernel and then adjust from 64 bit to 32 bit… now I’m in the weeds. I can tell I’m in the weeds. There’s no way I’m supposed to be doing this.

Maybe I should do a more thorough job of searching through the home folders. It suddenly dawns on me that when I was searching through them the first time I was using ls and not ls –al.

Listing out the contents of every subdirectory in /home I come across some good clues. 

First, Peter has the ability to use sudo-as-admin. Secondly, some of those hidden bash files have different sizes from each other. That could indicate unique entries in them. Thirdly, and most tellingly, Peter’s .bash_history isn’t accessible to any other user, whereas most of the other .bash_histories are. 

I decide to check out all of the hidden files and I’ll start with .bash_history and go down the list.

Finally, those clues led me in the right direction! I’ve got another password, but not only that, I’ve got Peter’s password! Now, it’s a simple task of switching to Peter, changing the root password with sudo.

Then I switch user to root and that’s the end!

Overall, I did enjoy this box. I could tell there were other ways in and some rabbit holes I could (and did) fall into. I didn’t even have to go through the webapps to find a way in, but I’m pretty sure that there’s a local file inclusion in one of them. One thing that struck me as interesting is that this is by far the slowest enumeration phase I’ve gone through for a box of this difficulty. It’s easy to go off half-cocked and get turned around because something looks more vulnerable than it actually is. Stapler is good practice and I’d heartily recommend it.

   

See you, Space Cowboy...