A friend who already rooted this box recommended it to me and now understand why.  It wasn't hard but it makes you put pieces together and that makes it fun.  I'll bring this up in a minute when we get to a specific point but somewhere in the middle, something kept breaking and I had to tear out the VM and import a new one.  I don't know if that was just me or if this is everyone but it'll be obvious if it happens to you and I'll make sure to point it out.

Anyway, kicking off with Nmap:

Lots of avenues to check out.  I enumerate SMB:

I find a couple of shares.  I access anonymous:

A nice little hint.  

At the same time, I'm enumerating users:

Excellent.  Back to SMB with those three passwords and qwerty is the winner:

Two more files.  Let's see what is inside:

That looks like a URL path:

Fix up the hosts file:


Using WPScan:

It uncovers:

We find:

Let's see if Exploit-DB has anything to say:

Excellent!  We have a Local File Inclusion vulnerability.  Can we read /etc/passwd:



This is the point where I know I'm supposed to poison.  When I looked back at my enumeration thus far, I see this SMTP port sitting there and that's when I realized, it was there for a reason:

I manually connect to SMTP, poison the message and when I go back to my LFI:

I get command execution. 

Now for a shell:

With my handler setup:

I search for setuid binaries and I find this unknown executable:

I run strings against it:

It's calling Curl. 

If we can write our own and change the path, we're golden.  

setuid.c : 

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
int main(void)
setuid(0); setgid(0); system("/bin/bash");

I keep these little gems in the /var/www/html directory on my attacking machine.  Makes it easy to just grab what I want.

Making my malicious Curl, setting executable permissions on it, adding /tmp to the path, and finally, running /opt/statuscheck:

A quick dir listing to make sure it worked and then I execute our setuid script. 


One final step:

Cool box!