Enumeration
As with every machine, I like to start off with an nmap scan of all TCP ports using the standard NSE scripts and gather version information. Additionally, I did a scan of the top UDP ports. The results of the scans show TCP ports 22, 80, 8338, and 55555 as open as well as UDP port 68 being open. Looking closer at the results, TCP ports 80 and 8338 are showing as filtered. This means there is a firewall or filter in place that is preventing a successful connection from the attack box to the target box.
┌──(kali㉿kali)-[~/HTB/Sau]
└─$ sudo nmap -sC -sV -p- -oA nmap/full.tcp 10.129.229.26
[sudo] password for kali:
Starting Nmap 7.94SVN ( https://nmap.org ) at 2023-12-25 21:31 EST
Nmap scan report for 10.129.229.26
Host is up (0.19s latency).
Not shown: 65531 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 aa:88:67:d7:13:3d:08:3a:8a:ce:9d:c4:dd:f3:e1:ed (RSA)
| 256 ec:2e:b1:05:87:2a:0c:7d:b1:49:87:64:95:dc:8a:21 (ECDSA)
|_ 256 b3:0c:47:fb:a2:f2:12:cc:ce:0b:58:82:0e:50:43:36 (ED25519)
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: Tue, 26 Dec 2023 02:47:31 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: Tue, 26 Dec 2023 02:47:01 GMT
| Content-Length: 27
| href="/web">Found</a>.
| HTTPOptions:
| HTTP/1.0 200 OK
| Allow: GET, OPTIONS
| Date: Tue, 26 Dec 2023 02:47:02 GMT
|_ Content-Length: 0
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port55555-TCP:V=7.94SVN%I=7%D=12/25%Time=658A3EA4%P=x86_64-pc-linux-gnu
SF:%r(GetRequest,A2,"HTTP/1\.0\x20302\x20Found\r\nContent-Type:\x20text/ht
SF:ml;\x20charset=utf-8\r\nLocation:\x20/web\r\nDate:\x20Tue,\x2026\x20Dec
SF:\x202023\x2002:47:01\x20GMT\r\nContent-Length:\x2027\r\n\r\n<a\x20href=
SF:\"/web\">Found</a>\.\n\n")%r(GenericLines,67,"HTTP/1\.1\x20400\x20Bad\x
SF:20Request\r\nContent-Type:\x20text/plain;\x20charset=utf-8\r\nConnectio
SF:n:\x20close\r\n\r\n400\x20Bad\x20Request")%r(HTTPOptions,60,"HTTP/1\.0\
SF:x20200\x20OK\r\nAllow:\x20GET,\x20OPTIONS\r\nDate:\x20Tue,\x2026\x20Dec
SF:\x202023\x2002:47:02\x20GMT\r\nContent-Length:\x200\r\n\r\n")%r(RTSPReq
SF:uest,67,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nContent-Type:\x20text/pl
SF:ain;\x20charset=utf-8\r\nConnection:\x20close\r\n\r\n400\x20Bad\x20Requ
SF:est")%r(Help,67,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nContent-Type:\x2
SF:0text/plain;\x20charset=utf-8\r\nConnection:\x20close\r\n\r\n400\x20Bad
SF:\x20Request")%r(SSLSessionReq,67,"HTTP/1\.1\x20400\x20Bad\x20Request\r\
SF:nContent-Type:\x20text/plain;\x20charset=utf-8\r\nConnection:\x20close\
SF:r\n\r\n400\x20Bad\x20Request")%r(TerminalServerCookie,67,"HTTP/1\.1\x20
SF:400\x20Bad\x20Request\r\nContent-Type:\x20text/plain;\x20charset=utf-8\
SF:r\nConnection:\x20close\r\n\r\n400\x20Bad\x20Request")%r(TLSSessionReq,
SF:67,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nContent-Type:\x20text/plain;\
SF:x20charset=utf-8\r\nConnection:\x20close\r\n\r\n400\x20Bad\x20Request")
SF:%r(Kerberos,67,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nContent-Type:\x20
SF:text/plain;\x20charset=utf-8\r\nConnection:\x20close\r\n\r\n400\x20Bad\
SF:x20Request")%r(FourOhFourRequest,EA,"HTTP/1\.0\x20400\x20Bad\x20Request
SF:\r\nContent-Type:\x20text/plain;\x20charset=utf-8\r\nX-Content-Type-Opt
SF:ions:\x20nosniff\r\nDate:\x20Tue,\x2026\x20Dec\x202023\x2002:47:31\x20G
SF:MT\r\nContent-Length:\x2075\r\n\r\ninvalid\x20basket\x20name;\x20the\x2
SF:0name\x20does\x20not\x20match\x20pattern:\x20\^\[\\w\\d\\-_\\\.\]{1,250
SF:}\$\n")%r(LPDString,67,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nContent-T
SF:ype:\x20text/plain;\x20charset=utf-8\r\nConnection:\x20close\r\n\r\n400
SF:\x20Bad\x20Request")%r(LDAPSearchReq,67,"HTTP/1\.1\x20400\x20Bad\x20Req
SF:uest\r\nContent-Type:\x20text/plain;\x20charset=utf-8\r\nConnection:\x2
SF:0close\r\n\r\n400\x20Bad\x20Request");
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 1033.18 secondsInitial Access
When TCP port 22 is open I like to check if there is low hanging fruit by doing a brute force attack with common usernames and passwords. In this case no valid credentials were found.
┌──(kali㉿kali)-[~/HTB/Sau]
└─$ hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt ssh://10.129.229.26As stated previously, TCP ports 80 and 8338 are showing as filtered. This was confirmed by connecting to the target machine’s IP in a browser and specifying the two ports. Each request eventually timed out. The only port left to check is TCP port 55555. After starting Burpsuite and opening its browser I navigate to the target machine’s IP and specified TCP port 55555. The purpose of using Burpsuite is to proxy the web traffic for analysis. The web requests can be viewed for any sort of information leakage in the headers such as software or version information. It also allows for the modification of web requests but at this point there is no need for that. The functionality of the web page seems fairly basic at first glance. Looking towards the bottom of the page is software and version information. Doing a Google search for “request baskets 1.2.1” reveals CVE-2023-27163.
I like to have some sort of enumeration going on in the background so before I dive too deep into researching the CVE I started a directory and file brute force against the web application.
┌──(kali㉿kali)-[~/HTB/Sau/feroxbuster]
└─$ feroxbuster -u http://10.129.229.26:55555/web -x html,asp,aspx,config,txt,config -C 400,404CVE-2023-27163 is a Server-Side Request Forgery (SSRF) vulnerability that can be exploited and can allow an attacker access to internal network resources or other sensitive information via a specially crafted API request. Additional information about the CVE can be found here – https://nvd.nist.gov/vuln/detail/CVE-2023-27163. Exploiting this vulnerability could bypass the filter in place that is preventing me from accessing TCP ports 80 and 8338.
The NIST website had the following Github page listed in the resource section – https://gist.github.com/b33t1e/3079c10c88cad379fb166c389ce3b7b3. It lays out exactly how to take advantage of the SSRF vulnerability. First thing that that needs to be done is create a basket.
After opening the basket, some changes to the configurations need to be made.
Clicking on the Settings button opens up the following menu. On the left is the basket settings and on the right is the Github page explaining how the vulnerability can be exploited. The exploit works by using the target system running request-baskets as a proxy to access internal resources that are not publicly available. Say, for example, the target system running request-baskets is also hosting a web server on TCP port 80. The target system has an iptables rule in place that only allows access to it via 127.0.0.1 , all other requests are dropped. Now if a request is made from the attack box to the target box in an attempt to access TCP port 80, it will be blocked based off that rule. By taking advantage of the SSRF however, the same request from the attack box will be proxied by the target system and will be allowed because the server is “tricked” into making the request itself. A more detailed explanation of SSRF can be found here – https://portswigger.net/web-security/ssrf.
Back to exploiting CVE-2023-27163. The forward_url parameter identifies where the request will be sent to. In this case I want to access TCP port 80. After a bit of trial and error I figured out that the Proxy Response setting needs to be enabled to interact with the internal web server.
With everything configured properly I hit Apply. After hitting OK I copy the URL for the basket that was just created and had its settings modified.
Success! Navigating to the basket’s URL triggers the vulnerability and I am able to access the internal web server on TCP port 80. Turns out TCP port 80 is running Maltrail v0.53 and it has a remote code execution (RCE) vulnerability. Going back to the NIST page above, there is a link in the resource section that contains a script for RCE – https://packetstormsecurity.com/files/174129/Maltrail-0.53-Remote-Code-Execution.html.
After reviewing the script it was discovered that an adjustment to the bucket settings needed to be made. Let me explain. Currently, traffic sent to http://{$TGT}/{bucket} is being forwarded to http://127.0.0.1:80/. However, the exploit takes advantage of a vulnerability in the Maltrail /login page. If the script is ran in the bucket’s current configuration the payload would be sent to http://{$TGT}/{bucket}/login which would obviously fail.
To fix that I need to go back and adjust the forward_url parameter so that it points to the Maltrail login page.
After making that change I was able to successfully run the script and get a callback!
Privilege Escalation
The first thing that I like to do after gaining initial access to a system is manual enumeration. My go to commands are as follows:ip aidsudo -lenvcat /etc/*releaseuname -anetstat -natplu
These commands provide situational awareness and help guide what the next steps should be. After doing my initial check I can see the user puma can run systemctl with sudo and no password is needed. Which is perfect because I do not have the user’s credentials. A quick search on GTFOBins shows that if a user can run systemctl with sudo, it is possible to get a root shell – https://gtfobins.github.io/gtfobins/systemctl/.
