Logique de 2FA cassée

2FA broken logic

Lab: 2FA broken logic | Web Security AcademyWebSecAcademy

L’application met en place une authentification à deux facteurs : après le login/mot de passe, un code 2FA est envoyé par email. On a :

• Nos identifiants : wiener:peter

• Le nom d’utilisateur de la victime : carlos

Accès au serveur mail pour recevoir les codes 2FA

Fonctionnement observé

1. Après la première étape de connexion, l’application envoie un code 2FA par email.

2. La seconde étape (/login2) vérifie ce code.

3. L’utilisateur pour lequel on valide le 2FA est déterminé via le cookie verify.

Exemple de requête vers la seconde étape :

GET /login2 HTTP/2

Host: 0a7500ab0376700f81a18e2c00f200a8.web-security-academy.net

Cookie: session=cNFHPofUz1wxXQpsZZN7yIiKQklG1Ygd; verify=carlos

Ici, on force le cookie verify à carlos pour que la vérification 2FA se fasse sur le compte de la victime.

Exploitation par force brute du code 2FA

1. On envoie la requête de validation 2FA au Intruder (ou équivalent) en ciblant la requête contenant :

mfa-code=XXXXX

• On configure la payload pour tester toutes les combinaisons possibles de code, de 0000 à 9999 (soit 10 000 valeurs).

On utilise le cookie :

verify=carlos

• pour que tous les essais de code soient effectués sur le compte de carlos.

• Dans les réglages, on ajoute une condition de filtrage sur la réponse afin d’ignorer celles qui contiennent le message :

  • Incorrect security code

1. On lance l’attaque de force brute.

2. Parmi les réponses, on repère celle qui ne contient plus le message d’erreur et qui retourne un code HTTP 302 (redirection). → Cette réponse correspond au code 2FA correct pour le compte de carlos.