Pentest applicatif — UnSAFE Bank

Contexte

Dans le cadre d’un cours de cybersécurité offensive, nous avons réalisé un audit de sécurité en boîte noire sur UnSAFE Bank — une application bancaire volontairement vulnérable, hébergée sur l’infrastructure de l’école. L’objectif reproduit une prestation réelle : simuler une attaque externe à partir d’une seule information (une adresse IP), identifier les failles, évaluer leur impact, et restituer les résultats dans un rapport professionnel accompagné d’une présentation orale.

Projet réalisé en équipe de trois sous le nom fictif Oteria-Pentest : Elise Chabeniuk, Florian Mora, Josselin Menguy.

UnSAFE Bank est un projet open source conçu pour l’apprentissage du pentest web et mobile : github.com/lucideus-repo/UnSAFE_Bank

Prise d’empreinte

À partir de l’IP 192.168.10.20, une reconnaissance via curl et nmap a révélé la surface d’attaque complète :

nmap -sS -p- -A 192.168.10.20

PORT     SERVICE   VERSION
22/tcp   ssh       OpenSSH 9.2p1 Debian
80/tcp   http      Apache/2.4.33 ← obsolète
199/tcp  smux      Linux SNMP multiplexer
3000/tcp http      nginx/1.27.2  ← UnSAFE Bank

Les headers HTTP exposaient la version Apache (2.4.33, non patchée depuis 2018), PHP/7.2.7 (EOL depuis 2019), et des en-têtes CORS trop permissifs (Access-Control-Allow-Origin: *) autorisant n’importe quel site à accéder aux ressources de l’API — y compris les données bancaires.

Vulnérabilités découvertes

🔴 ID01 — IDOR : Exfiltration de tous les comptes utilisateurs

Criticité : Critical | Exploitabilité : Medium 2.3 | Score : 9.0

L’API exposait les profils utilisateurs via un paramètre userid numérique séquentiel, sans aucune vérification que l’utilisateur connecté avait le droit d’accéder à cet ID. En configurant un Intruder Burp Suite avec une liste de 00000 à 99999, nous avons récupéré en quelques minutes les données complètes de tous les comptes de la plateforme : nom, adresse, numéro de téléphone, solde bancaire, numéro de carte, numéro fiscal, date de naissance…

Résultat Burp Intruder — IDOR ID01

Impact et score CVSS — ID01

Le tout sans droits administrateur, depuis un simple compte client standard.

Remédiation : contrôle d’accès côté serveur vérifiant que l’utilisateur authentifié accède uniquement à ses propres données ; remplacement des IDs séquentiels par des UUID aléatoires non prédictibles.

🔴 ID02 — Changement de mot de passe non sécurisé + énumération de comptes

Criticité : Critical | Exploitabilité : Medium 2.8 | Score : 9.6

La page “Mot de passe oublié” renvoyait des réponses HTTP de longueur différente selon que le compte existait ou non — permettant d’énumérer tous les comptes valides via Burp Intruder. Une fois un compte ciblé, l’OTP de validation était accessible directement dans la réponse HTTP du serveur côté client, rendant la protection 2FA totalement inutile. Aucun rate limiting, aucun CAPTCHA.

Énumération des comptes via Burp — ID02

Remédiation : réponse uniforme quelle que soit la validité du compte ; OTP généré et vérifié uniquement côté serveur ; rate limiting et CAPTCHA sur toutes les pages d’authentification ; tokens à durée de vie courte (nonce).

🔴 ID03 — Path Traversal : lecture de fichiers système

Criticité : Medium (mais impact critique en chaîne) | Exploitabilité : Medium 2.3 | Score : 6.5

Le paramètre file de l’API (GET /api/show?file=about.html) n’était pas sanitisé. En injectant des séquences de traversal encodées (../../../../etc/passwd), nous avons accédé directement aux fichiers système du serveur depuis le navigateur :

Path Traversal — accès /etc/passwd et /etc/hosts — ID03

Fichiers accessibles : /etc/hosts, /etc/passwd, /etc/shadow. L’accès à /etc/shadow permettrait des attaques par force brute hors ligne sur les mots de passe chiffrés — pouvant mener à une compromission totale du serveur.

Remédiation : validation stricte des entrées (whitelist de fichiers autorisés), normalisation des chemins, principe de moindre privilège sur les processus Apache/PHP.

🔴 ID04 — Input Manipulation : fraude financière par montant négatif

Criticité : High | Exploitabilité : Medium 2.3 | Score : 7.6

Lors d’un virement bancaire, la requête HTTP interceptée via Burp Suite contenait le champ amount en clair et modifiable. En injectant un montant négatif, le serveur acceptait la transaction sans validation — créditant le compte de l’attaquant :

"data": {
  "alias": "Margarita",
  "amount": -1000000,
  "remarks": "Donne mon argent"
}

Fraude par montant négatif — résultat du compte — ID04

Le solde après exploitation atteignait ₹11,716,626.60. Exploitable de façon automatisée et à grande échelle, avec un impact financier potentiellement catastrophique.

Remédiation : validation côté serveur interdisant tout montant ≤ 0 ; tokens anti-rejeu sur chaque transaction ; signature numérique des requêtes de paiement.

🔴 ID05 — XSS stockée sur la page de profil

Criticité : Major | Exploitabilité : Medium 2.1 | Score : 6.3

Le champ “Adresse” du formulaire de profil n’était pas sanitisé. Un payload JavaScript injecté dans ce champ était exécuté à chaque visite de la page, pour tous les utilisateurs consultant ce profil — y compris les administrateurs.

<img src=x onerror=console.log("salut")>

XSS stockée — injection dans le champ adresse — ID05

Impacts possibles : vol de cookies de session, phishing ciblé sur les administrateurs, défacement de l’interface, port scanning interne via le navigateur victime, modification des données de business logic.

Remédiation : échappement systématique de toutes les sorties HTML (escaping), sanitisation des entrées, mise en place d’une Content Security Policy (CSP) stricte.

Synthèse et bilan

Bilan de l'audit — répartition par gravité

Plan d'actions priorisé

ID	Vulnérabilité	Gravité	Score
ID01	IDOR — Exfiltration de tous les comptes	🔴 Critical	9.0
ID02	Changement de mot de passe non sécurisé	🔴 Critical	9.6
ID03	Path Traversal — Fichiers système	🟠 Medium	6.5
ID04	Input Manipulation — Fraude financière	🟡 High	7.6
ID05	Injection XSS stockée	🟡 Major	6.3

0 Low / 2 Medium / 1 High / 2 Critical

Les deux vulnérabilités critiques permettaient à elles seules, depuis un simple compte client, de compromettre l’ensemble des comptes utilisateurs de la plateforme et d’en prendre le contrôle total. Combinées au Path Traversal (ID03), la compromission complète du serveur était atteignable sans aucun droit particulier.

Ce que ce projet m’a appris

Ce pentest m’a permis de mettre en pratique une méthodologie d’audit complète — de la reconnaissance initiale à la rédaction d’un rapport professionnel. La chaîne ID01 → ID02 → ID03 illustre parfaitement comment des vulnérabilités “moyennes” isolées deviennent critiques lorsqu’elles sont combinées. C’est ce raisonnement en kill chain qui fait la valeur d’un audit de sécurité par rapport à un simple scan automatisé.

Projet réalisé en environnement isolé dans un cadre pédagogique. L’application UnSAFE Bank est un outil open source conçu explicitement pour l’entraînement au pentest.