March 2011 Archives

20-03-2011 23:06:22

[Secu] Facebook URL Redirection

Dans l'idée du post précédent sur lequel je reviendrai pour réévaluer tout ca, je vais vous présenter une URL redirection applicable directement sur le site de Facebook. Pour cela il suffit d'appeler 2 fois la variable "u" dans notre requete GET et le controle d'url se retrouve bypassé et la 2e requete est executé.

Voici un PoC appelant la requete suivante:
http://www.facebook.com/l.php?u=http%3A%2F%2Fwww.facebook.com%2Fpages%2FCin%25C3%25A9ma%2F104202296279674&h=8ae77&cb=3&p=AQCd3-oYLWKIy8Qz9FddRczehHGXLbUokzXxGei4HBNDeBcDcMr0TpAuAQ36lsm-IYmzLy62Zl6R48mn9VH_M2Yye8DiDcyYpL0tpQ&u=http://blog.madpowah.org
On peut imaginer les conséquences en mettant une URL avec un site de phishing Facebook à la place de mon blog ...

Prudence donc à chaque clic !

Posted by cloud | Permanent link | File under: Security

19-03-2011 19:32:58

[Secu] Les HTTP Parameter Pollution

J'ai été interpelé par le titre raccoleur d'un article de Clubic indiquant que 30% des sites web présenteraient une faille exploitable. Cette vulnérabilité se nomme HPP ou HTTP Parameter Pollution.

J'ai donc creuser un peu pour voir ce qu'il en était.

Les HPP ont été présentées en 2009 par l'OWASP. Les slides sont disponibles ici. Des chercheurs ont en fait constaté que les navigateurs interprétaient différement le fait qu'une variable soit envoyée plusieurs fois dans la meme requete. En effet certains vont ne considérer que la 1ère, d'autre la dernière et les plus intéressants vont concaténer les 2. Il est ainsi possible de voir la réaction des serveurs Web d'après les tests présentés ci dessous.



Ainsi on constate que IIS principalement concatène les données. Sachant que IIS représente environ 30% des serveurs Web sur Internet, on peut supposer que le journaliste a fait un énorme raccourci pour annoncer ses résultats.

Car au final à quoi sert une HPP ? A Rien ? "Presque". Si un site web ne propose aucune vulnérabilité complémentaire, cela ne sert dans 99% des cas strictement à rien. En effet au mieux cela va servir à passer un WAF (Youpi!) ou à la rigueur bypasser une protection CSRF comme présentée via la vuln Yahoo (qui va quand meme nécessiter une phase de SE donc peu critique).

La ou cela peut etre intéressant c'est pour tester un serveur Web perso qui n'apparait pas dans la liste et qui peut avoir un comportement étonnant comme l'exemple donné dans les slides pour CUPS. Et comme il faut une exception qui confirme la règle et donc nos 1% restant, il y a eu récemment une vulnérabilité qui a été récompensé par Google pour sa découverte et qui impactait le site Blogger.com. Le serveur propre à Google sembl(ait) gérer bizarrement les doubles variables en prenant une fois la 1ere puis l'autre. Du coup, lors du test de valeur, la valeur était légitime et la valeur prise lors de l'action était la 2e qui était pirate. Pour plus de détail sur cette attaque cliquez ici.

En conclusion les HTTP Parameter Pollution sont pour moi inutiles lors d'un pentest (sans WAF) dans le cas de l'utilisation d'un serveur web connu mais peuvent présenter un intéret dans le cas d'une application utilisant un serveur web différent de l'habitude. En tout cas on est très loin des 30% de sites web vulnérables :)

Posted by cloud | Permanent link | File under: Security