L'API sur roues : Un voyage sur les routes des vulnérabilités à risque

À quand remonte votre dernier voyage en voiture ? Selon l'endroit où vous vous trouvez dans le monde, il s'agit peut-être d'un retour récent à l'ordre du jour, mais il n'y a rien de mieux que la route et le dépaysement. 

À moins que vous ne soyez une vulnérabilité logicielle, bien sûr.

Nous avons longuement parlé des dangers posés par les mesures de cybersécurité laxistes dans l'industrie automobile, avec des entreprises comme Tesla et Jeep qui travaillent déjà avec des chercheurs en sécurité, trouvant des bogues exploitables qui auraient pu conduire à de graves problèmes de sécurité s'ils n'avaient pas été découverts à temps et corrigés rapidement. Nous avons également évoqué le fait que, d'une manière générale, la sécurité des logiciels en est encore au stade du Far West. Les logiciels sont omniprésents 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 de l'utilisateur final.

Les vulnérabilités des API deviennent particulièrement insidieuses, le trafic d'API malveillantes ayant augmenté de plus de 300 % au cours des six derniers mois seulement. C'est plutôt inquiétant, étant donné que les véhicules modernes sont essentiellement des API sur roues. Ils sont connectés, très bavards avec d'autres applications, et pourraient être pris dans des attaques ciblées comme l'un des nombreux points d'extrémité vulnérables. 

Quand votre chargeur de VE en dit trop

Les véhicules connectés ont fait l'objet d'un examen minutieux en ce qui concerne la sécurité de leurs logiciels, mais qu'en est-il de leurs accessoires ? L'équipe de génie de Pen Test Partners a découvert plusieurs vulnérabilités au niveau du code dans six marques de recharge de véhicules électriques domestiques, ainsi que dans un réseau public de recharge de véhicules électriques très répandu.

Qui se soucie d'un chargeur ? Qu'est-ce qu'un pirate pourrait y gagner ? Malheureusement, l'un des inconvénients des technologies puissantes et profondes qui font des heures supplémentaires pour nous est que ces appareils ont généralement un mauvais cas de TMI. Les chargeurs de VE communiquent avec les applications mobiles qui les accompagnent par le biais d'API, dans un environnement basé sur le nuage, et tout cela peut être vulnérable à l'exploitation si le codage et la configuration ne sont pas sécurisés. Les API, de par leur conception, ouvrent les vannes de la communication entre les applications, et si ces points de terminaison ne sont pas soigneusement configurés, trop de choses pourraient être partagées - ou pire - accessibles via une porte dérobée vulnérable de l'application.

Pen Test Partners a découvert des vulnérabilités extrêmement dangereuses qui auraient pu conduire au détournement de millions de chargeurs de véhicules électriques, plusieurs cas de problèmes d'autorisation API qui ont permis la prise de contrôle d'un compte et le contrôle/accès à distance à un compte, et même la possibilité de perturber le réseau électrique par le biais du contrôle synchronisé de plusieurs dispositifs de véhicules électriques. Ces problèmes ont tous été corrigés, mais le fait que quelques lignes de code étaient tout ce qui séparait les attaquants d'une perturbation complète de la fonctionnalité de base et de l'infrastructure de service est profondément inquiétant. 

Ce n'est pas non plus comme s'il s'agissait d'une affaire de génie. Wallbox, par exemple, avait deux références d'objet directes non sécurisées (IDOR) dans son API, qui auraient permis la prise de contrôle du compte si elles avaient été exploitées. L'IDOR fait partie des failles d'authentification, qui occupent la deuxième place dans le Top 10 des vulnérabilités des API de l'OWASP. Cette vulnérabilité est aussi courante que la saleté, ce qui indique une défaillance 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 par le biais d'une myriade de voies de communication boguées, et les API mal configurées sont précisément cela. 

Travailler en toute sécurité avec les API automobiles demande de la formation 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ésastres de cybersécurité à essayer d'atténuer, alors qu'en réalité, il s'agit simplement d'un nouveau cadre pour les mêmes vieux problèmes que nous avons vus pendant des décennies dans le développement web. Les scripts intersites, les injections, les erreurs de configuration : cela vous rappelle quelque chose ?

Les indicateurs récents d'organisations telles que le NIST sont prometteurs et montrent que la sécurité des logiciels est de plus en plus réglementée et normalisée. Cependant, nous sommes encore loin de disposer des experts nécessaires pour ne serait-ce qu'entamer la quantité de protection qui doit être apportée au déluge de code écrit chaque jour. Les développeurs doivent voir leurs connaissances et leurs responsabilités en matière de sécurité renforcées, et ce n'est pas à eux de prendre l'initiative. Si vous avez une équipe qui travaille 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'elle est équipée de ce dont elle a besoin pour cesser d'introduire des vulnérabilités courantes. 

Les différences entre une API sécurisée et une API vulnérable en raison d'un XSS sont minimes, par exemple, mais il faut montrer aux développeurs les nuances qui différencient un mauvais modèle de codage d'un bon. En outre, les processus de développement paresseux sont souvent habituels dans les configurations d'API, de nombreuses autorisations étant accordées au-delà des exigences minimales requises pour que l'API puisse accomplir les tâches qui lui sont assignées, ce qui ouvre une surface de menace supplémentaire et un potentiel de vol de données. Ces facteurs doivent être pris en compte lors de la construction, mais s'ils ne sont pas intégré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 de la menace

L'augmentation spectaculaire du nombre d'API ciblées par les acteurs de la menace montre que l'attention se porte sur ce qui est perçu comme un fruit à portée de main... et dans ce cas, il s'agit d'un fruit qui pourrait être une source de revenus importants, en plus des menaces potentielles pour la vie sous la forme d'une prise de contrôle potentielle d'un véhicule. 

Laisser la sécurité des API au hasard est un moyen infaillible d'introduire des problèmes plus tard, avec des conséquences potentiellement dévastatrices dans le pire des cas, et des travaux frustrants et des performances médiocres dans le meilleur des cas. Il devrait s'agir d'une considération essentielle dans le cadre de l'écosystème de communication des logiciels, et d'une priorité dans le cadre d'un programme de sécurité de premier ordre. La clé est de traiter chaque API comme s'il s'agissait d'un être humain et d'évaluer l'accès qu'il doit avoir. Jim de la comptabilité doit-il avoir accès à tous les documents juridiques sensibles de l'ensemble de l'entreprise ? Probablement pas, et en général, le contrôle d'accès est correctement déterminé dans le cas du personnel réel. On ne peut pas en dire autant des API, et il est important de se rappeler que ce sont de puissants bavards qui laisseront tout le monde connaître vos secrets s'ils ne sont pas configurés avec les mêmes méthodes de confiance zéro que tout le reste.

L'organisation doit être en état d'alerte, 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 qui mènent au désespoir. Il est temps de leur donner la possibilité de se développer et de s'épanouir en tant qu'ingénieurs sensibilisés à la sécurité, avec l'état d'esprit adéquat pour atteindre cet objectif et les compétences pratiques nécessaires pour prendre les bonnes décisions lors des étapes critiques de la création.