Sujets-libres.fr

Informatique, logiciels libres, internet, humeurs et… le reste !

web

L'abus de requêtes inter-domaines

Rédigé par -Fred- / 19 octobre 2016 / Aucun commentaire

S'il y a un truc qui me pose problème quand je navigue sur le web, c'est bien les requêtes inter-domaines. Prenez un site quelconque, et regardez la liste des domaines hébergeant les ressources nécessaires à l'affichage d'une page. On peut s'amuser à les compter si on veut (un petit "tcpdump port 53" par exemple est assez instructif). A titre indicatif, se connecter sur www.lemonde.fr nécessite d'effectuer plusieurs dizaines de requêtes DNS, pointant vers presque autant de domaines différents. Histoire de ne pas en accabler un plus qu'un autre, tout en restant dans les journaux en ligne, le constat est identique pour www.mediapart.fr , pour rue89.nouvelobs.com ou pour www.ouest-france.fr.

Sans forcement examiner dans le détail l'ensemble des domaines contactés, dans le lot on voit quand même passer beaucoup de domaines dont on sent bien qu'ils ne sont pas là pour apporter des contenus mais plutôt pour tracer l'activité des visiteurs ou pour afficher de la pub.

J'ai pris l'exemple des journaux en ligne mais bien entendu, ça ne se limite pas à eux (allez voir la page d'accueil de www.marmiton.org pour rigoler). Je constate que c'est plutôt, et de loin, la norme pour les sites un peu gros générant du trafic. Les sites plus confidentiels sont globalement plus propres de ce point de vue. Je me doute bien que les sites en question n'ont pour vocation première de pister leurs visiteurs mais ils font peut être quelque chose de plus grave : globalement ils s'en fichent, tout simplement.

Ce qui est gênant, pour l'internaute que je suis en tout cas, c'est de voir que parmi les sites abusant de ce type de pratiques, on retrouve à peu près toujours les mêmes fournisseurs de services CDN, les mêmes outils d'analyse de trafic, les mêmes régies de pub. Indépendamment c'est sûr rien à signaler car il n'y a pas d'entente à proprement parler entre les gestionnaires des sites en question mais à grande échelle, ils font tous les mêmes choix et créent ainsi, sans vraiment s'en rendre compte, de la centralisation.

Quand on met en place un outil sur son site, on se doit de prendre en compte tout les aspects de l'outil en question. Les gestionnaires de ces sites sont peut être entre l'enclume et le marteau car ils doivent composer avec des contraintes économiques et probablement tout un tas d'autres choses. Pour autant, ils sont les premiers responsables du pistage des internautes car ce sont eux, chacun dans leur coin mais quand même tous ensemble finalement, qui placent la majeure partie des sondes pour le compte des gros silos de données.

C'est principalement pour cette raison que j'utilise le plugin request policy dans firefox. Ça ne résoud pas tout, loin de là mais ça permet de faire un peu le ménage. A l'usage, je dois quand même régulièrement autoriser l'accès à tel ou tel CDN pour voir les contenus sur tel ou tel site. En de rares occasions, je constate même que pour accéder aux contenus de certains sites il faut autoriser l'accès à un grand nombre de domaines depuis tel autre domaine, ce qui est déplaisant car j'ai parfois l'impression que ça ne s'arrête pas.

Limites des réseaux sociaux

Rédigé par -Fred- / 21 septembre 2016 / Aucun commentaire

Les réseaux sociaux tels qu'on les connaît aujourd'hui ont vraiment modifié la manière de communiquer sur Internet. On pourrait aller jusqu'à dire qu'il y a un avant et un après. A une époque pas si lointaine encore, si l'on voulait communiquer sur Internet (et le web en particulier), on se construisait son propre site et on pouvait ensuite l'alimenter. Chaque site était différent et potentiellement géré par des acteurs différents eux aussi. Cette manière de faire fonctionne même si chacun propose des contenus dans son coin car des liens se tissent entre les pages. C'est à mon sens quelque chose de très important en fait car le système n'est pas centralisé.

Ils (les réseaux sociaux) fonctionnent sur le web mais pour autant, leur fonctionnement est un peu différent. Il faut les voir comme une couche intermédiaire entre l'utilisateur et le web. Lorsqu'il modifie sa page ou ajoute du contenu dans son profil de réseau social, l'utilisateur ne poste pas tant sur le web que sur la plateforme du réseau social qui lui est présent sur le web. La nuance est importante car bien que ce soit les utilisateurs qui apportent leur contenus au réseau social, c'est bien le réseau social lui même qui organise ces données ensuite et les met en valeur. Ces quelques sites sont tellement utilisés qu'ils sont à juste titre considérés comme des points de centralisation sur Internet. Si j'osais la comparaison, on pourrait dire qu'on est passé d'une démarche "artisanale" à une démarche "industrielle".

A l'heure où les blogs et autres page perso sont souvent remplacés par des simples pages facebook ou des comptes twitter, l'information y est donc concentrée. Cela va même plus loin car ces réseaux deviennent les canaux de communication principaux de bon nombre de communicants. Du côté de ceux qui recherchent l'information, ces médias deviennent vraiment incontournables et c'est ainsi que l'on rentre dans un cercle vicieux.

Dans leur recherche de confort, d'efficacité et de simplicité d'usage, bon nombre de communicants ont délégué à quelques entreprises la gestion des outils sur lesquels il s'appuient pour communiquer. On le constate vraiment à différents niveaux, depuis l'internaute lambda jusqu'aux politiques en passant par les journalistes. Globalement, ça peut concerner tout ceux ayant à un moment donné besoin de communiquer.

Ces plateformes centralisées posent plusieurs problèmes dont l'un concerne la censure. En fait, même si ce n'est pas leur but, les plateformes de réseaux sociaux doivent être à même de prendre des mesures permettant de retirer des contenus qu'ils hébergent lorsque ces contenus sont signalés comme posant un problème. Les raisons peuvent être multiples, violation de copyright, contenus violents, racistes, terroristes, etc ... Devant la masse d'informations gérées par ces sites, des procédures sont mises en place afin qu'il ne soit pas nécessaire d'engager une armée de modérateurs. Tout le monde peut ainsi remonter au réseau social des contenus inapproprié à faire enlever. Le site en question peut alors agir en écartant les contenus et en suspendant le compte de celui qui les a postés.

Ce qui est grave avec ce système, c'est que le fond n'est pas analysé immédiatement. C'est le ou les signalements qui ont de l'importance car c'est ce qui motive la suppression de contenus ou la suspension de compte (quitte à y revenir ensuite mais le mal est déjà fait). Ce procédé permet, au même titre qu'un DDOS mais en plus simple, de nuire à la capacité de communication d'une personne ou d'un groupe sur Internet. Voilà pourquoi il est important de ne pas dépendre uniquement des réseaux sociaux pour gérer sa communication sur internet. A ceux qui veulent faire passer des informations, prévoyez un site, une mailling list ou tout autre moyen neutre vous permettant de communiquer normalement. Les réseaux sociaux ne devraient être qu'un moyen parmi d'autre de communiquer et si vous en dépendez, vous devriez considérer que cela pose un problème. Accessoirement, amener les discussions à se dérouler via des outils neutres, ça permet à des olibrius dans mon genre de suivre un peu mieux ce qui se passe et se dit en marge des actus et autres billets de blogs.

Malgré cela, même ceux qui ont conscience du problème (les médias notamment) ne peuvent pas grand chose si ceux qui les suivent ne changent pas eux aussi leurs habitudes. Dernièrement, c'est le site Reflets qui a fait les frais d'une suspension abusive de deux comptes twitter (la Fachosphère ayant signalé des contenus inapproprié sur ces comptes ; twitter a réagit, sans autre forme de procès). Ni une ni deux, les administrateurs du site Reflets ont eu la bonne réaction en proposant une mailling list permettant à tout ceux qui le souhaitaient de pouvoir communiquer entre eux. Deux jours plus tard, les comptes twitter ont été réactivés et la mailling list ne vit pas beaucoup (je ne connais pas l'activité des comptes twitter mais ce serait intéressant de comparer, à titre indicatif). Ça me fait dire qu'on a beau avoir conscience des limites du système, on est pas près d'abandonner notre petit confort...

Bienvenue à Bonemine

Rédigé par -Fred- / 24 juin 2016 / Aucun commentaire

Après plusieurs années de bons et loyaux services, Abraracourcix, mon modeste serveur va passer la main à Bonemine. La config de cette nouvelle machine est la suivante :

  • Athlon 5150
  • 8Go de DDR3
  • DD de 1To
  • Alim Corsair 350W
  • GNU/Linux Debian 8

La config n'est pas monstrueuse mais amplement suffisante pour accueillir plusieurs machines virtuelles. La préparation du serveur va prendre quelques jours mais je devrais pouvoir le mettre en production début juillet si tout va bien.

Un changement de machine est l'occasion de refaire les choses proprement. L'utilisation de machines virtuelles va notamment me permettre d'en dédier à certains usages et donc de mieux cloisonner les différents services que j'utilise. Ceci dit, cela fait plus de machines à administrer au quotidien. Je dois donc encore choisir l'outil qui me permettra de garder un œil sur tout ça. Aujourd'hui, j'utilise Munin pour surveiller l'activité d'Abraracourcix mais je vais quand même faire le tour des solutions existantes pour trouver la plus adaptée.

Abraracourcix ne sera pas totalement démobilisé. Une fois que Bonemine sera en production, il sera reconfiguré pour resservir au cas où Bonemine venait à défaillir (il vaut mieux prévenir que guérir :p ).

Mise à jour blog vers PluXml 5.5

Rédigé par -Fred- / 06 avril 2016 / Aucun commentaire

Le blog évolue et passe de PluXml 5.4 à PluXml 5.5 . La mise à jour s'est effectuée sans incident. Une fois les nouveaux fichiers copiés (tous sauf les répertoires /data, /plugins et /themes, ainsi que le fichier config.php) et leurs droits vérifiés, il suffit de se rendre sur le blog et d'exécuter la mise à jour proposée afin de finaliser la migration. C'est tout.

J'apprécie toujours autant la simplicité d'utilisation de ce CMS. Merci donc aux contributeurs.

Page officielle du projet : www.pluxml.org

Blog compromis, ma réponse à l'incident

Rédigé par -Fred- / 06 octobre 2015 / 2 commentaires

Je vois peu de retours d'expérience concrets sur le net, alors je vais vous livrer le mien. Je ne suis pas spécialiste de la question. Mon analyse est donc probablement imparfaite ou incomplète. Toutefois, je le fais pour plusieurs raisons :

  • Les quelques visiteurs qui passent ici doivent savoir si mon blog est, ou a été, à risque.
  • Communiquer sur un cas réel me semble intéressant. Il est désagréable de parler de son propre cas mais au moins, j'ai accès à toutes les informations.
  • Si je suis en mesure de faire des erreurs, je ne dois pas être le seul. Expliquer quelles ont été mes erreurs pour que d'autres ne les commettent pas ne peut être que bénéfique.
  • Donner la possibilité à mes visiteurs de me faire un retour, notamment sur ma manière de réagir à cet événement, sera peut être pour moi l'occasion de progresser.

Analyse

Comment cela a été possible ?

J'ai passé un peu plus de temps à analyser mes logs et les seules informations que j'ai pu trouver se trouvent dans les logs d'apache. Rien ailleurs et pour cause, les faits datent du 5 novembre 2014. Il n'y a donc plus rien à voir dans les autres logs depuis longtemps.

Je constate donc une forte activité de la part de l'attaquant le 5 novembre 2014, date à laquelle l'un des fichiers a été déposé et exploité. Le fichier en question est un script php déposé dans un répertoire que j'avais créé manuellement à la racine de mon blog wordpress (pas grand chose dans ce dossier à part des photos présentes sur mon blog et quelques bricoles).

Je suspecte donc que l'un des plugins ou l'un des thèmes utilisé sur mon blog contenait une faille permettant l'upload de fichiers. Je précise toutefois que les plugins et thèmes utilisés proviennent tous de sources officielles (trouvés et installés via le panel d'administration du blog). J'écarte peut être trop vite Wordpress lui même mais dans le mesure où il se met à jour automatiquement, les failles connues sont comblées rapidement. Sauf à exploiter une 0 Day, c'est donc peu probable.

Certains répertoires avaient aussi des autorisations trop élevées. Je ne pense pas que ce soit du fait de l'attaquant mais plutôt moi qui a certainement un jour modifié cela (suite probablement à un problème de mise à jour wordpress).

Les logs montrent par ailleurs que pour lister les failles de mon blog et de quelques sites hébergés sur mon serveur, l'attaquant à utiliser au moins un outil open source de recherche de vulnérabilités web. L'outil en question est intéressant pour deux raisons. D'une part, il permet d'auditer ses propres sites, et d'autre part, il me permet de comprendre certains comportement étranges de mon serveur il y a quelques mois (CPU serveur chargé à presque 100% à cause d'un nombre anormal de processus apache2). J'ai donc compris que mon serveur avait fait l'objet de scans en vue d'y trouver des vulnérabilités.

A quoi servaient ces fichiers ?

Le premier fichier n'était clairement fait pour ne pas être lisible facilement (instructions codées en ascii, codes en base64, gzinflate...). Une fois décodé, il montre un peu plus ce à quoi il est destiné car il contient tout un tas de commandes permettant notamment de rechercher des fichiers sensibles du système (utilisable en environnement *nix ou windows). J'ai exécuté le fichier en machine virtuelle dans firefox (avec le module firebug) et je vois qu'il tente de se connecter à des ressources dispo sur un site externe (je continue à essayer de comprendre plus de ce côté là).

L'exécution du scripts en question en machine virtuelle montre qu'il tente de communiquer avec un serveur distant. Le domaine de ce serveur est en .ro . A ce que je peux voir rapidement, ce serveur héberge un certain nombre d'outils permettant le piratage de sites web.

Un autre fichier a été déposé plus récemment (fin juillet) et contient un exploit selinux. Un autre répertoire contient, si je comprend bien, un outil d'analyse open source. Je ne trouve pas de trace quand à l'utilisation de l'un ou l'autre de ces outils, contrairement à l'autre outil dont je parle au dessus et pour lequel je peux voir que l'attaquant l'a utilisé environ 1h sur ma machine.

Comprendre ce qui a été fait et les motivations

Je constate que l'attaquant a possiblement disposé d'une bonne vue de la structure des différents sites hébergés sur mon serveur et accessibles. Il ne me semble pourtant pas que des dégâts aient été fait. Rien non plus en base de donnée (en tout cas, s'il y a eu quelque chose à une époque, il n'en reste rien).

Actions

Actions curatives

Comme détaillé dans un billet récent, j'ai très rapidement vérifié que ma base de donnée Wordpress était saine. J'ai ensuite réinstallé une instance toute propre de Wordpress sans aucuns plugins, histoire d'avoir une solution fonctionnelle le temps de trouver une solution plus durable et plus sûre pour mon blog. La solution retenue a donc été de passer à Pluxml car l'outil correspond parfaitement à mes besoins.

Actions préventives

Pour ne pas avoir à subir un nouvel épisode de ce type, j'ai décidé d'être plus strict au niveau de la gestion de mon serveur. J'ai donc déjà nettoyé et réduit au maximum le nombre de services ouverts sur l'extérieur. Que ces autres services n'aient pas été touchés aujourd'hui ne signifie pas qu'ils ne le seront pas à l'avenir ou qu'ils ne puissent pas donner d'informations à d'éventuels attaquants. Certains services utiles ne sont plus ouverts qu'en local (munin notamment) et d'autres sont tout simplement fermés (webmail rainloop). Au niveau Web, je n'ai conservé sur l'extérieur que ce blog et deux pages statiques.

J'effectue à présent un suivi de l'activité de mon serveur de manière plus stricte. Je suis en train de réfléchir à automatiser ce qui peut l'être et qui est spécifique à mon installation. J'ai un peu chamboulé mon programme de pré-rentrée afin de remettre un peu d'ordre là où c'était nécessaire.

Conclusions

Mes erreurs ont été multiples. Je considère avoir globalement été trop laxiste, que ce soit au niveau de mes réglages apache qu'au niveau des services ouverts sur ma machine. Peu regardant aussi sur l'activité de mon blog. J'aurais, si j'avais bien fait les choses, dû voir immédiatement l'arrivée de ces fichiers.

Je considère avoir eu de la chance. Cette expérience m'a permis de connaitre l'existence d'outils intéressants d'audit de sites web. Je vois d'ailleurs mieux comment se comporte mon serveur lorsqu'il fait l'objet d'une analyse par ce type d'outil.

J'ai aussi pris conscience de l'importance des logs. Il est donc essentiel d'être réactif, sous peine de ne pas avoir de données exploitables. Se faire poutrer une fois, ça peut arriver. Ne pas avoir les éléments pour réagir, c'est l'assurance que ça arrivera une seconde fois.