Partons au Weekend d'Intégration gratuitement ! (scénario réel, illustrant les dangers de symfony)
Cela fait assez longtemps que je voulais publier un article dessus, mais tant qu'à faire j'y pense (grâce aux vacances et la jolie faille suivante).
Beaucoup plus de développeurs sont envoutés par la puissance de notre cher Framework Symfony. Cependant, dans de nombreux cas, le contenu est hébergé en mutualisé. J'aurais pu intituler cette article "Comment une assos à faillie froler la catastrophe?", mais comme c'est un cas que j'ai pu observer chez d'autres et on ne dira pas qui... il faut le généraliser un peu.
Ayant prévenu l'association avant de publier quoi que ce soit, je me permet donc d'expliquer les choses à ne pas faire lorsque vous utiliserez un quelconque framework. Ce qui a l'avenir évitera pas mal de soucis non seulement à l'organisme, mais aussi aux utilisateurs de cet organisme.
Cette méthode de piratage est la plus simple en soit et nous allons voir pourquoi...
Bon je reçois un mail d'invitation pour venir participer au WEI 2010. Là je me dis : "Cool! Alcool! Rencontre des nouveaux et bizutages (Ah non pas le droit aux bizutages apparemment...).
En rentrant dans le site, j'ai quant même des manies assez bizarres de "checker" la forme des requêtes en quelques clics, après si c'est des sites plus intéressants... "cela ne nous regarde pas!". Et là je vois une chose qui tombe souvent chez certains clients : L'erreur Symfony!
Comme on peut le remarquer, les développeurs ont oublié de personnaliser l'erreur Symfony, je sais donc vers quelle structure me diriger :
apps/ frontend/ backend/ cache/ config/ <---- data/ <---- Les répertoires les plus intéressants sql/ <---- doc/ lib/ model/ log/ <--- Celui-là pour les SESSIDs attacks en mode prévision (voir mon joli cours dessus : http://www.hackerzvoice.net/hzv_magz/download_hzv.php?magid=03) plugins/ test/ bootstrap/ unit/ functional/ web/ css/ images/ js/ uploads/
Maintenant analysons de plus prêt l'url... Tiens! On passe par "/web"... ça veut dire, que le virtualhost n'est pas pas appliqué pour séparer les deux couches : le "coeur" (1) et la partie web de Symfony (2) (Sachant que le vrai coeur de Symfony est surtout dans la partie "lib"; bref!).
Ainsi, si je me documente bien, Symfony est configuré de tel à ce que les accès "dsn" soient édités dans un fichier YAML, qui se trouve dans "/config" : databases.yml
Comme je suis curieux, alors j'y vais et BOOM!:
(Pas de .htaccess interdisant l'accès aux fichiers ".yml" et ".ini" !!!)
Alors en voyant les mots de passes composés de caractères spéciaux, de Upper/Lower cases et de nombres, j'aurais estimé le bruteforce à "The next big bang", avec la latence des réponses, les probabilités de rejets, etc... là étant donné qu'on les a en clair, bah : CTRL + C.
C'est là que dans un audit, si votre site est "invulnérable" aux attaques SQL injection, XSS, CSRF, inclusion, byte-zero, Code malicieux en formulaire... Avec ça vous passez du seuil vert au seuil rouge le plus critique! Car là vous pouvez : Voler les mots de passe des clients et les déchiffrer en puissance de calcul, même si c'est pas simple avec les salts md5 (Voir le projet de Celelibi sur le GPGU http://forums.thehackademy.net/viewtopic.php?f=30&t=2709). Il est possible aussi de modifier le contenu et d'y mettre n'importe quoi, modifier les informations de payement et plein d'autres...
Le vol de mot de passe client servira naturellement à faire un lien avec les comptes email (On vous surveil où que vous soyez!).
Bon souvent en sécurité on se complique là vie et on cherche tout les vecteurs d'attaques possibles (Voir un des mes articles à ce sujet : http://hakin9.org/fr/magazine/1144-securite-web-reseaux).
Donc on scan des ports assez connus sur le domaine et :
PORT STATE SERVICE VERSION 21/tcp open ftp ProFTPD 1.3.1 80/tcp open http Apache httpd | html-title: 301 Moved Permanently |_Requested resource was http://*****Je cache ça******/web
Il est possible que je trouve d'autres vecteurs en allant plus loin, car la plupart des administrateurs ont l'habitude de faire pour obfusquer, mais le mieux et de se diriger vers les port knocking, qui dépendant de la séquence, sera plus sécurisé : http://www.linuxjournal.com/article/6811
Sinon en connaissant un peu l'environnement à l'avance, je me doute que c'est un peu limité donc ProFTPD et Apache seulement. C'est là que je me dis bon ! On utilise les drivers MySql donc "Phmyadmin" est mon ami! Mais je pourrais aussi user de certain accès d'étudiants pour passer le filtrage du firewall et me connecter au serveur en "remote localhost".
En général, on donne un alias pour que phpmyadmin se retrouve dans tout les virtualhosts, sans pour le moins tout reconfigurer, mais là "/phpmyadmin" n'est pas bon. Je vais donc aller chatter sur Facebook (ambiance chaleureuse, photos comprométente.. mais c'est pas grâve, information pas mal personnelles... bref!).
Seb> Salut Jo' j'suis dans le pétrin! =S Jonathan> pk ? Seb> Le webmaster de mon assos est en Angleterre et n'a pas le net là et je dois réctifier une relation qui n'existe pas et ça risque de devenir un bordel pour les enregistrements =S. Seb> Tu n'aurais pas les nouvelles adresse type pour l'accès phpmyadmin ? Jonathan> Non mais le webmaster ou le prez l'ont je pense. Seb> Arf =/ faut que je me dépêche un peu, tiens moi au courant si possible. Merci beaucoup! ... ... Quelques conversations négatives plus tard ... Mathieu> Oui c'est : http://**********blablabla*************** Seb> Merci tu nous sauves là! Mathieu> Mais c'est pour quelle assos ? Seb> Attend je re ... ... Déconnecté
Bon maintenant qu'on a les accès, on va sur la partie Phpmyadmin et on retrouve comme il se doit notre joli base :
Pour s'enregistrer gratuitement, celle qui nous intéresse et celle là : attendee. Alors maintenant, comme j'ai envie de m'inscrire gratuitement, il ne me reste plus qu'à remplir les champs comme un grand et c'est là aussi qu'on peut découvrir de nouvelles failles :
Nous sommes dans le cas où il est possible d'injecter directement du code malvéillant sans filtrages, donc je pourrais prendre le contrôle du client en lui faisant faire des actions sans qu'il s'en rende compte, vol de cookies ou alors lui afficher une iframe avec au centre le site web qu'il désire visiter et sniffer toutes ses actions : Clics sur des liens, sniffing de clavier, ... (Le XSS est plus dangereux qu'on le croit, Voir le framework Xeek : http://www.segmentationfault.fr/projets/release-de-xeek-v0-1b/). Il faut alors filtré ça lors de la visualisation en "output"!
Donc aussi pour la partie qui nous intéressait au-début, nous avons les champs, qui définissent si nous avons bien payé ou non (dans le schema.yml on voit que certains champ doivent être juste booléens) :
Voilà plus qu'à "Submit" et c'est parti! Nous somme enregistré pour aller faire la fête!
Assurez-vous de bien connaitre le Framework que vous utilisez et n'hésitez pas à prendre du temps en vous mettant dans la peau d'un attaquant. Le plus raisonnable souvent est aussi de faire auditer son système régulièrement, ainsi que de se tenir informer des bonnes pratiques par des formations par exemple ou articles sur le web.
Si je ne n'étais allé sur la page par curiosité et que quelqu'un d'autres aurait vu ceci, je pense que l'association aurait eu quelque soucis de gestion...
Pour le pire scénario => 2 jours avant le départ, il y a :
Pour le reste, il y a master card...
Cette création est mise à disposition sous un contrat Creative Commons
