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!
root@kali:~# nmap -sV -T5 -sC -p- 192.168.56.101
Starting Nmap7.60(https://nmap.org ) at 2018-03-18 15:28 GMT
mass_dns:warning:Unable todetermine any DNS servers.Reverse DNS isdisabled.Tryusing--system-dns orspecify valid servers with--dns-servers
Nmap scan report for192.168.56.101
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH5.9p1Debian5ubuntu1.8(Ubuntu Linux;protocol2.0)
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!
The web server has a single page like the following –
With nothing interesting in the HTML other than the cryptic:
<!--NOTHING INHERE///\\\ -->>>>
Nikto has almost nothing to say about the webapp..
“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……)
%Total%Received%Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
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!
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!
WoW!Ifyou are viewing this,You have"Sucessfully!!"completed SickOs1.2,the challenge ismore focused on elimination of tool inreal scenarios where tools can be blocked during an assesment andthereby fooling tester(s),gathering more information about the target using different methods,though whiledeveloping many of the tools were limited/completely blocked,togetafeel of Old School andtesting it manually.
Thanks forgiving thistry.
@vulnhub:Thanks forhosting thisUP!.
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 –
bash-4.2# cat newRule
# Generated by iptables-save v1.4.12 on Mon Apr 25 22:48:24 2016
# Completed on Mon Apr 25 22:48:24 2016
As expected, it’s a very restrictive set of iptables rules!
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.