Ce n'est pas toujours logique
Encore une violation d'API dans l'actualité. La dernière en date a touché la plateforme Life360, où un attaquant a pu collecter 400 000 numéros de téléphone d'utilisateurs, selon un article publié sur Bleepingcomputer.com.
Connu uniquement sous le pseudonyme « emo », l'attaquant a expliqué que le point d'accès API non sécurisé utilisé pour dérober ces données offrait un moyen simple de vérifier l'adresse e-mail, le nom et le numéro de téléphone de chaque utilisateur concerné.
« Lors d'une tentative de connexion à un compte Life360 sur Android, le point d'accès de connexion renvoyait le prénom et le numéro de téléphone de l'utilisateur ; ces informations n'apparaissaient que dans la réponse de l'API et n'étaient pas visibles pour l'utilisateur », a déclaré emo.
« Si un utilisateur avait vérifié son numéro de téléphone, celui-ci était renvoyé sous une forme partielle, telle que +1******4830. »
En d'autres termes, l'attaquant a su tirer parti du fait que l'API fournissait trop d'informations. Je suis certain que l'équipe de développement Android n'a jamais imaginé que quelqu'un utiliserait un émulateur ou un proxy pour examiner le trafic réel renvoyé par l'API. Ils ont plutôt pensé qu'en ne les affichant pas dans l'application, ces informations seraient protégées, même si elles étaient présentes dans l'API. La sécurité par l'obscurcissement n'est pas une stratégie viable. Cela correspond à la catégorie n°3 de l'OWASP API Top 10 : « Exposition excessive de données ».
Des violations de ce type surviennent plus souvent que nous ne voulons l'admettre. Bien souvent, les applications mobiles exploitent les limites de leur environnement pour masquer des données au lieu d'empêcher leur divulgation dès la source. Dans un cas très similaire, une application nommée 3Fun (en savoir plus sur 3Fun) a exposé la localisation et les photos privées de ses utilisateurs via son API, alors même que l'application mobile n'affichait pas ces informations.
Détection Salt
Dans cette situation précise, j'ai demandé à notre vice-président de la recherche en sécurité, Yaniv Balmas, ce que Salt aurait pu détecter.
Yaniv a expliqué que Salt aurait pu identifier plusieurs types d'opportunités, mais que les plus pertinentes auraient probablement été l'énumération de paramètres (spécifiquement celle renvoyant des données sensibles). Il a ajouté que, puisque Salt aurait considéré cette activité comme unique pour cet attaquant, s'écartant du comportement normal des utilisateurs, cela aurait déclenché une alerte BOLA à identifiant unique.
La capacité de Salt à détecter et corréler ce type d'activité est une prouesse technique. C'est comme chercher une aiguille dans une pile d'aiguilles, elle-même perdue dans une meule de foin au milieu d'une grange. Notre architecture unique et nos modules de détection brevetés sont la raison pour laquelle nous aidons certaines des plus grandes entreprises à protéger leurs API.
Si vous souhaitez en savoir plus sur Salt et découvrir comment nous pouvons vous accompagner dans la découverte, la gouvernance et la protection de vos API, veuillez nous contacter, planifier une démo, ou consulter notre site web.