Ô clés API ! Clés API ! pourquoi êtes-vous toujours source de fuites ?

Yes, we just realized that wherefore means why, not where. Don’t judge. :)

La fuite de données liée à la clé API rabbit r1 est la dernière en date d'une série de brèches qui montrent que la sécurité des API n'en est qu'à ses balbutiements. C'est aussi l'une des nouvelles formes de vol d'identifiants et de piratage de comptes. Utilisée lors d'une attaque, une clé API permet d’accéder à toutes sortes de données qui sont facilement consommées en grandes quantités. Ce type d'attaque a un fort impact sur la sécurité.

Qu’est-ce que le rabbit r1 ?

Le boîtier rabbit r1, également appelé « r1 », joue le rôle d'un assistant virtuel requérant un nombre très limité d'entrées pour obtenir le résultat souhaité. Ce gadget alimenté par l'intelligence artificielle (IA) ressemble à un smartphone, mais ne comporte aucune application que l'utilisateur puisse ouvrir et parcourir.  Si vous souhaitez commander une course Uber ou écouter de la musique, il suffit de le dire au r1. Le r1 interagit avec vos comptes et services en arrière-plan, mais aucune de ces actions n'apparaîtra sur votre appareil. Une fois que vous avez configuré le backend du rabbit r1 de manière à ce que celui-ci puisse accéder à vos comptes, il suffit de parler au r1 pour accéder aux services concernés.

Côté performances, les avis sont mitigés, mais le PDG de rabbit, Jesse Lyu, déclare en avoir déjà vendu 130 000 à la date de juin 2024. Si chaque appareil est configuré pour accéder à Uber, à Spotify, à DoorDash et à d'autres services pris en charge, il a également accès à plusieurs comptes utilisateur.

Alors, que s'est-il passé ?

Le 16 mai 2024, un groupe de chercheurs/hacktivistes baptisé « rabbitude » a découvert des clés API codées en dur dans la base de code du rabbit r1. En termes simples, une interface de programmation d'application, ou API, facilite l'interaction entre deux applications. Les API permettent au rabbit r1 de communiquer avec les applications prises en charge que l'utilisateur a configurées. Les clés API sont des identifiants uniques utilisés pour authentifier l'utilisateur ou l'application qui tente d'accéder à l'API. Après avoir trouvé les clés API codées en dur, les hacktivistes ont pu accéder aux plateformes tierces suivantes :

• ElevenLabs (pour la synthèse vocale)
• Azure (pour un ancien système de reconnaissance vocale)
• Yelp (pour la recherche d'avis)
• Google Maps (pour la recherche de lieux)

L'accès fourni par les clés API variait, mais au moins l'une d'entre elles accordait l'intégralité des privilèges sur ElevenLabs. Cette clé permettrait à des acteurs malveillants d'obtenir l'historique de tous les messages de reconnaissance vocale antérieurs, d'ajouter des remplacements de texte personnalisés, et plus encore.  Elle pourrait même être exploitée pour faire planter le back-end du système d'exploitation de rabbit et rendre tous les appareils r1 inutilisables.

Pourquoi est-ce un problème majeur ?

Si tous les appareils, toutes les applications et toutes les entreprises sont susceptibles de comporter des vulnérabilités pouvant être exploitées, l'utilisation de clés codées en dur est une mauvaise pratique, connue depuis des décennies. C'est un problème de sécurité majeur, à tel point qu’il figure sur la liste des vulnérabilités potentielles de l'organisme MITRE sous le nom de Common Weakness Enumeration (CWE) 321. Ce problème de sécurité n'est pas nouveau. Les clés ou les identifiants codés en dur sont à l'origine de toutes sortes de compromissions, des routeurs aux commutateurs en passant par de gigantesques plateformes logicielles :

• Les clés API de Twitter ont été divulguées par le biais de milliers d'applications mobiles, et ont permis à des pirates informatiques d'accéder à différentes catégories d'informations sensibles.
• Toyota a divulgué des clés par inadvertance dans le code source transféré à GitHub, entraînant l'exposition de plus de 296 000 dossiers clients, adresses e-mail comprises.
• Les systèmes d'Uber contenaient un compte administrateur codé en dur, ce qui a permis à un attaquant d'accéder à l'infrastructure et au réseau de l'entreprise. (CWE 798 concerne les identifiants codés en dur)

L'industrie informatique semble décidée à répéter les erreurs du passé.

Les normes de sécurité en matière de développement et de sécurité informatiques mettent en garde contre cette pratique, à juste titre. Si une clé codée en dur est trouvée, il peut être difficile de la supprimer sans provoquer une rupture de l’API. Plus important encore : si la clé tombe entre de mauvaises mains, comme dans le cas du rabbit r1, elle peut être utilisée à des fins criminelles.

Les API sont les autoroutes de l’informatique ; elles nous permettent d’échanger de grandes quantités d’informations en appuyant sur un bouton. Elles sont indispensables à une automatisation adéquate et notre industrie ne pourrait pas avancer sans elles. Néanmoins, leur caractère sensible et l'impact des problèmes de sécurité nous obligent à prendre du recul et à analyser la façon dont nous les développons et interagissons avec elles.

Quelle est la solution ?

Il n’y a pas de solution unique dans des cas comme ceux que nous avons présentés, mais il existe quelques bonnes pratiques :

• N'utilisez jamais d'identifiants codés en dur dans les logiciels.
• Adoptez une stratégie complète de sécurité des applications, efficace à la fois lors de la création et au stade de l'exécution.
• Contrôlez régulièrement le code et les pratiques de sécurité.
• Tirez les leçons du passé. De nombreuses erreurs de sécurité ont déjà été commises de manière répétée.

Vous pouvez compter sur Barracuda

Barracuda Application Protection est une plateforme intégrée qui combine tout un ensemble de capacités interopérables afin d'assurer une sécurité complète des applications, y compris en fournissant une protection contre les dix principales menaces Web et API citées par l'OWASP. Accédez à notre site Web pour en savoir plus.