Journal apache.org compromis

Posté par  (site web personnel) .
Étiquettes : aucune
8
28
août
2009
La fondation apache a été piratée. Les sites sont arrêtés.

Pour rappel, la fondation Apache, en plus du serveur du même nom, c'est Tomcat, Ant, Cocoon, Xalan... Un tas de gros projets libres utilisés en entreprise.

http://apache.org/


The Infrastructure Team of The Apache Software Foundation is currently investigating a
potential compromise of one of our servers. For security reasons most apache.org
services are therefore offline, but will be restored shortly. We apologies for any
inconvenience this may cause.

10:42am UTC: Compromise was due to a compromised SSH Key, not due to any software
exploits in Apache itself.

More details soon.


Ben voila, il va falloir se mettre à IIS et .Net. maintenant... :o)

  • # Détails

    Posté par  . Évalué à 4.

    Vu qu'il y a un journal (et que ce n'est pas le premier), autant demander plus détails :

    Concrètement pour un newbie comme moi, que signifie une clée SSH compromise?
    Ils se sont rendu compte qu'elle avait changé lors d'une connexion distante et le client ssh à râlé, ou bien c'est un poil plus compliqué ?
    Qu'existe t il comme outils pour détecter ce genre de corruption ? (msec, des trucs comme ça ?)
    Que peut on faire pour éviter ce genre de situation (j'imagine que si on savait, ça arriverait pas...)

    C'est juste par curiosité informatique, personne est obligé de répondre, hein ;)

    • [^] # Re: Détails

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

      Le ~ d'un utilisateur autorisé a été compromis quelque part d'une façon ou d'une autre (un ~ sur un serveur NFS ?), la clef SSH stocké dedans a été utilisé pour accéder aux serveurs d'apache.org.
      Et on peut pas faire grand chose contre çà, vu qu'il ne s'agit pas vraiment d'une faille ...

      • [^] # Re: Détails

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

        la clef SSH stocké dedans a été utilisé

        Une clé non protégée pour un utilisateur... pas bien.

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

        • [^] # Re: Détails

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

          Le ssh-agent a peut être été compromis.
          Ou alors c'était une clef crée par une machine debian avec openssl sans entropie.

    • [^] # Re: Détails

      Posté par  . Évalué à 10.

      Une clé SSH est un couple de deux fichiers, l'un privé et l'autre public qui permet de s'authentifier sans présenter le mot de passe du compte SSH.
      Le fichier public est stocké sur le serveur auquel on veut se connecter et le fichier privé est gardé secret et hors de portée (généralement). On ne se sert du second qu'au moment de l'authentification.

      Par contre dans ce cas précis, la compromission ne dit pas si le fichier privé a été volé ou alors si il le compte a été attaqué sur une clé avec un niveau de sécurité faible.

      Quant à détecter ce genre de compromission c'est assez difficile car si la clé est volée, l'authentification n'a rien d'anormal. Si la clé est attaquée, on peut par contre plusieurs échecs d'authentification dans les logs.
      Je pense que la compromission a du être découverte suite à un comportement anormal de l'utilisateur qui s'est fait choper son compte.

      L'intérêt d'utiliser des clés SSH est néanmoins intéressant car même si l'attaquant usurpe l'identité de l'utilisateur il ne connaît pas ses mots de passe et ne peut donc pas immédiatement gagner des privilèges sur le système (sauf présence d'une faille de sécurité sur le système).

    • [^] # Re: Détails

      Posté par  . Évalué à -5.

      une clé SSH est un genre de mot de passe compliqué qui permet de t'identifier de manière unique et de signer un document électronique (on peut donc vérifier que c'est bien toi qui a signé).

      Le fait que une clé SSH a été compromise veut dire que quelqu'un a soit réussi à pirater le 'mot de passe' (très compliqué et très long) soit qu'il a réussi à récupérer le 'mot de passe' quelque part (bien plus probable).

      Pour la détection, ils ont détectés des manœuvres douteuses sur leur serveur et ont identifié d'où ca venait.

      Pour corriger ce problème, il faut qu'ils enlèvent tous les droits d'accès de la clé SSH incriminée, trouver où la personne a eu accès à cette clé et déployer une nouvelle clé.

      Pour éviter ça, tout le monde connait le système : éviter de laisser ses mots de passe partout...

      • [^] # Re: Détails

        Posté par  . Évalué à 10.

        J'aime bien ton explication. Ne serais tu pas journaliste?

    • [^] # Re: Détails

      Posté par  . Évalué à 2.

      que signifie une clée SSH compromise?

      Ça peut être une clé générée sur Debian...

  • # Le problème ne vient pas apparemment d'Apache

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

    10:42am UTC: Compromise was due to a compromised SSH Key, not due to any software
    exploits in Apache itself.
    Le problème ne vient pas d'apache mais de la clé SSH. Donc, IIS et .Net, tu peux les oublier...

    • [^] # Re: Le problème ne vient pas apparemment d'Apache

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

      La question est tout de même de savoir s'il y a un risque de corruption du code, et des exécutables des projets gérés par la fondation Apache.

      L'introduction d'une backdoor dans tomcat ou apache aurait des conséquences très très lourdes, vu l'utilisation massive de ces logiciels.

      Tant qu'on a pas la certitude que rien n'a été compromis, la remarque sur IIS n'est pas complètement dénuée de sens.
      (ha, on me souffle à l'oreille que IIS n'a pas besoin d'un piratage de microsoft.com pour avoir des backdoor, it's not a bug, it's a feature :-)

      • [^] # Re: Le problème ne vient pas apparemment d'Apache

        Posté par  . Évalué à 3.

        Compromettre un serveur support et compromettre le code d'un projet n'est pas tout à fait la même chose...

        Il faudrait trouver le moyen dans le gestionnaire de conf, d'inclure une backdoor sans que personne ne remarque le changement... Ce qui me semble assez peu probable sur un projet de ce genre et surtout après la publicité de la compromission d'un serveur. Qui plus est, il faudrait que la prochaine release soit buildée avec cette backdoor...

        Cela dit, ce n'est pas une très bonne publicité en effet.

      • [^] # Re: Le problème ne vient pas apparemment d'Apache

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

        Des projets comme ça sont géré par subversion ou autre gestionnaire de versions. Il sera facile de voir des modifications du code, des ajouts de fichiers etc.
        Faudrait que le pirate soit bien décidé pour entrer aller modifier également le contenu de l'arbo de développement, ainsi que les inévitables sauvegardes quotidiennes distantes, grâce auxquelles ont peut aussi faire des comparaisons.

      • [^] # Re: Le problème ne vient pas apparemment d'Apache

        Posté par  . Évalué à 4.

        La question est tout de même de savoir s'il y a un risque de corruption du code

        C'est une compromission par Monsieur Ducon alors... parce que foutre en l'air de serveur pour faire passer des backdoors dans le code sans qu'on s'en rende compte, c'est super discret !

  • # Non...

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

    Il suffit que je poste mon journal avec la petite phrase de fin qui va bien pour qu'ils basculent leurs serveurs... :(


    10:53am UTC: We have restored services on our european mirror machine which was
    not compromised. DNS should be shifting you over right about ... now..

    • [^] # Merci Murphy !

      Posté par  . Évalué à 10.

      Génial ! Grâce à la loi de Murphy, tu as réparé les serveurs Apache.

      • [^] # Re: Merci Murphy !

        Posté par  . Évalué à 10.

        DNS should be shifting you over right about ... now..

        Rassures toi, on va pouvoir troller sur les TTL trop bas des DNS.

  • # Ce n'est pas une faille de sécurité de apache

    Posté par  . Évalué à 3.

    Pas besoin de se mettre à IIS puisque les serveurs Apache n'ont pas de problème, c'est une clé SSH 'compromise' qui a été utilisée pour pirater les serveurs de Apache.org.
    En gros, un mot de passe a été piraté mais pas le programme

    • [^] # Re: Ce n'est pas une faille de sécurité de apache

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

      Bonsoir,

      Utiliser des clefs SSH sans phrase-pass, c'est prendre un risque et obtenir ce type d'accident.

      S'il y avait eu une passe-phrase sur la clef ce ne serait pas arrivé.

      Ou alors il y avait un programme pour lire le clavier ce qui aurait permis à l'intrus de connaître la pass-phrase.

      je ne fait que des hypothèses...

      A bientôt
      Grégoire

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: Ce n'est pas une faille de sécurité de apache

        Posté par  . Évalué à 10.

        > S'il y avait eu une passe-phrase sur la clef ce ne serait pas arrivé.

        À partir du moment ou un compte utilisateur est compromis il est très facile de récupérer la clé SSH associée, mot de passe ou non. Le mot de passe protège des vols de la clé par accès au support de stockage (partage NFS, clé USB, mauvaise permission de fichier, vol de laptop etc.) pas plus.

        http://people.apache.org/~jim/committers.html ça en fait des possibilités de clés à voler. Sans parler de tout les process automatiques...


        Au passage c'est moi ou y'a beaucoup de gens qui balance des trivialités ou du n'importe quoi avec condescendance ? Vu le niveaux des commentaires je trouve ca assez déplacé de casser du sucre sur l'équipe infrastructure d'apache qui jusqu'à preuve du contraire est très compétente... Sur ce cas précis 12 heures entre la compromission et la détection/analyse/prise de mesures/communication/restauration de service sur de la prod c'est du beau boulot. On peut voir le palmarès des donneurs de leçon ?

        • [^] # Re: Ce n'est pas une faille de sécurité de apache

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

          Bonsoir,

          À partir du moment ou un compte utilisateur est compromis il est très facile de récupérer la clé SSH associée, mot de passe ou non. Le mot de passe protège des vols de la clé par accès au support de stockage

          Est ce que si j'oublie ma clef USB contenant ma clef privée (avec pass-phrase) quelqu'un pourra se servir de cette clef? (sans connaître la passe-phrase).

          Si le compte utilisateur est compromis, on est bien d'accord qu'il est possible de placer un script pour lire le clavier, et donc découvrir la pass-phrase. n'est ce pas?

          C'est juste pour que ce soit plus clair pour moi.

          A bientôt
          Grégoire

          Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

          • [^] # Re: Ce n'est pas une faille de sécurité de apache

            Posté par  . Évalué à 4.

            > Est ce que si j'oublie ma clef USB contenant ma clef privée (avec pass-phrase) quelqu'un pourra se servir de cette clef?

            C'est le but de la protection par chiffrement symétrique (passphrase) de la clé privé. Voler la clé sur le support de stockage ne suffit pas pour avoir une clé opérationnelle.

            Après dire qu'il suffit d'avoir une passphrase pour que ce genre d'événements n'arrive pas, ca me semble un tantinet naïf...

          • [^] # Re: Ce n'est pas une faille de sécurité de apache

            Posté par  . Évalué à -1.


            Est ce que si j'oublie ma clef USB contenant ma clef privée (avec pass-phrase) quelqu'un pourra se servir de cette clef? (sans connaître la passe-phrase).

            Ah par ce que tu as l'habitude de stocker ta clef privée sur une clef USB ?

          • [^] # Re: Ce n'est pas une faille de sécurité de apache

            Posté par  . Évalué à 2.

            prend une "iron key" qui fait un "secure delete" de toute la mémoire si on c'est trompé plus de n fois.

            j'en acheterais bien une, mais ça douille /o\
            https://www.ironkey.com/

  • # plus d'info

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

    sur le blog d'apache

    https://blogs.apache.org/infra/entry/apache_org_downtime_ini(...)

    • [^] # Re: plus d'info

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

      Cela ne serait même pas la faute d'un utilisateur négligent :

      an account used for automated backups for the ApacheCon website

      Ce genre de compte n'est-il pas censé être protégé ? (pas d'accés shell notamment ?)

      • [^] # Re: plus d'info

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


        The attackers created several files in the directory containing files for www.apache.org, including several CGI scripts. These files were then rsynced to our production webservers by automated processes. At about 07:00 on August 28 2009 the attackers accessed these CGI scripts over HTTP, which spawned processes on our production web services.

        Le compte ne laisser pas d'accès au shell mais comme là il a s'agit d'écrire au bon endroit des scripts, l'accés shell est inutile.

        C'est une attaque bien conçu, loin d'être une attaque automatique car il y avait quelqu'un derrière le clavier pour réfléchir à comment atteindre sa cible.

        • [^] # Re: plus d'info

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

          Justement, ma question est, comment ces scripts ont-il pu être écrits sans accés shell ?

          Via apache ? Mais dans ce cas là ce serait la configuration qui serait mauvaise ?

          (Pour répondre au commentaire précédant, loin de moi l'idée d'être condescendant, j'ai juste envie de mieux comprendre)

Suivre le flux des commentaires

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