Journal SquirrelMail compromis...one more time !

Posté par  (site web personnel) .
Étiquettes : aucune
24
1
août
2009
SquirrelMail est un logiciel libre de webmail écrit en PHP.
Le 17 décembre 2007 un journal LinuxFR annonçait la compromission du serveur hébergeant le projet SquirrelMail et la distribution de packages compromis par l'attaquant ayant pris le contrôle du serveur.
Un cauchemar absolu donc pour l'équipe SquirrelMail, le pire qui puisse arriver à un projet. On pouvait donc espérer que les développeurs allait être plus prudents et sécuriser au maximum leur serveur...et bien c'est vraiment raté !

Le 16 juin dernier, avec une curieuse sensation de déjà vu, la compromission du serveur SquirrelMail a été annoncée par un mail laconique sur la liste de diffusion.
Les administrateurs, pensant à la réputation de leur projet, se sont voulu rassurants :
"The project administrators took immediate action to mitigate any futher compromises, locking all accounts out, and resetting critical passwords.
At this time, the SquirrelMail project administrators have shutdown access to the original server, and put a temporary hold on access to the plugins. It is believed that none of the plugins have been compromised, but further investigations are still being executed.
The compromise of this server does not include a compromise of the source control, which is hosted on a separate repository managed by SourceForge
".

Bon donc en gros le serveur a été compromis mais à priori ("It is believed") l'attaquant n'a rien pu faire.
Hélas, trois fois hélas, le 31 juillet il a été annoncé que plusieurs plugins de SquirrelMail avaient en fait été trojanés :
"During the initial announcement, we'd mentioned that we did not believe that any of the plugins had been compromised. Further investigation has shown that the following plugins were indeed compromised:
- sasql-3.2.0
- multilogin-2.4-1.2.9
- change_pass-3.0-1.4.0
Parts of these code changes attempts to send mail to an offsite server containing passwords. We cannot establish a timeline of when these plugins were compromised
".

Ouch ! Le plus inquiétant est évidemment la phrase finale qui indique que les développeurs du projet ne savent absolument pas depuis quand ces plugins sont compromis. Les utilisateurs actuels de ces plugins sont invités à télécharger de toute urgence les versions saines se trouvant sur le site SquirrelMail.
Une fois cette action d'autodéfense effectuée les utilisateurs de SquirrelMail pourront souffler...jusqu'à la prochaine fois.
  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 10.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Hit me baby one more time !

      Posté par  . Évalué à 9.

      C'est pas comme si c'etait arrivé a redhat : http://rhn.redhat.com/errata/RHSA-2008-0855.html / http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3844

      PS : ils utilisaient du gpg
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Hit me baby one more time !

          Posté par  . Évalué à 1.

          En même temps, on parle bien de passphrase, pas de mot de passe de 4 caractères, si tu joue le jeu, il est impossible de la bruteforcer sans une chance incroyable (ça fait combien de possibilités, 76 (environ, le nombre de caractères possibleset probablement utilisés pour un mot de passe : nombres, lettres minuscules et majuscules, et caractères spéciaux).
          Ça nous donne quoi, en prenant une phrase de 30 caractères, 76**30 possibilités ?
          D'après python, ça donne 265709919867685594851732658691842953382258130662117605376 possibilités.
          Donc si il y a eu bruteforce, c'est quand même une erreur de leur part (mauvaise phrase de passe).
        • [^] # Re: Hit me baby one more time !

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

          Si la passphrase est bien foutue, je vois pas trop le problème qu’il y a à laisser traîner la clé. Bon, évidemment, il ne FAUT PAS le faire, mais bon, c’est pas si grave que ça.
    • [^] # Re: Hit me baby one more time !

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

      Justement, à la suite de ce journal (merci à l'auteur pour l'info en passant) je me suis demandé s'il n'était pas temps de penser à une alternative. J'avais testé Roundcube par le passé mais il était encore un peu jeune. En retournant sur leur page je n'ai pas vu non plus de signature mais un simple checksum, MD5 qui plus est...

      D'autre part si un serveur est compromis comment peut-on faire encore confiance à une signature s'il n'y a pas une véritable chaine WOT derrière ? Qui te dis que l'admin n'a pas ses clefs sur le serveur avec un mot de passe à 4 lettres ?
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 5.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Hit me baby one more time !

          Posté par  . Évalué à 5.

          C'est peut-être une idée tordue, mais je soupçonne que les développeurs de webmail ne soient pas aussi choqués par l'idée d'avoir un clé gpg privée sur un serveur public:

          Le but du webmail, c'est d'avoir accès à un client de n'importe où via n'importe quelle machine.

          Suppose que tu veuilles faire tes mails depuis chez ta tantine, il va bien falloir que tu y ais accès à cette clé privée. (Je sais: sur la clé usb, tout ça. Tu peux donc aussi y mettre ta distro live et du coup pourquoi t'as besoin d'un webmail? On suppose donc que t'as pas de clé usb!).

          A ce moment, pouvoir la récupérer sur un serveur ne parait pas si bizarre!

          (Par contre, pour sécuriser des paquets et des archives, ça me paraît vachement moins important de les avoir sur le serveur public, c'est sûr!)
          • [^] # Re: Hit me baby one more time !

            Posté par  . Évalué à 2.

            C'est peut-être une idée tordue, mais je soupçonne que les développeurs de webmail ne soient pas aussi choqués par l'idée d'avoir un clé gpg privée sur un serveur public:

            On discutais avec quelques devs du support gpg dans roundcube, et pour le coté serveur faudra stoquer les clés privées.. sur le serveur. Ça pue mais y'a pas d'autre solutions...

            Enfin perso je veux implémenter ça coté client avec FireGPG :p
            • [^] # Re: Hit me baby one more time !

              Posté par  . Évalué à 1.

              La discussion a eu lieu aussi pour Squirrelmail. Eux ont fait le choix de ne pas implementer de chiffrage/signature gpg dans le webmail. Du coup, pas moyen de faire du GPG avec Squirrelmail.

              Pas moyen ? Bah quand y'a besoin, on s'en sort. Y'a un plugin GPG pour squirrelmail. Et... les cles privees sont sur le serveur !

              Ah, et sinon, je viens de voir que squirrelmail-1.4.19 est propose au telechargement accompagne d'une signature gpg (en plus du md5/sha qu'il y avait avant)
        • [^] # Re: Hit me baby one more time !

          Posté par  . Évalué à 3.

          Si la seule force de la clef privée réside dans le fait que tu espères que personne ne viendra lire tes fichiers, ce serait un peu merdique les clefs privées, heureusement qu'elles sont chiffrées avec un bon vieux mot de passe !
  • # ...

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

    Au moins lui n'a pas rejeté la faute sur OpenSSH comme c'est la mode en ce moment ...

    Perso j'adore Squirrelmail parce qu'il n'a pas besoin de base de donnée inutile pour juste lire et envoyer des mails. Par contre qu'est ce qu'il est moche ... faudrait un compromis ça serait super.

    Bon on va sûrement me dire : fais le toi même mais malheureusement j'ai pas le temps donc en attendant j'applaudis ce superbe projet.
    • [^] # Re: ...

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

      faudrait un compromis ça serait super.

      Une fois en 2007 et une fois en 2009, je ne vois pas ce que tu demandes de plus !
  • # Quitte à tout mettre chez SourceForge

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

    Hélas, trois fois hélas, le 31 juillet il a été annoncé que plusieurs plugins de SquirrelMail avaient en fait été trojanés :

    Ce qui me surprend c'est que SquirrelMail en lui même est stocké chez SourceForge:
    http://prdownloads.sourceforge.net/squirrelmail/squirrelmail(...)

    Mais les plugins (j'en ai pris un au hasard) sont stockés chez eux:
    http://www.squirrelmail.org/plugins/server_settings_backend-(...)


    Quelle est la logique? Bénéficier du mirroiring avec SquirrelMail mais pas avec les plugins? Je ne vois pas qu'est-ce qui les empêches de tout basculer chez SF.
  • # Je veux pas être méchant..

    Posté par  . Évalué à 7.

    Les utilisateurs actuels de ces plugins sont invités à télécharger de toute urgence les versions saines se trouvant sur le site SquirrelMail.

    A l'heure actuelle, si j'étais un utilisateur SquirrelMail, c'est pas du tout ce que je ferais.

Suivre le flux des commentaires

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