Le terrier du lapin de la backdoor sshd dans xz est bien plus profond que prévu

 (twitter.com/bl4sty)
2 points par GN⁺ 2024-04-07 | 1 commentaires | Partager sur WhatsApp
  • La backdoor sshd de xz va au-delà du hook RSA_public_decrypt révélé au départ : certains chemins de code supplémentaires, plus difficiles d’accès, peuvent aussi être déclenchés
  • Le déroulé de l’attaque consiste à installer un hook sur mm_answer_keyallowed au moyen d’une commande manipulée, puis à assembler un tampon de commande à l’aide de plusieurs fausses clés publiques ssh-rsa
  • Ce « magic buffer » contient des commandes de backdoor supplémentaires ainsi que deux signatures ed448 ; les signatures intègrent le condensat SHA256 de la clé d’hôte et le session_id du KEX
  • La PoC actuelle utilise une bibliothèque cliente SSH paramiko fortement modifiée ; la commande 0x03 permet une RCE basée sur system() ainsi que la définition de l’uid/gid
  • Un contournement de l’authentification a aussi été confirmé : en écrasant la réponse de mm_answer_authpassword via mm_keyallowed_backdoor cmd 1, il est possible de se connecter avec n’importe quel mot de passe

Un chemin de backdoor plus profondément connecté

  • La backdoor sshd de xz contient des fonctionnalités plus profondes que le comportement initialement connu, et certaines ont été directement déclenchées
  • Le point d’entrée principal est le hook RSA_public_decrypt
    • L’envoi d’une commande correctement conçue installe un autre hook dans la fonction mm_answer_keyallowed de sshd
    • Ensuite, plusieurs fausses clés publiques ssh-rsa sont fournies pour fragmenter puis réassembler le « magic buffer »
  • Le « magic buffer » est un tampon contenant des commandes de backdoor supplémentaires
    • Il contient également deux signatures ed448
    • Ces signatures sont salées avec le condensat SHA256 de la clé d’hôte, comme la signature de la backdoor côté RSA_public_decrypt
    • La dernière signature prend aussi en compte le session_id de 0x20 octets dérivé de l’échange de clés SSH initial (KEX)

PoC et contournement de l’authentification

  • La PoC actuelle est implémentée avec une bibliothèque cliente SSH paramiko fortement modifiée
  • La commande actuellement déclenchée dans ce chemin de code est 0x03
    • Elle réactive une RCE de base via system()
    • Elle prend aussi en charge la définition de l’uid/gid
  • Il reste encore du code à comprendre, et comme l’une des commandes de backdoor de mm_answer_keyallowed finit aussi par hooker mm_answer_keyverify, un contournement complet de l’authentification pour les sessions interactives semble possible
  • Le contournement de l’authentification a ensuite été confirmé
    • mm_keyallowed_backdoor cmd 1 permet d’écraser la réponse de mm_answer_authpassword avec une valeur définie par l’utilisateur
    • En définissant la réponse sur { u32(9), u8(13), u32(1), u32(0) }, il est possible de se connecter avec n’importe quel mot de passe

À lire aussi

1 commentaires

 
GN⁺ 2024-04-07
Avis sur Hacker News

  • https://threadreaderapp.com/thread/1776691497506623562.html

  • Cette affaire est étrange : par certains aspects, elle paraît très professionnelle, et par d’autres, assez amateur
    Une identité suffisamment fiable pour devenir mainteneur d’un paquet important a été construite sur une longue période, une attaque d’ingénierie sociale semblant impliquer plusieurs personnes a été menée, la véritable identité et l’origine de l’attaque n’ont pas été exposées, et l’obfuscation était sophistiquée
    Pourtant, le fait que des bugs et une régression de performance aient quand même atteint la version de production donne une impression de négligence. Si un groupe soutenu par un État avait vraiment été compétent, on pourrait penser qu’il aurait testé suffisamment en privé avant de soumettre quoi que ce soit à un projet public, afin d’éliminer toute baisse de performance suspecte

    • Je pense que l’expression « soutenu par un État » crée des attentes trop élevées. Les grandes organisations finissent par ressembler aux autres grandes organisations : elles subissent la bureaucratie, les délais, les cycles de publication et les problèmes de communication entre équipes
      Le récent incident iOS « qui était peut-être une backdoor » montre aussi qu’une organisation qui accumule beaucoup de vulnérabilités ne se soucie pas toujours d’en griller quelques-unes
    • Il n’est pas difficile de croire que les personnes qui ont développé le code ne faisaient pas en même temps tourner Valgrind pour surveiller les performances
      Les cibles étaient des serveurs et des appliances ; combien de serveurs ou d’appliances exécutent Valgrind sur leur image de base ? Avec le recul, on se dit « pourquoi n’y ont-ils pas pensé ? », mais il est très probable qu’ils aient testé sur les images système qu’ils visaient, pas sur les images personnalisées de développeurs ordinaires
    • Le 2024-02-29, une PR visant à ne plus lier liblzma à libsystemd a été ouverte [0]
      Kevin Beaumont a supposé que « Jia Tan » l’avait vue et avait immédiatement compris que la backdoor pouvait être neutralisée, puis s’était précipité pour ne pas perdre l’énorme quantité de travail investie dans cet exploit [1], et cela semble plausible
      Cette pression de délai expliquerait le crash dans la 5.6.0, ainsi que le manque de temps pour peaufiner, réduire ou éliminer la régression de performance qui a été la raison principale de la découverte de l’affaire
      [0]: https://github.com/systemd/systemd/pull/31550
      [1]: https://doublepulsar.com/inside-the-failed-attempt-to-backdo...
    • Si Google a pu lancer Gemini sans sourciller, est-il si difficile de croire qu’une organisation de l’ombre puisse échouer de manière plus subtile ?
      Comme Patrick McKenzie le fait remarquer ailleurs, les organisations criminelles fonctionnent, elles aussi, avec des comités et des compromis, à peu près comme les organisations non criminelles. Vu sous cet angle, on comprend qu’un navire puisse sombrer à cause d’une baisse de performance due à l’empilement de fonctionnalités. Les entreprises où j’ai travaillé ont fait des erreurs encore plus amateurs
    • Même les organisations compétentes soutenues par des États peuvent avoir des accidents. Les services de renseignement ne sont pas toujours aussi froidement compétents qu’on l’imagine. Les tentatives d’assassinat du Kremlin au Royaume-Uni relevaient presque de la comédie d’erreurs [1]
      Peut-être qu’une autre backdoor ou un autre moyen d’accès qu’ils utilisaient a été bloqué, et qu’ils ont eu besoin en urgence d’une nouvelle voie d’accès
      [1] https://en.wikipedia.org/wiki/Poisoning_of_Alexander_Litvine...

  • Ce qui est vraiment intéressant ici, c’est le niveau de sophistication, alors que l’affaire a finalement été repérée à cause d’une régression de performance assez visible
    Cela me rappelle une citation entendue dans une vraie émission criminelle : « Il y a un million de façons de se faire prendre pour meurtre, et si vous arrivez à en imaginer seulement la moitié, vous êtes un génie »

    • C’est compréhensible si l’on suppose qu’il y avait une équipe derrière le compte. Quelqu’un a pu développer la fonctionnalité, puis une autre personne, plus négligente ou moins expérimentée, a pu l’intégrer
      Une autre encore a peut-être géré les faux comptes et interagi dans les commentaires et les PR
    • C’est peut-être naïf, ou trop crédule, mais chaque fois que je m’inquiète à l’idée que ce genre de backdoor soit déjà largement répandu, je repense à ça
      Je ne sais pas si, cette fois, ils ont simplement eu la malchance de se faire prendre, ou si ce type d’attaque est en réalité trop difficile à réussir. J’espère que c’est la seconde option, mais en vérité, impossible de le savoir
    • Si ma mémoire est bonne, la régression de performance ne se produisait que lorsque le code était compilé avec -fno-omit-frame-pointer, qui n’est pas la valeur par défaut. https://mastodon.social/@AndresFreundTec/112187000944648334
    • Avec suffisamment de temps et davantage de tests locaux, ils auraient très probablement réussi
      Je suis convaincu que le patch de @teknoraver sur libsystemd a changé leur échéance
    • La phrase « si vous arrivez à en imaginer seulement la moitié » s’applique-t-elle aussi à ceux qui essaient de résoudre un meurtre ?

  • Dans ce genre d’affaire, quand beaucoup d’articles techniques fouillent les détails en profondeur, je me demande souvent pourquoi tout le monde dit « c’est forcément soutenu par un État », « regardez les horodatages, c’est une preuve irréfutable »
    L’affaire xz était certes une attaque discrète et préparée de longue date, mais faut-il vraiment quelque chose qui dépasse un seul individu compétent ? Le fait que des personnes quelconques en ligne puissent l’analyser et la comprendre signifie aussi que cela reste dans le champ de ce qu’une personne peut comprendre
    Pourquoi ne serait-il pas possible qu’une seule personne intelligente mais rancunière ait fait ça seule ?

    • L’élément qui évoque le plus un acteur étatique, c’est l’ampleur de la récompense attendue par rapport au temps investi dans l’attaque par ingénierie sociale
      Un plan lucratif de ce type est irrationnel. Je n’exclus pas la possibilité d’un acteur irrationnel ou d’un individu motivé par autre chose que l’argent, mais cela fait d’un acteur étatique le candidat le plus probable
      En cas de succès, la valeur revendable aurait été énorme, mais la probabilité d’insérer un exploit dans une infrastructure critique et de rester indétecté assez longtemps pour qu’un client l’achète et l’utilise est très faible. Un État peut se permettre un pari moonshot, alors qu’un individu cherchera plutôt, à mon avis, une cible à meilleure espérance de gain
      Bien sûr, cela ne veut pas dire pour autant qu’il s’agissait d’un acteur étatique compétent ni que beaucoup de ressources y avaient été affectées
    • D’accord. Ce hack a demandé beaucoup de compétences, de détermination et de temps
      Mais cela ne s’applique-t-il pas aussi à beaucoup de développeurs open source ? La motivation est évidente aussi. Cet exploit aurait valu des millions de dollars sur le marché noir
    • Rien du tout. Personne ne sait qui il est
    • Je serais curieux de savoir où tu as vu parler de « preuve irréfutable »
      J’ai vu beaucoup de suppositions de gens bien informés, mais je n’ai pas vu cette expression

  • Existe-t-il un article qui résume l’obfuscation de la porte dérobée elle-même ? Pas les scripts de build utilisés pour l’installation, mais la vraie porte dérobée
    J’ai chargé le binaire dans Ghidra et parcouru les fonctions trouvées, mais comme je ne connais pas bien le mécanisme ifunc utilisé pour intercepter l’exécution, j’ai abandonné et laissé ça à d’autres
    Vu qu’il y a des protections anti-débogage, je suppose que le code aussi est obfusqué. Comme il a été distribué sous forme de binaire opaque, je pensais qu’au moins une partie du code serait chiffrée avec une clé que nous n’avons pas. Comme certaines parties de la charge utile de STUXNET

    • Il n’existe pas encore d’analyse complète de la porte dérobée elle-même. Certaines protections anti-débogage peuvent être contournées avec des flags, mais ici c’est un peu plus délicat, car c’est traité à l’étape de compilation
      Le fait qu’il y ait des fonctions anti-débogage ne signifie pas forcément que le code est obfusqué. Comme dit plus haut, cela s’est fait au moment du build. C’est comme si l’on avait déjà posé des pièges chez soi
      Cette affaire montre le problème qui survient quand un gestionnaire de paquets ne récupère pas le code source depuis la bonne origine

  • Je n’ai pas suivi cette affaire dans les moindres détails, mais je trouve très étrange qu’on entende si peu parler de l’auteur du piratage

    • « Cela dit, je pense qu’en réalité il vient d’un fuseau horaire UTC+02 en hiver/UTC+03 en DST, c’est-à-dire une zone incluant l’Europe de l’Est (EET) ou Israël (IST) »
      https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
    • Il y a eu beaucoup de spéculations. Il est plus probable qu’il s’agisse de plusieurs personnes que d’une seule, et cela ressemble à un groupe de ransomware ou à un service de renseignement étatique
    • Comme pour l’analyse de Satoshi, il serait intéressant de faire une analyse sémantique des communications des personas en ligne liés à l’affaire pour essayer d’en déduire une orientation culturelle
      En regardant si le style d’écriture a changé au fil du temps, on pourrait aussi voir si plusieurs personnes ont opéré sous le même persona. Il y a aussi pas mal de code commité, donc il vaudrait la peine d’examiner les différences de style de code pour voir si plus d’une personne a été impliquée
    • Discuter de quoi ? On ne sait absolument rien

  • C’est plutôt une chance que cela ait été découvert avant de se répandre largement
    Pas seulement pour la raison évidente qu’on ne veut pas qu’un acteur inconnu dispose d’une exécution de code à distance dans notre infrastructure. Si les gens continuent à creuser, ils finiront probablement par produire une charge utile permettant à n’importe qui d’utiliser la porte dérobée
    Qu’un seul acteur ait un accès est déjà mauvais, mais que n’importe qui puisse y accéder serait bien pire

    • Si la charge utile est une clé RSA privée, n’est-ce pas quasiment impossible ?

  • Lien consultable à la place de thereaderapp.com :
    https://nitter.poast.org/bl4sty/status/1776691497506623562

  • Je suis surpris qu’après plusieurs jours, tout ne soit toujours pas complètement élucidé
    Avec les regards du monde entier braqués dessus et les pièces essentielles théoriquement publiques, tenir aussi longtemps signifie que l’obfuscation est plutôt bien faite

  • Ce qui m’inquiète dans cette affaire, c’est son caractère de jeu de longue haleine
    Premièrement, ils ont attendu longtemps pour construire l’« infrastructure » permettant de créer la porte dérobée. Deuxièmement, même après la diffusion de l’exploit en production réelle, ils auraient préparé un autre jeu de longue haleine. La bonne façon d’utiliser un gain à la loterie, c’est de l’investir
    Troisièmement, je me demande si ce genre de partie est encore en cours en ce moment. C’est effrayant