BlackSEO - Detector: Unas pruebas con el gobierno de USA
Fueron los recortes quienes acabaron con aquel evento tan interesante, la Open Source World Conference 2010 que se iba a celebrar en Málaga. Y también con una charla en la que Chema y yo íbamos a hablar sobre BlackSEO y a presentar una herramienta llamada BlueFinder. Era quizá más una curiosidad que cualquier otra cosa. Incluso estaba escrita en Bash. Pero sus algoritmos, sencillos a la vez que interesantes, le permitían detectar modificaciones no autorizadas de sitios web mediante el análisis de resultados de buscadores y respuestas de servidores. Y la cancelación de la conferencia le privó de su puesta de largo.
Recientemente, mientras preparaba la tercera edición de “Hacking con buscadores” que saldrá para estas navidades me la volví a encontrar en un párrafo. Algo se iluminó en mi mente y me prometí retomarla. Esta vez la reescribiría en Ruby y le tendría que cambiar el nombre: una consulta a Google me decía que ya existía una app para Android, y también una herramienta de búsqueda para fabricantes de productos textiles, con esa denominación. Por ahora, se quedará con “BlackSEO - Detector”. Una vez hube acabado con el libro, me puse a ello y aunque aún le quedan detalles por pulir, ya está dando sus primeros resultados. Y, como muestra, un botón.
Un caso de análisis de BlackSEO
El sitio web de este ejemplo pertenece al Federal Registry for Educational Excellence, un organismo gubernamental estadounidense. Me lo encontré en una de las pruebas de BlackSEO - Detector, tratando de localizar referencias a ventas irregulares de fármacos. El informe de salida de la herramienta, en formato HTML, comenzaba con generalidades sobre la URL reportada:
En este caso, el título del resultado parecía no estar relacionado con la búsqueda. Más bien tenía pinta de tratarse de un caso de venta de calzado deportivo. En todo caso, la parte en la que se analiza las respuestas obtenidas al acceder al recurso presentaba datos si cabe más llamativos:
La página presentaba tres respuestas diferentes. Si se accedía a ella de forma normal, se producía una redirección a otra página del mismo sitio que no parecía presentar problemas. Si se hacía utilizando el User-Agent de Google, la respuesta contenía palabras que apuntaban a contenidos extraños. Una petición con una cabecera Referer que le hiciera parecer procedente de un clic en un resultado del buscador parecía obtener una respuesta sin redirecciones ni contenidos extraños.
Y, como era de esperar, la cache de Google contenía indicios de problemas. Parecía ser el típico caso de Cloaking forzado. Así que, para verlo todo más claro, accedí a los detalles sobre las respuestas ante la URL:
En cuanto a los contenidos sospechosos, ahí estaban. Sólo hacía falta bajar hasta encontrarlos:
El código inyectado para hacer BlackSEO
Pero lo más llamativo era la respuesta cuando se simulaba el Referer de la página de resultados de Google. Un script cargado desde otro dominio. ¿Por qué no descargarlo para analizarlo? Pues ahí va su contenido:
Como no soy de los que entienden este tipo de galimatías, determiné la cadena que se ejecuta con la llamada inicial a “eval”. Debidamente embellecida, quedaría:
Figura 1: BlackSEO - Detector |
Recientemente, mientras preparaba la tercera edición de “Hacking con buscadores” que saldrá para estas navidades me la volví a encontrar en un párrafo. Algo se iluminó en mi mente y me prometí retomarla. Esta vez la reescribiría en Ruby y le tendría que cambiar el nombre: una consulta a Google me decía que ya existía una app para Android, y también una herramienta de búsqueda para fabricantes de productos textiles, con esa denominación. Por ahora, se quedará con “BlackSEO - Detector”. Una vez hube acabado con el libro, me puse a ello y aunque aún le quedan detalles por pulir, ya está dando sus primeros resultados. Y, como muestra, un botón.
Un caso de análisis de BlackSEO
El sitio web de este ejemplo pertenece al Federal Registry for Educational Excellence, un organismo gubernamental estadounidense. Me lo encontré en una de las pruebas de BlackSEO - Detector, tratando de localizar referencias a ventas irregulares de fármacos. El informe de salida de la herramienta, en formato HTML, comenzaba con generalidades sobre la URL reportada:
Figura 2: Cabecera del reporte de Black-SEO Detector |
En este caso, el título del resultado parecía no estar relacionado con la búsqueda. Más bien tenía pinta de tratarse de un caso de venta de calzado deportivo. En todo caso, la parte en la que se analiza las respuestas obtenidas al acceder al recurso presentaba datos si cabe más llamativos:
Figura 3: Alertas en el informe de Black SEO - Detector |
La página presentaba tres respuestas diferentes. Si se accedía a ella de forma normal, se producía una redirección a otra página del mismo sitio que no parecía presentar problemas. Si se hacía utilizando el User-Agent de Google, la respuesta contenía palabras que apuntaban a contenidos extraños. Una petición con una cabecera Referer que le hiciera parecer procedente de un clic en un resultado del buscador parecía obtener una respuesta sin redirecciones ni contenidos extraños.
Y, como era de esperar, la cache de Google contenía indicios de problemas. Parecía ser el típico caso de Cloaking forzado. Así que, para verlo todo más claro, accedí a los detalles sobre las respuestas ante la URL:
Figura 4: Evidencias de Cloacking en el informe de BlackSEO - Detector |
En cuanto a los contenidos sospechosos, ahí estaban. Sólo hacía falta bajar hasta encontrarlos:
Figura 5: Contenidos sospechosos detectados en BlackSEO - Detector |
El código inyectado para hacer BlackSEO
Pero lo más llamativo era la respuesta cuando se simulaba el Referer de la página de resultados de Google. Un script cargado desde otro dominio. ¿Por qué no descargarlo para analizarlo? Pues ahí va su contenido:
Figura 6: Script inyectado y ofuscado |
Figura 7: El código desofuscado |
Análisis explicado del comportamiento de BlackSEO
Aunque al final no pase de ser más que una redirección, desde luego, hace uso de una técnica interesante y no demasiado frecuente. Para empezar, una cookie, “MMHs”, permite cambiar el dominio de destino dependiendo de si se ha visitado antes o no la página.
Posteriormente se comprueba la URL de Referer, y en particular su parámetro GET “q”, en busca de la consulta realizada al buscador. Si dicho parámetro está vacío o si contiene texto que haga alusión a gafas de sol, se vuelve a cambiar la URL de destino. También se comprueba si el clic vino de una página de búsqueda de imágenes. En este caso, la ruta de la imagen es sometida a varias modificaciones, de modo que se termina forzando la visita a una página HTML, con lo que ésta pueda contener.
Una vez determinada la URL de destino, el procedimiento de redirección es también bastante artificioso. Lo que más me llamó la atención es que si el equipo que visualiza la página tiene una zona horaria correspondiente a GMT+8, redirige a una página de error. Una forma de evitar “clientes” no deseados. Echando un vistazo a las diferencias horarias, me sale que eso se corresponde con ciudades como Hong Kong o Beijing. Por poner algún ejemplo.
Como poco, ahí quedarían cuatro dominios a los que seguir la pista. Cinco, si se tiene en cuenta el que alojaba el script. Y en cuanto se empiece a investigar saldrán, seguro, algunos más, direcciones de correo, otros sitios afectados, etcétera. Pero eso es ya otra historia. Es hora de volver al tajo y seguir puliendo la herramienta.
Autor del libro "Hacking con Buscadores"
1 comentario:
Se puede bajar de algun sitio esta herramienta?
Publicar un comentario