Le 29 mars dernier, nous avons assisté à la révélation d'un des complots les plus fous d'infiltration informatique. Un développeur a pendant trois ans infiltré la communauté d'un des logiciels les plus utilisés au monde. Son but ? Installer du code malveillant.
Une porte dérobée dans un programme utilisé par plus de 100 millions de personnes. Son nom ? XZ. Il vous dit probablement rien, pourtant sans même que vous soyez au courant, il est partout. XZ, c'est une brique de base de l'informatique.
Il sert à la compression de fichiers et est utilisé par énormément d'autres programmes. De façon automatique, XZ est téléchargé des millions de fois. Alors comment s'en est-on rendu compte ? Une utilisation anormalement élevée du CPU qui serait passée inaperçue pour le commun des mortels.
Sans cette petite découverte, les conséquences auraient été d'ordre mondial. Et aujourd'hui, une question brûle les lèvres de tout le monde. Qui est ce mystérieux développeur, dénommé Giantan, qui se cache derrière l'attaque ?
Cette attaque est l'une des plus sournoises et sophistiquées qu'on ait pu observer. Pourtant, à peu près tous les pays de l'Union Européenne ont été touchés par cette attaque. Dans le petit milieu tech, peu de gens savent ce qui s'est réellement passé.
Alors on va reprendre aux bases. C'est quoi XZ ? Pourquoi s'y attaquer ? Et qu'est-ce qui rend cette attaque absolument unique ?
Et ensuite, on va pouvoir comprendre comment la porte dérobée a été découverte et comment on a tenté d'identifier le commanditaire. Laissez-moi vous présenter notre premier protagoniste, Andres Frund. Il est ingénieur chez Microsoft.
Fin mars dernier, il fait des tests de performance de l'outil sur lequel il travaille. Son but, traquer tout ce qui peut ralentir son programme informatique pour l'optimiser le plus possible. C'est ce qu'on appelle du micro-benchmarking.
Ce jour-là, il observe un petit délai inhabituel dans un processus normalement... très bien rodés. Et durant ce délai, il constate que le processeur de son ordinateur utilise davantage de ressources que d'habitude.
Alors, il mesure. Et il s'aperçoit qu'il y a un délai de 500 millisecondes exactement. André Spreun commence à enquêter. Et il découvre que cette latence n'est pas provoquée par son propre programme, mais par un programme extérieur, installé sur sa machine SSH.
C'est un outil très connu pour établir une connexion sécurisée et chiffrée entre deux ordinateurs distants. SSH, c'est une des commandes les plus utilisées au monde. Si vous êtes développeur, vous l'avez forcément déjà employé, parfois plusieurs fois par jour.
Donc, avoir été capable de détecter un délai de 500 millisecondes sur un outil du quotidien comme SSH, c'est assez fou. Mais si André Sfren l'a décelé, ça n'est que parce qu'il était dans une phase de mesure pour chasser les millisecondes en trop. Et d'ailleurs, il ne s'arrête pas là. Il se demande quel changement il y a pu avoir entre ces tests d'il y a quelques jours, sans délai, et les tests d'aujourd'hui avec un délai de 500 millisecondes. Et son acharnement va finir par payer, car il va finir par trouver.
Dans sa version de Debian, sa distribution Linux fraîchement mise à jour, il va faire une découverte stupéfiante. Une porte dérobée. Une backdoor introduite dans le code de l'outil XZ.
à l'origine de ce délai de 500 millisecondes. Depuis la dernière fois, il n'a rien fait. Pas téléchargé de logiciels craqués ni de pièces jointes bizarres. Juste, il a mis à jour son système.
Pour comprendre pourquoi c'est particulièrement perturbant, il faut qu'on se penche sur le fonctionnement de Linux. On parle de Debian, sa distribution Linux, parce que Linux n'est qu'un noyau, et ça a son importance dans l'histoire. Le noyau Linux, c'est la base, le cœur du système.
Mais si vous n'êtes pas développeur, vous n'en ferez pas grand-chose. Par contre, ce noyau est accessible librement à tous, et c'est pourquoi nombre de distributions Linux ont vu le jour. Vous n'installez jamais Linux en soi, mais une distribution comme Ubuntu, Debian, Fedora.
Contrairement à Windows, où les logiciels sont téléchargeables sur Internet, la plupart des distributions intègrent un gestionnaire de paquets pour gérer l'installation des logiciels. Le principe est simple. Quand vous installez une appli, elle peut avoir des dépendances à d'autres logiciels. Par exemple, au hasard, avoir besoin de XZ.
Dans ce cas, vous n'aurez rien à faire de plus. Le gestionnaire va s'occuper d'installer automatiquement les dépendances nécessaires et les mettre à jour au fil du temps. Et vous l'aurez compris, XZ est installé 99% du temps.
Revenons-en à la découverte de Andres Freund. Cet outil de compression XZ est intégré nativement dans les plus grosses distributions Linux du monde. Installé...
automatiquement sur des dizaines de millions d'ordinateurs dans quasiment tous les data centers du monde et sur les serveurs comme ceux de vos banques ou du gouvernement. Cette porte dérobée, si elle est utilisée de façon malveillante, pourrait avoir un terrible impact, un impact mondial. Ni une ni deux, Andrés Froen poste un message sur une liste de mails dédiée à la sécurité des logiciels open source pour avertir la communauté.
Sa découverte fait l'effet d'une bombe. Fin mars, tout le monde en parle. Parce que cette attaque est inimaginable. L'open source, par définition, c'est un livre ouvert. Tout ce qu'on y fait est public.
Tout le monde a accès au code des logiciels, on sait qui contribue au code, qui fait des modifications, qui les accepte. Bref, c'est la définition de la transparence. C'est un univers qui me fascine.
Dans Underscore, le talk show que je présente, j'ai eu la chance de rencontrer des acteurs majeurs de l'open source, comme JBKM, fédérés VLC, mais aussi d'autres comme un développeur qui a monté une entreprise valorisée à plusieurs milliards en produisant du code majoritairement open source. Cette boîte, c'est Odoo. Et je suis donc ravi qu'ils sponsorisent cette vidéo. Odoo, c'est plusieurs dizaines d'applications qui ont chacune des usages bien distincts, comme une de facturation, une de gestion de projet, de comptabilité et d'e-commerce.
Mais la vraie force d'Odoo, c'est que Toutes ces applis communiquent entre elles. Par exemple, l'app e-commerce peut enregistrer une vente sur votre site, générer la facture automatiquement dans l'appli de facturation qui sera ensuite envoyée automatiquement à l'appli de comptabilité. Et cette magie n'est possible que grâce à l'écosystème de la plateforme Odoo.
Si vous voulez tester doucement cette océante possibilité, je vous conseille de choisir une première appli qui répond à un de vos besoins, comme l'appli de facturation pour générer vos factures par exemple, sachant que la première est gratuite. Et ensuite, c'est un abonnement unique à 19,90 euros par mois pour toutes les autres. Je vous mets un lien en description pour demander une démo personnalisée ou essayez par vous-même. Si on revient à XZ, cette ouverture, ça voudrait dire que quelqu'un, au nez et à la barbe de tout le monde, a réussi à introduire cette backdoor. C'est une humiliation et un véritable séisme parce que l'open source est une machine rodée depuis des années.
Elle fonctionne très bien et est à l'origine des logiciels les plus sécurisés qui existent. Justement parce que n'importe quel expert... peut auditer le code, faire des suggestions pour améliorer la sécurité et si besoin, tirer la sonnette d'alarme en cas de faille critique.
Et c'est dans ces conditions que l'attaquant a tout de même réussi à installer une porte dérobée dans un logiciel open source. C'est littéralement mission impossible et pourtant il y est parvenu. Mais ça veut aussi dire qu'on va pouvoir analyser tout le code pour voir d'où vient la faille.
Alors il faut mener l'enquête et commencer à l'origine de la découverte. Grâce à André Sprund, cet ingénieur de chez Microsoft qui a détecté un délai de 500 millisecondes, on va pouvoir analyser et retrouver tout ce qu'il y a dans le code de cet outil XZ et refaire la chronologie des événements jusqu'à l'installation de la backdoor. La première étape, qui peut paraître étrange, c'est d'analyser l'historique du développeur en chef du projet, Las Collines.
On a déjà vu par le passé des développeurs péter un plomb, des sabotages purs et simples de logiciels open source, pour tout un tas de raisons. personnelle, financière ou même revendicative. Mais ici, en analysant les modifications du code de XZ et qui les a écrites, on s'aperçoit rapidement que la scoline n'y est pour rien.
C'est un autre contributeur qui ressort. Djan Tan. C'est lui, le traître.
C'est lui qui a installé la Bac d'Or. Il y a donc une solution toute simple. À notre mystère, il n'y a plus qu'à remonter jusqu'à Djan Tan.
Sauf que Djan Tan n'existe probablement pas. En tout cas, pas sous ce nom. Il faut savoir que dans la communauté open source, l'anonymat est quelque chose de plutôt naturel.
Et à la base, c'est plutôt une bonne chose. Chacun est libre de participer comme il veut et la réussite est davantage fondée sur l'accomplissement des projets plutôt que sur un nom, un poste ou une posture de manager par exemple. On ne sait donc pas précisément qui est Giantan.
Mais ça n'est pas perdu pour autant. On laisse toutes et tous des traces sur Internet. Et avec une armée d'enquêteurs bénévoles prêts à remonter la piste de Giantan, La chasse est ouverte. Alors, non sans mal, des valeureux aventuriers du net ont analysé tout ce qu'a pu produire Giantan pour des logiciels open source.
Et il y a des choses intéressantes. La première modification de code qu'il soumet à un projet open source, c'est en 2021. Et déjà à l'époque, c'est un peu suspect. Il demande le remplacement d'une fonction par la même fonction, mais moins sécurisée. Sa modification sera validée par la communauté, mais au final, ça n'a eu aucun impact. Sur cette entrée en matière, on pourrait croire que Janta n'est juste un enfoiré, très peu discret, mais en fait, c'est pas si évident.
Entre 2021 et 2024, il va soumettre plus de 6000 changements de code sur 7 projets open source différents. Et sur ces 6000... La plupart sont tout à fait légitimes. En réalité, Jian Tan est un bon développeur. Il n'y avait donc aucune raison de le discréditer jusqu'à aujourd'hui.
Durant ces trois années, en plus de participer au développement, Jian Tan échange des mails avec les autres contributeurs. Comme ça se fait souvent sur des boucles de mails, en public d'ailleurs, on peut les consulter librement. En trois ans, Jian Tan se construit assez naturellement un historique dans le milieu.
Une crédibilité, une réputation pour son futur piratage. Mais je vous rassure, être un bon développeur et participer à différents projets ne suffit pas à les compromettre. Ce serait trop simple. Certes, on peut tous participer au développement de ces logiciels, mais on ne peut pas faire n'importe quoi non plus.
Vous pouvez proposer une pull request, une modification ou un ajout du code en expliquant pourquoi c'est pertinent selon vous. Les responsables du projet vont l'examiner et s'ils sont d'accord, si vous avez bien travaillé, ils vont l'accepter. On dit qu'ils mergent la pull request à l'ensemble du projet. En bref, vous contribuez, mais votre pouvoir de nuisance est tout de même très limité en l'état et soumis à la confiance des responsables. Ce qu'il faut pour que Diantan puisse mettre son plan à exécution, c'est d'être à la tête d'un projet open source, en plus d'être extrêmement discret et malin.
Et malin, Diantan l'est. Car pendant longtemps, il n'a rien fait de mal. Mais ce qui va suivre est très troublant. En mai 2022, un certain Giliard-Kumar se plaint sur la mailing list du manque de réactivité de Las Collines.
le mainteneur de XZ. Il se demande pourquoi le patch n'a pas été accepté. Pourquoi aucune réponse n'est donnée ? Ça ralentit tout le projet.
Car oui, un logiciel aussi central que XZ, inclus dans des millions d'ordinateurs fonctionnant sur Linux et même sur Mac, est maintenu par une unique personne. Et cette personne est pénévole. C'est cette absurdité que Giantan va parvenir à exploiter très intelligemment.
Mais cette absurdité n'est en soi pas unique à XZ, et c'est un des grands problèmes de l'open source, qui revient régulièrement sur la table. Pour rester à jour et ne pas compromettre la sécurité, un logiciel doit forcément être maintenu. Ça demande du temps, surtout quand on sait que tout le monde peut soumettre des modifications dans le code.
Il faut donc être en mesure de répondre aux demandes des développeurs, et potentiellement faire évoluer son code pour le maintenir à jour et sécurisé. Ce travail est généralement fait bénévolement pendant des années par le développeur originel du projet. Pour XZ, Laskolin est le seul à pouvoir faire ce travail. C'est le créateur et le mainteneur principal du projet. Mais après 20 ans à le faire quasiment bénévolement, Laskolin est crevé.
Il le dit dans un mail de réponse à Giguard-Cumart, qui s'est plaint de la lenteur du processus. Il est toujours passionné, mais il rappelle qu'il fait ça bénévolement, pour le loisir, et qu'en ce moment, il a des soucis de santé mentale. Il n'a quasiment plus le temps de s'en occuper, et la seule façon de faire avancer son projet selon lui serait d'embaucher. un nouveau mainteneur.
Quelqu'un qui serait capable de faire avancer le projet avec lui. Et il évoque dans ce mail Diatan. S'ensuit des échanges de mail entre Jigar Kumar et Dennis Enns, un autre développeur qui participe à la conversation.
Les deux développeurs font monter la pression auprès de Laskolin pour ajouter un co-maintenant au projet XZ. Lorsque je consulte le journal Git, je vois qu'il n'a pas été mis à jour depuis plus d'un an. Il n'y aura pas de progrès tant qu'il n'y aura pas de nouveau responsable.
Le mainteneur actuel s'est désintéressé ou n'a plus envie de maintenir. C'est triste d'avoir trois repos comme celui-ci. Je n'ai pas perdu mon intérêt, mais ma capacité à m'occuper de la question a été assez limitée, principalement aux raisons de problèmes de santé mentale.
Récemment, j'ai un peu travaillé en privé avec Jatan sur XZutils. Peut-être qu'il aura un rôle plus important à l'avenir. Il est également bon de garder à l'esprit qu'il s'agit d'un projet de loisir non rémunéré.
La seule chose qui a bougé depuis avril, ce sont des changements insignifiants. Vous laissez pourrir une tonne de collectifs. Vous êtes en train d'asphyxier votre repo. Je suis désolé pour vos problèmes de santé mentale, mais il est important d'être conscient de ses propres limites.
Je comprends qu'il s'agit d'un projet de loisir pour tous les contributeurs, mais la communauté veut plus. Pourquoi ne pas céder la maintenance de XZ ? Comme je l'ai déjà laissé entendre dans les mails précédents, Giatan pourra avoir un rôle plus important à l'avenir.
Il a déjà beaucoup aidé en privé et est déjà pratiquement co-maintenant. Quoi qu'il en soit, un changement de mainteneur est déjà en cours. Giga Kumar et Dennis Hens mettent la pression à Las Collins pour qu'il passe le flambeau. Après ça, on les reverra d'ailleurs.
plus jamais sur le net. La probabilité pour qu'il soit en réalité des identités fictives derrière lesquelles se cache Giatan pour faire plier Laskolin est tout à fait plausible. Quoi qu'il en soit, la stratégie fonctionne. Trois jours après cet échange de mail, Giatan est nommé co-maintenant du projet par Laskolin. Giatan devient alors un contributeur régulier de XZ, le deuxième le plus actif après Laskolin.
Au fil des mois, il installe une certaine confiance avec Laskolin et petit à petit, il obtient de plus en plus de responsabilités et d'accès. En janvier 2023, il fait son premier merge de commit, c'est-à-dire qu'il prend la décision de faire avancer le développement et de valider des modifications du code pour en sortir une nouvelle version. En mars de la même année, il obtient les accès pour changer le mail de contact de OSS Fuzz, une plateforme qui vise à rendre les logiciels open source critiques.
plus sûr. C'est un changement important parce que s'il y a un problème détecté sur XZ par cette communauté de sécurité, on va envoyer un mail au mainteneur. Donc plus Laskolin, mais désormais Jiatan. Derrière ces importants jalons dans le plan de Jiatan, lui donnant quasiment les pleins pouvoirs sur XZ, il entreprend des actions pour supprimer les sécurités qui pourraient dans le futur le gêner. Et notamment dans OSS Fuzz, il met en place le code qui permettra d'accueillir la backdoor.
Petit bout par petit bout. Il demande des changements d'URL des sites internet. Il change d'hébergeur.
Tout ça dans le but d'avoir un maximum de contrôle. Il avait le contrôle sur le code, désormais il a le contrôle sur l'infrastructure et l'hébergement du code. Ainsi, si jamais il y a des alertes qui se mettent à sonner à cause de problèmes de sécurité, il peut les ignorer sans que la scoline s'en aperçoive. Tous ces changements...
Il ne les fait pas seul, il conserve la confiance de l'ASCOLIN et de la communauté. Après tout, il est officiellement co-maintenant. Personne ne se doute de rien. Enfin, le 23 février et le 9 mars, au milieu de changements dans le code tout à fait légitime, dans des fichiers de test, est introduite la BAC d'or.
Non seulement Giatan s'est infiltrée pendant plus de deux ans pour mettre à bien son attaque, mais en plus elle est extrêmement bien pensée d'un point de vue technique. Car en réalité, faire une porte dérobée, c'est hyper simple. En trois lignes de code et quelques secondes, je pourrais en injecter une dans un logiciel propriétaire.
A l'inverse, ce qui relève de la prouesse technique, c'est de parvenir à le cacher dans du code accessible au monde entier, qui vérifie minutieusement chaque ligne de code. Pour ça, il va imaginer un système complexe à trois étages. Du code malicieux compilé est caché dans un fichier corrompu, déguisé comme un fichier de test.
Au moment de la compilation, une macro en modifie certains octets pour le réparer et en extrait un script qui va lui-même récupérer un bout d'un autre fichier, le déchiffrer et l'ajouter au fichier compilé final. C'est génial. Et surtout, on aurait sûrement mis des années avant de détecter quoi que ce soit. Le deuxième défi auquel confrontait Jiatan, c'est qu'il ne veut pas faire une simple backdoor. Son code malicieux ne doit s'exécuter que dans des conditions bien précises.
Ce doit être un code dormant, qui permet de faire des attaques ciblées et qui sont utilisables uniquement par lui ou par ceux qu'il emploie. Et ça, c'est loin d'être évident. La plupart des botnets ou des chevaux de roi, à partir du moment où ils s'exécutent, sont eux-mêmes à l'initiative d'ouvrir une porte dérobée.
Je clique sur un malware, il se connecte au serveur pirate, qui peut maintenant exécuter des instructions. Le malware peut être configuré pour s'exécuter uniquement sous certaines conditions. Mais globalement, il y a toujours, à un moment ou un autre, une requête réseau qui part de la machine infectée. Et ça, ça se voit. Enfin, quand tu cibles des millions d'ordis, ça finit par se voir.
Et c'est là qu'on comprend que la cible de Jiatan n'a absolument pas été choisie au hasard. Car XZ, on l'a mentionné, est utilisée par SSH. Donc, Jiatan...
n'a pas besoin de démarrer un programme de contrôle à distance. Quand il est dans SSH, il est dans un programme de contrôle à distance. Ce qu'il fait, c'est de modifier le processus de vérification de la clé SSH pour qu'elle continue à faire son travail exactement comme d'habitude, sauf si elle voit passer une clé très précise, la clé des pirates. C'est un peu comme dans un hôtel.
Si vous voulez pouvoir cambrioler n'importe quelle chambre, soit vous recruter toute l'équipe de ménage qui peut vous ouvrir de l'intérieur, Pas très discret, soit vous avez un badge hacké universel qui ouvre toutes les portes de l'extérieur. En résumé, il peut prendre le contrôle à distance de toute machine infectée sans que la victime ne soit au courant, sans qu'aucune fenêtre ne s'affiche. C'est absolument dingue, c'est de la haute voltige en matière de piratage et d'infiltration. Et c'est pas tout, cette attaque est encore plus aboutie que vous ne le pensez. L'attaque ne se déclenche pas à chaque fois, elle est installée uniquement sur des versions bien particulières d'ordinateurs.
Par exemple, elle vise uniquement des systèmes d'exploitation Debian ou une distribution dérivée de Debian et Red Hat. En clair, c'est une attaque ciblée. Si l'ordinateur ne correspond pas à la cible, la porte dérobée ne s'installe pas.
C'est un signe de discrétion de la part de Jiatana. L'attaque est plus difficile à détecter et surtout, c'est une façon de faire qui en dit beaucoup sur la sophistication de l'attaque. Mais ça n'est pas tout. Les chercheurs qui ont analysé la porte dérobée ont découvert une subtilité absolument incroyable. La faille, la porte dérobée, n'est pas dans le code source original du projet.
Pour le comprendre, il faut que je vous explique le processus de déploiement d'un projet open source. Dans un premier temps, les développeurs font des changements dans le code sur GitHub. À un moment, le mainteneur, le chef du projet, va juger que toutes les nouveautés rassemblées, ça constitue une nouvelle version, prête à être envoyée à tous les ordinateurs du monde qui ont installé ce logiciel. Sauf que pour XZ, c'est un peu différent.
C'est un outil tellement utilisé qu'il est directement intégré dans bon nombre de systèmes d'exploitation. Donc XZ est en contact direct avec les développeurs de diverses distributions Linux, comme Debian. A chaque nouvelle version, ils l'envoient aux équipes de Debian et en interne, ils vont s'assurer que la mise à jour ne casse rien. C'est toute une chaîne qui prend plusieurs mois avant de se répercuter sur votre ordinateur chez vous. Et ça, c'est pour un seul logiciel.
Les développeurs de systèmes d'exploitation doivent faire cette procédure avec des centaines d'outils open source. Si chacun de ces outils lui envoie son code source tel quel, c'est une immense galère pour eux. Alors la solution trouvée, c'est d'envoyer des versions packagées du code source, prêtes à l'emploi pour les distributions Linux.
Ça s'appelle des tarballs. Et très ironiquement, on se sert de... XZ pour compresser ses fichiers.
Là où Jiatan est extrêmement malin, c'est que la porte dérobée est présente dans les versions packagées du code et envoyées aux distributions Linux. Vous ne la trouverez pas dans le code source de GitHub. Ça ne veut pas dire qu'elle est indétectable, mais quand même, Jiatan a pensé à tout. Dans notre malheur, il y a eu un miracle. La porte dérobée a été détectée un mois après son implémentation dans certaines distributions Linux.
Mais heureusement, il s'agissait de versions encore en test. Et c'est une de ces versions que Andres Freud utilisait lorsqu'il a découvert les 500 millisecondes de délai et la porte dérobée. Elle a été découverte au bon moment, et grâce à une chance inouïe, son impact a été limité.
Mais ça s'est joué à rien. Quelques semaines plus tard, courant avril, la version 40 de Fedora, une autre distribution Linux concernée, était prévue pour sortir de sa version test et être envoyée à la planète entière, avec à l'intérieur... XZ infecté de sa backdoor.
Après deux ans d'infiltration, il faut s'imaginer le sum de Jian Tan à cet instant précis. Pendant ce temps, les passionnés, les experts et la communauté open source ont ont continué l'enquête autour de son identité. On apprend alors que Jiantan est très bon pour assurer sa propre sécurité.
C'est ce qu'on appelle l'obstacle pour sécurité opérationnelle. Ce sont toutes les méthodes pour se protéger soi-même des informations sensibles au personnel qu'on peut laisser sur Internet. Les experts s'accordent à le dire, plus le temps est long, plus on garde une même identité et un même pseudo longtemps, plus il est difficile de ne laisser aucune trace. Mais pas pour Jiantan. Applaudissements À part ce qui est nécessairement public pour développer du code open source, c'est-à-dire du code et des mails, il n'y a absolument aucune trace de lui.
Rien. Beaucoup y verraient une mauvaise nouvelle pour remonter jusqu'à Jiatan, et c'est vrai. Mais certains y voient aussi un potentiel indice.
D'après eux, derrière Jiatan se cacherait potentiellement une attaque étatique. Pourquoi on soupçonne un état d'être derrière Giatan ? Premièrement, pour la complexité de l'attaque. C'est ce qu'on appelle une attaque supply chain.
Elle a nécessité plusieurs années d'infiltration. Au lieu de s'attaquer directement à Windows, par exemple, et y trouver une faille, les attaquants vont chercher à s'attaquer à un logiciel plus petit, mais avec la même portée mondiale. Jean-Baptiste Kempf, mainteneur principal de VLC, nous racontait sur Underscore qu'il devait être très attentif à ce type d'attaque.
Ils ont déjà été pris pour cible. Il y a un contributeur qui avait contribué depuis quelques mois, des petits patches. Il envoie un patch qui est un peu plus conséquent et ça m'a fait tiquer. J'ai regardé et j'ai fait, t'es sûr que tu fais ça comme ça ?
Tu devrais l'architecturer. Et quand j'ai dit, il a fait des trucs, il y avait une partie qui ne bougeait pas trop, qui était la partie qui me gênait le plus. Et quand j'ai fait la remarque, il est parti. Ce type d'attaque n'est pas courante dans le monde du cybercrime, car d'une rare complexité à mettre en œuvre pour des résultats très incertains. L'exemple le plus connu est très certainement celui de SolarWinds en 2020, un logiciel américain dont les serveurs des mises à jour ont été infiltrés.
Résultat des courses, les attaquants ont pu installer une backdoor dans les nouvelles versions du logiciel, déployée à plus de 33 000 clients. Parmi eux, de nombreux services du gouvernement américain. A savoir qui est derrière cette attaque, il n'y a pas eu officiellement d'attribution, mais le secrétaire d'état des Etats-Unis pense qu'il s'agit des Russes, pour le compte du SVR, leur service de renseignement. En fait, ces attaques d'une telle envergure sont si complexes à mettre en place que les seuls exemples connus sont très certainement liés à des hackers d'Etat.
Dans notre liste de suspects capables de réaliser une attaque supply chain de cette ampleur, nécessitant deux ans d'infiltration, on peut compter les Etats-Unis, la Chine, la Russie, la Corée du Nord et quelques autres suspects moins probables comme Israël. Déjà, les Etats-Unis ont assez vite été écartés pour une raison complètement what the fuck. La fonction cryptographique utilisée dans l'attaque de SSH n'est pas quantique-proof.
C'est-à-dire qu'elle n'est pas résistante aux futures attaques quantiques. Et d'après certains observateurs, si les Etats-Unis étaient à l'œuvre, ils auraient utilisé un algorithme de chiffrement quantique-proof. C'est leur signature.
Parce qu'ils sont américains. Pour les autres suspects, je vous l'ai dit, on n'a pas beaucoup d'éléments à analyser. Mais le peu qu'on a a été disséqué par les experts du secteur. Non pour essayer de savoir qui est Jiatan, mais plutôt où est Jiatan.
D'où pouvait-il bien opérer ? Des recherches aux int ont été effectuées, de l'investigation en source ouverte, notamment sur son activité GitHub et les métadonnées laissées derrière lui. Tout ce qu'on a trouvé, c'est qu'à priori, il utilisait un VPN, ou Utopia, pour se localiser à Singapour.
Et ça ne nous aide pas vraiment avec un VPN, il peut être n'importe où. Alors la communauté d'enquêteurs a eu une autre idée. A quelle heure travaillait-il ? Ça pourrait nous donner des indications sur son fuseau horaire. Et la très grande majorité de ces commits, ces changements de code, sont redatés à UTC plus 8. C'est le fuseau horaire de la Sibérie, de l'Indonésie, des Philippines, de l'Ouest Australien et de la Chine, à une heure de la Corée du Nord.
Sauf que, si vous êtes développeur, vous le savez peut-être, les heures de commit, ça se modifie, à l'aide de deux petites variables d'environnement. On peut même les modifier à postériori de l'envoi d'un commit. En pratique, c'est très dur de rester crédible et cohérent avec cette méthode sans que ça ne se remarque un moment ou un autre, surtout sur deux ans. Il y a plusieurs thèses à ce sujet sur internet.
Toutes ne concordent pas, mais une d'entre elles est particulièrement intéressante et selon moi crédible. Pour cacher d'où il travaille, Jihata n'aurait très bien pu changer le fuseau horaire de son ordinateur. tout simplement, et le configurer manuellement à UTC plus 8. Selon les spécialistes de l'Obssec, c'est une façon beaucoup plus simple, efficace et constante sur le long terme, tout en brouillant les pistes.
Sauf que, Diatan est faillible. A plusieurs reprises, on le soupçonne d'avoir oublié de changer son fuseau horaire. Je vous le disais, la très grande majorité de ces comites sont horodatées à UTC plus 8. Mais une poignée d'entre eux, 9 très exactement, sont horodatées à UTC plus 2 ou plus 3, en fonction de si c'est l'heure d'hiver ou l'heure d'été.
Vous me direz, il a le droit de voyager ? Sauf qu'à deux reprises, c'est physiquement impossible. Le 6 octobre 2022 et le 27 juin 2023, on observe des différences de quelques minutes d'intervalle entre un comite à UTC plus 8 et un comite à UTC plus 2. Même avec un avion supersonique, il faudrait revoir les lois de la physique pour y parvenir. Impossible d'être sûr à 100%, mais on pense que Diatan était à 9 comites près d'être le cybercriminel parfait avant de laisser échapper son véritable fuseau horaire. Ce qui est certain par contre, c'est que ces deux jours-là, Diatan a forcément trafiqué quelque chose de pas net.
Surtout, et c'est là que ça devient intéressant, ce fuseau horaire, couplé à ses heures de comite, coïncide totalement avec une journée classique de travail, 9h-18h. La plupart du temps en semaine, mais pas uniquement. Plus intéressant encore, les jours où il ne travaille pas correspondent bien mieux à un emploi du temps de l'Europe de l'Est plutôt qu'à la Chine.
On le voit travailler sur certains jours off en Chine. Et Dieu sait que les quelques congés, notamment autour du nouvel an chinois, sont respectés là-bas. S'il était chinois, ce serait très surprenant de le voir travailler sur ces jours précis du calendrier chinois.
Et pourtant, c'est le cas de Jiatan. Tout ce faisceau d'indices, amassé par de braves enquêteurs à la sueur de leur front, semble converger vers le fuseau horaire UTC plus 2 ou plus 3, en fonction de la saison. Il correspond à l'Europe de l'Est, Israël ou Moscou.
Giatan pourrait totalement correspondre à la signature du SVR et de leur groupe de hackers APT29. Les mêmes soupçons qui pèsent sur la cyberattaque entre SolarWinds. Évidemment, sans certitude.
Tout ce que je peux vous dire, c'est qu'aujourd'hui, nous n'avons plus aucune trace de Giatan. Il a disparu. Mais les spécialistes s'accordent à le dire, il y aura d'autres Djihadans, des fervents contributeurs open source derrière lesquels se cachent secrètement les agissements d'un gouvernement. Peut-être même que si on a découvert cette attaque, c'est qu'il y en a eu d'autres qui ont réussi et qu'au fond de votre système, il y a des failles dormantes.