SickOs: 1.2 Boot to Root VM Walkthrough

Introduction

Today I’ll be compromising the SickOs: 1.2 VM hosted by Vulnhub and created by @D4rk36. This was an obscure and fairly tough VM with a teensy tiny foothold-vulnerability that I’d not previously come across!

NMap #1

Tiny attack surface. Old SSH server and a lighttpd HTTP server.

Incidentally this version is apparently broken with a couple of serious vulnerabilities that can be used to read arbitrary files off of the disk in some circumstances. I wasn’t able to get the vulnerability to play ball on my box sadly!

Web Server

The web server has a single page like the following –

With nothing interesting in the HTML other than the cryptic:

Hrm..

Nikto

Nikto has almost nothing to say about the webapp..

Dirb

Dirb has the following little terse snippet to say about the server –

So nothing was found apart from “/test” which is an empty, listable directory.. What now!

NMap #2

I’ll admit that at this point I was stumped. I was trying to exploit the Lighttpd version, looking for UDP ports that I may have missed, looking for exploits in the SSH server, all sorts.

Eventually I remembered this excellent snippet from @Blackroomsec’s website

“What can I do, what can’t I do? What can I see, what can’t I see?”

Which spurred me into thinking about the basics again and got me wondering if for some wacky reason I’d be able to write to the /test directory with a PUT request (because it was the only visible thing……)

Enter NMap’s scripting engine –

That… Doesn’t look good does it? For comparison, the supported methods on the root ( / ) are “GET, HEAD, POST, OPTIONS”.

Let’s try it!

As you can see, the first attempt failed because an Expect header wasn’t set, but after specifying it it looks like the file was uploaded successfully. We can verify that by navigating to /test

Nice! Now we just spin up a reverse TCP handler and off we go.

Or not. Both reverse and bind TCP shells are failing to connect (presumably because of a firewall on the other end?) Changing from my good ol’ port 4444 to one of the “reserved” ports lower down (443) worked a treat though, so now we have a full meterpreter shell!

Limited Shell

So we’ve got a limited shell on the box now! Using the usual privesc tricks didn’t yield anything (kernel exploits just crash the box, no sticky-bit binaries I can use etc.). Looking in the cron.* directories in /etc/ I came across “chkrootkit” which is fairly famous as a privilege escalation vector. It requires you to create an executable file in /tmp named “update” which will be executed as root whenever the cron job fires. We’ll use it to get a bash binary with the sticky bit set.

Contents of /tmp/update –

There’s an excellent trick to get the cronjob to fire early which is run-parts /etc/cron.daily and then enter garbage for the password when prompted.

A few seconds later we have a bash binary with the sticky bit set which we can run as root!

Done! Let’s go and read the flag and call it a day.

Bonus Shenanigans

I’ve been curious about why a lot of network based exploits have failed against this box, and there’s a file named newRule in /root which sheds some light on it –

As expected, it’s a very restrictive set of iptables rules!

Conclusion

Great, great box! Probably one of the harder boxes I’ve compromised so far on this crazy infosec journey I’m trying to take. The Kernel exploit failures were frustrating and I’d love to know why they were making the box so unstable, but I’m glad that there was an alternative “route to root”.

Cheers for reading, hope you’ve learned something.

Add a Comment

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