Avant même que je ne commence à comprendre la science complexe de la sécurité de l'information, il me semblait que l'authentification 2FA est un moyen garanti de protéger votre compte et aucun "ces vos pirates" ne peut, par exemple, retirer ma monnaie interne pour acheter des vêtements pour les personnages sur le compte du jeu. Mais au fil du temps, il a été expérimentalement prouvé qu'un système d'authentification à deux facteurs peut présenter un grand nombre de vulnérabilités.
En termes simples, l'authentification à deux facteurs est une confirmation de l'action en entrant le code généré pour augmenter la sécurité et en jetant des bâtons dans les roues des pirates conditionnels pendant le mouvement ou avant qu'il ne commence.
Le système de confirmation de code est très répandu, il est utilisé partout sur divers sites et peut être connecté pour les connexions primaires et secondaires. Mais l'application ne se limite pas à cela - les développeurs attachent une confirmation sur la fonctionnalité de récupération de mot de passe, confirmation d'enregistrement / abonnement, confirmation supplémentaire des transactions financières, changement de mot de passe, changement de données personnelles. De plus, de temps en temps, 2FA est utilisé comme mur après la déconnexion pour le chronométrage, et non comme mot de passe ou autre moyen de confirmation.
Dans cet article, j'ai rassemblé des moyens de tester 2FA pour les vulnérabilités, leur exploitation, ainsi que les options possibles pour contourner la protection existante contre certains types d'attaques. Examinons la liste des vérifications de vulnérabilité qui s'appliquent à 2FA:
1. Absence de limite de taux
L'algorithme de limite de débit est utilisé pour tester si une session utilisateur (ou une adresse IP) peut être limitée en tentatives ou en vitesse, et dans quelles circonstances cela se produit. Si l'utilisateur a effectué trop de demandes dans un certain laps de temps, l'application Web peut répondre avec un code 429 (plusieurs demandes) ou appliquer une limite de débit sans afficher d'erreurs. L'absence de limite de taux implique que pendant l'énumération normale, il n'y a pas de restrictions sur le nombre de tentatives et / ou la vitesse - il est permis d'itérer sur les codes autant de fois (à n'importe quelle vitesse) au cours de la période de validité de la session / jeton.
Très souvent, vous devez faire face à une limite de débit «sans bruit», si vous voyez qu'il n'y a pas d'erreurs et que le corps / code HTTP ne change pas dans les requêtes suivantes, vous devriez être satisfait trop tôt, et vous devez d'abord vérifier le résultat final de l'attaque en utilisant un code valide.
2. La limite de taux existe, mais peut être contournée
Cas que j'ai dû rencontrer auparavant:
1) Limiter la vitesse des flux sans blocage après avoir atteint une certaine vitesse
Souvent, les chercheurs en sécurité essaient de récupérer du code en utilisant 5 threads ou plus pour accélérer une attaque (dans Burp Intruder, le nombre de threads par défaut est 5 sans délai). Mais parfois, un système de sécurité contre l'éclatement ou un équilibreur de charge normal ne peut répondre qu'à ce seul facteur. Si vous essayez de forcer brutalement avec 5 threads, vous devez réduire le nombre à 1, puis à 1 avec un retard d'une seconde. Plus tôt, j'ai eu la chance d'observer un tel comportement et c'est à l'aide de telles manipulations que la sélection réussie du code s'est produite, ce qui a conduit à la prise de contrôle du compte. Si le code 2FA n'a pas de date d'expiration spécifique, nous avons beaucoup de temps pour trier. Si la période de validité est présente, le succès de l'attaque est réduit, mais le danger potentiel de vulnérabilité est toujours présent, car il y a encore une chance d'entrer dans le code souhaité.
2) Le code OTP généré ne change pas
Cela ne s'applique pas aux codes en constante évolution comme dans Google Authenticator, mais uniquement aux codes statiques qui sont envoyés par SMS, e-mail ou en personne via Messenger.
L'essence de ce contournement est que le même code OTP est envoyé en permanence ou pendant un certain temps, par exemple 5 minutes, ce qui est valable pendant tout ce temps. Il est également utile de s'assurer qu'aucune limite de débit silencieuse ne se produit.
Exemple de rapport:
hackerone.com/reports/420163Supposons que l'application génère un code aléatoire de 001 à 999 et l'envoie au téléphone, dans les 10 minutes lorsque la fonctionnalité «envoyer à nouveau» est activée, nous obtenons le même code. Mais la limite de débit est liée à la demande, ce qui limite le nombre de tentatives par jeton de demande. Nous pouvons constamment demander un nouveau code, générer un nouveau jeton de demande, l'appliquer à une demande suivante (en utilisant grep-match dans une suite burp ou en utilisant notre propre script) et effectuer la force brute d'une plage de nombres de 001 à 999. Ainsi, en utilisant constamment un nouveau jeton de demande nous sélectionnerons avec succès le bon code, car il ne change pas et est statique pendant un certain temps. Les limites de cette attaque sont un nombre long ou le mélange de lettres avec des chiffres comme code de confirmation.
Cette situation ne doit pas être encouragée, vous devez essayer de trier au moins une partie de notre liste, car il est possible que le code généré se trouve dans cette partie de la liste, car il est généré de manière aléatoire. Lorsque vous essayez, vous devez vous fier au hasard, mais il y a toujours une chance de trouver la bonne combinaison, ce qui prouve une vulnérabilité qui doit définitivement être corrigée.
3) Réinitialisez rate-limit-a lors de la mise à jour du code.
Dans la demande de vérification de code, la limite de débit est présente, mais après avoir activé la fonction de renvoi du code, elle est réinitialisée et vous permet de continuer le code de force brute.
Exemples de rapports:
https://hackerone.com/reports/149598 , - théorie;
hackerone.com/reports/205000 , un exploit pratique basé sur un rapport précédent.
4) Contourner la limite de débit en changeant l'adresse IP
De nombreux verrous sont basés sur la restriction de la réception de requêtes IP, qui a atteint le seuil d'un certain nombre de tentatives lors de l'exécution d'une requête. Si l'adresse IP est modifiée, il est possible de contourner cette restriction. Afin de vérifier cette méthode, changez simplement votre IP en utilisant le serveur proxy / VPN et voyez si le blocage dépend de l'IP.
Façons de changer IP:
- Les proxys peuvent être utilisés dans une attaque à l'aide du module complémentaire IP Rotator pour Burp Suite github.com/RhinoSecurityLabs/IPRotate_Burp_Extension . À mon avis, c'est le meilleur choix, car il nous donne ~ des tentatives de force brute illimitées et des adresses IP qui vous permettent d'effectuer une attaque par force brute sans erreurs et interruptions 42x.
- Une bonne option pourrait être un script python avec un module de requêtes proxy, mais vous devez d'abord obtenir un grand nombre de proxy valides quelque part.
Étant donné que l'outil de rotation IP envoie des demandes à l'aide des adresses IP AWS, toutes les demandes seront bloquées si l'application Web se trouve derrière le pare-feu CloudFlare.
Dans ce cas, vous devez en outre découvrir l'IP du serveur Web d'origine ou trouver une méthode qui ne concerne pas les adresses IP AWS.
5) Le site inclut le support de X-Forwarded-For
L'en-tête X-Forwarded-For intégré peut être utilisé pour changer IP. Si l'application a un traitement intégré pour cet en-tête, envoyez simplement X-Forwarded-For: desire_IP pour remplacer l'adresse IP afin de contourner la restriction sans utiliser de proxy supplémentaires. Chaque fois qu'une demande est envoyée par X-Forwarded-For, le serveur Web pense que notre adresse IP correspond à la valeur transmise via l'en-tête.
Documents sur ce sujet:
hackerone.com/reports/225897medium.com/@arbazhussain/bypassing-rate-limit-protection-by-spoofing-originating-ip-ff06adf341573. Contourner 2fa en substituant une partie de la demande d'une session d'un autre compte
Si un paramètre avec une valeur spécifique est envoyé pour vérifier le code dans la demande, essayez d'envoyer la valeur de la demande à un autre compte.
Par exemple, lors de l'envoi d'un code OTP, l'ID de formulaire, l'ID utilisateur ou le cookie associé à l'envoi du code est vérifié. Si nous appliquons les données des paramètres du compte sur lequel vous souhaitez contourner la vérification du code (compte 1) à une session d'un compte complètement différent (compte 2), nous obtiendrons le code et le saisirons sur le deuxième compte, nous pourrons alors contourner la protection sur le premier compte. Après le rechargement, la page 2FA devrait disparaître.
4. Contournez 2FA en utilisant la «fonctionnalité de mémorisation»
De nombreux sites qui prennent en charge l'autorisation 2FA ont la fonctionnalité «se souvenir de moi». Il est utile lorsque l'utilisateur ne souhaite pas entrer de code 2FA lors des connexions suivantes. Il est important d'identifier la manière dont la «2FA» est «mémorisée». Cela peut être un cookie, une valeur dans la session / stockage local, ou simplement attacher 2FA à une adresse IP.
1) Si 2FA est attaché à l'aide d'un cookie, la valeur du cookie doit être impossible à deviner
Autrement dit, si un cookie se compose d'un ensemble de nombres qui augmentent pour chaque compte, il est tout à fait possible d'appliquer une attaque par force brute à la valeur du cookie et de contourner 2FA. Les développeurs doivent fournir le cookie (avec le cookie de session clé et le jeton CSRF) avec l'attribut HttpOnly afin qu'il ne puisse pas être volé à l'aide de XSS et utilisé pour contourner 2FA.
2) Si 2FA est attaché à l'adresse IP, vous pouvez essayer de le remplacer
Pour identifier cette méthode, connectez-vous à votre compte à l'aide de la fonction de stockage 2FA, puis passez à un autre navigateur ou au mode navigation privée du navigateur actuel et essayez de vous reconnecter. Si 2FA n'est pas demandé du tout, alors 2FA a été attaché à l'adresse IP.
Pour remplacer l'adresse IP, vous pouvez utiliser l'en-tête X-Forwarded-For au stade de la saisie du nom d'utilisateur et du mot de passe, si l'application Web le prend en charge.
En utilisant cet en-tête, vous pouvez également contourner la fonction de liste blanche d'adresses IP, si une est présente dans les paramètres du compte. Il peut être utilisé conjointement avec 2FA comme protection de compte supplémentaire ou 2FA peut même ne pas être demandé si l'adresse IP correspond à la liste blanche (avec le consentement de l'utilisateur). Ainsi, même sans attacher le 2FA à l'adresse IP, dans certains cas, le 2FA peut être contourné en contournant les méthodes de protection associées.
En général, attacher 2FA à une adresse IP n'est pas un moyen de protection complètement sûr, car lorsque vous êtes présent sur le même réseau, lorsqu'il est connecté au même fournisseur de services VPN / Internet avec une adresse IP statique, 2FA peut être contourné.
Le moyen le plus sûr de vous protéger est de ne pas vous souvenir du 2FA au détriment de la convivialité.
5. Bogue de contrôle d'accès incorrect sur la page d'entrée 2FA
Parfois, une page de dialogue pour entrer 2FA est présentée comme une URL avec des paramètres. L'accès à une telle page avec des paramètres dans l'URL avec des cookies qui ne correspondent pas à ceux utilisés pour générer la page ou sans cookies du tout n'est pas sûr. Mais si les développeurs ont décidé d'accepter les risques, vous devez passer par plusieurs points importants:
- Le lien expire-t-il pour l'entrée 2FA?
- si le lien est indexé dans les moteurs de recherche.
Si le lien a une longue durée de vie et / ou que les moteurs de recherche contiennent des liens de travail pour l'entrée 2FA / les liens peuvent être indexés (il n'y a pas de règles dans les balises robots.txt / meta), il y a une possibilité d'utiliser un mécanisme de contournement 2FA sur la page d'entrée 2FA, dans laquelle contournez complètement l'identifiant et le mot de passe et accédez au compte de quelqu'un d'autre.
6. Censure inadéquate des données personnelles à la page 2FA
Lors de l'envoi d'un code OTP sur une page, la censure est utilisée pour protéger les données personnelles telles que l'e-mail, le numéro de téléphone, le surnom, etc. Mais ces données peuvent être entièrement divulguées dans les points de terminaison API et autres demandes pour lesquelles nous avons suffisamment de droits au stade 2FA. Si au départ, ces données n'étaient pas connues, par exemple, nous avons entré uniquement une connexion sans connaître le numéro de téléphone, cela est considéré comme la vulnérabilité de divulgation d'informations. La connaissance du numéro de téléphone / e-mail peut être utilisée pour des attaques de phishing et de force brute ultérieures.
Un exemple d'exploitation d'une vulnérabilité à l'aide du bourrage d'informations d'identification. Disons qu'il existe une base de données dans le domaine public avec des connexions et des mots de passe pour le site A. Les attaquants peuvent utiliser les données de cette base de données sur le site B:
- Tout d'abord, ils vérifient si l'utilisateur existe dans la base de données du site B à l'aide du bogue «Énumération des comptes» lors de l'enregistrement / récupération du mot de passe. En règle générale, de nombreux sites ne considèrent pas cela comme une vulnérabilité et prennent des risques. La «vulnérabilité» réside dans la présence d'une erreur sur le fait de l'inscription des utilisateurs sur le site. Idéalement, un message sécurisé sur la page de récupération de mot de passe est le suivant:
- Après avoir obtenu la base de données des utilisateurs existants, les attaquants appliquent des mots de passe à ces comptes.
- S'ils rencontrent 2FA, ils sont bloqués. Mais en cas de censure insuffisante des données des utilisateurs, ils peuvent compléter leur base de données avec leurs données personnelles (s'ils n'étaient pas dans la base de données d'origine).
7. Ignorer 2FA dans certaines circonstances
Lors de l'exécution de certaines actions qui conduisent à une connexion automatique à votre compte, 2FA peut ne pas être demandé.
1) Ignorez 2FA lors de la récupération d'un mot de passe
De nombreux services se connectent automatiquement à votre compte après avoir terminé la procédure de récupération de mot de passe. Étant donné que l'accès au compte est fourni instantanément, lorsque vous vous connectez à votre compte 2FA, il peut être ignoré et complètement ignoré.
Impact d'un rapport de piratage similaire que j'ai envoyé récemment:
Si un attaquant accède au courrier électronique de la victime (il peut pirater le compte à l'aide de phishing, d'attaques par force brute, de bourrage d'informations d'identification, etc.), il peut contourner 2FA, bien que dans ce cas, 2FA devrait protéger le compte. Pour le moment, pour 2FA, il y a une vérification du code Google Authenticator ou du code de sauvegarde, mais pas du code de l'e-mail, donc ce contournement est logique.
2) Ignorer 2FA lors de la connexion via un réseau social
Vous pouvez attacher un réseau social à votre compte utilisateur pour vous connecter rapidement à votre compte et en même temps configurer 2FA. Lorsque vous vous connectez à votre compte via les réseaux sociaux, 2FA peut être ignoré. Si l'e-mail de la victime est piraté, il sera possible de récupérer le mot de passe du compte de réseau social (s'il le permet) et d'accéder au service sans entrer 2FA.
Impact d'un des rapports:
- Un tas d'autres vulnérabilités, telles que la mauvaise configuration OAuth précédemment envoyée # 577468, pour capturer complètement le compte, cassant 2FA.
- Si un attaquant piratait le courrier électronique de l'utilisateur, il pourrait essayer de retrouver l'accès au compte de réseau social et se connecter au compte sans vérification supplémentaire.
- Si un attaquant piratait une fois le compte d'une victime, il pourrait associer un réseau social au compte et se connecter à l'avenir, ignorant complètement 2FA et entrant le login / mot de passe.
3) Ignorer 2FA dans une ancienne version de l'application
Les développeurs ajoutent souvent des versions intermédiaires d'une application Web aux domaines / sous-domaines pour tester certaines fonctions. Fait intéressant, si vous vous connectez en utilisant votre nom d'utilisateur et votre mot de passe, 2FA ne sera pas demandé. Peut-être que les développeurs utilisent une ancienne version de l'application, dans laquelle il n'y a pas de protection pour 2FA, 2FA elle-même est désactivée ou elle a été intentionnellement désactivée pour les tests.
En outre, vous pouvez vérifier d'autres vulnérabilités en même temps, - l'enregistrement d'un nouvel utilisateur sur un serveur de transfert dont la messagerie existe dans la base de données de version de production peut nous fournir des données personnelles de production; l'absence de limite de débit dans des fonctionnalités importantes, par exemple la récupération de mot de passe. Un exemple de la dernière vulnérabilité est un bogue Facebook de 15 000 $, qui permettait de pirater un compte à l'aide du code de récupération de mot de passe bruteforce sur beta.facebook.com
www.freecodecamp.org/news/responsible-disclosure-how-i-could-have-hacked-all- comptes-facebook-f47c0252ae4d .
4) Ignorer 2FA en cas de multiplateforme
Les implémentations 2FA dans la version mobile ou de bureau peuvent différer de la version Web de l'application. 2FA peut être plus faible que dans la version Web ou complètement absent.
7. Lors de la désactivation de 2FA, le code actuel n'est pas demandé.
Si, lors de la désactivation de 2FA, aucune confirmation supplémentaire n'est demandée, comme le code actuel de l'application d'authentification Google, le code de l'e-mail / téléphone, alors dans ce cas, il existe certains risques. Avec une demande claire, il y a une chance d'une attaque CSRF. Si un vecteur de contournement de la protection CSRF est trouvé (le cas échéant), alors 2FA peut être désactivé. Une vulnérabilité de détournement de clics peut également être utilisée - après quelques clics d'un utilisateur sans méfiance, 2FA sera déconnecté. La validation du code précédent ajoutera une protection 2FA supplémentaire, compte tenu des attaques potentielles CSRF / XSS / Clickjacking, ainsi que des erreurs de configuration de CORS.
Je vais vous donner un exemple de hackerone.com, - lorsque vous désactivez 2FA dans un formulaire, vous devez saisir deux variables en même temps, - le code actuel avec l'application d'authentification google et le mot de passe. Il s'agit de la meilleure protection recommandée.
8. Les sessions précédemment créées restent valables après l'activation de 2FA
Lorsque 2FA est activé, il est souhaitable que les sessions parallèles sur le même compte se terminent et que la boîte de dialogue d'entrée 2FA s'affiche, de même avec un changement de mot de passe. Si le compte a été compromis et que la première réaction de la victime est l'inclusion de 2FA, la session de l'attaquant sera désactivée et le prochain login et mot de passe nécessitera 2FA. Dans l'ensemble, c'est la meilleure pratique à suivre. Je remarque souvent comment les échanges de crypto-monnaie ajoutent une protection similaire. Exemple de rapport HackerOne, -
https://hackerone.com/reports/534450.
9. L'absence de limite de taux dans votre compte
2FA peut être implémenté dans diverses fonctions du compte personnel de l'utilisateur pour plus de sécurité. Cela peut être un changement d'adresse e-mail, de mot de passe, la confirmation d'un changement de code pour les transactions financières, etc. La présence de rate-limit-a dans votre compte peut différer de la présence de rate-limit-a dans 2FA lors de la connexion à votre compte. J'ai souvent rencontré des cas similaires où il était possible de sélectionner librement un code 2FA dans mon compte, alors qu'à l'entrée une limite de taux «stricte» était fixée.
Si les développeurs ont initialement ajouté une protection contre les modifications de données non autorisées, cette protection doit être prise en charge et corrigée par tous les contournements possibles. Si un contournement est trouvé, cela est considéré comme une vulnérabilité de contournement des fonctionnalités de sécurité qui a été implémentée par les développeurs.
10. Versionnage de l'API
Si vous voyez quelque chose comme / v * / dans la demande de l'application Web, où * est un nombre, il est probable que vous puissiez passer à une ancienne version de l'API.
Dans l'ancienne version de l'API, il peut y avoir une protection faible ou pas du tout. Il s'agit d'un événement assez rare qui se produit si les développeurs oublient de supprimer l'ancienne version de l'API dans l'environnement de production / de transfert.Par exemple, / endpoint / api / v4 / login effectue une demande de connexion, vérifiant le nom d'utilisateur et le mot de passe. Si 2FA est présent dans le compte, cette demande doit être suivie de / endpoint / api / v4 / 2fa_check, rien d'autre. Si nous remplaçons la version API avant 2FA, alors, dans certains cas, nous pouvons l'éviter. / endpoint / api / v3 / login peut conduire à / endpoint / v3 / login_successful? code = RANDOM, ignorant 2fa_check car dans cette version de l'API, 2FA n'était tout simplement pas implémenté.Un autre exemple - dans la requête / endpoint / api / v4 / 2fa_check il y a une limite de débit, tandis que / endpoint / api / v3 / 2fa_check vous permet d'itérer sur les codes sans aucune restriction.11. Contrôle d'accès incorrect lors de la demande de codes de sauvegarde
Les codes de sauvegarde sont générés immédiatement après l'activation de 2FA et sont disponibles sur une seule demande. Après chaque appel ultérieur à la demande, les codes peuvent être générés par un nouveau ou rester inchangés (codes statiques). S'il existe des vulnérabilités CORS de mauvaise configuration / XSS et d'autres bogues qui vous permettent de «tirer» les codes de sauvegarde de la demande de réponse du point de terminaison d'affichage du code de sauvegarde, l'attaquant pourrait voler les codes et contourner 2FA si le nom d'utilisateur et le mot de passe sont connus.En général, 2fa est l'un des moyens les plus fiables de protéger votre compte, sauf si, bien sûr, les développeurs stockent les codes 2FA actuels de tous les utilisateurs de l'application Web dans le panneau d'administration - et cela s'est produit dans ma pratique. Je voudrais également noter que les développeurs de certaines entreprises créent des applications pour générer leurs propres codes 2FA (des exemples sont Salesforce, Valve) et, en raison d'une sécurité insuffisante, cette insistance sur l'indépendance par rapport à l'utilisation d'autres applications d'authentification donne aux attaquants un point d'entrée supplémentaire pour contourner 2FA. Le champ d'application de cette protection est assez large et donne à ceux qui souhaitent contourner la protection 2FA plus d'opportunités, un espace pour la créativité et augmente le nombre de variantes de dérivation 2FA.J'espère que ces informations ont été utiles aux chercheurs en sécurité de l'information, aux chasseurs de primes aux bogues, ainsi qu'aux développeurs pour minimiser le nombre de vulnérabilités dans le service en cours de développement. Restez en sécurité!