Bonjour à tous,
L'hébergeur OVH installe une clé SSH sur les serveurs dédiés qu'ils louent, pour avoir un accès de maintenance en cas de besoin. Cette clé SSH a probablement été compromise et OVH ne répond pas, ou à côté de la plaque, à mon signalement sur le sujet.
Grâce à une restriction sur l'IP source, l'attaque échoue dans la configuration par défaut. Néanmoins, face à cette compromission, OVH devrait générer une nouvelle clé, demander à tous les clients de supprimer l'ancienne, et déterminer autant que possible l'origine de la compromission pour prendre les mesures qui s'imposent.
Dans l'attente d'une clarification d'OVH, je conseille à toute personne possédant un serveur chez eux de désactiver leur clé SSH :
# mv /root/.ssh/authorized_keys2 /root/.ssh/authorized_keys2.disabled
Les détails sur la compromission : http://www.pps.univ-paris-diderot.fr/~kerneis/ovh-ssh-key/
# Aie
Posté par siegfried . Évalué à 1.
J'avais lu ton article plus tot, bien vu!
J'ai la meme sur un serveur, j'ai mailé OVH et l'IP concernée (des pays bas).
Aucun message sur un autre serveur où j'avais supprimé leur clé.
On va voir leur réponse, en espérant qu'il n'y ait pas de dégats.. Car meme s'il y a un filtre d'IP sur les serveurs loués, est ce pareil sur tous leurs serveurs? (notamment ceux utilisés pour leur infra) Pas sur..
[^] # Re: Aie
Posté par Misc (page perso) . Évalué à 3.
On peut supposer que oui, et on peut supposer qu'il y a pas la même clé chez les clients et sur le firewall,etc.
# Nop, bug d'OpenSSH
Posté par Pinaraf . Évalué à 10.
Hé non…
C'était super tentant, j'ai paniqué aussi…
Mais c'est qu'un bug d'OpenSSH.
J'ai pu reproduire le même message alors qu'aucune clé SSH dans mon authorized keys ne correspondait…
Dès qu'il y a un from sur une clé, si on tente de se connecter avec une clé, même hors de la liste, ça provoque ce message.
[^] # Re: Nop, bug d'OpenSSH
Posté par MrLapinot (page perso) . Évalué à 3.
Merde, tu as raison.
Je poste un rectificatif.
[^] # Re: Nop, bug d'OpenSSH
Posté par siegfried . Évalué à 1.
Nevermind tu as raison, testé et ça donne bien ce résultat.
Pourtant à moins que j'ai lu de travers, mais il m'avait semblé qu'OVH mentionnait un bug d'OpenSSH parlant d'un problème différent.
[^] # Re: Nop, bug d'OpenSSH
Posté par MrLapinot (page perso) . Évalué à 2.
En fait, c'est le même bug, mais dans les rapports ça ne se voyait pas parce que les gens testait avec une clé correcte malgré tout. Mais le bug se manifeste même avec une clé incorrecte.
[^] # Re: Nop, bug d'OpenSSH
Posté par siegfried . Évalué à 1.
Tout s'explique.. Merci.
Bizarre que ça ne soit pas corrigé, ça serait bien de signaler cette subtilité et éviter quelques crises cardiaques.
[^] # Re: Nop, bug d'OpenSSH
Posté par Pinaraf . Évalué à 4.
Le mieux serait que ça soit corrigé…
https://bugzilla.mindrot.org/show_bug.cgi?id=2027
[^] # Re: Nop, bug d'OpenSSH
Posté par benoar . Évalué à 1.
Dommage, ce patch est faux : la chaîne de format ne prend plus qu'un argument alors que deux sont toujours passés.
[^] # Re: Nop, bug d'OpenSSH
Posté par MrLapinot (page perso) . Évalué à 2.
En fait, le patch est non seulement faux mais aussi inutile. Le bug a été corrigé dans OpenSSH 5.6.
# Pourquoi attendre que la clef soit compromise ?
Posté par Niniryoku . Évalué à 4.
D'accord ce n'est pas de l'auto hébergement, on est pas maître de ses données, OVH est responsable, de toute façon OVH peut prendre le disque dur pour lire ce qu'il y a dessus et toussa…
Mais pourquoi attendre que la clef soit compromise pour la retirer ?
Personnellement je supprime direct le fichier /root/.ssh/authorized_keys2 quand je loue un dédié chez OVH, et supprime l'autorisation d'authentification SSH en root. (si je loue un dédié, c'est que je sais le configurer quand même, j'ai pas besoin qu'OVH s'y connecte)
Deuxième truc bizarre qu'OVH met dans la configuration par défaut, c'est un truc pour voir le status du serveur (utilisation des disques et toussa), j'ai galéré à le trouvé, regardez dans le cron.d ou crontab, je sais plus.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par lay . Évalué à 10.
Sans oublier le fichier /root/.p qui contient le mot de passe root…
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par ymorin . Évalué à 3.
Put … :-(
Bien vu ! Merci !
Hop,
Moi.
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Grégoire G (page perso) . Évalué à 2.
Certes, mais si tu changes le mot de passe du root, ce fichier est alors sans intérêt, non?
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par MrLapinot (page perso) . Évalué à 3.
Oui, heureusement il n'est pas mis à jour automatiquement !
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Mathieu . Évalué à 1.
J'imagine que ce fichier
.pest un "résidu" de leur processus d'installation automatique de serveurs.Pas de danger à l'horizon avec de tels droits.
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Xavier Claude (page perso) . Évalué à 3.
Si quelqu'un devient root grâce à une faille dans un programme, ça lui permet de connaître le mot de passe root pour pouvoir revenir plus tard pour organiser son attaque discrètement.
« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par ckyl . Évalué à 5.
Heu si t'es passé root il va pas te falloir longtemps pour connaitre le mot de passe root. Qui de toute façon n'est pas utile pour revenir. Ca simplifie juste un poil la tache, mais fichier .p ou pas c'est game over depuis bien longtemps…
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par lay . Évalué à 1.
Si l'admin fait les choses correctement, oui ça ne pose pas de problème.
Si il ne le fait pas, ça peut entrainer de grave problèmes.
Voici un exemple véridique:
Un admin débutant, pas très au courant des problèmes de sécu, à lancé un daemon teamspeak en root.
La version de teamspeak installée permettait à un attaquant de récupérer n'importe quel fichier local sur le serveur, avec donc les droits root.
Le mot de passe dans le fichier .p à donc donné un accès direct au root à l'attaquant, au lieu d’essayer de cracker le /etc/shadow en espérant que le mot de passe ne soit pas trop complexe.
C'est clairement une erreur grave de l'admin, mais la présence du .p facilite grandement le travail de piratage de la machine dans un cas comme celui-ci.
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Grégoire G (page perso) . Évalué à 1.
et il y a des logiciels qui refusent d'être lancés en root.
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Pinaraf . Évalué à 5.
Sinon…
Tu fais comme moi : mode rescue et debootstrap pour avoir une debian aux petits oignons…
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par root_rtfm . Évalué à 3.
Si je loue un dédié, je le prends sans OS et je l'installe tout seul, comme cela pas de problème de clefs SSH et autres accès non contrôlé. Sinon quel intérêt d'avoir un dédié ?
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Pinaraf . Évalué à 10.
Après, faut se mettre à la place du support OVH qui doit se prendre plein de demandes de personnes qui prennent un dédié et ne savent pas le gérer correctement…
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Moulator . Évalué à 3.
En fait, moi je commence par supprimer l'OS aussi chez OVH, pour installer OpenBSD (ne pas oublier de désactiver leur monitoring avant, sinon ça s'agite dans la foumilière).
Reynald
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.