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 darte un manual para hacerlo tú mismo, es útil entender 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 por xkcd

Ataque de denegación de servicio

¿Qué es?

Una "denegación de servicio" (a veces llamada "denegación de servicio distribuida" o DDoS) El ataque 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 se bloquea y se apaga. El 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 desmantelar 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. Así que, en esencia, la empresa 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.

Ejecución del ataque

Debido a la "fuerza bruta" forzar "la naturaleza de un ataque DDoS, necesita 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 sepa, hay muchas variantes de malware y troyanos que , una vez en su sistema, permanezca inactivo y ocasionalmente "llame 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 inicio 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 la utilización de las computadoras zombies no solo está en su efectividad, sino también también en su anonimato ya que el atacante en realidad 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 un explotar que aprovecha las pobres técnicas de desarrollo web 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 prevenir de manera completa y fácil si una aplicación web está programada adecuadamente.

Ejecutando el ataque

Cuando inicie sesión en un sitio web e ingrese su nombre de usuario y contraseña, para probar su credenciales la aplicación web puede ejecutar una consulta como la siguiente:

SELECCIONAR ID de usuario FROM Usuarios WHERE 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.

Entonces la combinación del nombre de usuario ingresado (myuser) y contraseña (mypass) debe coincidir con una entrada en el Tabla de 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, los mecanismos son bastante estándar.

Veamos ahora una consulta de autenticación de plantilla que podemos sustituir los valores que el usuario ingresa en el formulario web:

SELECCIONAR ID de usuario FROM Usuarios WHERE Nombre de usuario = " [usuario] "AND Password =" [pass] "

A primera vista, esto puede 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, se 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 ID de usuario FROM Usuarios WHERE Nombre de usuario = "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 WHERE 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 aplicación negligente e irresponsable y es completamente prevenible (que trataremos 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 aclarar algo.

Basado en el ejemplo anterior, puede verlo 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 respectiva base de datos.

Supongamos ahora que el sitio web tiene control total de su respectiva base de datos que le da la capacidad para 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, por lo que no es automáticamente una mala cosa que se otorgue el control total.

Así que para Para ilustrar el daño que se puede hacer en esta situación, utilizaremos el ejemplo provisto en el cómic anterior al ingresar lo siguiente en el campo de nombre de usuario:"Robert"; Usuarios de DROP TABLE; - ".Después sustitución simple la consulta de autenticación se convierte en:

SELECCIONAR ID de usuario FROM Usuarios WHERE Nombre de usuario = "Robert"; Usuarios de DROP TABLE; - 'AND Password = "wrongpass"

Nota: el punto y coma en una consulta SQL se usa para indicar el final de una instrucción particular y el comienzo de una nueva instrucción.

Que se ejecuta por la base de datos como:

SELECCIONAR ID de usuario FROM Usuarios WHERE Nombre de usuario = "Robert"

DROP TABLE Usuarios

Así pues, hemos utilizado un ataque SQLI para eliminar toda la tabla Usuarios.

Por supuesto, se puede hacer mucho peor, dependiendo de los permisos de 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 del usuario 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) sus entradas. El proceso de esterilización es en realidad bastante trivial ya que todo lo que hace es manejar cualquier carácter de comilla simple (') en línea apropiadamente de manera tal que no pueda usarse para terminar prematuramente una cadena dentro de una instrucción de SQL.

Por ejemplo, si quisieras busque "O'neil" en una base de datos, no podría 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" se desinfectaría 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 se desinfecta la entrada del usuario.

myuser '- / wrongpass :

SELECT UserID FROM Users WHERE UserName = " myuser "- 'AND Password =" wrongpass "

Como se escapó la comilla simple después de myuser (lo que significa que se considera parte del valor objetivo), la base de datos literalmente buscará el nombre de usuario de" myuser " - ".Además, como los guiones están incluidos dentro del valor de cadena y no de la declaración SQL en sí, se considerarán parte del valor objetivo en lugar de interpretarse como un comentario SQL.

Robert '; Usuarios de DROP TABLE; - / wrongpass :

SELECT ID de usuario FROM Usuarios WHERE Nombre de usuario = "Robert "; Usuarios de DROP TABLE; - 'AND Password = "wrongpass"

Simplemente escapando de la comilla simple después de Robert, tanto el punto y coma están contenidos dentro de la cadena de búsqueda UserName que la base de datos buscará literalmente"Robert' ; Usuarios de DROP TABLE; - "en lugar de ejecutar la eliminación de tabla.

En resumen

Mientras los ataques web evolucionan y se vuelven más sofisticados o se centran en un punto de entrada diferente, es importante recordar proteger contra ataques probados y verdaderos que han sido la inspiración de varias "herramientas de hackers" de acceso libre diseñadas 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 desde un inconveniente hasta catastrófico dependiendo de las precauciones tomadas.

¿Cómo protege su contraseña una carpeta en Linux / Unix sin encriptación?

Si no necesita o no quiere cifrar archivos en su computadora pero desea detener el espionaje casual, entonces ¿qué es? el mejor método para proteger con contraseña sus carpetas en Linux / Unix? La publicación de preguntas y respuestas SuperUser de hoy tiene respuestas útiles a la pregunta de un lector curioso.

(how-to)

Cómo buscar y eliminar archivos duplicados en Mac OS X

Los archivos duplicados son una pérdida de espacio en disco, consumen ese precioso espacio SSD en una Mac moderna y abarrotan sus copias de seguridad de Time Machine. Quítelos para liberar espacio en su Mac. Hay muchas aplicaciones de Mac pulidas para esto, pero en su mayoría son software pago. Esas aplicaciones brillantes en la tienda de aplicaciones de Mac probablemente funcionen bien, pero tenemos algunas buenas opciones si no quieres sacar tu tarjeta de crédito.

(how-to)