Las principales vulnerabilidades web

Cuando se va a atacar un sistema, lo último que se quiere es que salten todas las alarmas. Es por eso que usar fuentes online son una buena herramienta. Se puede utilizar hacking de buscadorespara localizar URLs con paso de parámetros, para comprobar si éstos están correctamente validados, para buscar correos electrónicos u otra información que pueda extraerse de un determinado sitio: ficheros de backup o de configuración que hayan quedado indexados, etc.

Un buscador muy utilizado es Shodan. Este buscador almacena toda la información pública que puede obtener de aquellos dispositivos que están expuestos a Internet. Entre otras cosas, podemos encontrar dispositivos con sus claves por defecto (routers, cámaras ip, etc), direcciones IP con los puertos que tienen abiertos, servicio y versión del mismo que corre en cada uno, certificados SSL, con sus respectivas suites de cifrado, etc. Una vez indexada una determinada IP en Shodan, evita tener que hacer una comprobación directa sobre el sistema, de manera que permite a un atacante conocer si un sitio web está correctamente actualizado, sin necesidad de lanzar un escaneo de puertos, que pueda delatarle a él.

METADATOS

Otra fuente de información importante son las fugas de información que se producen por culpa de los metadatos, que van incluidos en los documentos que se publican en Internet.

Con estos datos, es posible conocer nombres de usuario, equipos, sistemas operativos, versiones de software, etc. que se utiliza en la organización.

Si no se tiene cuidado, con estos datos es posible incluso realizar un mapa interno de la organización, desde los equipos cliente, con los usuarios de cada uno, hasta los servidores de los que se dispone, pasando por impresoras, etc.

Es por esto que es muy importante, antes de subir un documento o publicarlo, realizar una limpieza de metadatos del mismo.

Herramientas como FOCA, son de gran utilidad para comprobar qué información sensible estamos publicando, sin que seamos conscientes.

Principales vulnerabilidades web

Una vez que hemos visto lo importante que es la información acerca de nosotros que tenemos publicada, y que debemos intentar controlar, veamos qué vulnerabilidades más importantes puede presentar un sitio web.

En primer lugar nos situamos en el escenario, tenemos una plataforma montada sobre un sistema operativo, con su motor de base de datos, lenguajes, normalmente interpretados, certificados, etc. Ésta es la parte del servidor web en sí. Las vulnerabilidades que tendrá desde ese punto de vistas serán:

–Configuración débil, por defecto o mal configurado. Esto suele producirse por intentar desplegar el servicio lo más rápido posible o por una confianza excesiva en el software utilizado, incluso por desconocimiento. Cuando se expone a Internet un sistema con su configuración por defecto, si se encuentra una vulnerabilidad en el mismo, el exploit por defecto funcionará. Es necesario revisar el servicio a desplegar y buscar una configuración suficientemente fuerte.

– Comunicación insegura entre cliente y servidor. Es muy importante que la comunicación entre cliente y servidor esté cifrada, sobre todo, cuando se trata de envíos de formularios, por ejemplo, para autentificarse en sitio web. En muchas ocasiones, se configura el sitio web para usar cifrado, con una configuración débil, permitiendo protocolos inseguros, como SSLv2 y SSLv3, o suites de cifrado vulnerables, como MD5. Esto dará una falsa sensación de seguridad, el cliente verá que hay un certificado, que el sitio web, aparentemente está cifrado, y, sin embargo, por culpa de los protocolos permitidos, podría ser relativamente fácil descifrar esta comunicación. Es por ello que es necesario revisar el estado de la calidad en la configuración de nuestros certificados.

– Software desactualizado. Una vez desplegado el sistema, independientemente de que se hiciese el trabajo correctamente, pasado el tiempo, el software se desactualiza. Se localizan vulnerabidades, se corrigen en versiones posteriores, etc. Es necesario llevar un control de las versiones utilizadas, así como mantener el software actualizado, en el menor tiempo posible, desde que se libera una nueva versión. En caso contrario, al cabo de un tiempo, nuestro sistema será vulnerable y existirán exploits públicos que permitirán atacarlo.

Vulnerabilidades de la aplicación

Estas vulnerabilidades son propias de la aplicación que se quiere desplegar, del código de la misma. Independientemente de que la plataforma sobre la que despleguemos la aplicación esté correctamente fortificada, si la aplicación posee vulnerabilidades, corremos el riesgo de que puedan encontrarse y ser  atacadas.

Las vulnerabilidades más comunes en una aplicación web son:

Cross-Site Scripting (XSS), ésta es una vulnerabilidad o, mejor dicho, un conjunto de vulnerabilidades, que permiten, utilizando los parámetros de entrada de la aplicación, modificar y añadir código a la misma.

Son vulnerabilidades que se encuentran en el servidor, pero que están destinadas a atacar al cliente.

Generalmente, se necesita que el cliente sigua un enlace de la aplicación, en el que se ha modificado algún parámetro, para permitir añadir código, que se ejecutará en el navegador del cliente.

Normalmente, el código inyectado será html o JavaScript y la intención será un robo de cookies del cliente, predicción del id de sesión, etc.

Esta vulnerabilidad se aprovecha de la confianza en el cliente en el sitio web: Verá que es el dominio de la aplicación y que, al seguir el enlace, llega realmente al sitio web que quería, no hay suplantación del mismo.

Básicamanente, podemos agrupar los XSS en dos grupos:

– XSS reflejados: El código modificado se elimina al cargar la página de nuevo. Está basado en la URL y, por tanto, al recargar la página, se elimina el mismo.

-XSS persistentes: El código modificado queda almacenado en la web.

La forma de corregir esta vulnerabilidad es filtrar y validar todas las entradas de la aplicación. No se debe utilizar nunca una variable que se recibe desde el cliente, confiando en que ésta tendrá un valor correcto. Los lenguajes de programación incluyen diferentes funciones que permiten filtrar el contenido de las variables, dependiendo de dónde las vayamos a utilizar.

Cross Site Request/Reference Forgery (CSRF)

Esta vulnerabilidad es una evolución de los XSS. En este caso, se va a explotar la confianza en el servidor sobre el cliente. Es decir, nos haremos pasar por un cliente legítimo, utilizando datos parciales del mismo.

Esta vulnerabilidad está presente en formularios. Cuando estos se envían al servidor, es necesario asegurarse que la petición es legítima y debemos asegurarnos que el cliente ha realizado la petición, realizando los pasos previos necesarios.

La forma más común para eliminar esta vulnerabiliad o, al menos, mitigarla, es la inclusión de tockens dinámicos. En los actuales FrameWorks, suelen incluirse mecanismos para añadir esta protección a los formularios, de una forma muy sencilla. En algunos, por ejemplo, Laravel (utilizado para desarrollo de aplicaciones en PHP), basta añadir una etiqueta a la plantilla del formulario, para que se añada al mismo el tocken anti-csrf.

A continuación os muestro los nombres de los diferentes XSS más comunes, que dependen del lugar donde se consiga inyectar el código deseado.

• DOM Cross Site Scripting (DOM XSS)
• Cross Site Flashing (XSF)
• Cross Frame Scripting (XFS)
• Cross Zone Scripting (XZS)
• Cross Agent Scripting (XAS)
• Cross Referer Scripting (XRS)
• …

SQL INJECION

Si los ataques XSS son peligrosos, ya que pueden provocar un robo de sesión, los SQLi son aún más porque permiten acceder y manipular la BBDD. La idea es modificar las consultas que hace la aplicación a la base de datos, aprovechando las entradas de usuario a la aplicación.

Veamos una estructura de una consulta SQL típica.

SELECT [Columnas] FROM [Tabla] WHERE [Condiciones]

Primero se seleccionan las columnas que queremos mostrar, después se indica la BBDD y la tabla de la que queremos obtener las columnas y, por último, las condiciones para filtrar esos datos.

Cuando se van a realizar consultas, se realizan con un usuario de BBDD. Este usuario tendrá diferentes permisos.

Otra cosa a tener en cuenta es que, los motores de BBDD, tienen sus propias tablas para almacenar metadados, por ejemplo, las bases de datos que hay, qué tablas tiene cada BBDD, las columnas y tipo de cada una, información de usuarios, etc.

Hay que tener presente que, cuando se puede hacer un SQL injection, se hará con los permisos que disponga el usuario con el que se ejecuta.

Existen diferentes ataques de SQL injection, dependiendo de cómo se consiga inyectar y modificar la consulta, para obtener los datos que se desean.

• Bypass de un login mediante SQL Injection
• SQL Injection (Mediante UNION)
• Serialized SQL Injection
• Boolean-Base SQL Injection
• Time-Base SQL Injection
• Heavy-Queries SQL Injection
• Stack-Queries
• …

Ahora vamos a explicar cómo se realizaría un SQLi.

Empezaremos explicando un SQLi de tipo Union.

Lo primero es tener claro cómo sería la estructura de la consulta que se desea modificar. Cuando se va a utilizar Union para realizar la inyección, lo primero que debe hacerse es negar la consulta original, para que esa no sea la que devuelva la información.

Por lo tanto, se debe añadir una condición que siempre sea falsa.

SELECT ID, Nombre FROM Clientes WHERE ID=1 AND 1=0

Una vez que sabemos cómo negar la consulta legítima, vamos a testear cuantas columnas devuelve la consulta original. Esto es importante, porque los SQLi deben devolver exactamente el mismo número de columnas. Para ello, vamos probando mostrando un valor constante, luego dos, etc. hasta que veamos que tenemos un resultado.

http://dominio/index.php?id=1 AND 1=0 UNION SELECT 1
http://dominio/index.php?id=1 AND 1=0 UNION SELECT 1,2
...

Hecho esto, ya sabemos cuantas columnas debe devolver nuestra consulta, a partir de aquí, habrá que intentar obtener información de los nombres de tablas que hay en la BBDD, luego de los nombres de columnas por cada tabla y, una vez tengamos esa información, podremos ir extrayendo aquello que necesitemos.

user(): usuario que ejecuta las consultas en la aplicación

database():la base de datos usada actualmente

http://dominio/index.php?id=1+and+1=0+union+select+1,2,user(),database()

Otro escenario común es utilizar un consulta para validar la autentificación de un usuario. Se consulta en la BBDD si el nombre de usuario y password existen y, si devuelve un registro, entonces se le permite el acceso. Si alguna de estas variables es vulnerable a un SQLi, se puede forzar la consulta para que siempre devuelva algo, de manera que podremos saltar el login de la aplicación.

Por supuesto, existen herramientas que automatizan esto. Por ejemplo, SQLMap, nos permite automatizar los SQLis y, una vez detectado un parámetro vulnerable, nos permite extraer información de una manera muy cómoda. Incluso nos permitirá abrir una shell en el servidor, si esto es posible con el usuario actual, subir ficheros, realizar elevación de privilegios, etc.

Para prevenir los SQLi, se deben parametrizar las consultas y es necesario filtrar y comprobar el valor de las entradas. También es muy importante restringir al máximo los permisos del usuario con el que la aplicación se conecta a la BBDD y, por supuesto, para cada BBDD, utilizar un usuario diferente. Esto es muy importante y, aunque es una mala práctica usar una misma instancia del motor de BBDD para diferentes aplicaciones, es un escenario muy común. Por este motivo, si un usuario de la BBDD tiene permisos sobre varias BBDD de diferentes aplicaciones y una de éstas presenta esta vulnerabilidad, el atacante podría obtener los datos del resto de aplicaciones.

Además de esto, es muy importante ocultar los errores provocados por consultas en BBDD. Esto es porque la forma de detectar un SQLi es intentar forzar un error (la típica ‘) y, una vez se comprueba que existe, si se muestra al usuario, éste puede extraer información, como el motor de BBDD usado, etc., con lo que se le facilitará la realización del ataque.