Une vulnérabilité critique dans Swedish BankID expose les données des utilisateurs

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 numéro personnel 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.

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 endUserIp , qui contient l'adresse IP de l'utilisateur qui tente de se connecter, cela sera important plus tard dans le rapport.

Le point de terminaison de l'API /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" }

• orderRef est un identifiant que le RP peut utiliser sur le point de terminaison /collect 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.
• autoStartToken est un jeton utilisé par le RP pour créer un lien profond qui, une fois cliqué, ouvrira l'application BankID et invitera l'utilisateur à s'authentifier ( ce sera très important )

qrStartToken et qrStartSecret seront abordés ci-dessous mais ne sont pas strictement importants pour les recherches de sécurité effectuées.

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 politiques de certificat , celles-ci permettent au RP de communiquer à BankID lequel des deux flux a été choisi par l'utilisateur.

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' autoStartToken pour créer un lien profond qui ressemble à : bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login . Ce lien profond est ensuite récupéré par le système d'exploitation de l'utilisateur et transmis à l'application BankID.

Lors de l'enquête sur ce flux, une vulnérabilité Open Redirect a été trouvée car il n'y a pas de validation du paramètre redirect du côté de BankID. J'expliquerai plus tard pourquoi ce bug supplémentaire rend l'attaque de piratage de session encore plus puissante.

Authentification sur un autre appareil

Lorsqu'un utilisateur choisit de s'authentifier à l'aide de BankID sur un autre appareil, le RP utilise qrStartToken et qrStartSecret pour générer un code QR dynamique (en récupérant les données de la trame suivante à partir du point de terminaison /collect susmentionné) qui peut être scanné par l'utilisateur à l'aide de son Mobile BankID. application.

Politiques de certificat

Ceux-ci DEVRAIENT ê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.

En plus de cela, une fois l'authentification terminée, le RP peut récupérer l' ipAddress qui a été utilisée pour ouvrir l'application BankID à partir du point de terminaison de l'API /collect . Cela DEVRAIT 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 ».

Les politiques de certificat, ainsi que l' ipAddress DEVRAIENT être utilisées pour garantir que le flux d'authentification ne peut pas être falsifié.

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 bankid:/// 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 !

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 bankid:/// 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.

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 bankid:/// , 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.

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é Open Redirect présente dans BankID, permettant à l'attaquant de spécifier le paramètre redirect comme https://amazingservice.se/login/bankid . 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.

Démo

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 bankid:/// 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).

L'impact

Le bug de correction de session entraîne une prise de contrôle de compte en 1 clic 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 ipAddress . 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. Plus de 30 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.

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 opinion personnelle à 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 ce qui est obligatoire et non facultatif.

Entreprise privée en danger public

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 8,5 millions 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.

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 outil 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 Correction de session dès la conception - Cauchemars d'authentification multi-appareils

En attendant, piratez la planète !