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