Write-up: /dev/random: Sleepy

So to start off my new series of articles "Garden of Badb" we will begin with a full write-up of a publicly available vuln-hub virtual machine image sleepy.

Lets Get Started!

Setting up the labnet

okay so we are dealing with a know vulnerable target, from a respectable source; however just to be safe we will import the image into virtualbox and setup a host-only network, in order to keep the little bugger isolated and not talking to the world just in case...




For the sake of keeping to the 'plan' we will start off with some recon on the target. From VulnHub we are able to gather the following information just of the main banner for the target. There are some more details spread out with extended linkage about the target along with the author 'Sagi-'.

turning our attention to the author of the target we learn using some OSINT (Open Source Intelligence Gathering) techniques, that we are dealing with a very experianced author! I much admire the person as it seems the achievments of Offensive-Security Certified Professional & Expert as well as CREST Certified tester & Assessor designations have been awarded to the individual. Very impressive!


Okay so when we setup the labnet for this exercise we established a host-only network. We also know from the recon stage that the VM uses DHCP for ipaddress assignment. So now we need to find the little bugger.

My ip address configuration for the host-only network.

using that information we can just do a nmap ping scan to find our target IP.

At this point we are crossing the passive | active boundary, if we did not have a valid legal agreement at this point, we would be wearing a different hat...

okay now we have our target identified on the labnet - now lets dig a little...

okay looks like we have some vectors to check. port 21 looks like the best starting point as it is a common misconfiguration attack vector.

checking into the FTP Service

not looking good but at least we got a cute little picture


so before he wakes up lets keep moving. we had two other possible vectors 8009 (AJP13) and 9001 (JDWP).

We know that there is plenty of documentation around exploiting Apache Jserv so we will be checking into that very soon. However as far as my personal experience goes I have never heard of Java Debug Wire Protocol[1]! Doing a little research and digging around it looks like it is just a fairly simple packet / non-statefull protocol. This is the protocol that a given Java debugger communicates with the Java Virtual Machine (JVM). This is a pretty interesting find and definitely something to check out as this my be tied to a privileged JVM that we can exploit... time will tell lets start with some shrink-wrapped stuff first.

So I installed the apache mod-jk module ('libapache2-mod-jk') on my attacking machine. This is the module that we can leverage in order to connect to the tomcat servlet container, which will in turn let us access (hopefully) the administrative directories of the tomcat server.

No keep in mind while i was installing the mod all apache services were shutdown, not that it would be a requirement necessarily but you would or may have to restart services or reboot depending on your OS and apache configurations for the modifications to take affect.

And after firing up apache my local host is listening on port 80 and should redirect all my local traffic to the target destination & port 192.1168.56.5:8009.



We now have some leveraging access to the machine; at least technically. I tried a few default credential combinations less than fruitful results. At this point we could move into an online password attack but that would be very 'noisy' in a 'live fire' scenario so for the sake of good practice lets try something else... Time to research the debugger

**sigh of discontent followed by a few hours of digging and practice

So in the end the the debug protocol may serve useful after all and to boot it seems there is a command line tool 'jdb' out there that will allow you to take advantage of the protocols usefulness!

As you can see from the help screen this tool can connect to a remote debug instance...

So I connected to the target machine and then using 'classes' command listed all the available loaded classes available. I found one noteworthy class that didn't seem default and had a particularly facetious name. Checking out the class we can see that it has really only one real method other than defaults and doesn't have any fields belonging to it either. It is likely this could be an intrusion point as since this is a tomcat server and a mock target for penetration testing this class is probably being used. So lets setup a breakpoint on the method and see if we can catch it going off...

Sweet! looks like we got a hit after just a few seconds. And we can run some arbitrary code though the thing too! Unfortunately for us there is still some work to be done on getting any real usable information from this. This is because running a basic Java exec() command will return the command object ... not the result necessarily.

My initial thought here is - exec() is working just not spitting out useful output... what if we just try to use a simple remote shell? one of my favorite cheetsheets for remote shells is pentestmonkey Reverse Shell Cheat Sheet[2].

However to my dismay it seems it is not that easy... so I instead turn my attention back to the previous issue. How do I get the response of the exec() command into a human readable format? So doing a little digging I found myself at stackoverflow, a real great place to ask and find programming questions and phenomina. and find something we may be able to work with...

checking out the code snip above we can see that the author essentially uses a BufferedReader() and InputStreamReader() to extract the needed information out of the process object spit out by the exec() method. So with some doing we can convert this into a one-liner we can feed to JDB.

and to give it a whirl...

so this gives us something we can use to poke around a little bit lets see what we can find... first we did an 'id' and then tried a 'cat /etc/shadow' which through a fit and broke our debugger session :/ - that is a strike out! if this were a 'live-fire' exercise the admins would most definitely notice something our only hope is there response is "huh weird ... give it a reboot see if that fixes it"... for instructional purposes we will say that happened 🙂

Round 2 | so after a reboot of the vm and reconnecting jdb to the target setting our breakpoint lets see what we can do now ... without another strike! So what are we hunting for? a remote shell is a must at this point we cant be doing everything from the debugger as we can assume we broke everything by stepping outside its assigned user permission set. we know we cant just simply create a remote shell from our earlier attempts and searching the filesystem for 'nc' or netcat didn't provide any help either so ... **blank stare for a little bit** lets turn our attention back to the tomcat server itself... we have all the tomcat permissions and there are config files out there that set credentials and other juicy settings too...

okay so you may have to mess around and play with the formating of our awesome one liner in order for full use but I will leave that up to you : ) ultimately I found the following information after almost losing my mind messing with the formerly mentioned formating issues.


Now on to bigger and better things!

Gaining Access

Now that we have access to the tomcat manager we can use metasploit to pop the lid on the system and get us our long needed shell... so we can get to work.

At first glance we can see that this system is vulnerable to shell shock!

Now that we have a shell and shellshock, we will need to assess the system and determine the best way to get to root. My initial direction would be lets check for any setuid scripts or executables on the system.

pkexec - I though initially that this was a very viable exploit path as there are publicly available and working POCs for a CVE-2011-1485 Race Condition Privilege Escalation Exploit. There is also an available metasploit module! WRONG burnt quite a bit of time (good practice on exploit POC modification and compilation) but no luck. Other than heating up the CPU on my machine I accomplished absolutely nothing in the way of owning this thing.

So looking back at our sticky-bit files there is an oddball in there

Basically you run this file and it makes some ASCII art flames for a bit then asks you if you want to do it again... buy the 'no' option is broken. If you choose the no option a few times it will fire off an ASCII train animation (actually the old joke-ware /usr/bin/sl!) then close. after a bit of fuzzing I was able to find a possible attack vector by sending a ^c or 'Ctrl-C' at the prompt to repeat or not...

So the exploitation of /usr/bin/nightmare and the cascaded execution of /usr/bin/sl joke-ware by use of the shellshock vulnerability we can essentially set an environmental variable for /usr/bin/sl to just return a /bin/bash session - that due to the sticky-bit on /usr/bin/nightmare will be with root permissions! Now that we are dug in lets grab the flag

Maintaining Access

Okay so next step of the attackers methodology - maintaining access. In this particular case we dont need to accomplish this but typically I would grab a copy of the /etc/passwd and /etc/shadow file and run them through JTR (John the Ripper) in order to get the root password. Other options would be to inject a rootkit of some kind that would allow me to come back later, another simple one but also easily detectable would be a scheduled task that would fire of and keep calling home so I would be able to get back in without all the leg work. But for the purpose of this article we will leave that one alone.

Clearing Tracks

Now the last and most critical step of the entire process! clearing your tracks... This is obviously a huge topic in itself but simply for a linux system I would do the following.

Review and Clear all logs that I could find

Find any history files that would have tracking commands or other activites and clean them

and with that i think we are done! stay tuned for more


Credits and Thanks

[1] Oracle - Java Debug Wire Protocol