Vulnhub: Stapler 1 Boot2Root VM

 

Introduction

Today I’ll be documenting the process I followed to compromise the Stapler 1 vulnerable VM created by g0tmi1k and hosted with love by Vulnhub
Really, really enjoyed this box! Lots of fun twists, and I really loved the shenanigans on port 666 🙂

Port Scanning

As usual, we kick off with a TCP port scan of the target to see what’s listening.

A few interesting things pop out here –

  • Old version of vsftpd (potentially broken?)
  • dnsmasq (don’t see this often)
  • Non-Apache server on port 80
  • Samba (if mis-configured allows unauthenticated file reading)
  • Something running on port 666
  • Old version of MySQL (potentially broken?)
  • Apache server running on a random high port
Let’s go and find some treats, starting from the top.

FTP Server

As usual we’ll start off with checking for an anonymous login –

Which was successful and yielded a file named ‘note’, let’s GET it and read it.

 

Very mysterious.. I tried logging in as Elly with a few default credentials but had no luck, so we’ll keep this for later.

There are no known vulnerabilities for this version of vsftpd, so not going to pursue that avenue for now.

dnsmasq

Nothin’ useful

PHP CLI Server

Nothing particularly interesting here at first glance, just a 404 error page on almost any input. No XSS vulns present etc. dirb / nikto report that the user’s .profile and .bashrc files can be downloaded here but they don’t contain any sensitive info and none of the other common files are present (.ssh/id_rsa for example)
NEXT!

Samba

Finally, interesting stuff starts happening!

Running enum4linux on the host spews lots of output, but with one interesting nugget halfway down – a share named “kathy” with the description “What are we doing Fred?”.. Potential for a misconfigured share! Huzzah!

Let’s go poke it with “smbmap” and extract any treats which we find.

So, as we can see here there’s a few files of interest in this output, namely –

  • todo-list.txt
  • vsftpd.conf (in the backup folder!)
  • wordpress-4.tar.gz
    • This one is especially interesting as it may contain passwords
  • both read and write access to the tmp share, which may give us a route to getting files onto the box (shells etc.)
Let’s go scrape everything with –

and then inspect our loot.

 

  • todo-list.txt is empty
  • vsftpd.conf yielded nothing interesting
  • wordpress-4.tar.gz appears to be a vanilla install without passwords
  • ‘ls’ isn’t particularly interesting
So nothing here which will help us get a shell on the box by the look of it. Let’s park the Samba server for now and move onto the next service, which is………

Doom

(as classified by nmap 😉 )
Running netcat against doom yields a lot of binary data, which we output to a file.

So the file returned by D0Om was actually a ZIP archive containing a single JPG file, which looks as follows:

Sooo… Nothing hugely exciting tbh. Running ‘strings’ on the file yields a bit of shenanigans but nothing which will help me pwn the box..

1If you are reading this, you should get a cookie!

Shenanigans, but not much use to us.

Next service.. Running out of ports!

 MySQL

The installed version of MySQL has 3 local privilege escalation vulnerabilities which we may be able to leverage later to get root! But nothing in the immediate term sadly. Onto the final service on the box..

Apache

This was really interesting and caused some hairpulling to occur… Basically navigating to the site in the browser yields a huge splash screen effectively saying “we’ll do better next year, nothing here lol”, dirb couldn’t find anything interesting, there was nothing interesting in the source code other than a message from HR to Zoe saying that they’d like to hire her (???).
Nikto reported two entries in robots.txt which should be viewed manually, but any attempt to view robots.txt sent me straight back to the giant splash screen page. Hrm.
I even went as far as adding another nameserver in resolv.conf pointing at the DNS server on the target box, which yielded nothing.
Five minutes later I spotted that the nikto output was talking about SSL misconfigurations and it twigged that Nikto was accessing a https version of the page which I didn’t know existed. Blargh.
Onwards!
robots.txt mentions “blogblog” and “admin112233” (they look like credentials don’t they 😉 )
Looking at the latter sends me to a snooty XSS PoC and tries to redirect me to xss-payloads[.]com (didn’t work as I’m using a host-only VM network) so let’s look at /blogblog instead.
Side note: The point of this rambling paragraph is to show that I don’t have all (or even most) of the answers and it’s probably nice for you as a reader to see where I screw things up!

Rerunning dirb on the correct protocol yielded a couple of extra treats, a PhpMyAdmin install at /phpmyadmin and an announcements folder containing a message to Abby saying “Abby, we need to link the folder somewhere! Hidden at the mo”.. Could come in handy later.

BlogBlog

This is a WordPress blog (as proven by navigating to /wp-admin, and hinted at by the WordPress backup we found earlier), running “wpscan” on it hints that the site is screwed – hugely outdated and lots of authenticated vulnerabilities are present.
I spent some time poking around the blog / the admin login and couldn’t find any valid credentials sadly, ditto the PhpMyAdmin login.
I spent an age trying different things here.. wpscan’s enumerate users option, going back to the /tmp upload vulnerability which we found in samba, using the output of wpscan’s user enumeration to brute force ssh, ftp and mysql passwords and got completely stuck.
I’m ashamed to say that at this point I read the slide-deck which accompanied this VM to get the next little pointer to send me on my way. Note to the reader – I hate doing this, it feels like “cheating” and I hope that as my skills continue to improve I won’t need to use such “cheats”.
The slide-deck mentioned a vulnerable WP plugin which I’d completely skipped over while enumerating the site. I found an exploit here  and modified it to allow SSL rather than plain old http. This was done by creating a default, insecure SSL context for urllib to use. Google that for more details, it was pretty straight forward.
The exploit actually only partially worked, it performed the LFI perfectly but didn’t return results.. But the wp-config files were there clear as day on the frontend luckily, just had to find the broken thumbnail links on the .jpeg link and then curl them.

OK so now we’ve got a mysql password, let’s use it to get additional treats!

First up, login to MySQL with “mysql -u root -pplbkac -h 192.168.56.101”

We then dutifully copy these into a file in the format of “username:hash” and give them to John the Ripper to crack for us.

John’s identified the key password for us – John’s 😉

Now I thought that this’d be a done deal, but sadly not as the naughty root user has made the WordPress directory read only, so we can’t upload a webshell. Bleh!

Thinking around corners a little, we can try and read the passwd file using “select load_file(“/etc/passwd”);” and then use that to attempt to bruteforce ssh sessions on the box using the passwords which john has output for us.

We use Hydra, using the following syntax “hydra -L usernamesFromPasswdFile -P passwordsFromJohn -e nsr -t 5 ssh://192.168.56.101”

Some time later, a valid password combo pops out for one of the users in the passwd file (SHayslett:SHayslett) so we’ll SSH in as that.

Sadly this user has no privileges at all, and running “unix-privesc-check” yields no treats other than a world writeable WWW directory (which it turns out is where port 80 is pulling files from! That’s of no use to us now as we’ve already got a nice shiny SSH session open.)

At this point I spent a long LONG time wondering what to do, eventually I stopped being an idiot and spent some time enumerating the other user’s home directories. Eventually I found a .bash_history file in JKanode’s home directory which randomly contained user Peter’s password.

This is useful as user Peter has a file named “.sudo_as_admin_successful” in his home directory.. Implying that he can run stuff as root.

Using our newly found password to “su – JKanode” and running “sudo -l” we spot that peter can run anything as root, including “sudo su -” to become root.

Done! We can now read “flag.txt” in root’s home directory, which contains –

 

Conclusion

Really, really fun box! I’m a little ashamed that I had to seek help with the WordPress plugin section, but as I said above – hopefully as my skills improve then that won’t be necessary in the future.
As always, I need to Try Harder!

Add a Comment

Your email address will not be published. Required fields are marked *