EDIT 2
Comme promis, toutes les explications techniques ont étés fournies ainsi que les actions effectuées. C’est à lire ici. Et vous savez quoi ? Cette lecture m’a rendu fier.
Fier d’appartenir à une communauté de geek. Fier de voir que des gens qui travaillent de façon totalement bénévoles, et qui ne font probablement de l’admin sys que pour rendre service, avaient fait mieux que bien des « professionnels » de l’informatique. Et on ne parle pas de choses compliqués, mais simplement d’appliquer l’état de l’art du métier. (chiffrement avec salage, versioning des fichiers…). Cette attaque aura finalement fait moins de dégâts que si elle avait eu lieu dans n’importe quel « grosse » entreprise. Celles la même qui ont pourtant des moyens beaucoup plus importants pour se protéger, et qui surtout hébergent des données beaucoup plus sensibles. Malheureusement, ces entreprises oublient une chose. Ce n’est pas l’argent, le nombre de firewall ou la complexité des processus d’accès qui fait la sécurité. C’est l’informaticien. Lui, et la passion qui l’anime.
Oui, il faudrait des administrateurs passionnés, des gens qui ont réellement envi de protéger leur employeur, et pas simplement de toucher leur chèques à la fin du mois. Mais, personnellement, quand je voit comment sont traités ces « techniciens » chez les poids lourd du CAC40, je comprend aisément qu’ils puissent « oublier » de chiffrer des mots de passe des clients, qu’ils collent le leur sur des post-it volants (azerty09 parce qu’on est en septembre), ou qu’ils se simplifie la vie en évitant les 4 firewalls, 2 proxys et 3 machines de rebond que la sécurité leur à imposé pour accéder à… leurs machines de développement !
Bref. Sincères félicitations aux admins d’ubuntu-fr. Vous avez fait honneur aux « vrais » informaticiens.
EDIT
Il s’avère que ce ne sont pas les admins du site ubuntu-fr qui avaient un soucis, mais bien mes yeux 🙂 Voila ce que l’on peut lire dans la section forum du site (en tout petit et je doute que beaucoup l’ai lu, mais au moins l’information est présente) :
Le forum ubuntu-fr a été victime d’une attaque le 24/9 vers 11h10/11h15 (GMT+2). Nous avons effectué une revue de nos systèmes, et renforcé la sécurité de ceux-ci. Nous n’avons pas de signe indiquant que la base de données utilisateurs, dans laquelle les mots de passe sont chiffrés, ait pu être compromise.
Conclusion, la transparence existe bien sur le site ubuntu-fr, et cela me fait franchement plaisir 🙂 Je laisse en ligne mon message original, pour que tout le monde puisse voir à quel point je sais être médisant parfois 😉
Il se trouve que le site à été hacké hier midi :
Notez au passage que le « pirate » n’est visiblement pas parvenu à obtenir les droits administrateurs sur la machine (le fichier /etc/passwd étant accessible en lecture à tout le monde). Mais il à forcément eu accès au compte www-data (ou équivalent) ce qui lui à permis de modifier le site de façon très temporaire, la réaction ayant été très rapide comme vous pouvez vous en douter.
Bref, jusque la, rien d’extraordinaire, en tout cas pas de quoi faire un billet. Qu’il faille quelques heures aux admins pour préparer une communication, constater les dégâts, prendre des mesures etc, ça m’aurai également semblé d’une banalité affligeante. Sauf que, première surprise, le site est remis en ligne TRES rapidement. Serait-ce parce qu’il n’y a rien de grave ? Qu’aucun mot de passe n’a pu être compromis etc ? Personne ne peut si vite en être certain. Le minimum serait donc de prévenir les utilisateurs que leur compte est potentiellement compromis. Mais, j’ai beau attendre une communication dans ce sens, rien ne vient. Je décide donc d’écrire sur la mailing liste de la documentation.
J’espère sincèrement que la personne qui m’a répondu n’est pas un des administrateurs du site (ce que sa réponse laisse pourtant supposer) parce que voila comment elle conclu : « Alerter tous les consultants des sites ubuntu-fr qu’un serveur à été compromis sans être certain que nos mot de passe ont étés compromis est inutile. À bons entendeurs … »
Du coup, vous comprenez bien que j’ai pas eu d’autre choix que d’écrire ce billet. Et je le fais pas de gaieté de cœur hein… J’imagine déjà le nombre de posts idiots qui font fleurir sur le forum du genre « Ah bein tu vois, ubuntu, c’est pas si sécurisé que ça en fait hein ! » Et autre débilité de ce genre. Combien de fois faudra t-il alors expliquer que justement, le système linux qui était installé sur le serveur en question à au contraire très bien tenu le coup (permissions administrateur non obtenues), et que ce n’est que le site web qui à été modifié ?
Ouai, je viens de me donner pas mal de boulot la… A moi et à tous les autres contributeurs. Mais il y a des principes importants à respecter dans la vie. Comme la nécessité fondamentale de transparence de ceux qui organisent, vis à vis de ceux qui utilisent. (et cela dans tous les domaines). Ubuntu-fr à été hacké. La seule chose qui serait dramatique, ce serait de vouloir le dissimuler.
Salut,
je comprends tes inquiétudes.
Pour commencer, si cela peut te rassurer, la personne qui t’a répondu sur la ML de la doc n’est *pas* admin des serveurs.
Ensuite, et c’est censé rassurer tout le monde, nous avons la *certitude* que la table des utilisateurs n’a pas été dumpée, bien que l’attaquant aurait pu le faire. Il ne l’a pas fait. Par précaution, les mots de passes des modérateurs et administrateurs ont été changés, car l’attaquant a pu récupérer les hash salés de certains comptes critiques. (et seulement *certains* j’insiste.)
Concernant la remise en ligne rapide du forum, nous avons eu deux-trois cafouillages : puppet qui relance nginx automatiquement alors que nous examinions encore les méfaits, par exemple. Une attaque, ça ne prévient pas, et aucun des roots n’était réellement disponible hier après-midi. (Pour illustrer, une partie de la réparation s’est faite depuis un nokia E71 dans le métro parisien.)
Concernant la faille, elle n’était ni au niveau du noyau linux, ni au niveau d’Ubuntu, ni dans le code de fluxBB. Si nous traînons à publier la faille, c’est pour laisser le temps à d’autres sites vulnérables que nous avons contacté de se protéger. Ceci dit, la faille est déjà connue (par google, au moins).
Merci pour toutes ces précisions.
Le coup du serveur qui est automatiquement relancé, c’est à la fois amusant et tout à votre honneur. Quand à devoir intervenir à distance et en catastrophe sur ses machines avec les moyens du bord, je connais bien le sujet 🙂
Je suis très heureux d’apprendre que vous êtes parvenu à identifier précisément la faille utilisée (ce qui est de loin le plus compliqué à faire dans ce genre de situation il me semble…), et encore plus heureux d’apprendre que les détails techniques seront publiés ultérieurement.
Il reste juste un tout petit détail qui me turlupine, et c’est cette phrase : « nous avons la *certitude* que la table des utilisateurs n’a pas été dumpée, bien que l’attaquant aurait pu le faire ». Autant, il est facile de savoir si l’attaquant aurait pu ou non dumper la base, autant je vois assez mal comment on peut affirmer sans le moindre doute possible qu’il ne l’a pas fait. Si tu as encore un peu de temps à m’accorder, j’avoue que je serai très curieux d’en apprendre plus à ce sujet, que ce soit ici ou par mail.
J’allais justement revenir sur ce point. (le dump de la base)
Nous avons, dans le log nginx, le poids de toutes les requêtes exécutées par l’attaquant. Notre table d’utilisateurs est assez grosse, et un dump de celle-ci ne passerait pas inaperçu dans ce log. C’est pourquoi j’ai osé le mot « certitude ».
Aujourd’hui, nous avons cependant trouvé les traces d’une tentative de dump, partiel. Nous avons donc perdu cette certitude, et nous préparons une communication à ce sujet. Ce n’est que mon avis, mais il me semble que ce bout de dump n’ait été fait que pour aider l’attaquant à comprendre la structure SQL, avant de se projeter administrateur pour les besoins de son screenshots-preuve.
En parallèle, nous continuons de contacter plusieurs gros sites qui ont visiblement la même faille. (Pas tous sous Ubuntu, pas tous sur Nginx, et pas tous sur fluxBB.)
Clair et précis, merci 🙂
Une toute dernière question et nous aurons fait le tour du sujet. Une fois le moment venu, ou comptez vous publier les détails techniques ? Sur le forum d’Ubuntu-fr ? Sur une mailing liste particulière ? Ailleurs ?
Probablement sur le forum, au même endroit que l’avertissement déjà en place.
Merci de garder confiance en nous, hoper 🙂
Vous voulez connaitre le pire, il a aussi été piraté (gentiment) par une débutante en informatique en début d’année 2016. Bien sûr, les admins, après lui avoir demandée des informations, ont nié que le forum avait été hacké, puis ils ont banni la fille.
Chouette mentalité… Pas étonnant qu’il y ait aussi peu de filles en informatique, et que tous les hackers français se barrent bosser pour les grosses boites de sécurité informatique à l’étranger…
———————————–
De:
sabina75@swift-mail.com
À:
forum_admin-fr@listes.ubuntu-fr.org
Sujet:
faille
Date:
Samedi, 13 Février 2016 21:12
Taille:
4 KB
Bonsoir !
Je vous fais part des possibilités d’usurper des droits aux autres
utilisateurs par page piégée interposée :
Le premier point, c’est qu’il est possible, à travers la balise URL, de
cacher un lien différent du lien affiché. Par exemple, je vais poster un
lien avec une page connue :
http://lifehacker.com/breaking-delivers-the-news-to-your-mac-or-iphone-notifi-1689398859
Et la véritable URL vers laquelle on sera envoyé en cliquant dessus sera
une URL proche :
http://lifehacker.mms.com/breaking-delivers-the-news-to-your-mac-or-iphone-notifi-1689398859
La taille de l’URL fait que l’oeil aura beaucoup de mal à voir la
différence en passant la souris dessus, donc la cible du piège pensera
que l’URL qu’il va visiter sera bien l’URL affichée.
La page contenue dans le second lien pourra contenir une meta-refresh
avec 4 ou 5 secondes d’intervalle pour que le script s’exécute dans une
iframe de 0x0 contenant une seconde page piégée avec le script en
question (voir plus bas). Ainsi, la victime verra s’afficher la bonne
page alors qu’il aura visiter la page piégée contenant le script
malicieux. A la sortie, la victime pensera avoir visité la bonne page et
ne se posera pas de question.
D’aprés mes essais, il est possible de faire envoyer un message sur le
forum, de faire créer un nouveau topic, de faire effacer ou remplacer un
ancien message et de faire modifier les données du profil (sauf mot de
passe et email). Pour les données du profil, le piège doit être ciblé
car le script nécessite d’utiliser le numéro de membre du forum.
Toujours d’après mes tests, il n’est pas possible de faire exécuter des
commandes de modération et d’administration car la page retourne une
erreur de HTTP_REFERER.
Voici un exemple de script automatique pour faire poster un message sur
mon fil :
document.getElementById(« post »).submit();
On peut aller encore plus loin en randomisant les messages et les
nouveaux topics avec du javascript. C’est à dire qu’on prépare plusieurs
messages et topics différents, renvoyant vers plusieurs liens piégés
différents, et les membres auto-spameront le forum « à l’infini » jusqu’à
ce qu’un admin ferme le forum pour trouver le probléme et une sécurité.
Les adresses IP des messages seront celles des membres réels et il
suffit de poster le premier message avec une IP maquillée pour faire
spamer un forum sans laisser de trace. Et ceci au dela du fait de faire
modifier des données profils ou effacer, voire changer des anciens
messages à l’insu du membre, toujours sans laisser de trace.
Bonne soirée !
Sabina