El ataque de los bots: usando Google para encontrar vulnerabilidades en páginas web

El ataque de los bots: usando Google para encontrar vulnerabilidades en páginas web
15 comentarios Facebook Twitter Flipboard E-mail

El mundo del hacking y la seguridad está lleno de sorpresas e ingenio. Por ejemplo, puedes ser un administrador de sistemas que un día descubre con sorpresa que estás recibiendo ataques SQL Injection... de los servidores de Google.

Es lo que han descubierto en Sucuri, una empresa desarrolladora de soluciones de seguridad para aplicaciones web. Bots de Google, con direcciones de red de la red de Google y no falseadas, que estaban tratando de detectar vulnerabilidades en páginas web. ¿Se rebelan las máquinas o hay algo más detrás?

Por supuesto, ni las máquinas ni los bots ni se rebelan, ni tienen inteligencia ni nada. De hecho, son bastante tontos y hacen lo que les dices que hagan, y punto. La cuestión es que suelen estar muy entregados a su tarea; y alguien puede encontrar usos ingeniosos a esa entrega.

Un vistazo a…
'Sgroogled.com': cuando MICROSOFT lanzaba anuncios ANTI-GOOGLE

SQL injection, ataques modificando direcciones web

Por el mundo hay gente que, por curiosidad o por malicia, quiere buscar fallos en páginas web. Uno de esos posibles fallos se llama SQL Injection, y consiste en inyectar código SQL a través de las URLs.

Parece complicado, pero la idea básica es sencilla. Por ejemplo, cuando buscáis en un blog, ponéis mi texto en la caja de búsqueda y la dirección web a la que os lleva es algo como http://www.blog.com/search?q=mi+texto. El servidor coge el parámetro q ("mi búsqueda") y lo busca en la base de datos de artículos. Usará un lenguaje especial, SQL, para hacer la petición que será parecido a esto: SELECT * WHERE title = mi texto. Si sabéis inglés no es difícil saber lo que hace.

Ahora bien, ¿qué pasa si en lugar de mi búsqueda pongo a; DELETE ALL? La consulta SQL quedaría como SELECT * WHERE title = a; DELETE ALL, y no es difícil imaginar que eso ejecuta dos comandos y uno de ellos puede borrar toda la base de datos del tirón.

Por supuesto, esto es una simplificación, la inyección SQL es bastante más compleja, no es tan fácil de ejecutar y hay varios métodos de protección. Pero la idea básica es que modificamos parámetros de las direcciones web para poder ejecutar comandos en la base de datos de un servidor web.

Un hacker se dedicará a buscar fallos de este estilo en páginas web. Sin embargo, puede que le detecten. Puede que haya un sistema que evite este tipo de peticiones, o que su dirección IP esté baneada. Aquí es donde entran los bots de Google.

Este hacker puede crearse una página web aparentemente normal, con muchos enlaces. Y entre esos enlaces habrá algunos que prueben vulnerabilidades SQL Injection, como el que comentábamos antes (http://www.blog.com/search?q=a;+DELETE+ALL). El bot de Google indexará esa página y los enlaces que contiene.

Y como buen bot programado para llegar hasta el último rincón de Internet, visitará esos enlaces para ver que tiene. Sin saberlo, estará probando ataques SQLi contra una página web que no sabrá por qué los bots de Google hacen cosas tan raras.

Un atacante puede hacer que Google pruebe URLs maliciosas contra ciertos sitios web

¿Cuál es la ventaja? La primera es obvia: ser detectado es más difícil. En los registros no pasaría muy desapercibido un usuario normal que haga muchas peticiones en poco tiempo, pero si es Google no resulta tan extraño. También es más difícil saber quién es el atacante original, y además así se evitan bloqueos y listas negras de IPs.

La pregunta es, ¿cómo sabe después el atacante qué ataques han tenido éxito? Es posible que si el ataque tiene éxito aparezca después en los resultados de Google una cadena de caracteres específica, o quizás los ataques exitosos sean capaces de infectar con un virus ciertos sitios web (no estoy seguro de que pueda hacerse, pero tampoco diría que es imposible).

La prevención de estos ataques es delicada. El servidor web no puede bloquear a los bots de Google porque entonces se queda fuera de los resultados de búsqueda. Para Google también resulta muy difícil filtrar todos los posibles ataques SQLi en las direcciones que indexa. La protección más efectiva es la de siempre, programar bien los servidores web y asegurarse de que se escapan correctamente los parámetros que puede introducir el usuario. Pero no deja de ser curioso las nuevas formas que buscan los atacantes para saltarse las medidas de protección que se ponen en marcha.

Imagen | Robert Scoble

Comentarios cerrados
Inicio