Sponsored

2FA/MFA/OTP Bypass

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez le hacking Az : HackTricks Training Azure Red Team Expert (AzRTE)
Consultez le catalogue complet HackTricks Training.

Soutenir HackTricks

Techniques avancées de contournement de l’authentification à deux facteurs

Accès direct à un Endpoint

Voir Proxmox VE pour un exemple spécifique à un produit de confusion de l’état TFA choisi par le client.

Essayez d’accéder directement à l’endpoint post-connexion et vérifiez que le serveur — et pas seulement l’interface — exige que l’état MFA soit complété. Si une application fait confiance à tort aux métadonnées de navigation, testez également l’en-tête HTTP Referer correctement orthographié ; une implémentation sécurisée ne doit pas l’utiliser comme preuve de MFA.[2][5]

Réutilisation de Tokens

La réutilisation, au sein d’un compte, de tokens déjà utilisés pour l’authentification peut être efficace.[2]

Utilisation de Tokens inutilisés

Vérifiez si un token inutilisé, généré pour votre propre compte de test, est accepté à tort pour un autre compte de test autorisé. Cela permet de vérifier que les OTP sont liés au bon compte, à la bonne session, à la bonne finalité et à la bonne transaction.[2][5]

Exposition du Token

Vérifiez si le token est divulgué dans une réponse de l’application web.[2]

Exploitation du lien de vérification

L’utilisation du lien de vérification par e-mail envoyé lors de la création du compte peut permettre d’accéder au profil sans 2FA, comme le souligne un article détaillé.[3]

Manipulation de session

Initiez des sessions pour deux comptes de test autorisés, complétez le MFA dans l’une d’elles et vérifiez que son état de complétion ne peut pas être transféré à l’autre session. Le backend doit lier le résultat du MFA au même compte et à la même session pré-authentification.[5]

Mécanisme de réinitialisation du mot de passe

Il est essentiel d’examiner la fonction de réinitialisation du mot de passe, qui connecte l’utilisateur à l’application après la réinitialisation, afin de déterminer si elle permet plusieurs réinitialisations avec le même lien. Se connecter avec les nouveaux identifiants peut contourner le 2FA.[2]

Compromission de la plateforme OAuth

Vérifiez si un parcours de connexion fédérée OAuth/OIDC impose un niveau d’assurance équivalent à celui du parcours de l’application utilisant un mot de passe et le MFA. La prise de contrôle du compte d’identité en amont peut contourner le MFA local de l’application uniquement si la partie utilisatrice accepte cette session fédérée moins sécurisée.[5]

Attaques par Brute Force

Absence de Rate Limit

L’absence de limite au nombre de tentatives de saisie du code permet des attaques par brute force, mais il faut aussi tenir compte d’un éventuel rate limiting silencieux.[1][2]

Notez que même si un rate limit est en place, vous devriez vérifier si la réponse diffère lorsque l’OTP valide est envoyé. Dans cet article, le bug hunter a découvert que même si un rate limit était déclenché après 20 tentatives infructueuses et renvoyait une réponse 401, l’envoi du code valide entraînait une réponse 200.[4]

Brute Force lente

Une attaque par brute force lente est possible lorsque le flux est soumis à des rate limits, mais qu’aucun rate limit global n’est appliqué.[1]

Réinitialisation de la limite de renvoi du code

Renvoyer le code réinitialise le rate limit, ce qui permet de poursuivre les tentatives de brute force.[1]

Contournement du Rate Limit côté client

Si le throttling n’est mis en œuvre qu’en JavaScript, rejouez la requête directement et vérifiez si le serveur applique indépendamment des limites par compte, par session et des limites plus générales contre les abus.[1][5]

Absence de Rate Limit sur les actions internes

Les rate limits peuvent protéger les tentatives de connexion, mais pas les actions internes au compte.[1]

Coûts liés au renvoi de codes SMS

Le renvoi excessif de codes par SMS engendre des coûts pour l’entreprise, mais ne contourne pas le 2FA.

Régénération infinie d’OTP

La génération infinie d’OTP simples permet le brute force en réessayant un petit ensemble de codes.[1]

Exploitation d’une Race Condition

Envoyez simultanément le même OTP ou code de récupération et vérifiez que sa validation et sa consommation sont atomiques. Il existe une race condition si plusieurs requêtes peuvent utiliser une valeur à usage unique.[5]

Vulnérabilités CSRF/Clickjacking

L’exploitation de vulnérabilités CSRF ou Clickjacking pour désactiver le 2FA est une stratégie viable.[1][2]

Exploitation de la fonctionnalité « Remember Me »

Deviner la valeur du cookie « remember me » peut contourner les restrictions.[1]

Usurpation d’adresse IP

Usurper l’adresse IP de la victime à l’aide de l’en-tête X-Forwarded-For peut contourner les restrictions.[1]

Utilisation d’anciennes versions

Sous-domaines

Vérifiez si des sous-domaines exposent d’anciennes applications ou des parcours d’authentification qui n’imposent pas l’exigence MFA actuelle.[1]

Endpoints API

Les anciennes versions de l’API, indiquées par des chemins de répertoire /v*, peuvent être vulnérables à des méthodes de contournement du 2FA.[1]

Gestion des sessions précédentes

La suppression des sessions existantes lors de l’activation du 2FA protège les comptes contre les accès non autorisés à partir de sessions compromises.[1]

Failles de contrôle d’accès liées aux codes de secours

La génération immédiate de codes de secours et leur récupération potentiellement non autorisée après l’activation du 2FA, notamment en cas de mauvaise configuration CORS ou de vulnérabilités XSS, présentent un risque.[1][2]

Divulgation d’informations sur la page 2FA

La divulgation d’informations sensibles (par exemple, le numéro de téléphone) sur la page de vérification 2FA est préoccupante.[1]

Désactivation du 2FA lors de la réinitialisation du mot de passe

Un processus qui peut démontrer une méthode de contournement consiste à créer un compte, activer le 2FA, réinitialiser le mot de passe, puis se connecter sans que le 2FA soit exigé.[2]

Requêtes leurres

L’utilisation de requêtes leurres pour dissimuler des tentatives de brute force ou tromper les mécanismes de rate limiting constitue une autre stratégie de contournement. La création de telles requêtes nécessite une compréhension nuancée des mesures de sécurité et des comportements de rate limiting de l’application.

Erreurs de construction d’OTP

Si l’OTP est dérivé uniquement de données prévisibles ou fournies par le client, un utilisateur peut être en mesure de le reproduire. Vérifiez que les codes sont générés à partir d’un secret cryptographiquement sécurisé, qu’ils ont une durée de validité courte, qu’ils ne peuvent être utilisés qu’une seule fois et qu’ils sont liés au bon compte et à la bonne action.[5]

Authentification step-up non appliquée (acr, amr, auth_time)

Certaines applications autorisent les utilisateurs à se connecter avec une méthode peu sécurisée et ne demandent le MFA ou une nouvelle connexion qu’avant une action sensible (modifier l’adresse e-mail, ajouter un bénéficiaire, exporter des données, accéder à une zone d’administration). C’est ce qu’on appelle l’authentification step-up. Avec OpenID Connect ou OAuth, le processus fonctionne généralement ainsi :

  • Le client demande au fournisseur d’identité une connexion plus forte avec acr_values=<level> et/ou max_age=<seconds> dans la requête d’autorisation.[6]
  • L’ID token, ou un profil d’access token contenant le contexte d’authentification, peut indiquer ce qui s’est passé : acr (le niveau d’authentification satisfait), amr (les méthodes utilisées, par exemple ["pwd","otp"]) et auth_time (le moment où l’utilisateur s’est authentifié). Ces claims ne sont pas tous présents dans chaque token.[6]
  • Une API qui exige une connexion plus forte répond par 401 avec WWW-Authenticate: Bearer error="insufficient_user_authentication", acr_values="...", max_age=..., et doit vérifier acr et auth_time dans le token reçu.[7]

acr_values n’est qu’une requête. Le client (ou l’API) doit vérifier les claims reçus. OIDC Core indique que le client devrait vérifier que la valeur de acr est appropriée, ainsi que auth_time, et demander une nouvelle authentification si trop de temps s’est écoulé.[6] Dans le cas contraire, l’authentification step-up peut être ignorée.

Tests en boîte noire avec un compte de test doté du MFA :

  1. Interceptez la requête d’autorisation step-up et supprimez acr_values / max_age, ou remplacez acr_values par une valeur moins forte (par exemple, remplacez mfa ou urn:...:loa:2 par la valeur observée lors d’une connexion normale). Terminez la connexion sans MFA et utilisez le résultat pour effectuer l’action sensible.
  2. Appelez directement l’endpoint sensible avec le token ou la session de connexion normale (acr faible, amr sans otp/mfa). La requête doit être rejetée avec un challenge step-up.
  3. Utilisez un token dont auth_time est antérieur au max_age requis (connectez-vous, attendez, puis essayez d’effectuer l’action).
  4. Après une authentification step-up réussie (par exemple, pour consulter une clé API), réutilisez la même session ou le même token « élevé » pour d’autres actions sensibles, puis pour la même action bien plus tard. Vérifiez si l’état élevé est limité à une seule action et s’il expire.
  5. Si l’application conserve le résultat de l’authentification step-up dans un indicateur côté client ("mfaVerified": true, cookie elevated=1, champ dans un token non signé), modifiez-le manuellement.

La vulnérabilité est avérée si l’action sensible réussit sans acr/amr plus fort ou avec un auth_time antérieur à la limite autorisée. Pour un indicateur de session élevée réutilisé sur des fonctions sans rapport, voir également la réutilisation d’un état d’autorisation lié à la session.

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez le hacking Az : HackTricks Training Azure Red Team Expert (AzRTE)
Consultez le catalogue complet HackTricks Training.

Soutenir HackTricks
Sponsored