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.
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.
¿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
Ver 14 comentarios
14 comentarios
pigueiras
La mejor explicación que he visto nunca sobre que es un ataque de SQL injection es esta: http://security stackexchange com/a/25710/32572. Merece la pena echarle un ojo, aunque esté en inglés :)
iberhack
Lo que permite Google es una infimidad con lo que permitía otro buscador ya desaparecido: Alltheweb. Ese si era una maravilla para estos fines y con saber usarlo medio decentemente (algo fácil) es que daba el trabajo echo...
Pero esto no es nada nuevo, el hacking con buscadores nació con Altavista principalmente... yo mismo escribí un artículo para una ezine muy conocida del momento sobre esto mismo con Altavista en 1997... incluso con Ole (un buscador sobre el que Telefónica creo Terra) se podía hacer. Pero con AllTheWeb se llego a un extremo que te simplificaba tanto la tarea que ya daba asco.
Salu2
sathwan
Esto es lo mismo que Hacking con buscadores, de Enrique Rando, no?
segura2010
Si no sabes del tema no deberias escribir.. Primero Una SQL Injection no tiene por que ser explotada a través de parametros de URLs (parametros GET) sino que las hay en formularios (parametros POST). Estas últimas pueden ser muy interesantes por que pueden estar en un formulario de acceso al sistema de un usuario, por tanto permitiria el acceso añadiendo condiciones ciertas a la consulta.
Por otro lado no es posible ejecutar un DELETE como pones de ejemplo, pues no se permite mezclar consultas (SELECT) con actualizaciones de la base de datos (UPDATE, DELETE etc..)
Y por último es imposibleeter virus con una simple SQLi, pues solo podremos consultar el contenido de la base de datos o, si tenemos suerte y la inyección se produce en un comando de actualización, podremos actualizar campos de la base de datos.
Un saludo :)