Le Swedish BankID est une forme d'identification numérique utilisée par la plupart, sinon la totalité, des résidents suédois pour s'authentifier auprès de plusieurs services tels que : les fournisseurs d'accès Internet, les services bancaires en ligne, les sites de paris et en particulier les sites Web gouvernementaux. Vivant moi-même en Suède et avec la mentalité de hacker qui me trotte toujours dans la tête, j'ai décidé que ce serait un domaine très intéressant dans lequel faire des recherches sur la sécurité. Dans cet article, je présenterai une nouvelle vulnérabilité que j'ai trouvée présente chez la plupart des fournisseurs de services suédois en raison d'une mise en œuvre non sécurisée du protocole d'authentification de BankID. J'expliquerai brièvement comment fonctionne un tel protocole, à quoi ressemble une configuration vulnérable, comment l'exploiter, comment y remédier et, au final, ce que ces types d'attaques signifient pour la mise en œuvre globale des eID. Le protocole d'authentification BankID BankID est un service installé sur l'appareil d'un utilisateur et obtenu en le demandant à une banque suédoise, étant donné que vous disposez d'un suédois, un code fiscal personnel. L'application est installée sur l'appareil de l'utilisateur et connectée à son code fiscal, liant essentiellement son identité à une telle application. C'est souvent ainsi que fonctionnent les systèmes d'identification électronique : un tiers de confiance autorisé par le gouvernement distribue un logiciel lié à une personne spécifique, puis les services s'intègrent au fournisseur de ce logiciel pour permettre à leurs utilisateurs de s'authentifier sur leur compte. plateforme, un modèle de confiance partagé qui permet aux services d’authentifier facilement les personnes. numéro personnel BankID n'est pas différent et fournit une documentation pour ces services, qui seront désormais appelés Relying Party (RP), afin qu'ils puissent facilement intégrer leur flux d'authentification avec BankID. . https://www.bankid.com/en/utvecklare/guider/teknisk-integrationsguide/rp-introduktion Avec BankID, deux flux principaux sont utilisés pour authentifier un utilisateur : S'authentifier sur le même appareil S'authentifier sur un autre appareil Nous reviendrons bientôt sur ces deux flux, cependant, les deux flux commencent par l'envoi par le RP d'une requête à l'API de BankID pour lancer une commande d'authentification. Dans cette demande de publication, le RP doit spécifier le paramètre , qui contient l'adresse IP de l'utilisateur qui tente de se connecter, cela sera important plus tard dans le rapport. endUserIp point de terminaison de l'API Le /auth répondra avec quelque chose comme ceci : HTTP/1.1 200 OK Content-Type: application/json { "orderRef":"131daac9-16c6-4618-beb0-365768f37288", "autoStartToken":"7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6", "qrStartToken":"67df3917-fa0d-44e5-b327-edcc928297f8", "qrStartSecret":"d28db9a7-4cde-429e-a983-359be676944c" } est un identifiant que le RP peut utiliser sur le point de terminaison pour vérifier l'état d'authentification et récupérer plus tard les informations utilisateur dont il a besoin auprès de cette personne. orderRef /collect est un jeton utilisé par le RP pour créer un qui, une fois cliqué, ouvrira l'application BankID et invitera l'utilisateur à s'authentifier ( ) autoStartToken lien profond ce sera très important et seront abordés ci-dessous mais ne sont pas strictement importants pour les recherches de sécurité effectuées. qrStartToken qrStartSecret En plus de l'adresse IP de l'utilisateur, un RP peut spécifier davantage de paramètres pour l'ordre d'authentification, notamment le texte à afficher sur l'application BankID et . les exigences d'authentification Parmi les exigences d'authentification, celles sur lesquelles cet article se concentrera sont appelées , celles-ci permettent au RP de communiquer à BankID lequel des deux flux a été choisi par l'utilisateur. politiques de certificat Authentification sur le même appareil Lorsqu'un utilisateur choisit de s'authentifier à l'aide de BankID sur le même appareil, le RP utilise l' pour créer un lien profond qui ressemble à : . Ce lien profond est ensuite récupéré par le système d'exploitation de l'utilisateur et transmis à l'application BankID. autoStartToken bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login Lors de l'enquête sur ce flux, une vulnérabilité a été trouvée car il n'y a pas de validation du paramètre du côté de BankID. J'expliquerai plus tard pourquoi ce bug supplémentaire rend l'attaque de piratage de session encore plus puissante. Open Redirect redirect Authentification sur un autre appareil Lorsqu'un utilisateur choisit de s'authentifier à l'aide de BankID sur un autre appareil, le RP utilise et pour générer un code QR dynamique (en récupérant les données de la trame suivante à partir du point de terminaison susmentionné) qui peut être scanné par l'utilisateur à l'aide de son Mobile BankID. application. qrStartToken qrStartSecret /collect Politiques de certificat Ceux-ci être spécifiés par le RP lors du lancement d'une commande d'authentification, ils permettent à BankID de rejeter une tentative d'authentification si le flux ne correspond pas afin d'atténuer le phishing. Par exemple, si l'utilisateur choisit « l'authentification sur le même appareil », le RP doit le communiquer à BankID afin que si l'authentification est tentée sur un Mobile BankID et/ou à l'aide du code QR, l'application puisse la rejeter. DEVRAIENT En plus de cela, une fois l'authentification terminée, le RP peut récupérer l' qui a été utilisée pour ouvrir l'application BankID à partir du point de terminaison de l'API . Cela ensuite être vérifié par rapport à l'adresse IP de l'utilisateur sur le RP au cas où il aurait choisi « l'authentification sur le même appareil ». ipAddress /collect DEVRAIT Les politiques de certificat, ainsi que l' être utilisées pour garantir que le flux d'authentification ne peut pas être falsifié. ipAddress DEVRAIENT Néanmoins, même si ces mesures de sécurité sont en place, BankID ne parvient pas à en souligner l'importance et ne les met pas en œuvre correctement, même dans l'exemple de mise en œuvre fourni ! https://github.com/BankID/SampleCode Le bug de correction de session Alors, que se passe-t-il lorsque ce protocole n’est pas mis en œuvre de manière sécurisée ? Lorsque j'ai vu pour la première fois le lien profond je parcourais mes formulaires de candidature universitaire, accessibles en me connectant avec BankID. Au début, je me suis dit : que se passe-t-il si j'envoie ce lien profond à quelqu'un ? Je l'ai donc envoyé à un ami qui a cliqué dessus, et à ma grande surprise après qu'il ait ouvert BankID, j'avais devant moi toutes ses candidatures universitaires ! bankid:/// C'est à ce moment-là que j'ai commencé à étudier l'API de BankID, à implémenter mon propre RP et à découvrir tout ce que je viens de décrire. Après quelques semaines de recherche, j'ai développé un script qui automatisait la capture du lien profond pendant plus de 30 RP, le script démarrait un serveur Web et créait un chemin pour chaque service, lorsqu'un utilisateur visitait le lien pour un service spécifique, le script récupérerait un nouveau lien et y redirigerait l'utilisateur. Cela amènerait l'appareil de l'utilisateur à ouvrir l'application BankID et, lors de l'authentification, je serais authentifié à sa place. bankid:/// J'ai pu le faire parce que : Les RP n'ont pas envoyé les politiques de certificat à BankID, ce qui m'a permis de récupérer un lien profond et de le relayer vers une application Mobile BankID. Les RP n'ont pas comparé l'adresse IP demandant le lien avec l'adresse IP qui avait effectué l'authentification. Les RP ont fourni le lien même lorsque l'option « s'authentifier sur un autre appareil » a été choisie Ce qui a conduit à la vulnérabilité Session Fixation. L'attaque Imaginons un service vulnérable appelé AmazingSevice AB, ils ont implémenté le flux BankID en suivant l'exemple de code fourni et hébergent une telle implémentation sur . https://amazingservice.se/login/bankid Un acteur malveillant s'intéresse aux données utilisateur stockées sur AmazingSevice AB et a sa victime en vue. Il lui suffirait d'automatiser la capture du lien , de l'héberger sur son serveur, puis d'envoyer le lien vers son serveur malveillant à ses victimes. Après avoir choisi son mode de phishing préféré (SMS, email, etc.), il intégrera le lien dans le message se faisant passer pour AmazingSevice AB et demandant à la victime de se connecter. bankid:/// Un tel piratage de compte implique très peu d'ingénierie sociale car une fois que la victime clique sur le lien, elle est immédiatement invitée à ouvrir BankID, quittant le « territoire inconnu » du site de l'attaquant pour une interface beaucoup plus familière, BankID. De plus, la demande d'authentification que la victime verrait dans l'application BankID est demandée par AmazingSevice AB, ce qui rend impossible la détection d'un comportement frauduleux. Une fois la victime authentifiée, la session de l'attaquant est authentifiée sur le compte de la victime, la victime peut encore être trompée en exploitant la vulnérabilité présente dans BankID, permettant à l'attaquant de spécifier le paramètre comme . Cela conduirait la victime à être redirigée vers le site Web du service légitime, lui laissant simplement penser que l'authentification n'a pas réussi. Open Redirect redirect https://amazingservice.se/login/bankid Démo . Voici une petite démo vidéo qui montre l'attaque en action Je n'ai pas pu utiliser l'une des sociétés auprès desquelles je faisais rapport, pour des raisons évidentes, donc la démo montre à la place que le service de démonstration de BankID est vulnérable à cela ! Dans le coin droit se trouve la vue de la victime recevant le lien, ici simulée en visitant le site Web de l'attaquant. Une fois que la victime visite le lien, le serveur de l'attaquant ouvre le navigateur sans tête et extrait le lien qui est ensuite relayé sur le téléphone de la victime. Dans l'application BankID, vous pouvez voir « Test av BankID » qui est l'origine légitime du site de démonstration de BankID. De plus, au début de la vidéo, un VPN est activé pour constater qu'aucune vérification d'adresse IP n'est effectuée lors de l'authentification. Au final, il est possible de constater que sur l'ordinateur portable de l'attaquant, celui-ci est connecté en tant que victime (Johan Johansson). bankid:/// L'impact Le bug de correction de session entraîne une sur toute application qui utilise Swedish BankID comme fournisseur d'authentification et qui a mal (ou pas du tout) implémenté les politiques de certificat et les vérifications . C'est assez grave car les services qui utilisent BankID pour authentifier leurs utilisateurs ont souvent accès à des données et à des actions assez sensibles. applications ont été jugées vulnérables à cette attaque, le plus grand nombre possible ont été contactées, ce qui a donné lieu à 11 rapports de bug bounty acceptés sur les principales plates-formes. prise de contrôle de compte en 1 clic ipAddress Plus de 30 L'un des services à qui j'ai signalé cette vulnérabilité a pu me mettre en contact avec le CSIRT national suédois, en raison de l'ampleur et de la gravité du problème. Les discussions viennent de commencer, donc si vous voulez être informé, suivez-moi sur Twitter (X) @m4st3rspl1nt3r Assainissement Si vous recherchez un exemple de ce à quoi ressemble une implémentation sécurisée de l'API BankID RP, j'en ai créé une que vous pouvez utiliser soit comme bibliothèque Golang, soit personnaliser et déployer en tant que microservice. Vous pouvez le trouver . ici Réponse de BankID La plupart des services concernés, en particulier ceux dotés de BBP et de VDP, ont été assez réceptifs et ont répondu rapidement à mon rapport. Cependant, la réponse de BankID a été un peu différente. Dans le seul e-mail que j'ai reçu après les avoir contactés à plusieurs reprises via différents canaux, ils ont expliqué qu'ils étaient conscients du problème mais qu'ils estimaient qu'il n'y avait pas grand-chose à faire pour conserver une « facilité d'intégration » pour les RP. L'atténuation prévue, qui nécessite malheureusement encore des modifications du côté des RP, m'a été communiquée (mais pour une raison quelconque, elle ne se trouve nulle part dans leur documentation) comme suit : Une exigence supplémentaire que le RP pourra définir est le risque. Cela définira le niveau de risque acceptable pour la transaction. Si le risque de la transaction est supérieur à la limite requise, la transaction sera bloquée. « FAIBLE » - n'acceptez que les ordres à faible risque « MODÉRÉ » - acceptez les ordres à risque faible et modéré Si cette option est définie. Nous effectuerons entre autres la vérification IP de notre côté si elle est fournie par RP. Les autres paramètres de risque qui feront l'objet d'une surveillance des risques s'ils sont fournis sont ReferingDomain, UserAgent et DeviceIdentifier. De plus, un plan visant à corriger la vulnérabilité Open Redirect est également en place. Mon à ce sujet est que si vous développez et exploitez un fournisseur d'authentification aussi critique et hautement adopté, qui est souvent utilisé pour protéger les informations très sensibles des utilisateurs, vous devez correctement documenter vos mécanismes de sécurité afin que les RP puissent l'intégrer en toute sécurité. Les fonctionnalités de sécurité facultatives sont complètement inutiles, si un développeur peut gagner du temps en n'implémentant pas certaines fonctionnalités/paramètres, c'est ce qui se passera et nous ne pouvons pas blâmer le côté RP. BankID doit faire de son mieux pour déplacer autant de fonctionnalités anti-fraude et de sécurité de son côté afin de conserver une « facilité d'intégration », mais également s'assurer de documenter correctement toutes les fonctionnalités de sécurité supplémentaires que le RP est tenu de mettre en œuvre ; remarque sur et non facultatif. opinion personnelle ce qui est obligatoire Entreprise privée en danger public Cette partie du blog n'est que mon opinion. Pour moi, cette vulnérabilité est un exemple qui montre les dangers qu’il y a à laisser une entreprise privée contrôler totalement un système essentiel pour la population d’un pays. La raison pour laquelle je pense que c'est plus grave qu'une simple vulnérabilité chez un éditeur de logiciels est que BankID est quelque chose qui est utilisé par plus de de résidents suédois, il est utilisé pour se connecter à votre banque, votre assureur, votre fournisseur d'électricité et d'autres plateformes sensibles qui avoir des conséquences concrètes. 8,5 millions Si quelqu'un découvre un compte TakeOver sur Facebook, vous risquez de perdre des photos. Si quelqu'un trouve une vulnérabilité chez le fournisseur d'eID de votre pays (souvent privé), les répercussions sur la vie de quelqu'un peuvent être inimaginables. De plus en plus de pays européens adoptent l'eID, et l'UE prévoit de déployer sa propre eID dans les années à venir (vous pouvez en savoir plus à ce sujet ). ici J’espère que les régulateurs feront pression pour que les fournisseurs d’eID soient entièrement développés et contrôlés par des institutions publiques, éventuellement avec l’exigence que ces systèmes soient open source et régulièrement audités pour détecter les failles de sécurité. Comment pouvons-nous accepter en toute sécurité des logiciels aussi critiques dans notre société s’ils sont développés par une entreprise privée ? De plus amples recherches Bien que le sujet principal de cet article de blog soit l'attaque de fixation de session sur BankID, j'ai découvert que de nombreux autres fournisseurs d'authentification/identification ont tous été conçus avec le même défaut. Une nouvelle classe de vulnérabilité peut être trouvée chez les fournisseurs qui nécessitent l'utilisation d'un autre appareil (souvent un téléphone mobile) pour terminer le flux d'authentification. La recherche est en cours et j'espère bientôt publier davantage de mes découvertes ainsi qu'un sur lequel j'ai travaillé et qui peut être utilisé pour automatiser et exploiter ces vulnérabilités. Restez à l'écoute pour mon prochain sujet outil Correction de session dès la conception - Cauchemars d'authentification multi-appareils En attendant, piratez la planète !
