Le scandale des sites gouvernementaux qui se négligent

Vous m’avez, moi comme d’autres, souvent entendu pester sur le stupide délit de négligence caractérisée et l’obligation légale faite à l’internaute de sécuriser une belle abstraction légale : « la connexion Internet». Comme sur Internet plus qu’ailleurs, niveau sécurité, les conseilleurs sont rarement les payeurs, nous avons décidé, avec Paul Da Silva et Paul Rascagneres (RootBSD), d’aller jeter un oeil sur le pas de la porte des conseilleurs… comme on s’en doutait : c’est moche. Nous pourrions vous dire que nous avons été surpris… mais soyons sérieux, nous ne l’avons pas été le moins du monde.

Dans le titre, comme vous le constatez, j’emploie le terme un peu fort de scandale. Je vous dois une explication là dessus. Avoir un site web qui comporte des trous de sécurité, ce n’est pas une honte, ça arrive à tous, on sait qu’une faille 0day (même si très rarement exploité) peut suffire à compromettre une machine. Le vrai scandale, c’est quand un prestataire alerte d’une faille importante et que les personnes en charge d’un  site web gouvernemental qui exposent des données personnelles de fonctionnaires refusent à ces prestataires , depuis des mois, des années, l’intervention nécessaire à la correction de cette vulnérabilité… pas vu pas pris…

Ce que le texte d’HADOPI appelle pudiquement le manque de diligence à sécuriser son accès doit il être appliqué aux internautes ? En ce qui nous concerne, nous avons la conviction qu’il est bien plus grave qu’un site gouvernemental « manque de diligence » à fixer des trous de sécurité qui par escalation de privilèges peuvent mettre en péril certaines infrastructures sensibles de l’État… et d’aller crier à la presse que nous sommes la cible de hackers chinois…

Il faut donc que cette hypocrisie cesse au plus vite, ou que des garanties sérieuses soient données aux particuliers pour être en mesure de se défendre. Si cette absurde circulaire de la chancellerie était appliquée, à ce jour nous pourrions très bien faire déconnecter ou bloquer  un site gouvernemental (à quand le blocage des sites sauce Loppsi pour lutter contre les pirates ?) en y uploadant quelques mp3 et quelques divx… comme ça, juste pour rigoler.

Puisque l’Elysée ne semble pas convaincu de la nécessité de se référer à des experts avant d’orienter une législation vers une bourde certaine, nous allons concourir à l’y encourager un peu.

Rentrons dans le vif du sujet

Nous découvrions récemment avec surprise que le gouvernement, qui avec la loi Hadopi instaure le délit de négligence caractérisée, n’était pas mieux logé que les autres – bien au contraire. Le délit de négligence caractérisée vise à punir celui qui, par manque de compétences techniques notamment, ne « sécurise » pas son accès à internet si celui-ci venait à être utilisé à des fins de piratage (au sens de contrefaçon… il est important de le préciser vu que même le terme de piratage est ici sujet à caution). Une belle hypocrisie quand on sait que le niveau technique requis pour sécuriser ce qui est en mesure de l’être par un abonné final est très élevé et que, même comme cela, il est toujours possible d’usurper l’identité d’un abonné pour le faire paraître coupable (avec cette fois un niveau de compétences très relatif).
Nous (RootBSD, Bluetouff et Paul) avons décidé d’élever le débat et de vérifier si l’Etat lui même applique à son parc de sites internet les mêmes recommandations que celles qu’il souhaite voir ses concitoyens adopter.
A l’attaque !
Pour ce faire la méthode a été très simple : quelques minutes par site, des recherches de failles très basiques et à la portée de n’importe quel pirate en herbe… Occasionnellement des découvertes de documents dans des répertoires accessibles à tous et, si d’aventure on venait à tomber sur une faille un peu plus sérieuse (oui c’est le cas) passer un peu plus de temps dessus pour essayer de la faire parler. Tout l’art étant de la faire parler sans l’exploiter afin de ne pas se rendre coupable d’intrusion.
Le résultat est au delà de ce que l’on aurait pu imaginer en lançant, le 29 août vers 23h, ce capture the flag d’une envergure sans précédent (3 gus dans un garage) qui se finira le 30 août aux alentours de la même heure… Nous avons décidé de patienter jusque là pour publier ce billet mais l’actualité nous a enfin convaincu à vous livrer les résultats de nos travaux nocturnes.
Comme dit précédemment nous nous sommes concentrés sur des failles simples à trouver ou à exploiter et la liste de celles découvertes est assez évocatrice :

• Une vingtaine de XSS ;
• 2 LFI ;
• Des dizaines de documents accessibles au publics et qui ne devraient pas l’être (certains marqués « confidentiel ») ;
• Des authentifications défaillante (ou inexistantes !) d’accès à des intranets ;
• Un grand nombre de fichiers robots.txt qui ont bien orienté nos recherches (merci ) ;
• Des accès aux zones d’administration / phpmyadmin comme s’il en pleuvait ;
• Des CMS non mis à jour depuis plusieurs années ! Et présentant des vulnérabilités bien connues ;
• Des logs d’envois de mails / newsletter / de connexion FTP / …
• Un site en debug qui laisse, si l’on saisit la bonne url, voir les identifiants et mot de passe de connexion à la base de données ;
• Un script SQL de génération de base de données.
• …

Le XSS ?
Le XSS (Cross Site Scripting) est une faille qui permet de faire exécuter un script arbitraire (initialement non prévu par le site sur lequel on va le faire exécuter) en changeant certains paramètres de l’URL. Il peut permettre de voler des identifiants de session ou des cookies si il est suffisamment bien utilisé et que ladite URL est envoyée à une personne connectée. Il permet aussi de transformer l’affichage du site pour afficher, par exemple, des formulaires invitant à la saisie de données personnelles qui seront ensuite transmises à un autre site. Pour finir il est egalement possible via du javascript executé sur le navigateur de récupérer des informations personnelles (historique, geolocalisation, …) mais également de récupérer des informations sur le reseau auquel est connecté la personne (scan du reseau,…).
Le LFI ?
Le LFI (Local File Inclusion) est une faille qui permet d’inclure un fichier présent sur le serveur dans la page en cours de visionnage. Ceci peut permettre par exemple de récupérer un fichier de configuration, des logs, certains fichiers confidentiels, … Dans certains cas de figure (nous l’avons vu lors de notre exercice) il est possible d’exécuter du code (php) et donc d’avoir un accès distant sur le serveur vulnérable. Cet accès peut permettre de voir des fichiers, d’en éditer (pages web,…), de lancer des programmes, de rebondir vers d’autres serveurs, télécharger des fichiers (illégaux ?)… Pour l’exploiter il faudra spécifier le chemin du fichier à récupérer dans l’URL mais ceci est relativement simple à faire lorsque le serveur qui héberge le site en question autorise le listing des répertoires ou l’affichage d’erreurs comme c’est le cas sur presque tous les sites que nous avons visité.
La liste !
Pour des raisons évidentes (on préfère le confort de notre garage) nous ne pouvons pas diffuser les failles trouvées, nous allons en revanche vous lister publiquement tous les sites qui présentent ces vulnérabilités. Nous vous livrons cependant quelques éléments – les moins graves ou deja corriges – découverts pendant cette chasse à la faille. Une version non censurée de cette liste sera livrée aux autorités afin que ces dernières puissent faire suivre à qui de droit pour que ces failles soient corrigée, ainsi qu’à quelques journalistes si ces derniers s’engagent à ne pas diffuser ces failles tant qu’elles n’ont pas fait l’objet d’une correction.
Ce qui est montrable car corrigé :

• Sur le site http://interactif.service-public.fr, une splendide Local File Inclusion permettait d’executer du code PHP depuis le site référent en lisant les un peu les logs de sa propre connexion. En formattant une URL bien sentie comme celle ci. Il devenait par exemple possible d’obtenir le mot de passe de la base de données.Voici une capture d’un log Apache obtenu par local file inclusion

LFI Service Public

• Nous avions également pu constater à cette période non moins splendide XSS dans l’application de recherche de l’Assemblée Nationale que l’on retrouvait d’ailleurs sur d’autres sites gouvernementaux dans sa version non patchée. Nous n’allons pas revenir là dessus, tout est ici.

Ce qui n’est pas montrable pas pour l’instant : Nous avons identifié des vulnérabilités plus ou moins graves sur les sites suivants :
http://questionsfrequentes.service-public.fr/ http://www.stats.environnement.developpement-durable.gouv.fr/ http://www.csti.pm.gouv.fr/ http://www.somme.pref.gouv.fr/ http://questionsfrequentes.service-public.fr/ http://larecherche.service-public.fr/ http://ddaf18.agriculture.gouv.fr/ http://www.service-civique.gouv.fr/ http://www.immigration-professionnelle.gouv.fr/ http://www.prospective-numerique.gouv.fr/ http://forum.assemblee-nationale.fr/ http://agriculture.gouv.fr/ http://www.rhone-alpes.travail.gouv.fr/ http://www.cnml.gouv.fr/ http://www.projetsdeurope.gouv.fr/ https://www.adele.gouv.fr/ http://www.education.gouv.fr/ http://www.pollutionsindustrielles.ecologie.gouv.fr/ http://recherche.application.developpement-durable.gouv.fr/ http://www.projetsdeurope.gouv.fr/ http://www.cnml.gouv.fr/ http://www.premar-manche.gouv.fr/ http://recherche.application.equipement.gouv.fr/ http://www.coe.gouv.fr/ http://www.ofpra.gouv.fr/ https://admisource.gouv.fr/ http://www.datar.gouv.fr/ http://www.ira-lyon.gouv.fr/ http://www.droitsdesjeunes.gouv.fr/ http://sig.ville.gouv.fr/ http://www.telecom.gouv.fr/ http://www.hci.gouv.fr/ http://www.oncfs.gouv.fr/ http://www.cas.gouv.fr/ http://www.permisdeconduire.gouv.fr/ http://www.europe-en-france.gouv.fr/ http://www.fonction-publique.gouv.fr/ http://www.cete-nord-picardie.equipement.gouv.fr/ http://www.minefi.gouv.fr/ https://mioga.minefi.gouv.fr/

Qu’en déduire de l’applicabilité de la négligence caractérisée ?
Ce type de failles est très simple à exploiter, prévenir ou corriger. Cependant elles sont bien là, bien présentes, dans des institutions qui disposent d’une direction informatique et de moyens, là où le particulier est lui abandonné à son triste sort, condamné à faire confiance à une solution de « sécurisation », en fait un HADOPIPOWARE qui crée plus d’insécurité qu’elle n’en crée.
Dans ce contexte, il nous apparait injuste, voire hypocrite, de faire peser sur le particulier une présomption de culpabilité et de lui interdire d’office tout droit à un procès équitable alors qu’il est lui même victime d’une exposition de ses données personnelles.
Rappelons au passage qu’une institution, même publique, au même titre qu’une entreprise, a elle aussi un devoir de sécurisation des données personnelles de tiers qu’elle stocke. Nous avons ici pu constater que ce n’était pas tout à fait au point. Si la multitude d’entreprises qui a travaillé sur ces différents sites n’est pas capable de sécuriser son travail alors qu’il s’agit de leur métier comment peut-on demander à la boulangère du coin, au maçon du centre ville ou à n’importe quel non-expert en le domaine de faire mieux ?… Et pourtant, tout indique que les entreprises en question étaient bien au courrant de certaines de ces vulnérabilités, en fait, elles en auraient même avertis les administrations concernées qui ont semble t-il manqué de diligence à combler les trous. Nous tenons évidemment ces informations de la bouche de certains de ce prestataires, et nous croyons en leur bonne foi.
Certaines failles découvertes ici (en 24h est-il besoin de le préciser à nouveau ?) permettent de prendre le contrôle du serveur si elles sont exploitées correctement. Qu’arrivera-t-il quand un pirate moins bien intentionné que nous décidera d’en exploiter une pour prendre le contrôle d’un serveur loué par l’état et d’y lancer des téléchargements par exemple ? Un site web, quelques données personnelles, un ou deux mots de passe, et voici une banale histoire de système sensible compromis…
Les sites visités et les failles ici révélées, nous permettent de prendre la mesure de l’inadaptation de la réponse proposée par la loi Création et Internet. Les premiers envois de mails que l’on nous promet imminents interviennent alors qu’aucun dispositif des sécurisation labellisé par la HADOPI n’a pas encore vu le jour. Il est d’ailleurs probable qu’à moins de se compromettre dans une labellisation hasardeuse sur des dispositifs qui opèrent une surveillance mais ne sécurisent en rien une connexion, ce projet reste lettre morte.En attendant, la consultation de la Haute Autorité sur cette question a été prolongée jusqu’à fin octobre, il est important que les professionnels qui y répondront gardent en tête une chose :

• Soit on spécifie un dispositif imaginaire qui patchera même les failles des applications des postes clients alors que les éditeurs de ces applications ne les patchent pas eux mêmes.
• Soit on spécifie un mouchard avec toutes les conséquences en terme de sécurité et de viol de vie privée que ceci implique.

… messieurs, vous êtes maintenant face à vos responsabilités. Soit nous poursuivons une stupide course à l’armement que l’État ne peut gagner, soit les autorités, les hackers et les politiques se mettent autour d’une table pour entamer un dialogue sérieux et éclairé.

Par 3 gus dans un garage
Paul Da Silva
Paul Rascagneres (aka RootBSD) Olivier Laurelli (Bluetouff)

Possibly Related Posts:

• « Allo ?… Brice ? Y’a de la friture ! … ah ben on a été coupés »
• DRM : on confine toujours à l’absurde
• Lawtech : le full disclosure passe en procès à la Cantine
• Toute ta life sur Pastebin
• HADOPI : Chat La Tribune d’Eric Walter … les deux pieds dedans