Dyrk.org - Do You Really Know

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.