Test de Seguridad: Tipos de Ataques

Desde el surgimiento de la Web 2.0, el aumento de intercambio de información a través de redes sociales y la creciente adopción empresarial de la Web como un medio para hacer negocios y ofrecer un servicio, los sitios web son a menudo atacados directamente. Como resultado, la industria está prestando una mayor atención a la seguridad de las aplicaciones web y no solo de la seguridad de las redes y sus sistemas operativos.

Según un importante proveedor de seguridad informática las siguientes son las vulnerabilidades mas explotadas:

  • Cross Site Scripting (Secuencias de comandos en sitios cruzados)
  • SQL Injection (Inyección de SQL)
  • Path Disclosure (Divulgación de ruta)
  • Denial of Service (Denegación de servicio)
  • Code Execution (Ejecución de código)
  • Memory Corruption (Corrupción de memoria)
  • Cross Site Request Forgery (Falsificación de petición en sitios cruzados)
  • Information Disclosure (Divulgación de información)
  • Arbitrary File (Archivo arbitrario)
  • Local File Include (Inclusión de archivo local)
  • Remote File Include (Inclusión de archivo remoto)
  • Overflow (ataque con Tests de Stress)
  • Otros

A continuación se explicaran las vulnerabilidades más importantes y comunes:

Cross Site Scripting

Un ataque de Cross Site Scripting (XSS) permite que una persona mal intencionada inyectar en páginas web código JavaScript (u otro lenguaje de scripting similar), evitando medidas de control. Este tipo de vulnerabilidad está muy extendida y puede afectar a cualquier aplicación web que utiliza la información de un usuario en la salida que genera a través del navegador Web, sin validación o codificación de los datos de entrada de la aplicación. En múltiples ocasiones, no se le da la importancia que realmente tiene este tipo de ataques. Mediante una vulnerabilidad de XSS es relativamente sencillo enviar código malicioso a otro usuario desprevenido. El navegador del usuario objetivo no tiene forma de saber si lo que recibe es confiable y ejecuta el código malicioso al suponer que el script proviene de una fuente segura. Este script puede acceder a las cookies, los tokens de sesión u otra información sensible robando incluso la misma sesión.

Este es un ejemplo de un ataque XSS indirecto (que es el más común), tomado de Wikipedia:

Supongamos que un sitio web tiene la siguiente forma:

http://www.example.com/home.asp?frame=menu.asp

y que al acceder se creará un documento HTML enlazando con un frame a menu.asp.

En este ejemplo, ¿Qué pasaría si se pone como URL del frame un código javascript?

javascript:while(1)alert(“Este mensaje saldrá indefinidamente”);

Si este enlace lo pone un atacante hacia una víctima, un visitante podrá verlo y verá que es del mismo dominio, suponiendo que no puede ser nada malo y de resultado tendrá un bucle infinito de mensajes.

Un atacante en realidad trataría de colocar un script que robe las cookies de la víctima, para después poder personificarse como con su sesión, o hacer automático el proceso con el uso de la biblioteca cURL o alguna similar. De esta forma, al recibir la cookie, el atacante podría ejecutar acciones con los permisos de la víctima sin siquiera necesitar su contraseña.

Otro uso común para estas vulnerabilidades es lograr hacer phishing. Quiere decir que la víctima ve en la barra de direcciones un sitio, pero realmente está en otro. La víctima introduce su contraseña y se la envía al atacante.

Una página como la siguiente:

error.php?error=Usuario%20Invalido

es probablemente vulnerable a XSS indirecto, ya que si escribe en el documento “Usuario Inválido”, esto significa que un atacante podría insertar HTML y JavaScript si así lo desea.

Por ejemplo, un tag como que ejecute código javascript, cree otra sesión bajo otro usuario y mande la sesión actual al atacante.

Para probar vulnerabilidades de XSS en cookies, se puede modificar el contenido de una cookie de forma sencilla, usando el siguiente script. Sólo se debe colocar en la barra de direcciones, y presionar ‘Enter’.

javascript:void prompt(“Introduce la cookie:”,document.cookie).replace( /[^;]+/g,function( ){document.cookie=;});

SQL Injection

Una inyección SQL se da cuando se inserta código SQL “invasor” dentro del código SQL programado, a fin de alterar el funcionamiento normal del programa y lograr así que se ejecute la porción de código “invasor” incrustado, en la base de datos.

La forma principal de inyección de código SQL consiste en la inserción directa de código en variables especificadas por el usuario que se concatenan con comandos SQL y se ejecutan. Existe un ataque menos directo que inyecta código dañino en cadenas que están destinadas a almacenarse en una tabla o como metadatos. Cuando las cadenas almacenadas se concatenan posteriormente en un comando SQL dinámico, se ejecuta el código dañino.

A continuación un ejemplo de una inyección de SQL en PHP:

Esta sería una query común de logueo de usuario enviada desde el formulario de nuestro sitio web:

$sql=”SELECT * FROM tbl_user WHERE username= ‘”.$_POST[‘username’].”‘ AND password= ‘”.$_POST[‘password’].”‘”;
$result=mysql_query($sql);

Supongamos ahora que el atacante en “Usuario” y “Password” escribe “x’ OR ‘x’=’x’”, la query enviada sería la siguiente:

SELECT * FROM tbl_user WHERE username=’x’ OR ‘x’=’x’ AND password=’x’ OR ‘x’=’x’;

La fórmula “x’ OR ‘x’=’x’” lo que hace es garantizar que lo enviado en ese campo sea verdad sin importar la formula anterior, por lo tanto la query siempre va a devolver “true”, de esa manera el atacante puede loguearse en el sitio. Cabe aclarar que este es un ejemplo planteado en un sitio con un nivel de seguridad MUY bajo.

Path Disclosure

Una vulnerabilidad del tipo File o Path Disclosure es cuando queda al descubierto la ruta donde esta alojada la aplicación y de esta forma saber en qué directorio específicamente se encuentra el sitio web. Si bien esta vulnerabilidad no es peligrosa resulta bastante útil para explotar otro tipo de vulnerabilidades.

La clásica forma para lograr explotar esta vulnerabilidad es transformando las variables sospechosas pasadas por GET, por ejemplo:

http://sitio.com/index.php?module=login&action=etcetc

Lo transformamos en:

[[http://sitio.com/index.php?module[]=login&action=etcetc]]

Si el sitio no está correctamente desarrollado, lo que hará el sistema es intentar incluir el archivo “login” obteniendo el nombre del fichero desde la variable “module” y si esta variable es un array, mostrará un error o un warning donde podremos ver el path completo del sitio.
Otra forma muy común es, teniendo el mismo caso anterior, remplazar “login” por cualquier cosa:

http://sitio.com/index.php?module=holaholahola&action=etcetc

De esta manera el sistema intentará incluir el fichero “holaholahola” y como no existe, mostrará un warning o error también con el path completo del sitio.

Denial of Service (DoS )

Se genera mediante la saturación de los puertos con flujo de información, haciendo que el servidor se sobrecargue y no pueda seguir prestando servicios, por eso es denominado “denial of service” (denegación de servicio), ya que hace que el servidor no dé abasto con la cantidad de solicitudes. Una ampliación del ataque “DoS” es el “DDoS” o Distributed Denial of Service (ataque distribuido de denegación de servicio) el cual se lleva a cabo generando un gran flujo de información desde varios puntos de conexión.

Un ataque DoS puede ser llevado a cabo de varias formas, aunque básicamente consisten en:

  • Consumo de recursos, tales como ancho de banda, espacio de disco, o tiempo de procesador.
  • Alteración de información de configuración, tales como la información de rutas.
  • Alteración de información de estado, tales como interrupción de sesiones TCP (TCP reset).
  • Interrupción de componentes físicos de red.
  • Obstrucción de medios de comunicación entre usuarios de un servicio y la víctima, de manera que ya no puedan comunicarse adecuadamente.

La forma más común de realizar un DoS es a través de una botnet, siendo esta técnica el ciberataque más usual y eficaz por su sencillez tecnológica. En ocasiones, esta herramienta ha sido utilizada como un buen método para comprobar la capacidad de tráfico que un equipo puede soportar sin volverse inestable y afectar a los servicios que presta.

En un próximo post veremos cómo poner a prueba los sitios para detectar posibles vulnerabilidades.

 

Anuncios