(des)Protección de passwords HTTP en ClickJacking y CSRF

Ayer tarde en Informática 64 un joven compañero me enseñaba un 0day que había encontrado que le permitía explotar una vulnerabilidad similar a la que dio la vuelta al mundo porque usaba un CSRF a través de la configuración Mail de iPhone, aprovechándose de credenciales por defecto en un router. 

Al final, el fallo del que os hablo se aprovechaba de las mismas cosas, configuración de usuarios por defecto, ninguna protección contra CSRF en las URLs del panel de administración y un entorno confiable de carga de imágenes, ya sea mediante un iframe , un tweet acortado que se lea desde la intranet, o la típica etiqueta IMG para lanzar el ataque del lado del cliente como en los ejemplos del cliente Mail de iPhone e iPad para que el jefe hackee la base de datos de la intranet, ganar votaciones o dinero haciendo click-fraud.

En este caso concreto, la autenticación del usuario se hacía siguiendo el estándar HTTP, es decir, incluyendo el usuario y la password en la URL de la dirección para explotar del tipo:

http://user:password@www.sitioweb.com/app_vulnerable_CSRF

Solo con el CSRF sin autenticar usuarios se consiguen hacer muchas manipulaciones dentro del panel de administración, pero no todas, ya que algunas de las cosas requieren la autenticación y la interacción con el usuario para confirmar acciones, por lo que había que explotar el CSRF dentro de un esquema de ClickJacking. Esto hace necesario meter la URL explotable por CSRF dentro de un iframe transparente para robar los clics de los usuarios. Todo normal hasta este punto.

Para evitar pelearse con los filtros Anti-XSS de Google Chrome, Internet Explorer o NoScript, la opción más fácil resulta crear un sitio web mailicioso y engañar a la víctima para que entre a él, una vez allí, se abre la página web se carga en un iframe transparente el panel de administración autenticado con la password por defecto usando el bug de CSRF, y se roban los clics con algún truco de ClickJacking. Sencillo.

Sin embargo, ahí aparece una protección extra que tienen Internet Explorer y Apple Safari, y que NO aparece ni en Google Chrome ni en Mozilla Firefox. La protección contra el envío de credenciales en formato HTTP (aunque en el caso de Apple Safari lo explican "a su manera").

Figura 1: Warning de Apple Safari cuando se envían credenciales HTTP en la URL

Me ha sorprendido que ni Google Chrome ni Mozilla Firefox tengan esa protección, cuando parece de lo más lógico, pero es así. Esperemos que en Google Chrome, ahora que "ya han acabado con el malware" pasen a tener menos bugs y a mejorar estos detalles en el futuro - y ya si habilitan IPv6 por defecto se lo agradeceré yo y nuestra Evil FOCA -.

Saludos Malignos!