Xzbot : notes, honeypot et démo d’exploit pour la porte dérobée xz

Exploration de la porte dérobée xz (CVE-2024-3094)

• honeypot : détection des tentatives d’intrusion via un faux serveur vulnérable
• ed448 patch : correctif de liblzma.so pour utiliser sa propre clé publique ED448
• backdoor format : format de la charge utile de la porte dérobée
• backdoor demo : CLI qui déclenche une RCE en supposant que la clé privée ED448 est connue

honeypot

• Fournit un simple patch openssh qui enregistre toutes les tentatives de connexion dont la clé publique N correspond au format de la porte dérobée
• Les tentatives de connexion apparaissent ainsi dans les journaux sshd

ed448 patch

• La porte dérobée utilise une clé publique ED448 codée en dur pour vérifier la signature et déchiffrer la charge utile
• Remplacer cette clé par la sienne permet de déclencher la porte dérobée
• Télécharge l’objet partagé libxzma contenant la porte dérobée et exécute le script de patch pour remplacer la clé

backdoor format

• Il est possible de déclencher la porte dérobée en se connectant avec un certificat SSH et en incluant la charge utile dans la valeur N de la clé de signature CA
• Cette charge utile doit être chiffrée et signée avec la clé ED448 de l’attaquant
• La structure de la charge utile suit le format spécifié

backdoor demo

• Montre comment se connecter à un serveur SSH vulnérable et exécuter la commande id > /tmp/.xz
• Sur le serveur vulnérable, il est possible de surveiller l’appel à system() et d’observer l’exécution de la commande
• L’arborescence normale des processus sshd et celle via la porte dérobée apparaissent différemment

L’avis de GN⁺

• Cet article propose une exploration approfondie de la vulnérabilité de porte dérobée xz identifiée comme CVE-2024-3094 et fournit des informations très utiles aux chercheurs en sécurité comme aux administrateurs système.
• En présentant des méthodes pour détecter la porte dérobée et y répondre, il peut aider à protéger les systèmes vulnérables.
• Comme ce type de vulnérabilité peut contourner les mécanismes de sécurité fondamentaux d’un système, les développeurs logiciels et les experts en sécurité doivent en comprendre le fonctionnement et prendre des mesures pour les prévenir.
• Parmi d’autres outils ou projets de sécurité offrant des fonctions similaires figurent OpenSSH, Fail2Ban et Snort, qui peuvent apporter des couches de défense supplémentaires pour protéger les systèmes.
• Cet article fournit des détails techniques sur une nouvelle vulnérabilité, ce qui peut aider la communauté de la sécurité à élaborer des stratégies de défense plus robustes.

[GN⁺]

Commentaires sur Hacker News

• Résumé des commentaires Hacker News :
  • Remarque intéressante sur une vulnérabilité RCE (Remote Code Execution) qui nécessiterait la clé privée de l’attaquant. Correction : le lien a été mal interprété, et le commentaire d’origine est conservé à titre d’archive.

    • Cette vulnérabilité semblait ironiquement pensée avec la sécurité à l’esprit. Il apparaît aussi que la personne ayant commit la backdoor dans le même fil de discussion mail a récemment contribué au kernel.

  • Admiration pour la rapidité avec laquelle la communauté hacker, et en particulier amlweems, a implémenté et documenté un PoC (Proof of Concept). Correction : l’étape suivante consiste à trouver comment identifier les distributions vulnérables et comment surveiller le probing actif des serveurs SSH.

    • Éloges de la rapidité de réaction et d’analyse de la communauté.

  • Curiosité de savoir si le PoC a été testé contre des outils de détection de comportements anormaux (Carbon Black, AWS GuardDuty, SysDig, etc.) et s’il pourrait être détecté rapidement par ce biais.

    • Curiosité concernant les tests du PoC avec des outils de détection de comportements anormaux.

  • Question de savoir si cela fonctionnait même sans connexion SSH. La liste de chaînes sur GitHub contient aussi "DISPLAY" et "WAYLAND_DISPLAY".

    • Spéculations sur un périmètre d’impact plus large en raison de la présence de chaînes sans lien direct avec SSH.

  • Question sur la façon dont le patch a été appliqué à openssh_RSA_verify lorsque liblzma.so.5.6.1 était chargée en mémoire, sans nécessiter openssh.patch à l’exécution.

    • Question technique sur le processus d’exploitation de la vulnérabilité à l’exécution.

  • Le fait qu’une attaque réussie ne laisse pas de logs. Cela soulève la question de savoir si l’attaquant pouvait exécuter des commandes arbitraires sans laisser de traces dans les logs.

    • Inquiétude sur la possibilité d’une attaque sans génération de logs.

  • Avis sur la manière dont les responsables des projets xz, OpenSSH et Linux ont réagi à cette vulnérabilité, et sur les moyens d’éviter ce type de faille à l’avenir.

    • Intérêt pour la réponse des responsables de projets et les mesures de prévention futures.

  • Discussion sur l’espionnage étatique et les backdoors. Les États-Unis privilégieraient les interventions matérielles, tandis que d’autres pays comme Israël se concentreraient sur des backdoors logicielles de long terme.

    • Analyse des stratégies de backdoor selon les États.

  • Interrogation sur le choix d’ED448, alors que curve25519 est généralement recommandé.

    • Questionnement sur le choix d’un algorithme cryptographique particulier.