26Aug
Incluso si solo has seguido los eventos de los grupos hackers Anonymous y LulzSec, probablemente hayas oído hablar de sitios web y servicios pirateados, como los infames hacks de Sony.¿Te has preguntado alguna vez cómo lo hacen?
Hay una serie de herramientas y técnicas que utilizan estos grupos, y aunque no estamos tratando de darle un manual para hacerlo usted mismo, es útil comprender lo que está sucediendo. Dos de los ataques que escuchas consistentemente sobre su uso son "denegación de servicio( distribuida)"( DDoS) e "inyecciones de SQL"( SQLI).Así es como funcionan.
Imagen de 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 a la vez que los recursos del servidor están sobrecargados, el sistema simplemente bloqueaarriba y se apagaEl objetivo y el resultado de un ataque DDoS exitoso son los sitios web en el servidor de destino que no están disponibles para solicitudes de tráfico legítimas.
¿Cómo funciona?
La logística de un ataque DDoS se puede explicar mejor con un ejemplo.
Imagine que un millón de personas( los atacantes) se reúnen con el objetivo de obstaculizar el negocio de la Compañía X al derribar su centro de llamadas. Los atacantes se coordinan para que el martes a las 9 a.m. todos llamarán 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, de modo que todas las líneas entrantes estarán atadas por los atacantes. El resultado es que las llamadas legítimas de los clientes( es decir, las que no son atacantes) no se procesan porque el sistema telefónico está atado a las llamadas de los atacantes. Entonces, en esencia, la Compañía X está perdiendo negocios debido a que las solicitudes legítimas no pueden llevarse a cabo.
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 frente a atacantes hasta que el servidor web está procesando la solicitud, este tipo de ataque suele ser muy eficaz.
Ejecutando el ataque
Debido a la naturaleza de "fuerza bruta" de un ataque DDoS, necesitas tener muchas computadoras coordinadas para atacar al mismo tiempo. Revisando nuestro ejemplo de centro de llamadas, esto requeriría que todos los atacantes supieran llamar a las 9 AM y llamar en ese momento. Si bien este principio ciertamente funcionará cuando se trata de atacar un servidor web, se vuelve significativamente más fácil cuando se utilizan computadoras zombie, en lugar de computadoras tripuladas.
Como probablemente sabrá, hay muchas variantes de malware y troyanos que, una vez en su sistema, permanecen latentes y ocasionalmente se "vuelven a casa" para recibir instrucciones. Una de estas instrucciones podría, por ejemplo, enviar solicitudes reiteradas al servidor web de la Compañía X a las 9 AM.Entonces, con una única actualización de la ubicación de origen del malware respectivo, un solo atacante puede coordinar instantáneamente cientos de miles de computadoras comprometidas para realizar un ataque DDoS masivo.
La belleza de utilizar las computadoras zombies no solo está en su efectividad, sino también en su anonimato ya que el atacante en realidad no tiene que usar su computadora para ejecutar el ataque.
SQL Injection Attack
¿Qué es?
Un ataque de "inyección SQL"( SQLI) es un exploit que aprovecha las técnicas de desarrollo web deficientes y, por lo general, combinadas con una seguridad de base de datos defectuosa. El resultado de un ataque exitoso puede ir desde suplantar una cuenta de usuario hasta un compromiso completo de la base de datos o servidor respectivo. A diferencia de un ataque DDoS, un ataque SQLI se puede evitar de manera completa y fácil si una aplicación web está programada adecuadamente.
Ejecución del 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:
SELECT UserID FROM Users DONDE UserName = 'myuser' Y contraseña= 'mypass';
Nota: los valores de cadena en una consulta SQL deben estar entre comillas simples, razón por la cual aparecen alrededor de los valores ingresados por el usuario.
Por lo tanto, la combinación del nombre de usuario ingresado( myuser) y la contraseña( mypass) debe coincidir con una entrada en la tabla Usuarios para que se devuelva un ID de usuario. Si no hay coincidencia, no se devuelve ningún 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:
SELECT UserID FROM Users WHERE UserName = '[user]' AND Password = '[pass]'
A primera vista, estopuede parecer un paso directo 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 se ingresa "wrongpass" en la contraseña. Usando la sustitución simple en nuestra consulta de plantilla, obtendríamos esto:
SELECT UserID FROM Users DONDE UserName = 'myuser' - 'AND Password =' wrongpass '
Una clave para esta declaración es la inclusión de los dos guiones( -).Este es el token de comentario de inicio para las declaraciones de SQL, por lo que todo lo que aparezca después de los dos guiones( inclusive) será ignorado. Esencialmente, la consulta anterior es ejecutada por la base de datos como:
SELECT UserID FROM Users DONDE UserName = 'myuser'
La omisión evidente aquí es la falta de la verificación de contraseña. Al incluir los dos guiones como parte del campo del usuario, eludimos por completo la condición de verificación de contraseña y pudimos iniciar sesión como "mi usuario" 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 back-end, la aplicación debe proporcionar un inicio de sesión a la base de datos( nota, esto es diferente de un inicio de sesión del usuario al sitio web).Dependiendo de los permisos que requiera la aplicación web, esta cuenta de base de datos respectiva puede requerir cualquier cosa, desde permisos de lectura / escritura en tablas existentes hasta acceso completo a la base de datos. Si esto no está claro ahora, algunos ejemplos deberían ayudar a proporcionar cierta claridad.
Según el ejemplo anterior, puede ver que al ingresar, por ejemplo, "su usuario" - "," admin "-" o cualquier otro nombre de usuario, podemos iniciar sesión instantáneamente en el sitio como ese usuario sin conocer 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 respectiva. Los permisos de la base de datos no proporcionarán una red de seguridad para esto porque, típicamente, un sitio web debe tener al menos acceso de lectura / escritura a su base de datos respectiva.
Supongamos ahora que el sitio web tiene control total de su respectiva base de datos, lo que le permite eliminar registros, agregar / eliminar tablas, agregar nuevas cuentas de seguridad, etc. Es importante tener en cuenta que algunas aplicaciones web podrían necesitar este tipo de permiso parano es automáticamente malo que se otorgue el control total.
Para ilustrar el daño que se puede hacer en esta situación, utilizaremos el ejemplo proporcionado en el cómic anterior al ingresar lo siguiente en el campo de nombre de usuario: "Robert"; Usuarios DROP TABLE; - ".Después de una sustitución simple, la consulta de autenticación pasa a ser:
SELECT UserID FROM Users WHERE UserName = 'Robert';Usuarios de DROP TABLE; - 'AND Password =' wrongpass '
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 instrucción.
Que se ejecuta por la base de datos como:
SELECT ID de usuario FROM WHERE UserName = 'Robert'
DROP TABLE Usuarios
Así que así, hemos utilizado un ataque SQLI para eliminar toda la tabla Usuarios.
Por supuesto, se puede hacer mucho peor, dependiendo de los permisos SQL permitidos, el atacante puede cambiar valores, volcar tablas( o la base de datos completa) en un archivo de texto, crear nuevas cuentas de inicio de sesión o incluso secuestrar toda la instalación de la base de datos.
Prevención de un ataque de inyección SQL
Como mencionamos varias veces anteriormente, un ataque de inyección SQL es fácilmente prevenible. Una de las reglas cardinales del desarrollo web es que nunca confiamos ciegamente en la entrada de los usuarios como lo hicimos cuando realizamos una sustitución simple en nuestra consulta de plantilla anterior.
Un ataque SQLI es frustrado fácilmente por lo que se llama desinfectar( o escapar) tus entradas. El proceso de esterilización es en realidad bastante trivial, ya que todo lo que hace es manejar los caracteres de comillas simples en línea( ') apropiadamente de tal manera que no puedan usarse para terminar prematuramente una cadena dentro de una instrucción de SQL.
Por ejemplo, si desea buscar "O'neil" en una base de datos, no puede usar la sustitución simple porque la comilla simple después de la O provocaría que la cadena terminara prematuramente. En su lugar, desinfecte utilizando el carácter de escape de la base de datos respectiva. Supongamos que el carácter de escape para una comilla simple en línea está precediendo cada cita con un símbolo \.Entonces "O'neal" sería desinfectado como "O \ 'neil".
Este simple acto de saneamiento prácticamente evita un ataque SQLI.Para ilustrar, revisemos nuestros ejemplos anteriores y veamos las consultas resultantes cuando la entrada del usuario se desinfecta.
myuser '- / erróneamente :
SELECT ID de usuario FROM Usuarios WHERE UserName =' myuser \ '-' AND Password = 'wrongpass'
Porque se escapó la comilla simple después de myuser( lo que significa que se considera parte del objetivo)valor), la base de datos literalmente buscará el nombre de usuario de "mi usuario" - ".Además, como los guiones están incluidos dentro del valor de la cadena y no la declaración SQL en sí, se considerarán parte del valor objetivo en lugar de interpretarse como un comentario de SQL.
Robert ';Usuarios de DROP TABLE; - / erróneamente :
SELECT ID de usuario FROM Usuarios WHERE UserName = 'Robert \';Usuarios de DROP TABLE; - AND AND Password = 'wrongpass'
Simplemente escapando de la comilla simple después de Robert, tanto el punto y coma están dentro de la cadena de búsqueda UserName que la base de datos literalmente buscará "Robert"; DROP TABLE Users;- "en lugar de ejecutar la tabla borrar".
En resumen
Mientras los ataques web evolucionan y se vuelven más sofisticados o se enfocan en un punto de entrada diferente, es importante recordar proteger contra intentos y verdaderos ataques que han sido la inspiración de varias "herramientas de hackers" disponibles para explotarlas.
Ciertos tipos de ataques, como DDoS, no se pueden evitar fácilmente mientras que otros, como SQLI, sí pueden. Sin embargo, el daño que puede causar este tipo de ataques puede variar de inconveniente a catastrófico según las precauciones que se tomen.