Failles Multimania

J'ai refait mon site récemment, entre autre afin de proposer plus de téléchargements. Pour cela il a donc fallu que j'uploade des fichiers sur mon compte hébergé par Lycos/Multimania.
Par exemple j'ai uploadé le fichier Sk.zip dans le répertoire down. Je me suis servi de gFTP et ce dernier n'a pas eu de problèmes lors de l'upload. Au résultat j'avais bien un fichier de la même taille que l'original (sur mon disque) soit 578,411 Ko.
Afin de vérifier que le fichier est valide, j'essaye de le télécharger par l'intermédiaire de mon navigateur en tapant simplement l'adresse http://membres.lycos.fr/lotfree/down/Sk.zip
Je m'attendais à ce que le téléchargement se déroule normalement mais à la place je tombe sur la page suivante :

L'url de cette page est : http://multimania.lycos.fr/error/referer.phtml?_siteRedirect=http://membres.lycos.fr/lotfree&_siteRedirectFile=http://membres.lycos.fr/lotfree/down/Sk.zip

Le texte en rouge correspondant parfaitement à la variable _siteRedirectFile et le texte souligné à la variable _siteRedirect, je me suis tout de suite dit que le script lisait les variables à la lettre.
Pour vérifier je tappe : http://multimania.lycos.fr/error/referer.phtml?_siteRedirect=<script>alert(document.cookie);</script>&_siteRedirectFile=<script>alert('salut');</script>

Effectivement j'obtiens deux boîtes de messages, la première avec 'salut' et la seconde avec les variables du cookie (session etc.). La page est donc vulnérable à deux XSS.

La seconde chose que l'on remarque est la message "Pour avoir accès à ce fichier, vous devez visiter la page de ce membre".
Comment savent-ils si on a ou non visité la page du membre en question ? La réponse la plus évidente est la variable Referer dans un en-tête HTTP.
A chaque fois que vous cliquez sur un lien dans une page X, cette variable prend pour valeur l'url de cette page X. L'utilité de cette variable est bien evidemment statistique : par exemple celà permet à des sites marchands de savoir quels sont les sites qui leur amènent le plus de visiteurs.

Dans notre cas il faut sans doute avoir cliqué sur un lien vers le fichier zip et ce lien doit être inclus dans une des pages du membre.
Ce genre de protection au niveau du Referer existe, notemment dans certains CGIs mais n'apporte aucune protection puisqu'il est très facile de forger sa propre requête HTTP (voir la RFC 2616 sur le protocole HTTP/1.1).

Pour bypasser cette protection il nous suffirait d'envoyer la requête suivante avec telnet ou netcat:
GET /lotfree/down/Sk.zip HTTP/1.1
Host:membres.lycos.fr
Referer:http://membres.lycos.fr/lotfree

La variable Host est nécessaire quand un serveur héberge plusieurs sites web. (une même IP peut avoir plusieurs noms de domaine)
Personnellement je la met toujours, ainsi j'évite les mauvaises surprises.

Mais inutile de s'embarrasser dans notre cas, car il n'y a que le referer sur lequel on triche.
On peut donc utiliser un logiciel tout fait comme HKit (qui gère en plus les cookies) ou WWWSpoof sous Windows.
Sous Linux il me semble qu'il est possible de choisir ses headers avec Wget.
Attention avec Lynx : ce dernier permet de tricher avec le nom du navigateur (entête User-Agent) mais pas avec le referer.
Dans mon cas j'ai eu recours au programme GET qui est inclus dans ma distribution Linux (Mandrake 8.2). C'est un programme qui a été écris en perl et qui est très simple d'utilisation.
Il ne faut pas oublier de faire une redirection vers un fichier, surtout quand il s'agit d'un fichier binaire.

On obtiens alors un fichier zip de la même taille que l'original : la protection est bypassé :)
De plus l'upload s'est bien déroulé.

Ne comptez donc pas sur cette protection pour garder vos fichiers à l'abri. La meilleure protection reste les fichiers .htaccess

sirius_black@imel.org http://membres.lycos.fr/lotfree