Journal Compromission de clé SSH chez OVH

Posté par (page perso) . Licence CC by-sa
-1
20
juil.
2012

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 . É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 (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 . É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.

  • # Pourquoi attendre que la clef soit compromise ?

    Posté par . É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 . É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 . Évalué à  3 .

        Sans oublier le fichier /root/.p qui contient le mot de passe root…

        Put … :-(

        Bien vu ! Merci !

        Hop,
        Moi.

      • [^] # Re: Pourquoi attendre que la clef soit compromise ?

        Posté par (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 (page perso) . Évalué à  3 .

          Oui, heureusement il n'est pas mis à jour automatiquement !

          • [^] # Re: Pourquoi attendre que la clef soit compromise ?

            Posté par . Évalué à  1 .

            J'imagine que ce fichier .p est un "résidu" de leur processus d'installation automatique de serveurs.

            # ls -l .p
            -rwx------ 1 root root 13 Jul 20 10:30 .p
            
            

            Pas de danger à l'horizon avec de tels droits.

            • [^] # Re: Pourquoi attendre que la clef soit compromise ?

              Posté par (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 . É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 . É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 . É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 . Évalué à  3 .

      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

      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 . Évalué à  10 .

        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é ?

        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 . É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

Suivre le flux des commentaires

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