API sur roues : un road trip riche en vulnérabilités

À quand remonte votre dernier road trip ? Selon l'endroit où vous vous trouvez dans le monde, il est peut-être tout juste de retour à l'ordre du jour, mais rien ne vaut vraiment la route et le dépaysement.

À moins d'être une vulnérabilité logicielle, bien sûr.

Nous avons longuement parlé des dangers posés par le laxisme en matière de cybersécurité dans l'industrie automobile, avec des entreprises comme Tesla et Jeep qui collaborent déjà avec des chercheurs en sécurité pour découvrir des failles exploitables qui auraient pu entraîner de graves problèmes de sécurité si elles n'avaient pas été découvertes et corrigées rapidement. Nous avons également évoqué le fait que, de manière générale, la sécurité logicielle est encore au Far West. Les logiciels sont partout, et pour de nombreux appareils connectés, véhicules et périphériques, les mesures de sécurité nécessaires vont bien au-delà de l'éducation et de la vigilance des utilisateurs finaux.

Les vulnérabilités des API deviennent particulièrement insidieuses, avec un trafic API malveillant en hausse de plus de 300 % au cours des six derniers mois seulement. C'est assez préoccupant, étant donné que les véhicules modernes sont essentiellement des API sur roues. Ils sont connectés, communiquent constamment avec d'autres applications et pourraient être pris pour cible dans le cadre d'attaques visant l'un des nombreux points de terminaison vulnérables.

Quand votre chargeur de VE en dit trop

Les véhicules connectés ont été scrutés pour la sécurité de leurs logiciels, mais qu'en est-il de leurs accessoires ? L'équipe de génies de Pen Test Partners a découvert plusieurs vulnérabilités au niveau du code chez six marques de bornes de recharge pour véhicules électriques domestiques, ainsi que sur un réseau public de recharge pour VE très répandu.

Qui se soucie d'un chargeur ? Qu'est-ce qu'un attaquant pourrait y gagner ? Malheureusement, l'un des inconvénients de la technologie puissante et complexe qui travaille pour nous est que ces appareils ont généralement tendance à trop en dire. Les chargeurs de VE communiquent avec des applications mobiles compagnons via une API, dans un environnement cloud, et tout cela peut être vulnérable à l'exploitation s'il n'est pas codé et configuré de manière sécurisée. Par conception, les API ouvrent les vannes de la communication entre les applications, et si ces points de terminaison ne sont pas configurés avec soin, trop d'informations pourraient être partagées, ou pire, accessibles via une porte dérobée vulnérable.

Pen Test Partners a découvert des vulnérabilités extrêmement dangereuses qui auraient pu permettre le piratage de millions de chargeurs de VE, plusieurs cas de problèmes d'autorisation d'API permettant la prise de contrôle de comptes et l'accès ou le contrôle à distance, et même la possibilité de perturber le réseau électrique grâce au contrôle synchronisé de plusieurs appareils de recharge. Ces problèmes ont tous été corrigés, mais le fait que quelques lignes de code aient suffi à séparer les attaquants d'une perturbation totale des fonctionnalités de base et de l'infrastructure de service est profondément préoccupant.

Et ce n'est pas comme s'il s'agissait d'un travail de génie. Wallbox, par exemple, présentait deux références directes à des objets non sécurisées (IDOR) dans son API, ce qui aurait permis une prise de contrôle de compte en cas d'exploitation. L'IDOR fait partie des problèmes d'authentification défaillante, qui occupe la deuxième place du Top 10 des vulnérabilités API de l'OWASP. C'est monnaie courante, ce qui souligne une lacune dans l'apprentissage et la mise en œuvre d'un code de qualité. Nous ne pouvons pas continuer à connecter des appareils et des applications sensibles via une myriade de voies de communication buggées, et les API mal configurées en sont l'exemple parfait.

Travailler en toute sécurité avec les API automobiles demande de l'éducation et de la patience

Ce qui est frustrant avec la sécurité des API, c'est qu'elle est présentée comme une nouvelle vague de désastre en matière de cybersécurité à tenter d'atténuer, alors qu'en réalité, il ne s'agit que d'un nouveau cadre pour les mêmes vieux problèmes que nous observons depuis des décennies dans le développement web. Cross-site scripting, injection, mauvaise configuration : ça vous dit quelque chose ?

Les récents indicateurs d'organisations comme le NIST sont prometteurs et montrent que la sécurité logicielle devient plus réglementée et standardisée. Cependant, nous manquons encore cruellement d'experts pour ne serait-ce qu'entamer le travail de protection nécessaire face au déluge de code écrit chaque jour. Les développeurs doivent monter en compétences et en responsabilités en matière de sécurité, et ce n'est pas à eux de prendre l'initiative. Si vous avez une équipe travaillant sur des systèmes embarqués dans des appareils, ou sur des API qui pourraient transformer une voiture en jouet télécommandé, vous devez vous assurer qu'ils disposent de ce dont ils ont besoin pour cesser d'introduire des vulnérabilités courantes.

Les différences entre une API sécurisée et une API vulnérable à cause du XSS sont minimes, par exemple, mais les développeurs doivent être sensibilisés aux nuances qui distinguent un mauvais modèle de codage d'un bon. De plus, les processus de développement négligents sont souvent la norme dans les configurations d'API, beaucoup se voyant accorder de vastes autorisations bien au-delà des exigences minimales pour accomplir leurs tâches, ouvrant ainsi une surface d'attaque supplémentaire et un risque de vol de données. Ces facteurs doivent être pris en compte lors de la construction, mais s'ils ne sont pas ancrés dans des pratiques de développement acceptables, le processus continuera d'être un facteur de risque.

Éviter le nouveau terrain de jeu des acteurs malveillants

L'augmentation spectaculaire des API en tant que cible des acteurs malveillants montre que l'attention se porte sur ce qui est perçu comme une cible facile... et dans ce cas, il s'agit d'une voie royale vers un gain important, en plus des menaces potentielles pour la vie humaine sous la forme d'une possible prise de contrôle de véhicule.

Laisser la sécurité des API au hasard est le meilleur moyen de créer des problèmes à l'avenir, avec des conséquences potentiellement dévastatrices dans le pire des cas, et des retouches frustrantes ainsi que de faibles performances dans le meilleur des cas. Cela devrait être une considération critique au sein de l'écosystème de communication logicielle, et figurer en bonne place dans tout programme de sécurité de premier ordre. La clé est de traiter chaque API comme s'il s'agissait d'un humain et d'évaluer les accès dont elle a besoin. Jim de la comptabilité devrait-il avoir accès à tous les documents juridiques sensibles de toute l'entreprise ? Probablement pas, et en général, le contrôle d'accès est correctement déterminé pour le personnel réel. On ne peut pas en dire autant des API, et il est important de se rappeler qu'il s'agit de bavardes puissantes qui révéleront tous vos secrets si elles ne sont pas configurées avec les mêmes méthodes de confiance zéro que tout le reste.

L'organisation doit être en état d'alerte maximale, et les développeurs sont les yeux nécessaires sur le terrain pour créer un code de qualité, exempt de ces portails vulnérables vers le désespoir. Il est temps de leur donner l'opportunité de grandir et de s'épanouir en tant qu'ingénieurs conscients de la sécurité, avec le bon état d'esprit pour cet objectif et les compétences pratiques pour prendre les bonnes décisions aux étapes critiques de la création.