Journal Une backdoor de la NSA dans OpenSSH ?

Posté par  . Licence CC By‑SA.
-1
19
jan.
2015

Bonjour,

Info reçue via Twitter ce matin, comme le programme est libre on devrait vite en savoir plus sur sa véracité :

Une clé d'authentification publique (pubkey) intégrée au binaire sshd (daemon) permettrait un accès root :
https://www.spiegel....media-35663.pdf

Bon, techniquement ça dépasse de très loin toutes mes compétences, mais certains ici sont sans doute capables de nous expliquer plus en détail et de manière vulgarisée ce qu'il en est, la crédibilité, les potentiels dégâts occasionnés…

En tout cas le sujet, bien que redondant (depuis les révélations de Snowden, ce genre de rumeur est fréquent) est intéressant (il y avait déjà eu une suspicion, démentie après examen approfondi du code, de porte dérobée du FBI dans OpenBSD).

À suivre !

  • # Avec le lien

    Posté par  (site web personnel) . Évalué à 4.

    Ce serait mieux.

    • [^] # Re: Avec le lien

      Posté par  (site web personnel) . Évalué à 4.

    • [^] # Re: Avec le lien

      Posté par  . Évalué à 4.

      Comme le souligne le commentaire précédent, le seul lien dont je dispose pour le moment (après une rapide recherche ce matin) est celui du pdf sur le site du Spiegel, partagé sur Twitter, et il est dans mon post initial.

      N'ayant pas plus de données, c'est la raison pour laquelle le titre est une question et non une affirmation.

      Peut-être, au vu des réponses apportées par ailleurs sur ce thread, s'agit-il plutôt d'une vulnérabilité potentielle que d'une porte dérobée, ou que celle-ci, si elle existe, n'est pas dans le programme d'origine tel que distribué par OpenSSH, mais dans un binaire que l'on essaie de faire installer par sa cible…

      Auquel cas je me serais emballé un peu vite et aurais participé au FUD régulier dont je parlais justement en conclusion.

      • [^] # Re: Avec le lien

        Posté par  (site web personnel) . Évalué à 6.

        En fait le lien est cassé dans ton post, d'où le commentaire :)

      • [^] # Re: Avec le lien

        Posté par  . Évalué à 4.

        Auquel cas je me serais emballé un peu vite et aurais participé au FUD régulier dont je parlais justement en conclusion.

        Ce n’est pas grave, puisque tu as maintenant posté un tweet de correction pour rétablir les faits (avec un lien vers cette discussion ou vers le message de Stefan Sperling sur misc@openbsd.org). N’est-ce pas ?

      • [^] # Re: Avec le lien

        Posté par  . Évalué à 10.

        Peut-être […] s'agit-il plutôt d'une vulnérabilité potentielle que d'une porte dérobée, ou que celle-ci, si elle existe, n'est pas dans le programme d'origine tel que distribué par OpenSSH, mais dans un binaire que l'on essaie de faire installer par sa cible…

        Ce que dit le doc en question, c'est qu'un gars en bricolant le code d'OpenSSH a réussi à hardcoder une clef publique pour donner lui les droits root si elle se présente, et de discourir sur les avantages d'une telle solution par rapport à l'approche traditionnelle australienne qui était d'ajouter des clefs publiques dans un .authorized_keys2.
        A ce niveau, la, ce n'est plus vraiment une vulnérabilité, mais une métavulnérabilité tout ce qu'il y a de plus triviale/générique. Si j'arrive à avoir suffisamment de droits sur le système pour remplacer le binaire d'OpenSSH, est-bien une vulnérabilité d'OpenSSH ?
        Contre ce genre de menace, il n'y a pas vraiment d'autre solution que de s'assurer qu'on connait les binaires qui tournent sur la machine (signature numérique des binaires, tripwire ou équivalent, etc).

        • [^] # Re: Avec le lien

          Posté par  (site web personnel) . Évalué à 10.

          Quoi, les gens peuvent modifier les logiciels libres pour rajouter du code et remplacer le binaire  ?

          Clairement oui, je vais réinstaller mes serveurs en windows, car c'est visiblement plus sur.

  • # Non

    Posté par  . Évalué à 10.

    De ce que je comprends, il ne s’agit pas d’une backdoor insérée dans le projet public OpenSSH — qui donnerait un accès à une machine non encore compromise — mais d’une version modifiée de OpenSSH, prévue pour remplacer la version installée sur une machine déjà compromise (où l’attaquant a déjà les privilèges du superutilisateur).

    Le but étant de permettre à l’attaquant de revenir sur la machine à sa guise, de façon plus discrète qu’en laissant sa clef publique dans le fichier ~/.ssh/authorized_keys (ce que l’administrateur de la machine pourrait détecter plus facilement qu’un remplacement du binaire /usr/sbin/sshd).

    Selon moi, rien de bien sensationnel, et rien de spécifique aux agences gouvernementales à sigle à trois lettres.

    PANT SPARTY is a backdoor in the SSH daemon for *NIX, based on OpenSSH portable. It allows a public key to be embedded in the sshd binary […]
    Currently DSD uses authorized_keys as a quick-and-easy method of persistence against certain *NIX targets. In most cases this works, but it obviously isn’t very stealthy and can run into problems if that file is deleted or the SSH configuration changes to not use it. The goal for this project was to provide the same level of persistence but embedded in the sshd binary itself (obviously, assuming root access, as before)

    (DSD : probablement Defense Signal Directorate, la NSA australienne.)

    • [^] # Re: Non

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Un système Unix digne de ce nom lève une alerte quand un binaire système est modifié. Il faut donc en plus avoir désactivé ce mécanisme d’audit (ou les logs, etc.) : quand on en est là, de toute façon, c’est foutu !

      • [^] # Re: Non

        Posté par  (site web personnel) . Évalué à 4.

        Ouais enfin pour modifier un binaire il faut être root de base, à partir de là il peut désactiver tout ce qu'il veut avant.

      • [^] # Re: Non

        Posté par  . Évalué à 2.

        T'as beau être un espion, rien de tel que de pouvoir gérer un serveur au chaud depuis la "maison"

        Je trolle dès quand ça parle business, sécurité et sciences sociales

      • [^] # Re: Non

        Posté par  . Évalué à 10.

        Un système Unix digne de ce nom lève une alerte quand un binaire système est modifié

        Je t'invite à tenter l'opération sur n'importe quel linux après installation. Tu vas être très déçu.

      • [^] # Re: Non

        Posté par  . Évalué à 2.

        Ah oui ?
        J'étais pas au courant que ce genre de mécanisme existait. Ca scanne tous les binaires de (/usr)?/s?bin et les compare à un checksum ?
        Quel unix implémente ça ?

        • [^] # Re: Non

          Posté par  . Évalué à 9.

          Sur Debian, dpkg conserve le checksum de tout les fichiers installés.
          Le programme debsums permet de les vérifier

          # debsums openssh-server
          /lib/systemd/system/ssh.service                                               OK
          /lib/systemd/system/ssh.socket                                                OK
          /lib/systemd/system/ssh@.service                                              OK
          /usr/lib/tmpfiles.d/sshd.conf                                                 OK
          /usr/sbin/sshd                                                                OK
          /usr/share/apport/package-hooks/openssh-server.py                             OK
          /usr/share/doc/openssh-client/examples/sshd_config                            OK
          /usr/share/lintian/overrides/openssh-server                                   OK
          /usr/share/man/man5/sshd_config.5.gz                                          OK
          /usr/share/man/man8/sshd.8.gz                                                 OK
          

          Mais comme indiqué dans un post précédent, si le root du serveur se fait hacker alors debsum ou les fichiers contenant les checksums pourront aussi être modifiés.

          Une vérification depuis un serveur externe est plus sûre mais même alors il sera difficile de s'assurer que le transfert d'information est sain.

          La solution la plus robuste consiste probablement à effectuer ces vérifications dans une VM depuis son hyperviseur.

        • [^] # Re: Non

          Posté par  (site web personnel) . Évalué à 7.

          Entre autre, NetBSD avec veriexec (cf https://www.netbsd.org/docs/guide/en/chap-veriexec.html)

        • [^] # Re: Non

          Posté par  . Évalué à 3.

          De mémoire, rkhunter vérifie (entre autres) que les *bin/* n'ont pas été modifiés. Il devrait pouvoir tourner sur la plupart des Unix…

          rkhunter is a shell script which carries out various checks on the local system to try and detect known rootkits and malware. It also performs checks to see if commands have been modified, if the system startup files have been modified, and various checks on the network interfaces, including checks for listening applications.

          Je suis sûr qu'il y a mieux…

        • [^] # Re: Non

          Posté par  . Évalué à 7.

          sous mandriva (et mageia maintenant) msec avait CHECK_RPM=full/quick

          le full équivalait à un rpm -Va (a pour all)

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Non

          Posté par  . Évalué à -3.

          Je recommande le package chkrootkit pour la base du système, et nikto si un service Web (ou pas) tourne.

        • [^] # Re: Non

          Posté par  . Évalué à 2.

          Y'a un systeme équivalent sur RHEL aussi je crois, ça utilise la puce TPM pour stocker les hashs du systeme de base et le valide au démarrage.

          • [^] # Re: Non

            Posté par  . Évalué à 4.

            Point de détail : la puce TPM ne stocke pas les hash de fichiers. De mémoire dans ce cas, les hashs sont stockés dans un fichier et c'est le hash de ce fichier dont l'intégrité est mesurée par le TPM (via signature ou scellement via l'état des PCR).

    • [^] # Re: Non

      Posté par  . Évalué à 10.

      Accessoirement, la nécessité pour le DSD d’installer ce genre de backdoor pour conserver l’accès à une machine tendrait à démontrer qu’il n’y a pas de backdoor intégrée « de base » dans le code public d’OpenSSH…

      (Ou du moins, pas de backdoor dont le DSD ait connaissance.)

      (À moins bien sûr que la fuite de ce document n’ait été organisée précisément dans le but de nous faire croire qu’il n’y a pas de backdoor.)

      • [^] # Re: Non

        Posté par  . Évalué à 10.

        À moins bien sûr que tu ne sois un agent de la DGSI ayant pour mission de faire croire que le DSD a une backdoor pour nous faire détourner les yeux de la DGSI

        • [^] # Re: Non

          Posté par  (site web personnel) . Évalué à 10.

          mais tu pourrais être un agent du FSB qui ferait la remarque pour que quelqu'un fasse un remarque sur le fait que je soit un agent de la NSA qui va faire remarquer que en parlant de la DSD et de la DGSI tu fait oublier la NSA ?

          • [^] # Re: Non

            Posté par  . Évalué à 2.

            Tu pourrais être un membre de la Quadrature du Net qui cherche à agiter des théories du complot pour grapiller des dons tout en lançant des rumeurs malveillantes sur ceux qui ne donnent pas.

    • [^] # Re: Non

      Posté par  (site web personnel) . Évalué à 4.

      Selon moi, rien de bien sensationnel, et rien de spécifique aux agences gouvernementales à sigle à trois lettres

      Oui, j'ai déjà vu ça dans la nature, et ce n'était sûrement pas la NSA derrière, mais plutôt des « script kiddies » qui se sont même gourés d'architecture, du coup ça ne fonctionnait plus.

  • # RAS

    Posté par  . Évalué à 6.

    Même si c'est pas explicitement dit dans le PDF, ce qui y est décrit est trop énorme pour que ce soir upstream sans que personne ne l'ai vu. J'en conclus qu'il n'y a rien à voir dans OpenSSH et que c'est une version maison de la NSA (sauf si Théo est un agent de la NSA ;)), pour maintenir l'accès qu'ils ont déjà à un serveur. C'est malin, mais tant qu'ils ont pas troué ton système, ça ne te concerne pas.

    • [^] # Re: RAS

      Posté par  . Évalué à 5.

      Il semblerait que ce soit effectivement ça : non un code malveillant inséré dans le projet upstream de OpenSSH, mais une version modifiée et patchée qui, si elle est installée, ouvre l'accès par cette porte…

      https://news.ycombinator.com/item?id=8905581

      http://www.mail-archive.com/misc@openbsd.org/msg135510.html

      _They are not talking about the official OpenSSH code.

      To save everyone a bit of time (and hassle with a PDF), from the same document:

      "It allows a public key to be embedded in the sshd binary and will then always grant a root login shell if presented with the proper key pair for that key. […] authorized_keys as a quick-and-easy method of persistence […] obviously isn't very stealthy […] The goal for this project was to provide the same level of persistence but embedded in the sshd binary itself (obviously, assuming root access, as before)"

      In other works, no backdoor in sshd unless the system has already been rooted by other means and sshd replaced with a bugged binary. Boohoo._

      Au temps pour moi. L'info sur cette possibilité n'en est pas moins inintéressante sur le principe.

      Est-il possible de modifier le titre d'un journal après publication pour le rendre plus proche de la vérité (par un modérateur peut-etre) : Comment introduire une backdoor dans OpenSSH

      • [^] # Re: RAS

        Posté par  . Évalué à 4.

        L'info sur cette possibilité n'en est pas moins inintéressante sur le principe.

        Il n’y a rien de nouveau, hein. Des pirates font la même chose probablement depuis que SSH existe.

        Cette backdoor n’a même pas l’air très raffinée, comparée à Linux/Ebury par exemple (qui ne modifie pas le binaire sshd, et pourrait donc échapper à un contrôle superficiel des signatures des exécutables, contrairement à ce « PANT SPARTY »).

  • # Titre accrocheur :-)

    Posté par  . Évalué à 8.

    Vu ce que dit le mec de la NSA, il s'agit plus d'un binaire maison, patché dans tous les sens pour permettre un login root distant et discret. Il faudrait plus d'infos sur le mode d'installation dudit binaire ensuite.

    Je trolle dès quand ça parle business, sécurité et sciences sociales

    • [^] # Re: Titre accrocheur :-)

      Posté par  . Évalué à 2.

      Oui, comme je l'ai dit, je ne possède pas le niveau technique pour comprendre le pdf, tout ce que j'ai vu passer, c'est le lien vers ce document et le commentaire repris par chaque relayeur sur le réseau social en copier-coller :

      The #NSA's #OpenSSH backdoor: pubkey embedded in sshd binary allows root access.

      ou

      Report of an NSA Employee about a Backdoor in the OpenSSH Daemon (2012)

      Ce qui m'a fait penser à une backdoor plus qu'à un binaire modifié et distribué par ailleurs dans un premier temps.

      De plus, je l'ai précisé aussi, ce genre d'info alarmiste il en sort quasi-une par semaine (on a eu droit aussi à Debian infiltré il y a quelques temps…), sauf qu'un jour il est possible que l'une d'elle soit vraie, et dans ce cas il faut le savoir.

      Donc le but de mon journal n'était pas de faire du clic ni du sensationnalisme (même si le titre peut effectivement le laisser penser), mais justement d'obtenir des éclairages tel que celui-ci :)

      • [^] # Re: Titre accrocheur :-)

        Posté par  . Évalué à 3. Dernière modification le 19 janvier 2015 à 09:28.

        Une backdoor (une porte d'entrée située à l'arrière) peut être ajoutée dans le code source original comme dans une copie propre à l'auteur de la backdoor. C'est le résultat final qui compte: la possibilité d'avoir cette porte disponible en l'installant chez un tiers.

      • [^] # Re: Titre accrocheur :-)

        Posté par  . Évalué à 2.

        Il explique dans le document que le DSD (NSA australienne) se contente pour le moment d'installer une clé dans autorized_key ce qui n'est pas résistant à un changement de config ou une désactivation de l'utilisation de ce fichier et pas discret du tout.

        C'est pour cela que le mec doit faire un binaire modifié pour le DSD. Il a eu pas mal de peine mais y est parvenu.

        Par contre, il précise bien qu'il part du principe que les espions ont un accès au préalable sur le serveur où ils veulent installer le binaire.

        Je trolle dès quand ça parle business, sécurité et sciences sociales

        • [^] # Re: Titre accrocheur :-)

          Posté par  . Évalué à 1.

          C'est pas une méta-backdoor, cette méthode? À moins de devoir gérer plein de binaires différents, si un méchant terroriste récupère la clé, il va pouvoir s'infiltrer dans tous les serveurs contrôlés par le DSD, non? Du coup, le remède me semble bien pire que le mal…

  • # On n'a pas toujours les sources

    Posté par  . Évalué à 9.

    OpenSSH est utilisé dans de nombreux équipements réseau : routeurs, firewalls, proxys, souvent d'origine américaine et dont l'utilisateur n'a pas les sources (au hasard, Cisco, Juniper, Bluecoat, etc.).

    Il va être encore plus compliqué de vérifier le binaire de ces équipements que celui de nos Unix préférés…

    • [^] # Re: On n'a pas toujours les sources

      Posté par  . Évalué à 5.

      Je n'ai pas retrouvé de lien mais il y a quelques (dizaines d'?) années, un chercheur a codé un exemple de backdoor dans les sources d'un compilateur. Ce backdoor détectait la compilation d'un programme spécifique pour y insérer une autre backdoor (par exemple dans OpenSSH server). L'idée géniale est que la backdoor du compilateur était également capable de détecter la compilation du compilateur lui même pour se réinsérer dans le binaire.

      En pratique, cela signifie que si une version binaire du compilateur avec backdoor pouvait être inséré dans une distribution alors toutes les versions suivantes du compilateur auront aussi la backdoor même si les sources de ceux ci sont propres. L'inspection des sources ne sert alors à rien.

      Si on pousse le concept plus loin, la backdoor pourrait se trouver dans le binaire de quasiment n'importe quel outils utilisé pour programmer (compilateur, assembleur, linker, make , bash, editeur, …). La seule façon de faire un OS propre serait alors de créer son propre processeur et mémoires avec des transitors soudés à la main.

  • # C'est vieux comme le monde

    Posté par  . Évalué à 10.

    Il n'y a vraiment pas besoin d'être la NSA pour avoir ce genre d'idée.

    J'ai vu des machines rootées avec des binaires SSH remplacés soit par des binaires préfabriqués en fonction de la distribution, soit carrément compilés sur la machine. C'est généralement utilisé sur des machines où un rootkit ne peut pas être installé ou alors n'est pas pérenne.

    Le patch était juste d'accepter un mot de passe fonctionnant pour tout les utilisateurs en plus de leurs mots de passes habituels.

    Et c'était il y a déjà plus de 10 ans!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.