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 Sylvain Briole (site web personnel) . Évalué à 4.
Ce serait mieux.
[^] # Re: Avec le lien
Posté par Stéphane ESCAICH (site web personnel) . Évalué à 4.
http://www.spiegel.de/media/media-35663.pdf
[^] # Re: Avec le lien
Posté par Xavier G. . É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 Stéphane ESCAICH (site web personnel) . Évalué à 6.
En fait le lien est cassé dans ton post, d'où le commentaire :)
[^] # Re: Avec le lien
Posté par gouttegd . Évalué à 4.
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: Correction
Posté par Xavier G. . Évalué à 4.
Tout à fait, plus d'un même, ex. :
https://twitter.com/valeryan24/status/557092663191928832
https://twitter.com/ppsticino/status/557074726871265280
Et j'ai aussi corrigé complètement le sujet identique posté sur Numérama, grâce justement aux infos données par les contributeurs ici-même, que je remercie :)
[^] # Re: Avec le lien
Posté par oinkoink_daotter . Évalué à 10.
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 Misc (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 gouttegd . É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.
(DSD : probablement Defense Signal Directorate, la NSA australienne.)
[^] # Re: Non
Posté par Thierry Thomas (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 Renault (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 TImaniac (site web personnel) . Évalué à 0.
Etre root… ou exploiter une faille de sécurité.
[^] # Re: Non
Posté par passant·e . É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 oinkoink_daotter . Évalué à 10.
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 Xaapyks . É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 SChauveau . Évalué à 9.
Sur Debian, dpkg conserve le checksum de tout les fichiers installés.
Le programme debsums permet de les vérifier
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 zul (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 Trollgouin . É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…Je suis sûr qu'il y a mieux…
[^] # Re: Non
Posté par fearan . É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 georgeswwbush . É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 Tonton Benoit . É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 oinkoink_daotter . É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 gouttegd . É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 Professeur Méphisto . É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 Misc (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 Antoine . É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 laurentb (site web personnel) . Évalué à 4.
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 ondex2 . É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 Xavier G. . É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 gouttegd . Évalué à 4.
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 passant·e . É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 Xavier G. . É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 Elfir3 . É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 passant·e . É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 arnaudus . É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 Flyinva . É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 SChauveau . É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.
[^] # Re: On n'a pas toujours les sources
Posté par Tonton Th (Mastodon) . Évalué à 4.
http://cm.bell-labs.com/who/ken/trust.html
[^] # Re: On n'a pas toujours les sources
Posté par gouttegd . Évalué à 6.
Ken Thompson, Reflections on Trusting Trust, un classique.
Et une réponse possible.
[^] # Re: On n'a pas toujours les sources
Posté par Maclag . Évalué à 2.
J'espère que non, parce l'ordre de grandeur du nombre de transistors dans un proco moderne, c'est la centaine de millions ou le milliard.
Et il est strictement impossible de faire plus qu'1bit de mémoire avec un seul transistor, alors 4Go (32Gbits…), ça va prendre encore plus de temps!
# C'est vieux comme le monde
Posté par lay . É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.