L’extranet de TMG aussi est vulnérable au XSS

Bon c’est pas que j’ai l’impression de me répéter mais après avoir découvert une faille XSS sur Hadopi.fr je pensais qu’ils feraient le nécessaire auprès des autres prestataires au service de cette loi, à commencer par celui qui manipule toutes les informations sensibles : la fameuse police privée TMG.

Le truc drôle c’est que même si j’espérai que hadopi.fr et les 40 sites gouvernementaux vulnérables trouvés avec Bluetouff et RootBSD commenceraient à les faire réfléchir sur la pertinence d’un délit de négligence caractérisée ou au moins les pousser à sécuriser un minimum leurs outils (oui parce que bon, donner l’exemple c’est mieux quand on veut « changer les comportements »)… Je n’y ai jamais cru un instant…

Bref ce coup-ci c’est l’interface qui sert aux ayants-droits pour communiquer avec la Hadopi qui présente une vulnérabilité au XSS sur le formulaire de connexion, fièrement suivi d’un logo « Secured by Thawte ». Bah oui la sécurisation c’est pas juste un certificat valide (aka une solution technique), c’est un ensemble de comportements et de précautions à prendre que l’on ne peut pas demander à un simple citoyen de connaitre et de maitriser quand ceux qui mettent en place des sites pour le gouvernement, les Hautes Autorités ou les milices à financement public n’en sont pas capables…

Cette faille permettrait quand même, si j’envoie un lien malicieux à quelqu’un de connecté à l’interface en question (au hasard chez l’Alpa ?), de voler ses cookies et de les envoyer sur un serveur tiers. Partant de là je n’ai plus qu’à recréer le cookie de mon côté pour être connecté à mon tour exactement comme si j’avais eu les informations de connexion…

Comme pour Hadopi.fr l’utilisation de $_REQUEST est une aberration, le filtrage des infos passées ou tout simplement un petit htmlentities aurait pu éviter cela… Ça coute pas plus cher les gars hein !

J’ai bien sur averti qui de droit (Eric Walter sur Twitter et TMG via le formulaire de contact dispo sur leur site) pour qu’ils corrigent… Mais on ne devrait pas trouver ce type de failles sur ce type de sites…

Je vous laisse sur la réflexion suivante : est-il normal de laisser le droit à cette entreprise dont la structure présente pour le coup des signes manifestes de négligence caractérisée le droit de collecter des informations sensibles sur des Internautes qui vont être accusés à leur tour d’être négligents ?

7 réflexions sur « L’extranet de TMG aussi est vulnérable au XSS »

  1. Gratis

    Finalement, c’est Messieurs Walter & Co (comprendre qui doivent tmg.eu, hadopi.fr, alpa.fr, etc…) qui doivent être contents !
    Ils ont 4 ou 5 très bons experts en sécurité informatique (Vous Mr PDS, Mr Bluetouff, Mr RootBSD,…) qui tout les jours leur trouvent et leur disent comment combler leur nouvelles failles… le tout gratis.

    L’expression « il faut savoir se faire des ennemis » n’a jamais été aussi vraie.
    Dommage que pour ce cas ci, le full-disclosure ne soit pas de la partie.

    « commenceraient à les faire réfléchir  »
    Je doute qu’ils changent d’avis un jour. Sinon, ils l’auraient fait il y a bien longtemps. Sauf peut-être si un jour on abroge la loi. D’ici-là…
    De toute façon, Mme MMM, Mr Walter et tout les autres ne sont que des exécutants, à la manière des soldats dans l’armée. Quand le chef donne un ordre, on obéit ou c’est la porte.

  2. mosquito

    Dommage !
    Belle démo technique, Paul.
    Mais dommage, la faille aurait pu servir. Autant il est quelque part vain de faire tomber hadopi.fr, autant saborder TMG serait un bon coup médiatique.

    Pour ce qui est des leçons de morale que tu leur prodigues, Paul, je crains que tu ne t’essouffles avant eux, et pour rien.

    Dis-moi, tu leur envoies une facture, au moins ?

  3. Le petit imbécile qui paie des impots

    Il est rare que je dise cela, mais je pense que vu que cela est fait avec notre argent public, cela me répugne….

    Je pense que tout le monde devrait arréter de chercher des bebetes à nos hadopi and co pour trouver les failles, car a chaque fois cela va aider cette belle structure à les combler (technquement, juridiquement, etc….)

    D’autant plus qu’a coté il n’y a aucun retour sur les arguments construits, mais juste « ah oui vous avez raison, on va régler le probleme…. »

    Bref, non pas que je trouve que ton travail ne sert a rien (mais comme le disent d’autres essaie de le monayer 😉 , je pense qu’il serait bon de les laisser dans l’ignorance….

    Personnellement, »je ne parle pas aux cons ca les instruits » (c) qui de droit….

  4. Qyy

    [QUOTE]l’utilisation de $_REQUEST est une aberration[QUOTE]

    Il est plutôt dangereux de considérer que remplacer $_REQUEST par $_POST / $_GET apporte une quelconque sécurité, le problème n’est certainement pas là.

    Le client envoi bien les requêtes sous la forme qui lui plaît, et envoyer une requête GET en POST ne relève que du simple clic avec un plugin Firefox…

    La sécurité passe surtout par un contrôle minutieux de l’information que l’on manipule, en excluant tout autre format que celui que l’on attend.

    Dans ce cas, un htmlentities est d’ailleurs très malvenu : en quoi un caractère pouvant être transformé en entité à quelque chose à faire dans la chaîne d’un login ?

    L’usage des fonctions ctype (http://fr.php.net/manual/fr/book.ctype.php) et au pire d’une regex pour contrôler le format autorisé d’un login serait bien plus adaptés. La sécurité générique, ça n’existe pas !

    Je ne comprends pas non plus la réflexion au sujet de la mention « Secured by Thawte » qui ne parle pas du tout de la sécurité de l’application, mais du certificat SSL : outre le fait que Thawte est connu pour ça (et non pas pour la sécurisation de script PHP), il suffit de cliquer sur le lien pour s’en rendre compte.

    Pour finir, les possibilités d’exploit que vous décrivez me semble un brin exagérées : à mon sens, si vous avez mis en entier plutôt qu’une chaîne dans le alert() ce n’étais pas parce que vous aviez peur de faire quelque chose de réellement impressionnant, mais simplement parce que l’ajout de guillemets ne donnais rien, ce qui limite quand même énormément les possibilités d’exploiter quoi que ce soit…

    Je ne remets certainement pas en cause le point que vous soulevez, à savoir qu’il est honteux qu’un aussi faible niveau de qualité et de robustesse soit présent sur un logiciel sensé véhiculer des données sensible, ni sur le côté « c’est l’hôpital qui se fout de la charité » ;

    Je regrette cependant ce ton racoleur et cette volonté de faire du sensationnel quitte à exagérer et à dire des choses tellement génériques qu’elles en deviennent fausses, même si je peux comprendre que ce n’est pas pour rien que M6 et TF1 font autant d’audience, et que tout le monde aime avoir de l’audience…

    Après, ce n’est que mon avis, et qui plus est plus sur la forme que sur le fond : j’apprécie votre blog et le suis assidûment ^^

  5. Paul Auteur de l’article

    On est bien d’accord que l’utilisation d’un $_POST ne résout pas le problème en soi, maintenant il est aussi justifié de se demandé en quoi un formulaire envoyé en POST a besoin de récupérer les informations passées en URL. Une grande partie des failles XSS exploitables viennent de là.

    Certes la même faille reste exploitable si l’on utilise uniquement le $_POST pour remplir les champs mais cela reste un peu plus compliqué alors qu’avec le $_REQUEST un simple lien direct et c’est joué.

    Sur le htmlentities : c’est juste le premier rempart que n’importe qui peut mettre en place. Il sera beaucoup plus efficace de filtrer par une expression régulière mais cette explication aurait légèrement alourdi l’article (sur hadopi.fr ils ont corrigé en utilisant un bête strip_tags).

    Ensuite sur l’explication de la faille : j’ai juste expliqué le principe et l’intérêt des XSS, en effet il y avait un addslashes qui rendaient toute utilisation beaucoup plus compliquée.

    Pour Thawte je connais bien sûr cette entreprise et les services qu’elle fourni et je sais faire la différence entre un certificat SSL et les bourdes d’un développeur qui a envie de prendre une pause café… Je soulève par contre le parallèle avec le « logiciel de sécurisation » de la Hadopi qui « sécurisera » un ordinateur mais surement pas une connexion internet.

    Enfin, et pour finir par le pire, « le côté M6 et TF1 » : aïl ! Espérons que tu auras mieux compris l’angle de cet article après mon commentaire, mais à aucun moment je ne veux verser dans le Morandini (pour continuer sur les bons exemples), j’essaye juste de vulgariser ce qui est toujours relativement compliqué quand on travaille dans le domaine en question 24/7 (en gros, des fois plus :P)

  6. Qyy

    Oui, j’y suis allé un peut fort avec la comparaison « TF1 / M6 » désolé. Je suis en effet assez bien placé pour comprendre la difficulté de la vulgarisation quand j’essaye d’expliquer à un chef d’entreprise pourquoi il faut re-développer son extranet en PHP qui « marche très bien » « juste » parce que les mots de passes sont stocké en clair dans la DB et qu’on peut accéder aux donné simplement avec l’uri directe aux ressources et le bon ID d’utilisateur dans les paramètres…

    Par contre, je maintiens que l’usage de $_POST / $_GET n’est pas préférable. cela ne fait que compliquer le code coté serveur, pour un paramètre vraiment trivial à contourner le fait de devoir faire passer des données en POST plutôt qu’en GET (« dans un url ») ne complique vraiment en rien la tache de qui que ce soit (sauf si on considère l’usage d’un plugin Firefox comme quelque chose de compliqué).

    Au mieux ça limite le risque d’effet de bord lié à des entrées erroné dans la barre d’adresse par l’utilisateur, mais si l’application en est à être sensible à ça, il faut se pencher bien plus loin que sur un simple problèmes de POST/GET.

    Tout ceci est très bien expliqué à la page 5 du cours (très accessible et très bien vulgarisé d’ailleurs) de John Gallet sur la sécurité web dynamique «  »Je suis sûr que c’est arrivé en POST »
    (http://www.saphirtech.com/securite.html).

    Pour moi, l’usage de $_GET ou $_POST ne fais donc que compliquer le code et donner un faux sentiment de sécurité : les variable super globales, les fonction d’émargement générique, l’authentification au niveau de PHP avec les session plutôt qu’au niveau du serveur HTTP, etc. sont bien plus à craindre et amènent déjà assez de travail lors de l’audit d’un code pour ne pas s’en rajouter inutilement à la recherche du « il est passé par ici / il repassera par là » en différenciant les sources du tableau $_REQUEST…

    Pour conclure, en me relisant quelque heures après, je trouve que mon commentaire faisait très « flame » et je m’en excuse : étant autiste Asperger, j’ai souvent du mal à gérer mon « non verbal » (le ton sur lequel je cherche à passer une simple information), problème que je retrouve étrangement d’autant plus à l’écrit.

  7. Qyy

    Désolé pour le flood : mais je viens de réaliser que ce qui taraude le plus les gens qui veulent absolument différencier les GET et les POST sont les attaques de type CSRF (http://fr.wikipedia.org/wiki/Cross-site_request_forgery).

    Elle sont certes un tantinet plus compliqué à mettre en place lorsque le GET et le POST sont différencié, mais si peux : il suffit de faire pointer vers une page avec un JS qui requête comme il faut le site en AJAX (par exemple, mais de toute façon, c’est trivial)

    Je ne sais pas combien de serveur plombé avec ce genre de script j’ai audité… : le pirate récupère les identifiants FTP d’une manière ou d’une autre (toujours automatisé, comme un vers, un virus…) puis déploie (d’une manière tout aussi automatisé) ces scripts qui souvent renvoi un paquet de mail en même temps qu’ils effectue leur tache à chaque fois qu’ils sont appelle (par un des mails qu’ils envoient eux même d’ailleurs).

    C’est d’autant plus pratique que lorsqu’un serveur est déplombé, il arrête automatiquement d’envoyer des mail : seul les script valides appellent à êtres utilisés…

    Et ce n’est qu’un exemple…

Les commentaires sont fermés.