AVIS D’EXPErT – Thomas Segura, Technical expert chez GitGuardian, explique aux lecteurs de Solutions Numériques comment les secrets (clés d’API, tokens, clés d’identification) conduisent à des cyberattaques.
Si un mot pouvait résumer l’année 2021 en termes de cybersécurité (en fait, trois), cela serait ceux-ci : « attaque de la supply chain logicielle ». Une attaque de la supply chain logicielle se produit lorsque des pirates manipulent le code de composants logiciels tiers pour compromettre les applications qui les utilisent en aval. En 2021, nous avons assisté à une augmentation spectaculaire de ce type d’attaques : des incidents de sécurité très médiatisés ont impacté d’importantes sociétés fournissant des services informatiques aux États-Unis, telles que SolarWinds, Kaseya ou encore Codecov. Ces attaques ont ébranlé la confiance des entreprises dans les pratiques de sécurité des fournisseurs de services tiers.
En quoi les secrets (clés d’API, tokens, clés d’identification) sont-ils liés à ce type d’attaques ? Par exemple, dans l’affaire Codecov, il s’agit d’un cas d’école illustrant la façon dont les pirates utilisent des informations d’identification codées en dur pour obtenir un accès initial aux systèmes de leurs victimes et récolter d’autres secrets en aval de la chaîne.
Les secrets dans le code restent l’une des vulnérabilités les plus négligées dans le domaine de la sécurité des applications, bien qu’il s’agisse d’une cible de choix pour les pirates. Comment faire en sorte que les secrets restent en dehors du code, c’est une priorité pour sécuriser le cycle de vie du développement logiciel.
Qu’est-ce qu’un secret ?
Les secrets sont des identifiants numériques d’authentification (clés API, certificats, jetons, etc.) utilisés dans des applications, des services ou des infrastructures. De la même manière qu’un mot de passe (plus un dispositif matériel en cas de 2FA) est utilisé pour authentifier une personne, un secret authentifie des systèmes pour permettre leur interopérabilité. Mais il y a une importante différence : contrairement aux mots de passe, les secrets sont destinés à être distribués.
Pour fournir continuellement de nouvelles fonctionnalités, les équipes de développement doivent interconnecter de plus en plus de composants. Les organisations voient exploser le nombre de secrets utilisés par leurs équipes (équipe de développement, SRE, DevOps, sécurité, etc.). De temps en temps, les développeurs conservent les clés dans un endroit non sécurisé pour faciliter la modification du code, de sorte que les identifiants sont souvent oubliés par erreur et publiés par inadvertance.
En termes de sécurité applicative, les secrets codés en dur constituent un type de vulnérabilité vraiment différent. Tout d’abord, le code source est un actif très propice aux fuites car il est par nature destiné à être cloné, observé et distribué sur plusieurs machines très fréquemment. De fait, les secrets présents dans le code le sont donc tout autant. Mais ce qui est encore plus problématique, c’est que le code a aussi une mémoire.
Aujourd’hui tout dépôt de code est géré par l’intermédiaire d’un système de contrôle de version (VCS) qui conserve une chronologie parfaite de toutes les modifications qui lui ont été apportées, parfois sur des décennies. Le problème est que des secrets encore valides peuvent se cacher n’importe où sur cette ligne de temps, ouvrant ainsi une nouvelle dimension, historique cette fois-ci, à la surface d’attaque logicielle. Malheureusement, la plupart des analyses de sécurité ne concernent que l’état actuel, prêt à être déployé, du code source d’une application. En d’autres termes, lorsqu’il s’agit de secrets vivant dans un ancien commit ou même une branche jamais déployée, ces outils sont totalement aveugles.
Six millions de secrets publiés sur GitHub
L’année dernière, en surveillant les commits publiés sur GitHub en temps réel, plus de 6 millions de secrets divulgués*, ont été détectés, soit le double de ce qui avait été relevé en 2020. En moyenne, 3 commits sur 1 000 contenaient un secret, ce qui est 50 % de plus que l’année dernière.
Une grande partie de ces secrets donnait accès à des ressources d’entreprise. Il n’est donc pas étonnant qu’un attaquant cherchant à pénétrer un système d’entreprise étudie en tout premier lieu ses dépôts publics sur GitHub, puis ceux appartenant à ses collaborateurs. La plupart des développeurs utilisent GitHub pour des projets personnels, et il peut arriver qu’ils divulguent par erreur des secrets donnant accès à des ressources d’entreprise (oui, cela arrive régulièrement !).
Avec des identifiants valides, les attaquants opèrent comme des utilisateurs autorisés, et la détection post-intrusion devient beaucoup plus difficile. Le temps nécessaire pour qu’un identifiant soit compromis après avoir été publié GitHub est d’à peine 4 secondes (les acteurs malveillants enregistrent tout ce qu’il s’y passe en permanence), ce qui signifie qu’il doit être immédiatement révoqué et remplacé pour neutraliser le risque de violation. Dans la panique, ou par manque de connaissances techniques, certaines personnes essaient de couvrir l’erreur en faisant disparaître le secret de l’état actuel du code (en écrivant un commit qui efface le secret), ce qui ne mitige pas du tout la faille de sécurité.
Au contraire, cela passe sous silence la faille qui ne pourra plus être détectée ni lors de la revue du code, ni par des équipes de sécurité, et qui sera dupliquée autant de fois que le code est cloné. Autant dire, une aubaine pour les hackeurs.
Une autre erreur pour les entreprises serait de tolérer la présence de secrets à l’intérieur de ses dépôts privés. Le rapport The State of Secrets Sprawl 2022 souligne le fait que les dépôts privés cachent beaucoup plus de secrets que leur équivalent public. L’hypothèse est que les dépôts privés procurent un faux sentiment de sécurité, ce qui rend les personnes y contribuant un peu moins méfiantes.
C’est ignorer le fait que peu importe que ces dépôts soient privés, des secrets oubliés pourraient un jour être collectés lors d’une attaque pour pivoter vers d’autres systèmes où bien élever des privilèges. Les scénarios de piratage sont nombreux, mais ils ont tous un point commun : utiliser les secrets qui sont à disposition pour maximiser l’impact d’une attaque informatique.
Les équipes chargées de la sécurité des applications sont bien conscientes du problème. Malheureusement, la quantité de travail à accomplir pour enquêter, révoquer et mettre à jour les secrets compromis chaque semaine est tout simplement écrasante, sans même parler de fouiller dans des années de code inexploré.
Attaques à la une
Cependant, il y a urgence. Les pirates utilisent activement des dorks sur GitHub, qui sont des modèles pour identifier des secrets facilement reconnaissables. Et GitHub n’est pas le seul endroit où ils peuvent être actifs, tout registre (comme Docker Hub) ou toute fuite de code source peut potentiellement devenir une mine d’or pour trouver des vecteurs d’exploitation.
Pour s’en convaincre, il suffit d’examiner les attaques récentes : l’une d’elle concerne Codecov, un outil très répandu de couverture de code. L’année dernière, il a été compromis par des hackers qui y ont accédé en extrayant un identifiant de compte Cloud de son image Docker officielle. Après avoir réussi à accéder au dépôt de code source officiel, ils ont pu altérer un script CI et récolter des centaines de secrets de la base d’utilisateurs de Codecov.
Plus récemment, la base de code complète de Twitch a fait l’objet d’une fuite, exposant plus de 6 000 dépôts Git et 3 millions de documents. Malgré de nombreux éléments démontrant un certain niveau de maturité en matière d’AppSec, près de 7 000 secrets s’y trouvaient ! On parle de centaines de clés AWS, Google, Stripe et GitHub. Seules quelques-unes d’entre elles suffiraient à déployer une attaque de grande envergure sur les systèmes les plus critiques de l’entreprise. Cette fois, aucune donnée client n’a été divulguée, car ce n’était pas la cible des attaquants, mais cela aurait pu être le cas dans d’autres circonstances.
Il y a quelques années, Uber n’a pas eu cette chance. Un employé a accidentellement publié du code d’entreprise sur son dépôt personnel GitHub (public). Des pirates l’ont découvert et ont récupéré les clés d’un fournisseur donnant accès à la totalité de l’infrastructure cloud d’Uber. Une brèche massive s’en est suivie.
La détection des secrets et la capacité de remédiation sont indispensables
En résumé, on ne peut pas vraiment savoir quand un secret sera exploité, mais il faut garder à l’esprit que des acteurs malveillants surveillent les développeurs et recherchent du code ayant des secrets codés en dur. Ces incidents ne sont que la partie émergée de l’iceberg et de nombreuses autres attaques ont probablement eu pour cause des secrets sans que l’information soit dévoilée publiquement.
Les secrets sont un composant essentiel de tout logiciel, et ils sont particulièrement puissants, ils nécessitent donc une protection très forte. Leur nature distribuée et les pratiques modernes de développement logiciel font qu’il est très difficile de contrôler où ils atterrissent, qu’il s’agisse du code source, des logs de production, des images Docker ou des applications de messagerie instantanée. La détection des secrets et la capacité de remédiation sont indispensables, car les secrets peuvent être exploités dans une attaque conduisant à une brèche majeure. De tels scénarios se produisent fréquemment et comme de plus en plus de services et d’infrastructures sont utilisés dans le monde de l’entreprise, le nombre de fuites potentielles augmente à un rythme très rapide. Plus on agit tôt, plus il est facile de protéger le code source contre les menaces futures.
