Hack The Box: Shibboleth


Jump Ahead: EnumUserRootResources

TL;DR;

To solve this machine, we begin by enumerating open ports using nmap – finding ports TCP:80 and UDP:623 open. Looking into UDP:623, we learn it allows for out-of-band system monitoring. Using this port, we are able to get hashed credentials for Zabbix, which is hosted on port TCP:80. After we cracked the password, we are able to log into Zabbix, and are able to execute a reverse shell as the zabbix user. As zabbix, we are able to reuse the previously cracked password to get a shell as ipmi-svc, and read user.txt. Enumerating the configuration files for Zabbix, we get the database credentials. While enumerating the system, we find vulnerable software, and exploit it to get a reverse shell as root, and read root.txt.

Enumeration

Like all machines, we begin by enumerating open ports using nmap. From our initial TCP scans, we find port 80 open.

$ sudo nmap -v -p- --min-rate 3000 $RHOST
[...]
$ sudo nmap -sV -A -oA enum/nmap/tcp-scripts $RHOST
# Nmap 7.91 scan initiated Sun Nov 14 10:46:34 2021 as: nmap -sV -A -oA enum/nmap/tcp-scripts 10.129.255.156
Nmap scan report for 10.129.255.156
Host is up (0.056s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.41
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Did not follow redirect to http://shibboleth.htb/
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.91%E=4%D=11/14%OT=80%CT=1%CU=44753%PV=Y%DS=2%DC=T%G=Y%TM=61913D
OS:7F%P=x86_64-pc-linux-gnu)SEQ(SP=FF%GCD=2%ISR=10E%TI=Z%CI=Z%II=I%TS=A)OPS
OS:(O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST1
OS:1NW7%O6=M54DST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)ECN
OS:(R=Y%DF=Y%T=40%W=FAF0%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=A
OS:S%RD=0%Q=)T2(R=Y%DF=Y%T=40%W=0%S=Z%A=S%F=AR%O=%RD=0%Q=)T3(R=Y%DF=Y%T=40%
OS:W=0%S=Z%A=O%F=AR%O=%RD=0%Q=)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
OS:T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A
OS:=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%D
OS:F=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=4
OS:0%CD=S)

Network Distance: 2 hops
Service Info: Host: shibboleth.htb

TRACEROUTE (using port 993/tcp)
HOP RTT      ADDRESS
1   63.30 ms 10.10.14.1
2   63.49 ms 10.129.255.156

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Nov 14 10:46:55 2021 -- 1 IP address (1 host up) scanned in 21.34 seconds

Since port 80 is the only open port we found, we launch a basic UDP port scan in the background to see if we can expand the attack surface. In the meantime, we enumerate the webserver using gobuster and nikto. From gobuster, we get wildcard responses, and from nikto we learn the webserver is Apache 2.4.41 and that the webserver redirects to shibboleth.htb (which we add to /etc/hosts). Since we have an FQDN for the webserver, we relaunch gobuster and find a couple files and directories.

$ for i in files directories; do gobuster dir -t 30 -u shibboleth.htb -w /opt/wordlists/seclists/Discovery/Web-Content/raft-medium-$i.txt -o enum/web/gobuster-80-rm${i:0:1}.txt; done
[...]
/index.html           (Status: 200) [Size: 59474]
/.htaccess            (Status: 403) [Size: 279]
/.                    (Status: 200) [Size: 59474]
/.html                (Status: 403) [Size: 279]
/blog.html            (Status: 200) [Size: 19196]
/.php                 (Status: 403) [Size: 279]
/.htpasswd            (Status: 403) [Size: 279]
/.htm                 (Status: 403) [Size: 279]
/.htpasswds           (Status: 403) [Size: 279]
/changelog.txt        (Status: 200) [Size: 499]
/.htgroup             (Status: 403) [Size: 279]
/wp-forum.phps        (Status: 403) [Size: 279]
/.htaccess.bak        (Status: 403) [Size: 279]
/.htuser              (Status: 403) [Size: 279]
/.ht                  (Status: 403) [Size: 279]
/.htc                 (Status: 403) [Size: 279]
[...]
/assets               (Status: 301) [Size: 317] [--> http://shibboleth.htb/assets/]
/forms                (Status: 301) [Size: 316] [--> http://shibboleth.htb/forms/]
/server-status        (Status: 403) [Size: 279]

Additionally, we use gobuster to also check for potential vHosts, and we find several.

$ gobuster vhost -r -w /opt/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u shibboleth.htb
[...]
Found: monitor.shibboleth.htb (Status: 200) [Size: 3686]
Found: monitoring.shibboleth.htb (Status: 200) [Size: 3686]
Found: zabbix.shibboleth.htb (Status: 200) [Size: 3686]

Next, we go to the webserver in our browser. Looking around, we see that it is pretty generic and filled with lorem ipsum. Looking at the blog page, it too seems pretty generic.

Looking at the changelog page, it seems related to the framework for the webpages, so likely not important to us.

Going to the /forms directory, we see a contact page and Readme file, but those seem irrelevant as well.

Looking at all the discovered vHosts in the browser reveals they all point to Zabbix.

Before we move on, we check our UDP scans, and find port 623 open – which nmap labels as “asf-rmcp”.

Getting User

Doing some research on UDP port 623, we find this article that explains it is used as Intelligent Platform Management Interface (IPMI) – which facilitates out-of-band monitoring of systems. Following the article we are able to enumerate the port to get the IPMI version, and exploit the version (2.0) to get the password hash for the Administrator user.

After getting the password hash, we are able to crack it using hashcat.

Since Zabbix is the only interface we have where we are able to supply credentials, we give the username and password, and are able to login.

Looking around Zabbix, we go to Configuration -> Actions, and create an action that executes a reverse shell when a trigger severity equals “Disaster”. We also need to set the operation step duration to something like 1m (1 minute). Next, we set a netcat listener for when the reverse shell executes.

Next, we go to Configuration -> Hosts, select “shibboleth.htb, and select the “Triggers” page. Here we create a new trigger, set its severity to “Disaster, and the expression (what causes this to trigger) to be when processes are greater than 0 (causing it to always trigger).

After some time, we get a reverse shell as the zabbix user.

Next, since we have a password, we attempt to use it against system users using su, and get a shell as the ipmi-svc user. This now gives us access to user.txt.

Getting Root

Since we have a shell on the machine as ipmi-svc, we begin to look for avenues to privilege escalate. For this, we run sudo -l and look for SetUID programs, but nothing stands out. Next, to automate the process, we run LinPEAS, and from it, the only thing that really stands out is that the Zabbix configuration file is at /etc/zabbix/zabbix_server.conf – which is listed in the output of the ps command.

Looking at this file, we get the database credentials for Zabbix.

Using the credentials to look in the database, we do not find anything that is of particular interest other than user hashed credentials. Since they are bcrypt encrypted, we will attempt to crack them in the background while we continue enumerating (cracking bcrypt is very time consuming). Nothing else in the output of LinPEAS catches our immediate attention, so we decide to do more manual checks. First, we start looking into the versions of software we know is in use. Looking at the MySQL (MariaDB) version, we learn it is running version 10.3.22. Using searchsploit to lookup exploits, we only see one that is major version “10”.

Since the minor version is less than what we are running, we Google “mariadb 10.3 vulnerability”, and find this CVE page. Reading through it, we see “wsrep_provider” mentioned, which we also saw in our searchsploit results. Additionally, it mentions the vulnerability exists for versions “10.3 before 10.3.28”, which the version we have falls between. Following the exploit, we create a reverse shell shared object file.

Next, we start a reverse shell listener on our machine with netcat. Lastly, we upload the malicious shared object to the vulnerable machine, and run the mysql command to get it to execute. Once executed, we get a reverse shell on the machine as root, and can now read root.txt.

Thank you for taking the time to read my write-up. I am interested in other ways this machine has been solved. Feel free to reach out to me and we can discuss it. Thanks!

Resources