Synopsis de l’incident

L’équipe de Salt Labs applique ses talents de recherche approfondie en sécurité pour aider les clients et les prospects à découvrir les vulnérabilités de leurs API.

Les secteurs d’activité modernes à croissance rapide sont souvent un terrain très fertile pour trouver des problèmes de sécurité. Les entreprises qui se développent très rapidement publient souvent des logiciels rapidement et donnent parfois la priorité aux fonctionnalités commerciales plutôt qu’à la sécurité. Plus une entreprise se développe rapidement, plus elle a de chances de trouver des problèmes de sécurité dans son environnement. Étant donné que les API sont au cœur de la plupart des services modernes, elles sont soumises aux mêmes défis.

Le domaine que nous avons choisi d’examiner cette fois-ci passe avec brio la définition du « mouvement rapide » – le marché des crypto-monnaies. Passant d’un marché de 21 millions de dollars au début de 2017 à près de 1 milliard de dollars aujourd’hui, et incluant de nouveaux services tels que les échanges cryptographiques et les coffres-forts de portefeuilles cryptographiques en ligne, l’écosystème de crypto-monnaie présente des chances importantes de trouver des problèmes de sécurité API. En outre, l’impact de telles failles de sécurité pourrait être très important.

Dans ce cas, nous avons enquêté sur la plate-forme d’un grand service de portefeuille cryptographique en ligne, desservant environ 2 millions d’utilisateurs dans le monde et gérant plus de 150 000 Bitcoins (évalués à plus de 3 milliards de dollars selon le prix actuel du commerce BTC). Le service se voit confier les portefeuilles cryptographiques de ses clients et leur permet d’acheter, d’échanger, d’emprunter et même de gagner des crypto-monnaies supplémentaires.

Suite aux vulnérabilités de l’API identifiées par nos chercheurs, ils ont pu lancer des attaques où :

• Un attaquant pourrait complètement prendre en charge une grande partie du compte de l’utilisateur dans le système.
• Un attaquant a obtenu un accès complet au compte d’un utilisateur et aurait pu transférer des fonds vers n’importe quel endroit de son choix, ainsi qu’effectuer toute autre action financière au nom de cet utilisateur.
• Le service en ligne était sensible à deux problèmes d’API courants :

Mauvaise configuration de sécurité (API-7) et

Manque de ressources et limitation du débit (API-4).

• Chaque problème de sécurité à lui seul fournissait des capacités limitées à l’attaquant. Cependant, un attaquant pourrait enchaîner ces problèmes pour propager une attaque très percutante, comme le transfert de l’intégralité du solde du compte vers son portefeuille ou son compte bancaire privé.

Comme toujours, nous avons suivi notre processus de divulgation coordonné et informé le service de ces problèmes. Nous avons également aidé à trouver une solution technique appropriée, et tous les problèmes ont été résolus au moment de la rédaction de cet article.

Notre approche de recherche

Lorsqu’il s’agit d’environnements de grande taille, il est très facile de se perdre dans le bois des appels d’API et d’autres fonctionnalités de service. Pour créer une approche systématique, nous cartographions les domaines possibles pour trouver des vulnérabilités et des expositions et nous nous concentrons sur eux jusqu’à ce que quelque chose attire notre attention.

L’un des premiers domaines d’intérêt dans les systèmes complexes est la fonctionnalité « Connexion de l’utilisateur ». Bien que cela puisse sembler simple au premier abord, l’authentification dans de tels systèmes est souvent complexe, avec de nombreuses pièces mobiles et de nombreux autres endroits où les choses peuvent terriblement mal tourner.

En naviguant sur la page de connexion de ce système de cryptowallet, nous voyons un écran de connexion d’apparence familière. Cet écran de connexion offre aux utilisateurs plusieurs options pour se connecter à la plateforme.

En option, un utilisateur peut s’inscrire au système, choisir un nouveau nom d’utilisateur et un nouveau mot de passe et remplir tous les autres détails nécessaires. Pour offrir une expérience plus conviviale, le site permet également aux utilisateurs de se connecter au système en utilisant l’un d’une liste commune de fournisseurs d’authentification externes, notamment Google, Twitter, AppleID ou Facebook.

Ces options sont toutes valables, bien sûr, et leur simple existence sur ce site ne suggère rien. La sécurité de ces fonctionnalités de connexion est cependant très fortement liée à la manière dont elles ont été mises en œuvre. Alors, allons-y pour examiner plus en détail les détails de la mise en œuvre…

Nous commençons par la fonctionnalité d’authentification de Google, car nous pensons qu’il s’agit de l’option la plus couramment utilisée (nous nous trompons peut-être, mais nous devons commencer quelque part). Google, comme de nombreuses méthodes d’authentification externes, utilise une norme appelée OpenID Connect (OIDC), qui est une extension d’une autre norme d’autorisation commune nommée OAuth 2.0. Le schéma suivant montre un processus d’authentification simplifié commun utilisant ces normes.

Si vous vous sentez un peu confus par ce diagramme, ce n’est pas grave – comme vous le verrez dans ce que nous détaillons ici, vous n’êtes pas le seul. La norme OIDC définit un processus d’autorisation/authentification très sécurisé, qui peut être utilisé rapidement par n’importe quel utilisateur, mais il faut bien comprendre son fonctionnement interne pour le mettre en œuvre correctement. Les erreurs ici peuvent s’avérer très chères.

En regardant la requête envoyée par le client à notre serveur, nous remarquons quelque chose de louche :

Le schéma précédent des flux de requêtes et de réponses montre que dans aucun flux l’utilisateur n’envoie jamais son ID au serveur d’application. Le seul endroit où il est jamais envoyé est au service OIDC. Pour une raison quelconque, cependant, comme on peut le voir dans la requête ci-dessus, notre client envoie le « google_id » de l’utilisateur en tant que paramètre avec le reste du jeton d’accès. Nous trouvons cette action très étrange, car elle n’est pas du tout requise selon les normes OIDC, et le mappage des utilisateurs à leurs jetons d’accès doit être effectué de manière transparente par le serveur. Alors pourquoi le « google_id » est-il envoyé par le client ?

Bien que nous n’ayons aucun moyen de voir le code du serveur ou de répondre directement à cette question, nous pouvons essayer de répondre à une question à peu près équivalente : « Que se passe-t-il si le mauvais google_id est envoyé ? » ? Ou mieux, que se passe-t-il si nous décidons d’envoyer le google_id de quelqu’un d’autre à la place ?

Nous enregistrons donc un nouvel utilisateur à l’aide de l’option d’authentification Google, et nous utilisons cette nouvelle valeur google_id dans la requête adressée au serveur par l’utilisateur d’origine, et… cela a fonctionné ! Nous avons réussi à nous connecter au système au nom du nouvel utilisateur (l’utilisateur qui détient le nouveau google_id), alors que nous n’aurions jamais dû avoir la permission de le faire.

Nous avons propagé une attaque de prise de contrôle de compte très efficace. Tout ce dont nous avons besoin pour prendre en charge les comptes d’utilisateurs est de connaître le google_id valide pour les utilisateurs qui s’authentifient à l’aide des services Google OIDC.

Mais comment pouvons-nous obtenir ce google_id ?

Apparemment, google_id n’est pas défini comme un secret par Google. Si vous connaissez l’adresse e-mail Google d’un utilisateur, l’extraction de son google_id valide est un processus caché mais relativement simple. L’un des moyens les plus courants consiste à utiliser la fonctionnalité « Mot de passe oublié » de Google. En saisissant simplement l’adresse e-mail d’un utilisateur, en cliquant sur « Mot de passe oublié » et en inspectant la source de la page renvoyée, la valeur google_id peut être trouvée en tant que membre de la variable JavaScript globale nommée « window.WIZ_global_data ».

Mais ce n’est toujours pas la fin.

Une fois que nous nous sommes authentifiés avec succès en tant qu’utilisateur différent dans le système, un autre défi apparaît. Cette fois, c’est sous la forme d’une authentification à deux facteurs (2FA). Pour terminer le processus de connexion et avoir un accès effectif au compte, nous devons remplir un code PIN à 6 chiffres qui est envoyé à l’appareil mobile, à l’e-mail ou à tout autre endroit de l’utilisateur.

L’authentification à deux facteurs est un moyen très efficace d’atténuer les attaques comme la nôtre. Cependant, encore une fois, le diable se cache dans les détails – et une mauvaise mise en œuvre peut rendre inutiles même de grandes solutions.

Nous pourrions toujours essayer de deviner le bon code PIN. L’utilisation de codes PIN à 6 chiffres signifie que nous devrons essayer au maximum 999 999 options jusqu’à ce que nous atteignions le code PIN correct. Très certainement, le point de terminaison de l’API pour la validation du code PIN a appliqué une limitation de débit et nous empêchera d’essayer plus d’une poignée d’options. Cependant, la plate-forme de chiffrement utilise-t-elle d’autres points de terminaison d’API liés au code PIN qui pourraient nous fournir des fonctionnalités similaires ?

En parcourant les options des points de terminaison d’API liés au code PIN, nous trouvons rapidement un point de terminaison qui semble répondre à cet objectif.

Le point de terminaison API /api/v3/me/pin/set est à l’origine destiné à permettre à un utilisateur de changer son code PIN. Lorsque nous essayons de lui fournir un code PIN erroné, il répondra par une erreur et ne renverra le succès que lorsque le code PIN est correct.

Plus important encore, ce point de terminaison ne contient aucune sorte de limitation de débit, de blocage d’utilisateurs ou de fonctionnalité de désactivation temporaire de compte. Fondamentalement, nous pouvons maintenant exécuter l’ensemble des 999 999 options de code PIN et obtenir le code PIN correct en moins d’une minute.

Mettre tous ensemble

En reliant ces séries d’attaques, nous pourrions prendre le contrôle de n’importe quel compte du système qui utilise l’authentification Google comme type de connexion, ce qui s’applique à un très grand nombre d’utilisateurs du système.

Une fois que nous nous sommes connectés avec succès aux comptes d’un utilisateur, nous pouvons potentiellement utiliser toutes les fonctionnalités disponibles pour l’utilisateur, y compris le transfert de fonds, l’affichage de l’historique des transactions, la consultation des données personnelles de l’utilisateur, qui peuvent inclure le nom, l’adresse, le numéro de compte bancaire et d’autres données précieuses. .

Nos recherches sur cette plate-forme cryptographique montrent une fois de plus que la sécurité des API est un élément crucial de tout service moderne, un élément qui doit être soigneusement pris en compte et traité dans le cadre de la conception du service. Une mise en œuvre incorrecte et une mauvaise configuration des fonctionnalités liées à l’API peuvent avoir de graves conséquences et peuvent même parfois casser complètement les solutions de sécurité considérées comme les normes de l’industrie ou « à l’épreuve des balles ».

Nous apprenons une fois de plus qu’avant d’intégrer une fonctionnalité tierce – qu’il s’agisse d’un service externe, d’une bibliothèque de codes ou de toute autre chose – les équipes doivent comprendre son architecture et ses pièges. Sans cette compréhension approfondie, la marge d’erreur pourrait être grande et le coût des erreurs cher.

Un autre point à retenir est de s’assurer que les mesures de sécurité sont bien conçues et appliquées de la même manière sur l’ensemble des fonctionnalités exposées. Le fait qu’un point de terminaison d’API n’est pas « censé » offrir un service spécifié ne signifie pas nécessairement qu’il ne le peut pas, et les attaquants essaient souvent de profiter de ce fait pour pouvoir contourner les mesures de protection existantes.

Les erreurs d’authentification ne sont pas rares dans les déploiements d’API. Comme mentionné précédemment, cette société de cryptographie a immédiatement corrigé l’ensemble complet des vulnérabilités de l’API que notre équipe Salt Labs a partagée avec elles. Chaque fois que votre équipe utilise des normes d’authentification tierces, assurez-vous qu’elle a reçu la formation appropriée pour les mettre en œuvre en toute sécurité.

indéfini

*** Ceci est un blog syndiqué du Security Bloggers Network du blog Salt Security rédigé par Salt Labs. Lisez le message d’origine sur : https://salt.security/blog/api-vulnerability-on-cryptocurrency-platform-could-have-allowed-large-scale-account-takeover