Bricklink, le « Boncoin » du Lego, s’est vu informé récemment de la présence d’une faille critique dans son code causée par une absence de sécurisation de certains champs de saisie dans une API.
C’est dans le laboratoire de Salt Security, spécialisé dans la sécurité des API, que le chercheur Shiran Yodev découvre la vulnérabilité. “Ma première approche a été d’enquêter sur le domaine principal de lego.com, raconte-t-il sur le blog de Salt. J’ai examiné le site Web du point de vue de l’utilisateur et j’y ai observé peu de fonctionnalités et une surface d’attaque assez réduite. En tant que fan de Lego, j’ai utilisé bricklink.com à plusieurs reprises, et je savais que le service fourni est assez complexe par rapport au site principal de LEGO. En général, une telle logique est synonyme d’une grande surface d’attaque potentielle, alors pourquoi ne pas tester la solidité de ces briques ? »
BrickLink est un site d’achat et de vente de produits du groupe Lego (pièces, minifigurines, sets, catalogues, notices, autocollants, etc.) neufs et d’occasion par des particuliers et des sociétés situés dans le monde entier. Ce “Boncoin” du Lego a été lancé par Daniel Jezek en 2000 et racheté par le groupe suédois en 2020 et offre depuis une plateforme de studio pour les concepteurs afin de concevoir leurs créations Lego, et plus encore.
Connecter deux briques pour une prise de contrôle de compte
Shiran a donc commencé par rechercher les différents endroits où Bricklinks reçoit des données de l’utilisateur et a vérifié comment elles étaient traitées et ce qui pouvait en être fait. “Ma première découverte a été la fonctionnalité de recherche de bons de réduction », raconte-t-il. Comme on peut le voir dans la capture d’écran ci-dessous (Capture 1), Shira a rentré “XSS” dans le champ nom d’utilisateur et a vérifié ensuite dans le code source (affichée par la fonction inspection du code html du navigateur) la valeur qui était renvoyée au serveur.
A ce moment-là, le chercheur constate que la saisie utilisateur n’est pas “nettoyée” mais renvoyée telle quelle (Capture 2). Une porte vient donc de s’ouvrir. La suite est à lire en intégralité sur le blog du chercheur.
Ce type d’erreur est fréquent. Nicolas Jeanselme, ingénieur sécurité API chez Salt, raconte à Solutions Numériques que dernièrement il a pu prouver à un client encore sceptique sa capacité à exfiltrer des données personnelles ou à réaliser une escalade de privilèges, tout cela depuis un compte client et vers un statut administrateur. “J’ai également rencontré de nombreux cas de réutilisation d’informations de cartes bancaires », explique-t-il. Pour lui, la sécurisation des API tarde à faire sa place dans la juridiction des RSSI et reste encore trop confiné au DevSecOps, lorsqu’il y en a…
Comment éviter une vulnérabilité similaire dans vos systèmes
Dans le cas des vulnérabilités liées aux API, les dommages sont causés par des attaques combinées ou en cascade. Shiran Yodev conclut donc son billet en partageant trois grandes recommandations.
Tout d’abord, le Cross Site Scripting (XSS) est parfois injustement sous-estimé, car il ne constitue pas une menace directe sur le serveur. Cependant, lorsque les utilisateurs sont compromis, l’effet et les dommages peuvent s’intensifier rapidement. La règle de base la plus importante en matière de XSS est de ne jamais faire confiance à la saisie de l’utilisateur. Les données doivent être correctement nettoyées et échappées. Pour plus d’informations et pour connaître les moyens spécifiques de prévenir les vulnérabilités XSS, la fiche de prévention XSS de l’OWASP délivre un grand nombre d’informations. Ensuite, l’identifiant de session est une cible courante pour les attaquants car il peut souvent être utilisé pour le détournement de session et la prise de contrôle de compte. Il est important d’être très prudent lors de sa manipulation et de ne pas l’exposer ou l’utiliser à d’autres fins.
Enfin, le moyen le plus simple et le plus efficace de stopper les attaques par injection XXE est de désactiver complètement les entités externes dans la configuration de votre analyseur XML. Pour plus de détails sur la prévention de ces expositions, consultez la fiche de prévention XXE de l’OWASP.
