DevOps : les informations d’identification codées en dur représentent un risque réel

Alors que l’année 2022 touche à sa fin, les récents incidents ne font pas exception : le risque de fuite de secrets est élevé.

Mi-septembre, Uber, la société de VTC, a confirmé les annonces d’un attaquant ayant réussi à s’introduire dans plusieurs systèmes internes critiques après avoir trouvé des identifiants d’administrateur codés en dur dans un script Powershell. Les secrets permettaient de se connecter à la plateforme de gestion d’accès privilégiés d’Uber, où de nombreuses autres informations d’identification étaient stockées : l’attaquant a ainsi pu prendre le contrôle de plusieurs comptes administratifs de AWS, GCP, Google Drive, Slack, SentinelOne, HackerOne, et plus encore.

Quelques semaines plus tard, Toyota, le géant de l’automobile, a révélé qu’il avait accidentellement exposé une clé d’identification permettant d’accéder à des données clients dans un dépôt public GitHub pendant près de cinq ans. Bien qu’ils aient assuré que la clé avait été invalidée, une exposition aussi longue pourrait signifier que de multiples acteurs malveillants y avaient déjà accédé.

Des millions de secrets exposés

Les secrets (noms d’utilisateur et mots de passe, jetons d’API, clés de chiffrement, etc.) sont la pierre angulaire de la sécurité, car ils permettent aux bonnes identités (qu’elles appartiennent à des humains ou à des machines) d’accéder à la bonne chose au bon moment. Lorsque la sécurité consistait à sécuriser le périmètre d’une organisation, les secrets étaient hautement protégés et gardés hors de portée de la plupart des développeurs et autres professionnels de l’informatique. Conserver les “joyaux de la couronne” en lieu sûr était relativement facile tant que le développement et les opérations étaient des domaines complètement séparés.

Mais avec l’avènement du DevOps et des pratiques agiles, les systèmes hyperconnectés ont complètement bouleversé la notion de périmètre de sécurité. A mesure que le nombre de composants logiciels interconnectés augmente, le nombre de secrets nécessaires pour les faire communiquer augmente également. Les composants logiciels comprennent les bases de données, les composants tiers utilisés lors de la phase de construction ou d’exécution, les microservices, etc. Maintenant que toutes les personnes et tous les actifs du cycle de développement logiciel utilisent des secrets, ceux-ci ne sont plus une ressource rare. Mécaniquement, la probabilité d’avoir une fuite de secret quelque part est également plus élevée.

C’est ainsi qu’en 2021, plus de six millions de secrets ont été exposés sur GitHub, le lieu « où le monde construit des logiciels ». Ce chiffre a doublé par rapport à 2020. En moyenne, 3 commits sur 1 000 contenaient une créance, ce qui est 50 % de plus que l’année dernière. Beaucoup de ces secrets sont directement liés aux ressources de l’entreprise comme les comptes cloud, les serveurs web ou les certificats publics, et beaucoup d’autres pourraient être utilisés pour usurper l’identité d’un employé ou escalader les privilèges.

Cette situation est clairement une aubaine pour les pirates. Les secrets sont là, prêts à être exploités.

Divers rapports ont mis en évidence le problème : « l’utilisation d’informations d’identification volées » est le moyen le plus courant de pénétrer dans les applications web, selon le dernier rapport DBIR. Elle représente plus de 80 % des violations, tandis que « les exploitations de vulnérabilités » représentent moins de 20 % des cas. Le rapport la qualifie de « stratégie peu coûteuse et très payante, attrayante pour toute une série d’attaquants ».

Le problème de l’éparpillement des secrets dans les bases de code connaît une croissance exponentielle. Pourtant, la sécurité des applications a pris du retard dans la réponse à cette menace. Essayons de comprendre pourquoi.

Secrets dans le paysage de la sécurité applicative

L’objectif de la sécurité applicative a traditionnellement été de trouver des vulnérabilités telles que le Cross-Site Request Forgery (CSRF), le Server-Side Request Forgery (SSRF), ou des failles logiques dans le code source. Ces vulnérabilités se manifestent toujours dans l’état actuel et déployé d’une application.

Avec les secrets, l’histoire est différente. Un secret codé en dur par erreur ne nécessite pas que le logiciel soit en cours d’exécution pour être exploité. En fait, cette faille restera dangereuse même si elle n’est pas présente dans le code en cours d’exécution !

Lorsque les développeurs collaborent sur du code, ils utilisent un système de contrôle de version – aujourd’hui presque systématiquement git. Cet outil garde la trace de chaque révision du code source – y compris les erreurs – ce qui signifie qu’un secret valide peut être codé en dur dans une version du code qui n’a jamais été déployée, et répliquée aussi souvent que la base de code est clonée. C’est ainsi que les informations d’identification peuvent s’étendre bien plus rapidement que ce que la sécurité applicative peut suivre, à l’intérieur ou à l’extérieur du périmètre informatique de l’entreprise.

Les informations d’identification codées en dur ont une autre caractéristique : elles s’accumulent dans le temps. Plus les développeurs ont travaillé (ou travailleront) sur un projet, plus la probabilité que des secrets aient été codés en dur à un moment donné est élevée. Ces probabilités augmentent également avec la taille de la base de code et le nombre total de dépôts. Par conséquent, les secrets codés en dur s’accumulent un peu comme le fait la « dette technique », à la différence que cette dernière apparaît dans les revues de code, tandis que les secrets n’y seront pas.
En effet, les revues de code ne prennent en compte que la différence nette entre l’état actuel et le changement proposé, et pas toutes les modifications intermédiaires où des secrets auraient pu être ajoutés par inadvertance.

La conséquence est que la dette de sécurité s’accumule au fil du temps et, passé un certain point, elle peut devenir ingérable pour une équipe de sécurité des applications.

Lorsque des recherches ont été effectuées sur les bases de code de Twitch et Samsung l’année dernière, entre 6 500 et 7 000 secrets codés en dur ont pu être découverts : mots de passe de messagerie interne de l’entreprise, clés d’API de services cloud, jetons de tiers et autres identifiants d’authentification, etc.

En moyenne, on peut estimer qu’une entreprise type comptant 400 développeurs et quatre ingénieurs AppSec découvriraient en moyenne 1 050 secrets uniques codés en dur dans leurs dépôts de code. Plus inquiétant encore, chaque secret est codé en dur plusieurs fois – 13 en moyenne – ce qui multiplie l’effort nécessaire pour « nettoyer » correctement le code (ou au moins enquêter sur chaque cas) pour l’équipe de sécurité applicative.

Comment éviter les informations d’identification codées en dur ?

La première étape consiste à mettre en œuvre dès maintenant les contrôles permettant d’éviter que les informations d’identification ne soient codées en dur mois après mois et de « stopper l’hémorragie ». Le contrôle en temps réel est le meilleur moyen de freiner la prolifération des secrets, car il permet de détecter les erreurs le plus tôt possible.

Si le développeur est alerté juste avant de faire entrer un secret dans le VCS, le coût unitaire de la remédiation est inférieur à une minute. L’identifiant n’a été exposé que sur le poste de travail local, et le développeur peut exécuter quelques commandes pour modifier sa contribution sans conséquences pour son équipe.

En revanche, si le commit défectueux atteint le dépôt distant, le secret doit être considéré comme compromis : en effet, n’importe qui disposant d’un accès en lecture, aujourd’hui ou demain, pourrait l’exploiter. Cela signifie qu’il s’agit d’une vulnérabilité. Pour y remédier, le secret doit être révoqué, régénéré et redistribué partout où il était utilisé. Cette procédure de remédiation peut prendre des minutes, des heures, voire plus, interrompant les flux de travail de plusieurs personnes.

En moyenne, le coût de la remédiation s’élève souvent à au moins deux heures-personnes. Si l’on applique cela aux chiffres mentionnés précédemment, au moins 2 100 heures-personnes seraient nécessaires pour atteindre zéro secret dans le code dans le cas moyen (2 heures x 1 050 secrets). Et il s’agit d’un minimum, puisqu’elle suppose qu’aucun autre secret ne sera codé en dur à l’avenir.

Enquêter sur des milliers d’incidents liés à des secrets codés en dur, les classer par ordre de priorité et y remédier peut sembler insurmontable pour une équipe de sécurité applicative ne disposant pas de stratégie préalable. Pourtant cela n’est pas une fatalité. En commençant modestement et en freinant progressivement l’accumulation de nouvelles vulnérabilités, dans 6 ou 12 mois, les gains seront évidents, car les ingénieurs en sécurité auront vu leur temps moyen de remédiation s’améliorer constamment.

Ne négligez pas vos secrets

Dans le monde du développement logiciel, tel qu’il est aujourd’hui, personne ne peut ignorer le fait que les informations d’identification codées en dur représentent un risque important qui menace la sécurité des entreprises. Si l’on souhaite véritablement obtenir des résultats sur le long terme, il est nécessaire de commencer dès aujourd’hui à reprendre le contrôle sur sa dette de sécurité. Pour les secrets codés en dur, cela signifie tirer parti des analyses incrémentales du code source pour freiner leur accumulation dans le temps. Cela se révèlera être un atout indispensable afin d’aider les développeurs et les ingénieurs en sécurité à résoudre ce problème ensemble.