Post

Write-up - Interceptor

Write-up - Interceptor

Write-up - Interceptor

La cible est la machine CTF Interceptor (10.129.176.139). Le chemin d’exploitation repose sur une fuite de fichier de backup, un compte administrateur de staging encore présent, un contournement de 2FA via une requête interceptée avec Burp, puis une lecture de fichier locale via la fonctionnalité d’import de flux.

Synthèse

La compromission suit la chaîne suivante :

  1. scan TCP complet : SSH, DNS et HTTP exposés
  2. énumération web sur MediaHub
  3. découverte de login.php.bak
  4. lecture du backup et récupération d’un indice sur le compte administrateur
  5. authentification avec admin@mediahub.thm et MediaHub2026
  6. interception de la requête OTP avec Burp
  7. validation de la 2FA grâce au paramètre client-side is_verified
  8. accès au dashboard administrateur et récupération du premier flag
  9. abus de l’import de feed pour faire lire /var/www/user.txt par le serveur
  10. récupération du flag final

Reconnaissance

Le scan TCP complet montre trois ports ouverts : SSH, DNS et HTTP.

1
2
TARGET=10.129.176.139
nmap -p- -Pn -oA "$TARGET"_full_ports --min-rate 1000 "$TARGET" -v

Scan TCP complet

Ports ouverts :

PortService
22/tcpssh
53/tcpdomain
80/tcphttp

Une énumération de version confirme que le port 80 héberge une application web appelée MediaHub sur Apache.

1
nmap -sVC -p 80,22,53 "$TARGET"

Services observés :

1
2
3
4
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu
53/tcp open  domain  ISC BIND 9.16.1
80/tcp open  http    Apache httpd 2.4.41
http-title: MediaHub

Découverte du backup PHP

Une énumération web avec des extensions de fichiers de backup permet de trouver login.php.bak. Les réponses de taille 1491 correspondent au comportement générique de l’application, elles sont donc exclues.

1
2
3
4
5
6
gobuster dir \
  -w /usr/share/dirb/wordlists/common.txt \
  -u "http://$TARGET/" \
  -x php.bak,bak,log,tar.gz,zip \
  -xl 1491 \
  -b 403

Découverte du backup login.php.bak

Le fichier est ensuite téléchargé localement.

1
wget "http://$TARGET/login.php.bak"

Téléchargement du backup PHP

Fuite d’identifiants administrateur

Le début du fichier login.php.bak contient une note de développement temporaire. Elle expose l’adresse du compte administrateur de staging ainsi que le format du mot de passe.

1
head -20 login.php.bak

Indice administrateur dans le backup

Informations récupérées :

1
2
3
Email: admin@mediahub.thm
Admin password follows company format:
MediaHub + any year

Le premier essai d’authentification a réussi avec les identifiants suivants :

1
admin@mediahub.thm : MediaHub2026

Connexion administrateur

Contournement de la 2FA avec Burp

Après la connexion, l’application demande un code OTP à six chiffres. La requête de validation est interceptée avec Burp.

Requête OTP interceptée dans Burp

Dans le corps multipart de la requête POST vers verify_otp.php, le champ envoyé par le formulaire porte initialement l’attribut name="otp". En interceptant la requête avec Burp, cet attribut est remplacé par name="is_verified".

Cette modification indique que l’application fait confiance à un état envoyé par le client au lieu de valider uniquement un secret côté serveur. La requête est acceptée et l’utilisateur est redirigé vers la session administrateur.

OTP accepté

Le dashboard administrateur affiche alors le premier flag :

Dashboard administrateur

Flag obtenu :

1
THM{ADMIN_ACCESS_USING_BURP}

Lecture locale via l’import de feed

Le dashboard contient une fonctionnalité Import Feed. Elle accepte une URL RSS/Atom, puis le serveur la récupère et renvoie la sortie brute. Le message de l’interface précise que, sans accès Internet, la réponse attendue est Internet not connected.

L’entrée utilisateur est transmise à l’outil de récupération côté serveur sans validation suffisante. En fournissant une seconde URL file://, le serveur lit un fichier local et renvoie son contenu.

Payload utilisé :

1
http://127.0.0; file:///var/www/user.txt

Lecture locale via l'import de feed

La première partie du payload provoque une requête HTTP locale invalide, mais la seconde URL file:// est traitée ensuite et retourne le contenu de /var/www/user.txt.

Flag obtenu :

1
THM{SYSTEM_PWNED_SUCCESSFULLY}

Tableau récapitulatif des flags

ÉtapeVulnérabilité principaleFlag
Accès administrateur2FA contournable via paramètre client-sideTHM{ADMIN_ACCESS_USING_BURP}
Import de feedlecture de fichier local via URL file://THM{SYSTEM_PWNED_SUCCESSFULLY}

Causes racines et remédiations

  • Supprimer les fichiers de backup comme *.bak de la racine web et empêcher leur exposition par la configuration du serveur HTTP.
  • Ne jamais laisser de comptes de test ou de notes de développement contenant des indices d’identifiants dans du code déployé.
  • Appliquer une vraie politique de secrets : mots de passe générés aléatoirement, rotation, stockage hors code et hors commentaires.
  • Valider la 2FA côté serveur uniquement, avec un OTP lié à la session, une expiration courte et aucune confiance dans un paramètre d’état envoyé par le client.
  • Encadrer strictement les fonctionnalités de fetch serveur : allowlist de schémas et domaines, interdiction de file://, interdiction des adresses locales si non nécessaires, et exécution sans shell.
  • Séparer les permissions applicatives afin qu’un composant web ne puisse pas lire des fichiers sensibles comme /var/www/user.txt sans nécessité métier.

Conclusion

Interceptor illustre une chaîne d’exploitation typique côté web : une fuite de backup donne un accès initial, une 2FA mal conçue permet d’obtenir une session administrateur, puis une fonctionnalité serveur trop permissive permet de lire un fichier local. Le challenge montre surtout l’importance de ne pas exposer les artefacts de développement et de ne jamais faire confiance à un état de sécurité contrôlé par le client.

This post is licensed under CC BY 4.0 by the author.