Cette semaine, nous avons une vulnérabilité dans l’application mobile BrewDog exposant les PII des utilisateurs grâce aux jetons au porteur codés en dur, Cisco a annoncé l’arrivée de leur APIClarity à la KubeCon 2021, F5 a publié un rapport sur les attaques d’API dans Open Banking, et enfin , il existe un méga-guide sur les bonnes pratiques de sécurité des API.
Vulnérabilité : jeton de support d’API codé en dur dans l’application mobile Brewdog
La grande nouvelle de cette semaine est la vulnérabilité de l’application mobile BrewDog révélée par Pen Test Partners. Cette vulnérabilité a potentiellement exposé les données personnelles de plus de 200 000 actionnaires d’Equity for Punks au cours des 18 derniers mois. Il est actuellement difficile de savoir si la vulnérabilité a été exploitée, mais son impact potentiel n’est certainement pas négligeable.
Les chercheurs ont découvert que les développeurs de l’application mobile avaient des jetons de support d’API codés en dur dans le code source de l’application. Cela signifiait que tout utilisateur de l’application pouvait récupérer des informations pour des utilisateurs arbitraires simplement en devinant leurs identifiants d’utilisateur. Pire encore, ces informations comprenaient clairement des informations personnellement identifiables (PII) selon les définitions du RGPD.
Lorsque l’utilisateur interagit avec l’application mobile, chaque appel que l’application effectue pour consommer l’API sous-jacente inclut un jeton de support dans le cadre du processus d’authentification. En règle générale, ces jetons doivent être des jetons de session de courte durée et uniques à chaque utilisateur de l’application. Les jetons sont généralement obtenus via un protocole d’authentification – généralement OAuth2 – après une authentification réussie. Cela fait d’un jeton au porteur un actif sensible car il représente l’identité déléguée de l’utilisateur. En tant que tel, il doit être sauvegardé dans l’application et supprimé à la fin d’une session. Certainement, ces jetons au porteur devraient plus jamais être stockés dans le code source de l’application, même s’ils étaient cryptés.
Remarquablement, c’est exactement ce que les chercheurs ont découvert lors de la rétro-ingénierie de l’application BrewDog, avec des preuves évidentes de trois jetons au porteur codés en dur :
De plus, en manipulant l’ID utilisateur dans les appels API, il était possible de récupérer des informations sur d’autres utilisateurs, y compris leurs informations personnelles telles que le nom, l’adresse e-mail, la date de naissance, les adresses et les numéros de téléphone. Il y avait aussi un ‘Identifiant de remise au bar’ qui est utilisé pour créer des codes QR pour des réductions sur les bières ! Bien que les ID utilisateur ne soient pas séquentiels, il serait assez facile pour un attaquant de forcer et de télécharger tous les détails pour tous les utilisateurs. Bières gratuites, tout le monde!
La réponse de BrewDog a été quelque peu inadéquate : ils ont d’abord cherché à éviter le problème, puis ont supprimé quelque peu maladroitement l’API vulnérable, ce qui a rendu l’application quelque peu dysfonctionnelle. Il a fallu plusieurs tentatives avant que le problème ne soit correctement résolu, les notes de version indiquant légèrement ironiquement « rien de trop excitant ».
Les enseignements à tirer ici sont nombreux et importants, à savoir :
- L’authentification est un processus complexe semé d’embûches potentielles. Il est conseillé aux développeurs d’applications d’utiliser un cadre robuste et éprouvé dans l’industrie, tel que OAuth2, plutôt qu’une méthode terriblement inadéquate, comme le codage en dur des informations d’identification.
- Une recherche de machine rudimentaire (comme utiliser
grep) peut identifier les informations d’identification du porteur codées en dur dans la base de code et s’assurer qu’elles sont éliminées avant qu’elles ne soient validées dans un référentiel de code. Le fait qu’ils aient été présents dans ce cas aussi longtemps qu’ils l’ont fait suggère que les développeurs d’applications en étaient conscients et se sont appuyés sur des vœux pieux qu’ils n’ont jamais été découverts. Les attaquants sont un groupe très intelligent. - La possibilité d’énumérer les ID utilisateur suggère que l’API BrewDog était vulnérable à API1:2019 – Autorisation au niveau de l’objet cassée, bien que cela ait pu être simplement le résultat d’une authentification cassée en premier lieu.
- Les organisations avisées devraient avoir un processus établi pour la gestion des violations et la divulgation des vulnérabilités, ce qui faisait clairement défaut dans ce cas.
Bravo au chercheur Alan Monie sur cette découverte et cet article — buvez une bière avec nous !
Événement : annonce APIClarity à la KubeCon 2021
Cette semaine, les conférences KubeCon et CloudNativeCon 2021 se déroulent virtuellement, ainsi qu’en personne. D’intérêt pour l’API, les praticiens de la sécurité sont Vijoy Pandey de Cisco (VP de la plate-forme cloud et du groupe Solutions de Cisco) qui annonce un nouveau programme open source appelé APIClarity. Le projet vise à résoudre les problèmes liés à la sécurité et à l’observabilité des API, à savoir les dérives de configuration, les API zombies (obsolètes) et shadow (non documentées), pour n’en citer que quelques-unes.
APIClarity — disponible sur GitHub — est décrit comme « Wireshark for APIs » et est maintenu par Cisco, 42Crunch (en savoir plus ici) et APIMetrics. Un aperçu rapide de la solution est disponible dans cette vidéo :
Rapport : Rapport F5 sur les cyberattaques contre les banques et les services financiers
Ensuite, nous examinons les attaques d’API et Open Banking dans la deuxième partie d’un rapport complet de F5 sur les incidents de sécurité signalés dans les organisations financières.
La statistique la plus révélatrice ici est l’augmentation du nombre d’incidents liés aux API. De 2018 à 2020, seulement 6 % environ des incidents étaient liés aux API, alors qu’en 2020, les API représentaient 55 % des incidents !
Une statistique tout aussi révélatrice est le fait que le secteur financier est beaucoup plus susceptible de subir un incident lié aux API (un total de 50 %) par rapport à la moyenne de 4 % dans toutes les industries.
Les principaux points à retenir du rapport sont les suivants :
- L’Open Banking est susceptible de devenir de plus en plus dépendant des API et de moins en moins dépendant de l’Open Financial Exchange (OFX).
- Les deux tiers des incidents d’API en 2020 ont été causés par des combinaisons d’absence d’authentification, d’autorisation ou d’échecs dans l’un ou l’autre.
- La combinaison des deux points ci-dessus suggère une surface d’attaque croissante pour les attaquants afin d’exploiter les implémentations d’Open Banking.
Guide : Méga-guide sur la sécurité des API
Enfin, Expedited Security a publié un méga guide extrêmement complet et facilement consommable sur les meilleures pratiques de sécurité des API.
Ce guide devrait s’avérer inestimable pour les novices comme pour les experts et couvre plusieurs sujets clés, tels que :
- Attaques par déni de service distribué (DDoS)
- Attaques de violation de données
- Top 10 des vulnérabilités OWASP
- Contrôles de sécurité des API
- Authentification et autorisation API
- Directives de conception d’API sécurisées
- Procédures de sécurité
Vous pouvez vous inscrire à cette newsletter sur APIsecurity.io.