Cómo los hackers se apoderan de los sitios web con inyección de SQL y DDoS
Incluso si solo has seguido de manera flexible los eventos de los grupos de hackers Anónimo y LulzSec, probablemente hayas oído hablar de sitios web y servicios pirateados, como los infames hacks de Sony. ¿Alguna vez te has preguntado cómo lo hacen??
Hay una serie de herramientas y técnicas que utilizan estos grupos, y si bien no intentamos darle un manual para hacerlo usted mismo, es útil comprender lo que está sucediendo. Dos de los ataques que escuchas constantemente sobre ellos son "Denegación de servicio (distribuido)" (DDoS) y "Inyecciones de SQL" (SQLI). Así es como funcionan.
Imagen por xkcd
Ataque de Denegación de Servicio
Qué es?
Un ataque de "denegación de servicio" (a veces llamado "denegación de servicio distribuida" o DDoS) ocurre cuando un sistema, en este caso un servidor web, recibe tantas solicitudes al mismo tiempo que los recursos del servidor están sobrecargados, el sistema simplemente se bloquea. y se apaga. El objetivo y el resultado de un ataque DDoS exitoso es que los sitios web en el servidor de destino no están disponibles para solicitudes de tráfico legítimas.
Como funciona?
La logística de un ataque DDoS puede explicarse mejor mediante un ejemplo.
Imagine que un millón de personas (los atacantes) se unen con el objetivo de obstaculizar los negocios de la Compañía X al retirar su centro de llamadas. Los atacantes se coordinan para que el martes a las 9 AM todos llamen al número de teléfono de la Compañía X. Lo más probable es que el sistema telefónico de la Compañía X no pueda manejar un millón de llamadas a la vez, por lo que todas las líneas entrantes serán atadas por los atacantes. El resultado es que las llamadas legítimas de los clientes (es decir, aquellas que no son los atacantes) no se realizan porque el sistema telefónico está atado a manejar las llamadas de los atacantes. Así que, en esencia, la Compañía X está potencialmente perdiendo negocios debido a que las solicitudes legítimas no pueden comunicarse.
Un ataque DDoS en un servidor web funciona exactamente de la misma manera. Debido a que prácticamente no hay forma de saber qué tráfico proviene de solicitudes legítimas contra atacantes hasta que el servidor web procesa la solicitud, este tipo de ataque suele ser muy efectivo.
Ejecutando el ataque
Debido a la naturaleza de "fuerza bruta" de un ataque DDoS, necesita tener muchas computadoras coordinadas para atacar al mismo tiempo. Revisando el ejemplo de nuestro centro de llamadas, esto requeriría que todos los atacantes supieran que llamarían a las 9 AM y llamarían en ese momento. Si bien este principio ciertamente funcionará cuando se trata de atacar un servidor web, se vuelve mucho más fácil cuando se utilizan computadoras zombie, en lugar de computadoras tripuladas reales..
Como usted probablemente sabe, hay muchas variantes de malware y troyanos que, una vez en su sistema, permanecen inactivos y, en ocasiones, "llamando a casa" para obtener instrucciones. Una de estas instrucciones podría ser, por ejemplo, enviar solicitudes repetidas al servidor web de la Compañía X a las 9 AM. Entonces, con una sola actualización de la ubicación de inicio del malware correspondiente, un solo atacante puede coordinar instantáneamente cientos de miles de computadoras comprometidas para realizar un ataque DDoS masivo.
La belleza de utilizar computadoras zombie no solo es su efectividad, sino también su anonimato, ya que el atacante no tiene que usar su computadora para ejecutar el ataque..
Ataque de inyección SQL
Qué es?
Un ataque de "inyección SQL" (SQLI) es una vulnerabilidad que aprovecha las técnicas de desarrollo web deficientes y, en general, se combina con una seguridad de base de datos defectuosa. El resultado de un ataque exitoso puede variar desde hacerse pasar por una cuenta de usuario hasta un compromiso completo de la base de datos o servidor correspondiente. A diferencia de un ataque DDoS, un ataque SQLI se puede prevenir completa y fácilmente si una aplicación web está programada adecuadamente.
Ejecutando el ataque
Cada vez que inicie sesión en un sitio web e ingrese su nombre de usuario y contraseña, para probar sus credenciales, la aplicación web puede ejecutar una consulta como la siguiente:
SELECCIONE el ID de usuario de los usuarios DONDE Nombre de usuario = "myuser" Y Contraseña = "mypass";
Nota: los valores de cadena en una consulta SQL deben estar entre comillas simples, por eso aparecen alrededor de los valores ingresados por el usuario.
Por lo tanto, la combinación del nombre de usuario (myuser) y la contraseña (mypass) ingresados deben coincidir con una entrada en la tabla de Usuarios para que se pueda devolver un UserID. Si no hay ninguna coincidencia, no se devuelve un ID de usuario, por lo que las credenciales de inicio de sesión no son válidas. Si bien una implementación particular puede diferir, la mecánica es bastante estándar.
Ahora veamos una consulta de autenticación de plantilla en la que podemos sustituir los valores que el usuario ingresa en el formulario web:
SELECCIONAR ID de usuario de usuarios DONDE Nombre de usuario = "[usuario]" Y Contraseña = "[pasar]"
A primera vista, esto puede parecer un paso sencillo y lógico para validar fácilmente a los usuarios. Sin embargo, si se realiza una simple sustitución de los valores ingresados por el usuario en esta plantilla, es susceptible a un ataque SQLI..
Por ejemplo, supongamos que "myuser'-" se ingresa en el campo de nombre de usuario y que se ingresa "wrongpass" en la contraseña. Usando la sustitución simple en nuestra consulta de plantilla, obtendríamos esto:
SELECCIONE ID de usuario de los usuarios DONDE Nombre de usuario = "miusuario" - 'Y Contraseña = "paso incorrecto"
Una clave para esta declaración es la inclusión de los dos guiones (-). Este es el token de inicio de comentarios para las sentencias de SQL, por lo que cualquier cosa que aparezca después de los dos guiones (inclusive) se ignorará. Esencialmente, la consulta anterior es ejecutada por la base de datos como:
SELECCIONAR ID de usuario de usuarios DONDE Nombre de usuario = "miusuario"
La omisión evidente aquí es la falta de verificación de contraseña. Al incluir los dos guiones como parte del campo de usuario, omitimos por completo la condición de verificación de contraseña y pudimos iniciar sesión como "myuser" sin conocer la contraseña correspondiente. Este acto de manipular la consulta para producir resultados no deseados es un ataque de inyección SQL..
¿Qué daño se puede hacer??
Un ataque de inyección SQL es causado por una codificación de aplicación negligente e irresponsable y es completamente prevenible (que cubriremos en un momento), sin embargo, la extensión del daño que se puede hacer depende de la configuración de la base de datos. Para que una aplicación web se comunique con la base de datos backend, la aplicación debe proporcionar un inicio de sesión a la base de datos (tenga en cuenta que esto es diferente al inicio de sesión de un usuario en el sitio web). Dependiendo de los permisos que requiera la aplicación web, esta cuenta de base de datos respectiva puede requerir cualquier cosa, desde el permiso de lectura / escritura en las tablas existentes hasta el acceso completo a la base de datos. Si esto no está claro ahora, algunos ejemplos deberían ayudar a proporcionar cierta claridad..
En base al ejemplo anterior, puede ver que al ingresar, por ejemplo,, "youruser '-", "admin' -" o cualquier otro nombre de usuario, podemos iniciar sesión instantáneamente en el sitio como ese usuario sin saber la contraseña. Una vez que estamos en el sistema, no sabemos que no somos realmente ese usuario, por lo que tenemos acceso completo a la cuenta correspondiente. Los permisos de la base de datos no proporcionarán una red de seguridad para esto porque, normalmente, un sitio web debe tener al menos acceso de lectura / escritura a su base de datos respectiva.
Ahora supongamos que el sitio web tiene el control total de su base de datos respectiva, lo que permite eliminar registros, agregar / eliminar tablas, agregar nuevas cuentas de seguridad, etc. Es importante tener en cuenta que algunas aplicaciones web pueden necesitar este tipo de permiso para que No es automáticamente algo malo que se conceda el control total.
Entonces, para ilustrar el daño que se puede hacer en esta situación, usaremos el ejemplo proporcionado en el cómic anterior al ingresar lo siguiente en el campo de nombre de usuario: "Robert '; DROP TABLE Users; -". Después de la simple sustitución, la consulta de autenticación se convierte en:
SELECCIONAR ID de usuario de usuarios DONDE Nombre de usuario = "Robert"; DROP TABLE Usuarios; - 'AND Contraseña = "paso incorrecto"
Nota: el punto y coma que se encuentra en una consulta SQL se usa para indicar el final de una declaración particular y el comienzo de una nueva declaración.
Que se ejecuta por la base de datos como:
SELECCIONAR ID de usuario de usuarios DONDE Nombre de usuario = "Robert"DROP TABLE Usuarios
Así que, hemos utilizado un ataque SQLI para eliminar toda la tabla de Usuarios.
Por supuesto, se puede hacer mucho peor ya que, dependiendo de los permisos de SQL permitidos, el atacante puede cambiar los valores, volcar las tablas (o toda la base de datos) a un archivo de texto, crear nuevas cuentas de inicio de sesión o incluso secuestrar la instalación de la base de datos completa..
Previniendo un ataque de inyección SQL
Como mencionamos varias veces anteriormente, un ataque de inyección de SQL se puede prevenir fácilmente. Una de las reglas principales del desarrollo web es que nunca confía ciegamente en las opiniones de los usuarios como hicimos cuando realizamos una sustitución simple en nuestra consulta de plantilla anterior.
Un ataque SQLI es fácilmente frustrado por lo que se llama desinfección (o escape) de sus entradas. El proceso de desinfección es en realidad bastante trivial, ya que lo único que hace es manejar cualquier comilla (') en línea de manera apropiada, de manera tal que no puedan usarse para terminar prematuramente una cadena dentro de una declaración SQL.
Por ejemplo, si desea buscar "O'neil" en una base de datos, no podría usar una sustitución simple porque la comilla simple después de la O causaría que la cadena terminara prematuramente. En su lugar, lo desinfecta utilizando el carácter de escape de la base de datos correspondiente. Supongamos que el carácter de escape para una comilla simple en línea está precediendo a cada cita con un símbolo \. Entonces "O'neal" sería saneado como "O \ 'neil".
Este simple acto de saneamiento prácticamente previene un ataque SQLI. Para ilustrar, revisemos nuestros ejemplos anteriores y veamos las consultas resultantes cuando la entrada del usuario esté saneada.
mi usuario-- / paso incorrecto:
SELECCIONE el ID de usuario de los usuarios DONDE Nombre de usuario = "myuser \" - 'Y Contraseña = "paso incorrecto"
Debido a que la comilla simple después de que mi usuario se escapa (lo que significa que se considera parte del valor objetivo), la base de datos buscará literalmente el nombre de usuario de "mi usuario '-". Además, dado que los guiones se incluyen dentro del valor de la cadena y no de la propia instrucción SQL, se considerarán parte del valor objetivo en lugar de interpretarse como un comentario SQL.
Robert '; DROP TABLE Usuarios;-- / paso incorrecto:
SELECCIONAR ID de usuario de usuarios DONDE Nombre de usuario = "Robert \"; DROP TABLE Usuarios; - 'AND Contraseña = "paso incorrecto"
Simplemente escapando de la comilla simple después de Robert, tanto la coma como los guiones están contenidos dentro de la cadena de búsqueda UserName, por lo que la base de datos buscará literalmente "Robert '; DROP TABLE Users; -" en lugar de ejecutar la eliminación de tablas.
En resumen
Si bien los ataques web evolucionan y se vuelven más sofisticados o se enfocan en un punto de entrada diferente, es importante recordar protegerlos contra ataques probados y verdaderos, que han sido la inspiración de varias "herramientas de piratas informáticos" disponibles gratuitamente diseñadas para explotarlos..
Ciertos tipos de ataques, como el DDoS, no pueden evitarse fácilmente, mientras que otros, como el SQLI, sí pueden evitarse. Sin embargo, el daño que pueden causar estos tipos de ataques puede variar desde un inconveniente hasta catastrófico, según las precauciones tomadas..
