Si un mot pouvait r\u00e9sumer l’ann\u00e9e 2021 de l’infos\u00e9curit\u00e9 (enfin, trois en fait), ce serait celui-ci\u00a0: “attaque de la cha\u00eene d’approvisionnement”. <\/p>\n
Une attaque de la cha\u00eene d’approvisionnement logicielle se produit lorsque des pirates manipulent le code de composants logiciels tiers pour compromettre les applications \u00ab en aval \u00bb qui les utilisent. En 2021, nous avons assist\u00e9 \u00e0 une augmentation spectaculaire de ces attaques\u00a0: des incidents de s\u00e9curit\u00e9 tr\u00e8s m\u00e9diatis\u00e9s tels que SolarWinds, Kaseya et Codecov<\/a> Les violations de donn\u00e9es ont \u00e9branl\u00e9 la confiance des entreprises dans les pratiques de s\u00e9curit\u00e9 des fournisseurs de services tiers.<\/p>\n Qu’est-ce que cela a \u00e0 voir avec les secrets, pourriez-vous demander? Bref, beaucoup. Prenons l’affaire Codecov (nous y reviendrons rapidement) : c’est un exemple classique pour illustrer comment les pirates exploitent les informations d’identification cod\u00e9es en dur pour obtenir un acc\u00e8s initial aux syst\u00e8mes de leurs victimes et r\u00e9colter plus de secrets tout au long de la cha\u00eene. <\/p>\n Les secrets dans le code restent l’une des vuln\u00e9rabilit\u00e9s les plus n\u00e9glig\u00e9es dans l’espace de s\u00e9curit\u00e9 des applications, bien qu’ils soient une cible prioritaire dans les playbooks des pirates. Dans cet article, nous parlerons des secrets et de la fa\u00e7on dont les garder hors du code source est la priorit\u00e9 num\u00e9ro un d’aujourd’hui pour s\u00e9curiser le cycle de vie du d\u00e9veloppement logiciel.<\/p>\n Les secrets sont des identifiants d’authentification num\u00e9riques (cl\u00e9s API, certificats, jetons, etc.) qui sont utilis\u00e9s dans des applications, des services ou des infrastructures. Tout comme un mot de passe (plus un appareil en cas de 2FA) est utilis\u00e9 pour authentifier une personne, un secret authentifie les syst\u00e8mes pour permettre l’interop\u00e9rabilit\u00e9. Mais il y a un hic : contrairement aux mots de passe, les secrets sont destin\u00e9s \u00e0 \u00eatre distribu\u00e9s. <\/p>\n Pour fournir en permanence de nouvelles fonctionnalit\u00e9s, les \u00e9quipes d’ing\u00e9nierie logicielle doivent interconnecter de plus en plus de blocs de construction. Les organisations voient le nombre d’identifiants utilis\u00e9s dans plusieurs \u00e9quipes (\u00e9quipe de d\u00e9veloppement, SRE, DevOps, s\u00e9curit\u00e9, etc.) exploser. Parfois, les d\u00e9veloppeurs conservent les cl\u00e9s dans un emplacement non s\u00e9curis\u00e9 pour faciliter la modification du code, mais cela entra\u00eene souvent l’oubli par erreur et la publication par inadvertance des informations.<\/p>\n Dans le paysage de la s\u00e9curit\u00e9 des applications, les secrets cod\u00e9s en dur sont vraiment un type de vuln\u00e9rabilit\u00e9 diff\u00e9rent. Premi\u00e8rement, \u00e9tant donn\u00e9 que le code source est un actif tr\u00e8s fuyant, destin\u00e9 \u00e0 \u00eatre clon\u00e9, extrait et bifurqu\u00e9 sur plusieurs machines tr\u00e8s fr\u00e9quemment, les secrets sont \u00e9galement fuyants. Mais, plus inqui\u00e9tant, n’oublions pas que le code a aussi une m\u00e9moire. <\/p>\n Toute base de code est g\u00e9r\u00e9e avec une sorte de syst\u00e8me de contr\u00f4le de version (VCS), conservant une chronologie historique de toutes les modifications qui y ont \u00e9t\u00e9 apport\u00e9es, parfois sur des d\u00e9cennies. Le probl\u00e8me est que des secrets encore valides peuvent se cacher n’importe o\u00f9 sur cette chronologie, ouvrant une nouvelle dimension \u00e0 la surface d’attaque. Malheureusement, la plupart des analyses de s\u00e9curit\u00e9 ne sont effectu\u00e9es que sur l’\u00e9tat actuel, pr\u00eat \u00e0 \u00eatre d\u00e9ploy\u00e9, d’une base de code. En d’autres termes, lorsqu’il s’agit d’informations d’identification vivant dans un ancien commit ou m\u00eame une branche jamais d\u00e9ploy\u00e9e, ces outils sont totalement aveugles.<\/p>\n L’ann\u00e9e derni\u00e8re, surveillant les commits pouss\u00e9s vers GitHub en temps r\u00e9el, GitGuardian d\u00e9tect\u00e9 plus de 6 millions de secrets divulgu\u00e9s<\/a>doublant le nombre par rapport \u00e0 2020. En moyenne, 3 commits sur 1 000 contenaient un identifiant, ce qui est cinquante pour cent plus \u00e9lev\u00e9 que l’ann\u00e9e derni\u00e8re. <\/p>\n Une grande partie de ces secrets donnait acc\u00e8s aux ressources de l’entreprise. Il n’est donc pas \u00e9tonnant qu’un attaquant cherchant \u00e0 s’implanter dans un syst\u00e8me d’entreprise examine d’abord ses r\u00e9f\u00e9rentiels publics sur GitHub, puis ceux appartenant \u00e0 ses employ\u00e9s. De nombreux d\u00e9veloppeurs utilisent GitHub pour des projets personnels et peuvent divulguer par erreur des informations d’identification d’entreprise (oui, cela arrive r\u00e9guli\u00e8rement !). <\/p>\n Avec des informations d’identification d’entreprise valides, les attaquants agissent en tant qu’utilisateurs autoris\u00e9s et la d\u00e9tection des abus devient difficile. Le temps n\u00e9cessaire pour qu’un identifiant soit compromis apr\u00e8s avoir \u00e9t\u00e9 pouss\u00e9 vers GitHub n’est que de 4 secondes, ce qui signifie qu’il doit \u00eatre imm\u00e9diatement r\u00e9voqu\u00e9 et tourn\u00e9 pour neutraliser le risque de violation. Par culpabilit\u00e9 ou par manque de connaissances techniques, on comprend pourquoi les gens prennent souvent le mauvais chemin<\/a> pour sortir de cette situation.<\/p>\n Une autre mauvaise erreur pour les entreprises serait de tol\u00e9rer la pr\u00e9sence de secrets dans des r\u00e9f\u00e9rentiels non publics. Le rapport State of Secrets Sprawl de GitGuardian met en \u00e9vidence le fait que les r\u00e9f\u00e9rentiels priv\u00e9s cachent beaucoup plus de secrets que leur \u00e9quivalent public. L’hypoth\u00e8se ici est que les r\u00e9f\u00e9rentiels priv\u00e9s donnent aux propri\u00e9taires un faux sentiment de s\u00e9curit\u00e9, les rendant un peu moins pr\u00e9occup\u00e9s par les secrets potentiels qui se cachent dans la base de code.<\/p>\n C’est ignorer le fait que ces secrets oubli\u00e9s pourraient un jour avoir un impact d\u00e9vastateur s’ils sont r\u00e9colt\u00e9s par des pirates. <\/p>\n Pour \u00eatre juste, les \u00e9quipes de s\u00e9curit\u00e9 des applications sont bien conscientes du probl\u00e8me. Mais la quantit\u00e9 de travail \u00e0 faire pour enqu\u00eater, r\u00e9voquer et faire pivoter les secrets commis chaque semaine, ou creuser \u00e0 travers des ann\u00e9es de territoire inexplor\u00e9, est tout simplement \u00e9crasante.<\/p>\n Cependant, il y a urgence. Les pirates recherchent activement des \u00ab idiots \u00bb sur GitHub, qui sont des mod\u00e8les facilement reconnaissables pour identifier les secrets divulgu\u00e9s. Et GitHub n’est pas le seul endroit o\u00f9 ils peuvent \u00eatre 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.<\/p>\n Pour preuve, il suffit de regarder les failles r\u00e9cemment r\u00e9v\u00e9l\u00e9es : favori de nombreux projets open-source, Codecov est un outil de couverture de code. L’ann\u00e9e derni\u00e8re, il a \u00e9t\u00e9 compromis par des attaquants qui y ont eu acc\u00e8s en extrayant un identifiant de compte cloud statique de son image Docker officielle. Apr\u00e8s avoir r\u00e9ussi \u00e0 acc\u00e9der au r\u00e9f\u00e9rentiel de code source officiel, ils ont pu alt\u00e9rer un script CI et r\u00e9colter des centaines de secrets \u00e0 partir de la base d’utilisateurs de Codecov. <\/p>\nQu’est-ce qu’un secret ?<\/h2>\n
Six millions de secrets transmis \u00e0 GitHub<\/h2>\n
Violations de titre… et le reste<\/h2>\n