Porte dérobée SSH
Un responsable néfaste ou compromis a inséré un comportement malveillant dans une bibliothèque nommée liblzma, qui fait partie des outils et bibliothèques de compression xz, ce qui entraîne une porte dérobée dans SSH. Il s'agit d'une attaque avancée de la chaîne d'approvisionnement logicielle, car la bibliothèque a été intentionnellement modifiée pour la porte dérobée, avec des techniques d'obscurcissement et de furtivité pour cacher la charge utile de l'attaque aux évaluateurs. Elle a été découverte et divulguée récemment (le 29 mars dernier), et le traitement de l'attaque est en cours. Cependant, elle a été rapidement contenue car elle semble affecter uniquement les versions préliminaires d'un ensemble limité d'environnements (packages DEB et RPM, pour l'architecture x86_64, et compilés avec GCC). Quoi qu'il en soit, la CVE a reçu un Score de base CVSS de 10, réservé aux vulnérabilités de cybersécurité les plus critiques. Si cette vulnérabilité était intégrée aux distributions stables, son impact serait considérable. L'analyse technique de l'attaque, y compris la La porte dérobée xz expliquée en détail, a été analysé ailleurs. Cet article se concentrera sur la chronologie de l'attaque, la manière dont elle a pu être détectée, la manière dont l'incident a été géré jusqu'à présent et les leçons qui peuvent être tirées de l'attaque.Comment la porte dérobée XZ a été injectée
Remarque : le dépôt git est dans git.tukaani.org. Toutefois, il y avait aussi un Dépôt hébergé GitHub (actuellement bloqué) où le compte GitHub publiait les modifications qui ont ensuite été intégrées dans le référentiel Git. Une partie de la porte dérobée semble se trouver uniquement dans les archives tar distribuées pour les versions 5.6.0 et 5.6.1, pas dans les référentiels git et repose sur un une seule ligne dans le build-to-host.m4 fichier de macro utilisé par autoconf. L'autre partie était dans deux supposés fichiers de test bad-3-corrupt_lzma2.xz et good-large_compressed.lzma qui étaient engagé par le compte GitHub « Jia Tan » (JiaT75) Dans le référentiel xz le 23 février. Il s'agissait d'un changement inoffensif ajoutant des fichiers de test (soi-disant blocs compressés .lzma et .xz). Chose intéressante, les fichiers de test n’ont pas été utilisés par les tests ! La ligne du fichier .m4 injecte un script obscurci (inclus dans l'archive tar) à exécuter à la fin de configure si certaines conditions correspondent. Il modifie le Makefile pour le liblzma bibliothèque pour contenir le code qui extrait les données du fichier .xz, qui se termine après la désobscurcissement dans ce scénario, est invoqué à la fin de configure. Il décide s'il faut modifier le processus de build pour injecter du code : uniquement sous GCC et l'éditeur de liens GCC, sous Debian ou rpm, et uniquement pour Linux x86_64. Lorsqu'il correspond, le code injecté intercepte l'exécution en remplaçant deux sifonc résolveurs afin que certains appels soient remplacés. Cela provoque l'analyse des tables de symboles en mémoire (cela prend du temps, ce qui a conduit à la détection, comme expliqué plus loin). Ensuite, les choses deviennent intéressantes : la porte dérobée installe un hook d'audit dans l'éditeur de liens dynamique, en attendant l'arrivée du symbole de fonction RSA_public_decrypt, qui est redirigé vers un point dans le code de la porte dérobée, qui à son tour rappelle libcrypto, probablement pour effectuer une authentification normale. Et la charge utile s'active si le programme en cours d'exécution porte le nom du processus /usr/sbin/sshd. Il était clair que les serveurs SSH étaient la cible. Traditionnellement, sshd les serveurs comme OpenSSH n'étaient pas liés à liblzma, mais sshd est souvent patché pour prendre en charge systemd-notify afin que d'autres services puissent démarrer lorsque sshd est en cours d'exécution. Et puis liblzma est indirectement chargé par systemd, fermant le cercle. La porte dérobée n’a pas encore été entièrement analysée, mais elle semble l’être. permettre l'exécution de commandes à distance (REC) avec les privilèges du démon sshd, exécuté dans un contexte de pré-authentification. Les informations du certificat distant, lorsqu'elles correspondent à la porte dérobée, sont déchiffrées avec ChaCha20, et lorsqu'elles sont déchiffrées avec succès, elles sont transmises au système(). Il s’agit donc essentiellement d’un RCE fermé, bien pire qu’un simple contournement de clé publique. Une archive tar 5.6.1 ultérieure a montré des efforts supplémentaires pour masquer les traces, ajoutant davantage d'obscurcissement pour les noms de symboles et essayant de corriger les erreurs observées. Un mécanisme d'extension où des fichiers de test supplémentaires ont été recherchés pour certaines signatures à ajouter à la porte dérobée, ils ont également été mis en place. Cette attaque assez sophistiquée pourrait passer inaperçue jusqu'à ce que des distributions Linux stables soient disponibles. Heureusement, certaines personnes aiment vérifier pourquoi des choses anormales se produisent.La découverte de l'attaque de porte dérobée XZ
Souvent, les comportements malveillants injectés sont découverts par hasard ou par accident. Un bon exemple était un avertissement de dépréciation (« Qui se soucie des avertissements ? ») qui a conduit à la découverte du attaque par flux d'événements en octobre 2018. Un autre est l'utilisateur qui a prévenu Codecov en avril 2021, leur script de téléchargement bash n'a pas réussi la somme de contrôle (« Qui vérifie l'intégrité des artefacts avec des sommes de contrôle » ?) Anomalies et symptômes étranges avec ssh logins (loginprend beaucoup de CPU et augmente le temps écoulé, erreurs valgrind) a éveillé la curiosité de Andrés Freund, un développeur PostgreSQL vigilant mais pas un analyste de sécurité (comme il l'a déclaré). Après quelques investigations avec OpenSSH sur Debian Sid, il a conclu qu'un problème de temps de réponse reposait sur une bibliothèque, liblzma, Une partie de l' xz-utils bibliothèque de compression. La raison: "le référentiel xz en amont et les archives tar xz ont été détournés». Ce diagnostic était si précis ! Le 29 mars 2024, Andres a publié dans Openwall la première analyse : «porte dérobée dans xz/liblzma en amont conduisant à une compromission du serveur ssh». Le fait : les archives XZ Utils 5.6.0 et 5.6.1 contiennent une porte dérobée. Ces archives tar ont été créées et signées par le compte Jia Tan susmentionné. He publié dans Mastodonte plus tard dans la journée, reconnaissant que la découverte était accidentelle et nécessitait de nombreuses coïncidences. Les commentaires des autres utilisateurs valent la peine d'être lus. Utilisateur GitHub le même (alias Sam James) a publié un joli Gist FAQ sur la porte dérobée xz-utils où l'attaque a été résumée, reliant plus analyses approfondies de la charge utile d’attaque. Ces analyses, techniquement juteuses, nous ont permis de mieux comprendre l'injection, qui était très élaborée :- xz/liblzma : Explication de l'obfuscation au niveau Bash. Belle analyse sur la désobfuscation par le script d'injection, en quatre « étapes ».
- Le fil bleu ciel de Filippo Valsorda Analyse de la porte dérobée elle-même dans RSA_public_decrypt, qui montre sa nature : un RCE, pas un contournement d'authentification, et fermée (accepte la clé privée de l'auteur et sinon, revient à un comportement normal) / non remboursable. L’auteur avait l’intention de faire profil bas pour éviter d’être détecté !
- Analyse de la porte dérobée XZ par @smx-smx (WIP) – Analyse complémentaire de la backdoor (je me suis perdu quasiment au début 😀)
- wiki de documentation de porte dérobée xz, une autre analyse du script d'injection 5.6.1.
Comment l'incident a été géré
La divulgation par Andreas Freund était prudente car, selon ses propres mots :Étant donné l'implication apparente des développeurs en amont, je n'ai signalé aucun bogue en amont. Pensant initialement qu'il s'agissait d'un problème spécifique à Debian, j'ai envoyé un rapport préliminaire à security@...ian.org. J'ai ensuite signalé le problème à distros@. CISA a été notifié par une distribution.
Red Hat a attribué ce problème CVE-2024-3094. Puis la nouvelle s’est répandue comme une traînée de poudre.
Lasse Collin, l'autre responsable du XZ, a ajouté un nouvelle commit le samedi 30 mars intitulé « CMake : correction du contrôle saboté du bac à sable Landlock ». L’une des méthodes de sandboxing de la bibliothèque a été sabotée, du moins lors de la construction avec CMake. Il a rapidement révélé le problème dans le Porte dérobée XZ Utils.
Red Hat a attribué ce problème CVE-2024-3094 (voir aussi dans CVE, NVD, Ubuntu). On lui a attribué un énorme Score de base CVSS de 10. De tels scores prennent toujours d’assaut Internet.
CISA le même 29 mars a publié un alerter, peut-être trop simpliste en raison de l'urgence, recommandant aux utilisateurs de rétrograder vers la version stable 5.4.6.
Les référentiels GitHub de l'organisation Tukaani ont été désactivés (est-ce bon ou mauvais ? Je pense que c'est bien : de nombreuses distributions et organisations étaient toujours liées aux versions de GitHub pour obtenir les archives tar infectées pour la construction. La désactivation du dépôt empêche cela. Il existe de toute façon une copie ou les dépôts à git.tukaani.org). Les comptes GitHub de JiaTan75 et de Lasse Collins (Larhzu) ont également été suspendus. Cela fait partie du endiguement, même si cela peut toucher des innocents. JiaT75 activité dans les référentiels non désactivés on ne peut pas encore le voir.
L'industrie a réagi rapidement. De nombreux fournisseurs ont publié des règles pour détecter les systèmes vulnérables, comme Règles de Yara, ou une assistance dans les outils commerciaux de Sydig, PAN, et d'autres. Les spécialistes de la sécurité comme James Berthoty publié sur l'examen de la façon dont nous abordons les logiciels open source.
Nous sommes maintenant dans la phase d'éradication et de rétablissement de l'incident. D'autres projets maintenus par JiaTan75 sont à l'étude de près, notamment le libarchive/libarchive (où JiaTan75 était un contributeur régulier) et le fuzzer oss-fuzz (où ce commit réalisé par JiaTan75 a essayé d'éviter oss-fuzz, ce qui en fait n'a pas pu détecter la porte dérobée). Ces tentatives de dissimulation ajoutent des preuves supplémentaires.
Qui est attaqué ?
Soit le compte GitHub JiaT75 a été compromis (rappelez-vous que GitHub a récemment mandaté 2FA), soit l'utilisateur physique propriétaire du compte est passé du côté obscur. Mais il existe des raisons impérieuses de penser à une menace persistante avancée (APT), peut-être soutenue par un État, en raison de la sophistication technique de l’attaque. Une enquête plus approfondie menée par les agences de cybersécurité et les forces de l’ordre nous le dira… Cette entrée dans YCombinator Hacker News à propos de Jia Tan apporte un éclairage sur le « qui » et son activité. Recommandé! Il donne de nombreuses informations sur la manière dont les méchants tentent de tromper les autres utilisateurs, en utilisant l'ingénierie sociale.Très agaçant ! L'auteur présumé de la porte dérobée était en communication avec moi (rwmj) depuis plusieurs semaines pour essayer d'intégrer xz 5.6.x à Fedora 40 et 41 en raison de ses « nouvelles fonctionnalités géniales ». Nous avons même collaboré avec lui pour corriger le problème de valgrind (qui, il s'avère maintenant, était dû à la porte dérobée qu'il avait ajoutée). Nous avons dû nous dépêcher hier soir pour résoudre le problème après une rupture involontaire de l'embargo. Il participe au projet xz depuis deux ans, ajoutant toutes sortes de fichiers binaires de test, et pour être honnête, avec un tel niveau de sophistication, je me méfierais même des anciennes versions de xz jusqu'à preuve du contraire.
Jia Tan a pris des mesures pour éviter d'être suivi : il semble avoir utilisé un VPN (vpn.singapore.witopia.net) pour se connecter – ce qui est acceptable en soi. Et de nombreux changements semblent être soutenus par des e-mails temporels à usage unique (de ProtonMail dans ce cas) invitant à fusionner les modifications.
L'acteur pourrait avoir l'intention d'aller encore plus loin, jusqu'au noyau Linux, en tant que contributeur au xy-intégré projet. Une première analyse n’a trouvé aucune preuve de fausse couche à ce jour.
Remarque : un autre Contributeur XZ discret « Hans Jansen » (Utilisateur GitHub « hansjans162 ») est sous surveillance. Son compte sur Debian est maintenant bloqué. Il a fait de nombreuses mises à jour de Debian Games pour cacher celle qu'il voulait sur debian/xz-utils, une mise à jour vers l'amont 5.6.1 pour accélérer la distribution de la porte dérobée vers debian/instable.
Tout ce que nous pouvons dire, pour l'instant, c'est qu'il s'agit d'une APT (encore non identifiée) utilisant différents comptes, travaillant depuis au moins deux ans sur cette campagne, et travaillant patiemment à l'implantation d'un RCE dans SSH.
L’attaque de la porte dérobée XZ était-elle évitable ?
Plutôt difficile. Premièrement, une partie de la porte dérobée injectée se trouvait dans des fichiers de test compressés qui n'étaient pas utilisés par les tests. Rétrospectivement, cela pourrait déclencher des alarmes (bruyantes), mais qui se soucie de vérifier que tous les fichiers de test sont utilisés par des tests réels dans le monde réel ? Deuxièmement, une partie de la porte dérobée injectée se trouvait dans des fichiers de macros dans les archives tar de la version, et il est difficile de vérifier manuellement les différences avec les archives tar attendues. L'automatisation est également complexe, car le résultat attendu de la compilation elle-même (pour quiconque connaît le fonctionnement d'automake/autoconf) est difficile à modéliser pour analyser si l'archive tar réelle correspond aux attentes. Certains l'ont posé as "La non-concordance des archives tar de l'arborescence git est une fonctionnalité, pas un bug". La provenance des archives binaires à partir de leur code source est un problème non résolu. Réputation des utilisateurs ? Eh bien, le compte JiaTan75 GitHub ne faisait pas de choses malveillantes comme par le passé commits. Il a été suspendu seulement après l'accumulation des preuves, mais jusqu'au 29 mars, il s'agissait d'un utilisateur régulier exerçant ses activités normales. Eh bien, ce n'est pas si normal. Plus tard commits (ceci., ceci., ceci. et ceci. qui a ajusté le code d'exploitation) a essayé de corriger les erreurs et les plantages de valgrind dans certaines configurations, en raison de différences avec la disposition de la pile attendue par la porte dérobée. Commit les revues pourraient le détecter, mais qui a la patience d'analyser les changements dans un fichier de test binaire ou la véritable motivation pour un changement dans les attributs GCC dans le code source C ? Faut-il déclencher des alarmes lorsqu'un SSH login prend 800 ms au lieu de 300 ms ? Seules les personnes hyper-prudentes en prendraient probablement note. Cicéron a dit : « La témérité appartient à la jeunesse ; prudence jusqu’à la vieillesse. L'infrastructure ifunc a été ajoutée en juin 2023 par « Hans Jansen » et « Jia Tan ». C'est le premier commit ajout du support ifunc à crc64_fast.c (utilisé plus tard pour injecter la porte dérobée). Des mois avant d'injecter les binaires backdoor dans les fichiers de test !
Remarque : Auteur et committer diffèrent ici, mais c'est normal : Lasse Collin est le mainteneur du projet, et il a fusionné les modifications. Il remercie même « Hans Jansen »…
Personne n'a soulevé d'inquiétude avant le message d'Andres Freund et le CVE créé par RedHat. Si vous voyez une cascade d'outils capables de détecter ce problème, ils détectent maintenant le composant concerné, ex post facto.
La meilleure prévention vient probablement de la nature des distributions Linux et du fait que les versions instables et à la pointe de la technologie ne sont transmises aux distributions stables en aval qu'après un processus rythmé.
Leçons tirées de l'attaque de porte dérobée XZ
Nous avons constaté combien il est difficile de détecter intentionnelle ? portes dérobées. Les portes dérobées doivent être considérées comme une menace interne, car elles sont installées par le personnel interne ou via des comptes internes compromis. Et ces gars-là sont pour la plupart dignes de confiance. Et lorsque la porte dérobée est implantée dans l’artefact distribué, elle rend sa détection plus difficile.
Certains auteurs comme Kevin Beaumont pointé vers Système, qui ouvre une large surface d'attaque des services tiers aux portes dérobées. C’est ce dont a abusé ici le mauvais acteur. Systemd a beaucoup de globes oculaires, mais XZ est une bibliothèque obscure en haut de la chaîne. « Quand l’amont est souillé, tout le monde boit de l’eau empoisonnée en aval ».
Une demande de modification sans rapport dans le système pour chargement dynamique des bibliothèques de compression, qui supprimerait la porte dérobée, a déjà été fusionné dans le système mais n'a pas encore été livré. Les dépendances supplémentaires introduites par libsystemd peuvent être à l'origine de vulnérabilités, et hier cette demande a été ouverte.
A commentaire dans le « xz : Désactiver ifunc pour résoudre le problème » commit a donné un aperçu précis des points sur lesquels se concentrer si nous voulons empêcher une telle activité (c'est moi qui souligne) :
« La leçon que nous devrions tirer en tant que communauté est davantage de sécuriser software supply chain security de manière globale, auditer les systèmes de build au-delà du simple code source. Comme la violation de SolarWinds où les attaquants ont modifié les mises à jour logicielles pour l’offre de logiciels de surveillance à source fermée de SolarWinds.
La découverte précoce et la réaction rapide ont grandement limité l’impact. Si vous vous souvenez du scène de fin de Men in Black III: "C'était serré". Encore une fois, K n'a pas oublié de laisser le pourboire. Et aucun boglodite n'est entré dans les distributions stables Linux.
1. « Je ne suis *pas* chercheur en sécurité, ni ingénieur inverse. » 2. Jia est un prénom chinois courant. Tan est aussi un nom de famille courant qui signifie « magnifique ». De nombreuses personnes sans lien de parenté portent ce prénom ; merci de ne condamner personne sous ce nom !
