tema3

Vulnerabilidades web [3.1] ¿Cómo estudiar este tema? [3.2] OWASP [3.3] Plataformas de aprendizaje [3.4] Herramientas para hacking web

TEMA

3

[3.5] Tipos de vulnerabilidades

TEMA 3 – Esquema

Top 10

Introducción • ¿Qué es? • ¿Qué busca?

OWASP

WebGoat • Introducción • Instalación

Mutillidae • Introducción • Instalación

DVWA • Introducción • Instalación

Plataformas de aprendizaje

2

Tamper Data

Hydra

SQLMap

OWASP - ZAP • Herramientas de la suite

BurpSuite • Herramientas de la suite

Herramientas

Vulnerabilidades web

Protección insuficiente en la capa de transporte

Almacenamiento criptográfico inseguro

Gestión de sesión

Subida de archivos sin restricción

Redirecciones y reenvíos

Inyección

Configuraciones inseguras

Referencia directa insegura a objetos

XSS

Ejecución maliciosa de ficheros

CSRF

Fuerza bruta

Authentication bypass

Tipos de vulnerabilidades

Análisis de Vulnerabilidades

Esquema

© Universidad Internacional de La Rioja, S. A. (UNIR)

Análisis de Vulnerabilidades

Ideas clave 3.1. ¿Cómo estudiar este tema? Para estudiar este tema lee las Ideas clave que se exponen a continuación. En la actualidad, casi todo está relacionado con Internet y las aplicaciones y servicios web que proporciona, ya sea para ver el correo o para hacer compras online. Pero hay datos sensibles y debe haber una seguridad en todos estos servicios y aplicaciones. En este tercer tema se hablará de las vulnerabilidades web más importantes, de las diferentes herramientas que tenemos para encontrarlas y explotarlas y de diferentes plataformas de aprendizaje para el alumno. En primer lugar hablaremos de OWASP, un proyecto de código abierto creado para luchar contra las vulnerabilidades web. Este proyecto ha creado diferentes herramientas y guías tanto para la defensa como para el ataque. Además, cada 3 años publica un documento con el Top 10 de las vulnerabilidades más importantes para prevenir a los administradores y ayudar a evitarlas. Después veremos tres plataformas de aprendizaje: DVWA, Mutillidae y WebGoat. Mediante estas plataformas el alumno podrá practicar lecciones de ataque web a páginas y aplicaciones vulnerables (sin que tenga que atacar sitios reales). Luego se verán diferentes herramientas para poder analizar y explotar vulnerabilidades web. Todas las que se verán forman parte del Top 10 de herramientas de Kali Linux por su gran versatilidad y potencial. Son: BurpSuite, una suite de diferentes herramientas para analizar peticiones web y reenviarlas para explotar vulnerabilidades. OWASP-ZAP, otra suite de herramientas similar a BurpSuite diseñada por el proyecto OWASP. SQLMap, una herramienta para realizar inyecciones SQL de cualquier tipo (normales, blind…) Hydra, una herramienta para realizar ataques por fuerza bruta a servicios en Internet.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

3

Análisis de Vulnerabilidades

Tamper Data, un plugin muy útil que realiza la función de captura y modificación de peticiones HTTP. Finalmente, se hablará de los diferentes tipos de vulnerabilidades web. Por cada vulnerabilidad se explicará en qué consiste, un ejemplo teórico o práctico de cómo se podría explotar y qué formas hay para evitar y protegernos de dicha vulnerabilidad. Estas vulnerabilidades son: Authentication bypass, fuerza bruta, Cross Site Request Forgery (CSRF), ejecución maliciosa de ficheros local (LFI) y remota (RFI), Cross Site Scripting (XSS), configuraciones inseguras, referencia directa insegura a objetos, inyección (de comandos y SQL), redirecciones y reenvíos, subida de archivos sin restricción, gestión de sesiones, almacenamiento criptográfico inseguro y protección insuficiente en la capa de transporte.

3.2. OWASP OWASP es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro. La Fundación OWASP es un organismo sin ánimo de lucro que apoya y gestiona los proyectos e infraestructura de OWASP. Los documentos con más éxito de OWASP son OWASP Testing Guide y OWASP Top 10. El primero, que ya va por su versión 4, consiste en una guía práctica y teórica para realizar pentesting a aplicaciones web; el segundo consiste en una recopilación de las vulnerabilidades más frecuentes que nos podemos encontrar en las aplicaciones web, así como su funcionamiento, impacto y formas de evitarlas. Las herramientas OWASP más usadas incluyen el entorno de formación WebGoat que veremos más adelante, las herramientas WebScarab (para pruebas de penetración) y OWASP-ZAP (para realizar escaneos de vulnerabilidades en aplicaciones web) y las utilidades de seguridad para entornos .NET OWASP DotNet. Nos vamos a centrar en el top 10 OWASP, su objetivo es educar a desarrolladores, diseñadores, arquitectos, gerentes y organizadores sobre las consecuencias de las vulnerabilidades de seguridad más importantes en aplicaciones web. Dicho documento provee de técnicas básicas sobre cómo protegerse en estas áreas de alto riesgo y también provee orientación sobre los pasos a seguir. TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

4

Análisis de Vulnerabilidades

Nos vamos a fijar en los top 10 de los años 2010 y 2013 (este último es el más actual) y veremos cómo han cambiado en estos años. En los próximos apartados veremos más a fondo los diferentes tipos de vulnerabilidades.

Figura 1. Comparación Top 10 OWASP 2010 y 2013.

La guía además clasifica estas vulnerabilidades según la facilidad de explotación que tengan, la prevalencia (la cantidad de sitios donde podemos encontrar la vulnerabilidad), la detección (la facilidad de que un atacante encuentre este tipo de vulnerabilidad) y el impacto que puede provocar en la aplicación web.

Figura 2. Clasificación del Top 10 OWASP 2013.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

5

Análisis de Vulnerabilidades

Puedes encontrar documentación de OWASP en la siguiente dirección web: https://www.owasp.org/index.php/Main_Page Accede al top 10 de 2013: https://www.owasp.org/images/5/5f/OWASP_Top_10_-_2013_Final_-_Español.pdf Accede a la Guía de Testing OWASP v4: https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf

3.3. Plataformas de aprendizaje Para poder realizar algunos ejemplos y poder practicar las vulnerabilidades que iremos viendo será necesario un entorno que simule una aplicación web real. No es conveniente hacerlo con sitios web reales ya que podemos causar verdaderos problemas a los sitios y hacerlo sin consentimiento de los administradores del sitio es ilegal. Para ello tenemos a nuestra disposición tres plataformas diseñadas especialmente para el aprendizaje de las vulnerabilidades web. Estos entornos ya contienen vulnerabilidades a propósito para que podamos explotarlas de la misma forma que lo haría un atacante real. Poseen diferentes niveles de dificultad, aunque cada plataforma los gestiona de una forma diferente. A continuación explicaremos cada una de las tres plataformas, tanto su instalación como características principales. 1. DVWA DVWA (Damn Vulnerable Web Application) es un reconocido entorno de entrenamiento en explotación de seguridad web, que permite estudiar e investigar sobre las diferentes temáticas involucradas en dicho campo. Será la plataforma que utilizaremos para nuestros ejemplos y demostraciones, ya que es la que presenta la interfaz más cómoda y no necesita descargar nada extra para su instalación.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

6

Análisis de Vulnerabilidades

Tiene tres niveles de dificultad: Bajo (Low). Simula un entorno muy vulnerable, nos permitirá hacer casi cualquier cosa. Medio (Medium). Simula un entorno más controlado, serán necesarias diversas técnicas de evasión de filtros. Alto (High). Simula un entorno real seguro, no podremos vulnerarlo. Las temáticas que cubre la plataforma son las siguientes:

Brute Force

Command execution

CSRF

Insecure CAPTCHA

File Inclusion

SQL Injection

Blind SQL Injection

Upload

XSS Reflected

XSS Stored

Categorías principales de DVWA.

Su interfaz es la siguiente:

Figura 3. Interfaz de DVWA.

Vamos a explicar cómo realizar su instalación en nuestra máquina Kali Linux, pero se podría hacer en cualquier sistema operativo. Para realizar la instalación será necesario TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

7

Análisis de Vulnerabilidades

tener un servidor, una base de datos y PHP ya instalado (ya que DVWA está basado en este lenguaje). En nuestro caso, en la máquina Kali ya los tenemos, por lo que descargaremos la plataforma de la página oficial http://www.dvwa.co.uk/. Descomprimiremos el zip, lo moveremos a la carpeta del servidor y le daremos permisos de ejecución: unzip DVWA-1.0.8.zip. mv DVWA-1.0.8 /var/www/dvwa. chmod -R 755 /var/www/dvwa. Ahora iniciaremos el gestor de bases de datos y crearemos la base de datos de la aplicación. service mysql start. mysql -u root -p (Cuando nos pida contraseña simplemente pulsaremos enter). create database dvwa; show databases; (Para comprobar que la hemos creado correctamente). Exit. Finalmente iniciaremos el servidor y ya podremos conectarnos a la plataforma: service apache2 start. Nos conectaremos a ella poniendo en el navegador 127.0.0.1/dvwa/ o localhost/dvwa/. El usuario de login será «admin» y la contraseña «password» (ambas sin las comillas). Hay otra forma de instalar la plataforma en cualquier sistema operativo (Linux, Windows, Mac…) y es usando XAMPP, una aplicación que incluye un servidor Apache, una base de datos MySQL y varias librerías para lenguajes como PHP y Perl. La aplicación administrará por nosotros el servidor web. Puedes obtener más información en la siguiente dirección web: https://www.apachefriends.org/index.html

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

8

Análisis de Vulnerabilidades

2. Mutillidae Mutillidae es otra plataforma para poder entrenar los conocimientos de seguridad orientados a una aplicación web. Esta plataforma es complementaria por si quieres practicar con más ejemplos que los que se trabajarán en la plataforma DVWA. Mutillidae contiene varios tipos de vulnerabilidades más que DVWA y posee dos niveles de sugerencias o consejos (Tips) para ayudar al usuario a explotarlas. Incluye todas las vulnerabilidades vistas en el OWASP Top 10 (tanto de 2010 como de 2013). La plataforma tiene dos modos: En el modo inseguro (por defecto), las páginas serán vulnerables, al menos a la vulnerabilidad que indique la pestaña a la que pertenezcan, aunque pueden ser vulnerables a muchas más. Tendrá dos niveles dentro del modo inseguro. En el modo seguro, Mutillidae intenta proteger a las páginas con scripts del lado del servidor, pero seguirán siendo vulnerables y se podrá explotar. Además, las sugerencias se desactivan en este modo. El código fuente de las páginas y los scripts estás comentado para permitir al usuario ver cómo funcionan las defensas y vulnerabilidades.

Figura 4. Interfaz de Mutillidae.

De nuevo nos conectaremos a la plataforma mediante el navegador, en este caso pondremos 127.0.0.1/mutillidae/ o localhost/mutillidae/. No hará falta usuario ni contraseña. TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

9

Análisis de Vulnerabilidades

En la siguiente dirección web encontrarás, en el apartado Downloads, todas las versiones de la aplicación para descargar: http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerablephp-owasp-top-10 El autor de la plataforma también ha creado una gran colección de vídeo tutoriales de pentesting de aplicaciones web utilizando Mutillidae. Puedes ver todos estos vídeos en la siguiente dirección web: http://www.irongeek.com/i.php?page=videos%2Fweb-application-pen-testingtutorials-with-mutillidae 3. WebGoat WebGoat es una plataforma con aplicaciones web deliberadamente inseguras desarrollada y mantenida por OWASP para enseñar y practicar lecciones de seguridad web. La página se divide en diferentes lecciones, en la cuales el usuario deberá demostrar su conocimiento del fallo de seguridad explotando una vulnerabilidad real en la aplicación web. Por ejemplo, en una de las lecciones el usuario deberá utilizar la inyección SQL para robar números de tarjetas de crédito (falsos). La plataforma además proporcionará al usuario consejos y el código de cada vulnerabilidad. WebGoat está escrito en Java y se puede instalar en cualquier máquina que tenga una máquina virtual de Java, por lo que funciona sobre cualquier sistema operativo (Linux, Windows, Mac OS X...).

Actualmente hay 30 lecciones de aprendizaje entre las cuales encontramos las siguientes vulnerabilidades: o Cross Site Scripting (XSS). o Gestión de acceso. o Seguridad de hilos. o Manipulación de campos y parámetros. o Sesiones débiles de cookies.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

10

Análisis de Vulnerabilidades

o Inyección SQL (String, Numeric, blind…). o Peligros de los comentarios HTML. La plataforma además incluye información acerca de las cookies y los parámetros que se envían y gestionan.

Figura 5. Interfaz de WebGoat.

La instalación será sencilla en cualquier tipo de plataforma, el único requisito será tener Java 1.6 o superior. Las últimas distribuciones de Kali Linux ya lo llevan incorporado, pero para asegurarnos comprobaremos la versión en la consola de comandos con java –version. Si no tenemos 1.6 o superior lo podremos descargar de la página oficial de Oracle: http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads1880260.html Puedes descargar WebGoat desde la siguiente dirección web: https://webgoat.atlassian.net/builds/browse/WEBWGM/latestSuccessful/artifact/shared/WebGoat-Embedded-Tomcat/WebGoat-6.0.1war-exec.jar Una vez descargado ejecutaremos el siguiente comando cada vez que queramos utilizar la plataforma, pues no necesita instalación ni ejecutar ningún servidor o base de datos extra, ya lo hace todo el archivo jar: java -jar WebGoat-6.0.1-war-exec.jar.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

11

Análisis de Vulnerabilidades

Cuando aparezca en la consola el siguiente mensaje ya podremos acceder a la plataforma a través del navegador con la URL http://localhost:8080/WebGoat.

Figura 6. Plataforma WebGoat lista para funcionar.

Es importante recordar que no debemos cerrar la consola en la que hayamos ejecutado el comando anterior, porque entonces dejará de funcionar la plataforma.

3.4. Herramientas Antes de comenzar a ver los diferentes tipos de vulnerabilidades web vamos a ver más a fondo algunas herramientas diseñadas especialmente para el análisis y explotación de aplicaciones y servicios web. Estas herramientas facilitarán enormemente la búsqueda de vulnerabilidades y la automatización de la explotación. En el próximo apartado de tipos de vulnerabilidades web utilizaremos algunas de estas herramientas y alguna otra más, como Crunch, pero se deja como tarea para el alumno el investigar más sobre ellas. Todas las herramientas que vamos a ver están por defecto en Kali Linux. 1. BurpSuite BurpSuite es una suite de herramientas de las más utilizadas a la hora de realizar un pentesting a una aplicación web por la gran variedad de herramientas que contiene. Forma parte del Top 10 de aplicaciones de Kali. Dispondremos de la versión gratuita en nuestra máquina Kali, que se diferencia de la versión de pago solamente en que carece de un par de funcionalidades.

Figura 7. Herramientas de BurpSuite.

La primera herramienta es el Proxy, nos proporciona un servidor proxy que nos permite capturar y manipular el tráfico que pase a través de él. Nos mostrará todos los TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

12

Análisis de Vulnerabilidades

parámetros separando cabecera y datos y normalmente será capaz de marcar en color rojo lo que crea que son parámetros modificables, facilitando la tarea al usuario. Al modificar parámetros podremos realizar multitud de funciones como: aumentar el tamaño máximo permitido a la hora de subir archivos, introducir más texto en un campo del permitido, modificar la cookie de sesión… Para usarlo será necesario establecer en el navegador que vamos a utilizar un proxy, en este caso lo vamos a explicar para Iceweasel (Firefox) el navegador por defecto en Kali. En preferencias iremos a Advanced > Network > Settings.

Figura 8. Preferencias de Iceweasel.

Después seleccionaremos una configuración proxy manualmente, por la dirección 127.0.0.1 y el puerto 8080 (en el caso de que queramos utilizarlo con WebGoat será necesario cambiar el puerto al 8081, por ejemplo, ya que la plataforma corre en el mismo puerto).

Figura 9. Ajustes de conexión de Iceweasel.

Además quitaremos que no se pueda usar un proxy en localhost (puesto por defecto). TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

13

Análisis de Vulnerabilidades

Por defecto BurpSuite utiliza el puerto 8080, pero si lo queremos modificar podemos ir a Proxy > Options y ahí lo cambiaremos. Podemos ver un ejemplo de captura a WebGoat con este proxy:

Figura 10. Captura de WebGoat con el proxy de BurpSuite.

Nota: no olvidar desactivar el proxy en las opciones del navegador al cerrar BurpSuite, ya que no funcionará, porque todas las peticiones las mandará al puerto proxy y no habrá ninguna aplicación para reenviarlas. La siguiente herramienta, Spider, es una herramienta que puede enumerar y realizar un mapa del sitio web y de las diferentes páginas a las que enlaza, parámetros y objetos que tiene… Para ello examina las cookies e inicia conexiones a la aplicación web a las páginas que encuentre. Para utilizarlo elegiremos una captura hecha con el proxy y con clic derecho o pulsando Action, seleccionaremos «Send to Spider».

Figura 11. Spider en funcionamiento.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

14

Análisis de Vulnerabilidades

Figura 12. Resultado de Spider en WebGoat.

La siguiente herramienta, el Scanner, es específica para la versión de pago, por lo que no nos interesa. Es capaz de realizar un escaneo de una aplicación web en busca de vulnerabilidades. Otra de las herramientas y una de las más potentes de la suite es Intruder, con la que podremos realizar ataques sobre aplicaciones web automatizados. Nos permitirá generar peticiones HTTP maliciosas y detectar y explotar vulnerabilidades como inyección SQL, XSS, manipulación de parámetros o ataques por fuerza bruta. Esta herramienta nos permitirá seleccionar diferentes partes de las peticiones y convertirlas en parámetros, para después automatizar peticiones modificando estos parámetros mediante listas de palabras. La versión gratuita tendrá ciertas limitaciones a la hora de utilizar listas en archivos de texto.

Figura 13. Interfaz del Intruder.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

15

Análisis de Vulnerabilidades

En el próximo capítulo de tipos de vulnerabilidades web utilizaremos esta herramienta y se verá más detalladamente su funcionamiento. La siguiente herramienta, el Repeater, será muy simple. Nos permitirá coger una petición realizada y reenviarla tantas veces queramos modificando manualmente los parámetros.

Figura 14. Interfaz del Repeater.

Las cuatro herramientas restantes tienen funciones más específicas y no las utilizaremos, pero se describirá brevemente su utilidad: El Sequencer se utiliza para comprobar la aleatoriedad de los tokens de sesión generados por la aplicación web. El Decoder se utiliza para codificar una petición o URL a diferentes formatos como Base64, URL o incluso convertirlos en hashes MD5 o SHA-1. El Comparer se utiliza para comparar entre dos conjuntos de datos, puede ser entre peticiones o entre respuestas, palabra por palabra o bit a bit… Finalmente el Extender nos permitirá añadir funcionalidades y plugins extra a BurpSuite. 2. OWASP-ZAP OWASP Zed Attack Proxy u OWASP-ZAP es una suite de herramientas creada y mantenida por el proyecto OWASP. Está escrita en Java y es multiplataforma (incluyendo Linux, Windows y Mac OS X).

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

16

Análisis de Vulnerabilidades

Figura 15. Interfaz de OWASP-ZAP.

Es una suite de herramientas para la búsqueda y explotación de vulnerabilidades web muy similar a BurpSuite, pero tiene todas sus funcionalidades disponibles ya que es software libre. Las principales herramientas con las que cuenta son: Un proxy de intercepción que, al igual que en BurpSuite, nos permite capturar y modificar las peticiones HTTP realizadas y las respuestas por parte del servidor. Para su funcionamiento será necesario establecer el proxy manualmente como ya hemos visto. El puerto por defecto será de nuevo el 8080. Aunque no tengamos activa la captura de peticiones y respuestas, todos los sitios web que visitemos mientras utilicemos el proxy quedarán guardadas en el mapa de sitios de OWASP-ZAP.

Enviar petición o respuesta

Capturar peticiones y/o respuestas

Proxy de OWASP-ZAP.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

17

Análisis de Vulnerabilidades

Un escáner de vulnerabilidades. Con esta herramienta podemos realizar un escaneo de uno o varios sitios web, ya sea los que tengamos guardados por la herramienta en la parte de sitios o porque se haga un escaneo total de un sitio. Podemos ver un ejemplo de esta herramienta en la plataforma DVWA, en la pestaña de XSS Reflected. Para la demostración pondremos la seguridad de la página en low. En primer lugar establecemos manualmente el proxy por el puerto 8080 y visitamos la página. Aparecerá un cuadro de texto en el que podremos escribir:

Figura 16. XSS Reflected en DVWA.

Podremos ver que en OWASP-ZAP nos ha aparecido el sitio en la pestaña de sitios a la izquierda. Para realizar el escaneo daremos clic derecho y seleccionaremos Atacar > Active Scan single URL.

Figura 17. Realizar un escaneo sobre un sitio web.

El escaneo aparecerá en la pestaña de Escaneo Activo y cuando encuentre algo aparecerá en la pestaña de Alertas. En este caso ha encontrado una vulnerabilidad de XSS y lo notifica colocando una banderita roja delante del sitio.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

18

Análisis de Vulnerabilidades

Figura 18. Resultado del escaneo.

En el reporte nos aparece el código malicioso que podemos introducir para comprobar el resultado de escaneo:

Figura 19. Probamos introducir en el cuadro de texto el código generado.

Un spider o araña, que intenta indexar y capturar las URL de una página para hacer un mapa completo del sitio web. Una forma que tiene de hacerlo es ver el código HTML y buscar todas las direcciones del mismo dominio para redirigir y repetir. Tiene dos tipos de spider, uno tradicional y otro para sitios web AJAX. Para utilizarlo simplemente daremos clic derecho en un sitio guardado en la pestaña de sitios y seleccionaremos Atacar > Spider «tipo», donde «tipo» podrá ser el sitio entero o una URL específica. Un fuzzer, capaz de realizar funciones de ataque por fuerza bruta, inyecciones SQL, inyecciones de código XSS… Realiza peticiones dando diferentes valores a un parámetro que seleccionemos y a diferencia de BurpSuite solo permite seleccionar un parámetro. Para utilizarlo tendremos que seleccionar un trozo de texto en una petición (que será nuestro parámetro), clic derecho, Fuzz y seleccionaremos el tipo de fuzzer.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

19

Análisis de Vulnerabilidades

3. SQLMap SQLMap es una herramienta que nos permite descubrir vulnerabilidades de inyección de SQL y explotarlas en busca de información de las bases de datos. Nos permitirá seleccionar una URL como objetivo o los resultados de un Google Dork (una búsqueda en Google específica cuyos resultados son páginas vulnerables o potencialmente vulnerables). Para utilizar la herramienta utilizaremos la consola de comandos. Para comprobar si una página es vulnerable pondremos: sqlmap --url="http://www.paginaweb.com/injeccion?=id=1" Para obtener las diferentes bases de datos que tenga: sqlmap --url="http://www.paginaweb.com/injeccion?=id=1" --dbs Para obtener las tablas de una base de datos: sqlmap

--url="http://www.paginaweb.com/injeccion?=id=1"

--tables

-D

--dump

-D

nombre_base_datos Para obtener los datos de una tabla: sqlmap

--url="http://www.paginaweb.com/injeccion?=id=1"

nombre_base_datos -T nombre_tabla En el apartado de tipos de vulnerabilidades web, cuando se vea inyección SQL se verá un ejemplo práctico del funcionamiento de esta herramienta. Puedes acceder a más información y ejemplos en la siguiente dirección: https://github.com/sqlmapproject/sqlmap/wiki/Usage

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

20

Análisis de Vulnerabilidades

4. Hydra Hydra es una herramienta de ataques de fuerza bruta multiprotocolo, es decir, nos permite intentar autenticarnos en diferentes servicios a través de múltiples protocolos como HTTP, FTP, IMAP… A diferencia de otras herramientas de fuerza bruta sin conexión, Hydra realizará este tipo de ataque a servicios y aplicaciones web. Los ataques por fuerza bruta intentan adivinar las credenciales de autenticación para ganar acceso al sistema. Es una manera simple y segura de conseguir un resultado, pero tiene dos grandes desventajas: El tiempo que puede tardar en probar todas las combinaciones posibles de usuario y contraseña. El ruido que causa, pues genera mucho tráfico (pudiendo provocar denegaciones de servicio con estas herramientas de ataque por fuerza bruta). Para utilizar la herramienta lo haremos por consola. Por ejemplo, si queremos realizar un ataque por fuerza bruta para obtener las credenciales para conectarnos por SSH a una máquina con la IP 192.168.1.30 utilizando una lista para usuarios y otra lista para contraseñas: hydra -L users.txt -P passwords.txt 192.168.1.30 ssh

Figura 20. Uso de Hydra para conectarnos a una máquina por ssh.

5. Tamper Data Tamper Data no es una aplicación como las anteriores que hemos visto, sino que es un plugin para el navegador (en concreto para Firefox y derivados), pero es una herramienta muy útil, sencilla y rápida. Cuando hablamos de BurpSuite vimos que traía una herramienta de Proxy, pues Tamper Data realiza esa misma función, pero al ser un plugin del navegador nos permite no tener que modificar las conexiones para establecer manualmente un proxy.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

21

Análisis de Vulnerabilidades

Cuando solo queramos trabajar modificando algunos parámetros o comprobando las cabeceras, será más sencillo utilizar este plugin que otras herramientas. Nos permitirá modificar todas las peticiones, abortarlas y algunas funciones extra como falsificar el User-Agent del navegador o inyectar parámetros SQL o XSS en la petición.

Figura 21.Interfaz de Tamper Data.

3.5. Tipos de vulnerabilidades web 1. Authentication Bypass Muchas páginas web requieren algún tipo de autenticación para acceder a zonas restringidas o información privada, normalmente con un nombre de usuario y contraseña. Cuando una página web permite la introducción de un usuario o contraseña lo hace mediante peticiones GET o POST. Para realizar estas peticiones se deben rellenar ciertos campos donde introducir las credenciales.

Figura 22. Campos para credenciales.

Cuando se genera la petición, el servidor comprueba en la base de datos que la tupla existe, es decir, que el nombre está asociado a la contraseña (guardada en formato hash). Dependiendo de si la tupla existe o no, podrá redirigirnos a una página restringida o mandarnos de nuevo a que nos autentiquemos.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

22

Análisis de Vulnerabilidades

A causa de malas configuraciones podemos encontrar diferentes métodos para saltarnos esta autentificación y acceder a las zonas privadas sin conocer usuario o contraseña. Estas son: URL’s mal restringidas. Un error muy básico que comete un gran número de desarrolladores es crear un mecanismo de autentificación para un servicio web, pidiendo usuario y contraseña en una página de login y, posteriormente, dar acceso al resto de páginas del servidor sin realizar otra comprobación. El problema con esto reside en que si obtenemos una URL de la zona «privada» podríamos acceder a ella sin autenticarnos, ya que no comprobará si lo hemos hecho previamente. Un ejemplo puede darse en las URL’s de un banco. Tenemos una cuenta en un banco y nos conectamos a su página web para consultar nuestro saldo y realizar transacciones. Nos pide usuario y contraseña para acceder a nuestra cuenta y vemos que la URL es: https://www.mibanco.es/user/getAccount. Pero si las URL no estuvieran bien configuradas podríamos acceder a otras zonas de la página web que deberían ser privadas cambiando /user/ por otra cosa, como /admin/, /manager/, /administrator/… Este tipo de fallos se puede evitar configurando correctamente estas URL y realizando diversos tipos de comprobaciones: o Acceso restringido solo a usuarios autorizados. o Gestionar los permisos basándose en usuarios o grupos. o Bloquear las peticiones a páginas no autorizadas como ficheros de configuración, logs, código fuente… o Verificar el acceso en cada petición. o Proteger cada URL de la aplicación por un filtro externo (Java EE web.xml) o mediante la comprobación interna en el código (método isAuthorizedForURL() de ESAPI). o Verificar que la configuración del servidor deniega peticiones de tipos de ficheros no autorizados por defecto. Cambiar parámetros en la URL. Otro error muy grave es comprobar el estado de una sesión con un parámetro que se imprime en las URL. Por ejemplo, un servidor da acceso a páginas restringidas comprobando que el usuario se ha

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

23

Análisis de Vulnerabilidades

conectado mediante el parámetro «auth=1» (autenticado) o «auth=0» (no autenticado)

y

lo

muestra

en

la

URL

de

esta

manera:

http://www.paginaweb.com/areaadmin.asp?auth=0 Podríamos simplemente modificar el parámetro final a «auth=1» para conseguir acceso total a esta página sin necesidad de conocer nombres de usuario y contraseñas. Para evitar este fallo es aconsejable mostrar el mínimo de información posible en las URL y realizar las verificaciones del punto anterior. Ofuscar las URL. Algunos servidores web tienen listas de páginas que están restringidas y que necesitan de autentificación para acceder a ellas. Pero podría haber URL’s que no estén en la lista de páginas restringidas que apunten a dichas páginas. Por

ejemplo

puede

ser

la

página

restringida:

http://www.mipaginaweb.com/admin/configuration/. Si añadimos algún símbolo como ‘/’, ‘?’, ‘%’ o ‘~’ podríamos hacer que la URL apunte a la misma página, pero cambiando

el

nombre

de

la

forma:

http://www.mipaginaweb.com/admin/configuration// Si la configuración no es correcta y el servidor comprueba la lista de páginas restringidas literalmente sin parsear las URL’s, no nos pedirá autenticación. Por ello es conveniente utilizar métodos que, antes de devolver el contenido al usuario, comprueben las URL’s y eviten los símbolos, codificando estos en formato hexadecimal de la forma ‘%25’. SQL injection. El último método para saltarse la autenticación consiste en aprovecharnos de los errores al realizar la comprobación del usuario y la contraseña en la base de datos. Podremos hacer una inyección en la petición SQL a la base de datos para saltarnos el proceso de autenticación. Tenemos un ejemplo en la página de la plataforma DVWA (ya explicada anteriormente):

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

24

Análisis de Vulnerabilidades

El ejemplo lo encontramos en el nivel low de la pestaña de fuerza bruta, si nos fijamos en su código fuente vemos:

Figura 23. Código fuente de la pestaña de fuerza bruta (low)

Podemos ver que no realiza ninguna comprobación de seguridad en la entrada de texto del usuario y la contraseña, por ello podremos saltarnos la autentificación conociendo un usuario (o buscándolo por fuerza bruta, que se explicará en el próximo apartado). En este ejemplo usaremos el símbolo ‘#’ que se utiliza para crear una tabla temporal en la base de datos. Introduciremos en usuario: admin’#. El usuario admin es el que sabemos que estará en la base de datos.

Figura 24. Texto introducido en el campo usuario.

Esto pasará a la consulta de la siguiente manera: "SELECT * FROM `users` WHERE user=‘admin’#‘ AND password=’‘;"

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

25

Análisis de Vulnerabilidades

La consulta solo analizará hasta el usuario, ya que para el resto creará una tabla temporal que dará un error, aunque esto no nos afectará. Como el usuario existe y solo hay una entrada en la base de datos, nos identificará como este usuario y podremos saltarnos la autentificación sin necesidad de introducir contraseña.

Figura 25. Acceso a la zona de admin.

La forma más fácil para evitar estos fallos es utilizar funciones que comprueben los parámetros antes de pasárselos a las consultas, como en los niveles medio y alto de DVWA de fuerza bruta. 2. Fuerza bruta ¿Qué ocurre si el servidor comprueba correctamente las entradas de texto del usuario? Podemos ver en los niveles medio y difícil como en el código fuente realiza comprobaciones para evitar las comillas (‘ ’) o los slashes ( \ ). La única forma que nos queda será comprobar todas las posibles combinaciones de usuario – contraseña. Normalmente esta es una tarea muy tediosa, por lo que se recurren a diccionarios (archivos de texto con gran cantidad de palabras que se suelen utilizar como usuario o contraseña). A este tipo de ataque se le llama de fuerza bruta. Para ver un ejemplo nos fijamos de nuevo en la página DVWA, en la pestaña de Brute Force. En este caso usaremos la dificultad medium. Vamos a utilizar la técnica de fuerza bruta para poder obtener el nombre de usuario y la contraseña. Para ello utilizaremos la herramienta BurpSuite y su pestaña de Intruder. Pasos: En primer lugar pondremos el navegador en modo proxy por el puerto 8080 como ya se ha explicado. TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

26

Análisis de Vulnerabilidades

En la pestaña de Proxy nos fijaremos que en un botón ponga Intercept is on y realizaremos una petición en la página de DVWA con un nombre de usuario y contraseña cualquiera para poder capturar el mensaje HTTP enviado y modificarlo posteriormente. Pulsaremos el botón Action y Send to Intruder para mandar el mensaje a la pestaña Intruder.

Figura 26. Enviar el mensaje capturado al Intruder.

En la pestaña Intruder seleccionaremos el tipo de ataque cluster bomb (para poder modificar varias variables). Y seleccionaremos en el mensaje lo que queremos que sean las variables a modificar; primero pulsaremos clear para quitar todas las que vienen por defecto y luego pulsaremos add para seleccionarlas manualmente.

Figura 27. Pestaña Intruder.

En la subpestaña de Payloads podremos seleccionar las diferentes variables (en este caso payload 1 será el usuario y el 2 la contraseña). Podremos crear una lista nosotros insertando valores en la parte de Payload Options o cargar una lista de palabras de un archivo txt. En Kali podemos encontrar algunas listas de palabras en el directorio: /usr/share/wfuzz/wordlist/general

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

27

Análisis de Vulnerabilidades

Figuras 28 y 29. Asignar listas de palabras a los payloads.

En este caso se ha usado una pequeña lista con combinaciones que se conoce de antemano que funcionarán, para ahorrar tiempo, pero en un entorno real será necesario probar uno o varios diccionarios completos. En la pestaña de Options estableceremos que nos indique si ha coincidido con un patrón (en este caso para conexión incorrecta).

Figura 30. Campo para marcar mensajes correctos o incorrectos.

Pulsaremos Start Intruder para comenzar el ataque por fuerza bruta.

Figura 31. Comenzar el ataque.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

28

Análisis de Vulnerabilidades

Finalmente obtendremos los resultados de las combinaciones de usuario y contraseña encontradas.

Figura 32. Resultados obtenidos, a la derecha están marcados los mensajes que coinciden con el patrón anterior

Hay formas de dificultar o evitar este tipo de ataques. Algunas de ellas son: o Establecer retrasos a las peticiones realizadas cuando sean incorrectas (como hace el código de DVWA en el nivel alto de fuerza bruta). Aunque un atacante lo podría contrarrestar realizando muchas peticiones en paralelo. o Poner límite de intentos para bloquear alguna IP en particular o para bloquear a algún usuario que haya introducido mal su contraseña en varias ocasiones. o Usar un segundo factor de autenticación, por si un atacante obtiene las credenciales por fuerza bruta, que necesite la otra forma de autenticación para poder acceder.

Nota: a veces para mejorar la efectividad de los ataques de fuerza bruta por diccionario, es conveniente crear nuestro propio diccionario. Para ello nosotros usaremos la herramienta Crunch ya incluida en Kali Linux. Esta herramienta nos permite utilizar patrones para generar grandes listas de palabras que podremos utilizar como diccionarios. Nos permite elegir la longitud que queremos que tengan las palabras generadas (mínima y máxima). Para ver todas las opciones de esta herramienta escribiremos en consola: crunch --help

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

29

Análisis de Vulnerabilidades

Si por ejemplo conocemos que las contraseñas de alguna organización se generan con 3 letras y 4 números podremos generar un diccionario con todas las combinaciones posibles para poder usar luego herramientas como Hydra o BurpSuite para atacar por fuerza bruta.

Figura 33. Herramienta Crunch.

3. Cross Site Request Forgery (CSRF) Un ataque Cross Site Request Forgery o CSRF consiste en forzar a la víctima a realizar una petición HTTP a una aplicación web vulnerable a la que ya se autenticó, aprovechando la cookie de la sesión y cualquier otra información para volver a conectarse y poder realizar acciones en nombre de la víctima. Esta vulnerabilidad se aprovecha de la confianza que tiene un sitio web en el navegador, haciendo que este realice una operación hostil que beneficia al atacante. CSRF es tan peligroso como la aplicación web que se ataque, si fuera un banco, un atacante podría hacer transferencias desde la cuenta de la víctima, cerrar una cuenta bancaria, etc. Una aplicación web será vulnerable a CSRF si: No verifica de nuevo la autenticación antes de realizar la operación. La autenticación por defecto permite realizar operaciones. Se autorizan operaciones basándose únicamente en las credenciales que se suministran automáticamente por el navegador como cookies de sesión, token Kerberos, autorización clásica, certificado SSL… El gran problema con este tipo de vulnerabilidades es que es muy difícil seguir la pista hasta el atacante, ya que la IP que realiza la petición a la aplicación web vulnerable es la de la víctima (como si fuera una operación lícita). TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

30

Análisis de Vulnerabilidades

Un ejemplo de un ataque CSRF es: Un atacante introduce un script con una URL maliciosa en su web que hace automáticamente Likes en Facebook y lo oculta como si fuera una imagen. El script puede ser del formato: La víctima que tiene abierta una sesión en Facebook visita la página web del atacante, al hacerlo descarga la imagen y el navegador ejecuta el código oculto. Si la sesión de la víctima no ha caducado, Facebook tomará la petición como legítima (ya que la cookie de sesión no ha caducado, el navegador y la IP son los de la víctima, etc.) y realizará la acción del atacante sin el conocimiento de la víctima. Deben cumplirse varias condiciones para que pueda darse a cabo este tipo de ataque: El atacante debe elegir una aplicación web que no compruebe el campo de la cabecera de referer, que indica de dónde procede el enlace a esa página, o elegir una víctima con un navegador o plugin que permita falsificar ese campo de referer. Un ejemplo del funcionamiento de este campo es: La página www.pagina1.es tiene un enlace a la página www.pagina2.com, cuando alguien haga clic en el enlace se creará una petición a la segunda página en la que el campo referer tendrá www.pagina1.es. Esta medida, por ejemplo, se usa para evitar acceder a páginas de forma directa, es decir, sin pasar por páginas de registro. El atacante debe encontrar alguna forma (HTML) o URL que realice la acción que desee (como hacer likes, transferir dinero o cambiar una contraseña). El atacante debe determinar el valor correcto de los parámetros de la forma o URL, si cualquiera de ellos requiere valores secretos de la autenticación o tiene valores que el atacante no puede adivinar, el ataque fallará. Si un atacante quiere hacer una transferencia desde la cuenta de la víctima podría usar una URL como: http://bank.ejemplo.com/withdraw?account=Victima&amount=10000&for=Atacante

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

31

Análisis de Vulnerabilidades

El atacante deberá conocer el valor Victima (que podría ser un nombre, una cuenta o un identificador de cliente) para poder realizar la operación. El atacante debe asegurarse que la víctima accede a la página con el código malicioso cuando tiene una sesión abierta en el sitio objetivo. Podemos ver un ejemplo de este tipo de ataque de nuevo en la plataforma DVWA, en la pestaña de CSRF. Consiste en cambiar la contraseña de la página de inicio de la víctima (por defecto password) mediante un ataque CSRF. Nos fijaremos en el nivel bajo y en el intermedio. En ninguno de ellos la página pide que introduzcamos la contraseña antigua para poder cambiarla, solo introducir la nueva contraseña y confirmarla. El nivel intermedio además comprueba que en el campo referer de la petición HTTP contenga la cadena «127.0.0.1», para simular que solo puede realizarse la operación desde una página web específica. Igualmente se podría saltar, ya que solo comprueba que la cadena esté, no la posición, o se podría intentar spoofear (falsificar) este campo. Para ambos niveles la URL que aparece cuando cambiamos la contraseña es: 127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=pass&password_conf=pass&Ch ange=Change# Siendo las palabras en negrita la nueva contraseña y la confirmación. Para el ejemplo, primero con el nivel bajo, crearemos una pequeña página web con una imagen que referencie a la URL maliciosa y la guardaremos en la carpeta /var/www/falso.

Figura 34. Código HTML de la web falsa.

Accederemos a la página desde la dirección IP privada del ordenador (para no usar la dirección 127.0.0.1).

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

32

Análisis de Vulnerabilidades

Figura 35. Página web falsa.

Si nos conectamos ahora a la plataforma DVWA, veremos como la contraseña ha cambiado. El segundo ejemplo, con el nivel intermedio, será similar. En este caso crearemos una página con un enlace que nos redireccionará a la página de DVWA y cambiará la contraseña.

Figura 36. Código HTML de la página falsa 2.

De nuevo accederemos desde la IP privada del ordenador.

Figura 37. Página web falsa 2.

El pulsar en el enlace debería aparecer la confirmación de que la contraseña ha sido cambiada, pero no es así. Esto ocurre porque no se cumple que en el campo de referer esté la cadena 127.0.0.1, como requiere el código de este nivel. Para solucionarlo utilizaremos un plugin para el navegador para poder modificar las cabeceras de los mensajes, Tamper Data. Abrimos el plugin, le damos a comenzar la modificación y hacemos clic en el enlace malicioso. Podremos ver como en el campo referer está la dirección de la página maliciosa, así que lo cambiaremos por http://127.0.0.1. TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

33

Análisis de Vulnerabilidades

Figura 38. Campo referer en Tamper Data.

Finalmente podremos cambiar la contraseña (en este caso a «enlace»).

Figura 39. Confirmación de cambio de contraseña.

4. Ejecución maliciosa de ficheros Este tipo de vulnerabilidad ocurre únicamente en páginas dinámicas en PHP que permiten especificar un fichero o una ruta a un fichero, ya sea interno a la aplicación (LFI) o externo (RFI), mediante parámetros mal validados en la URL. En el código fuente de este tipo de páginas encontramos funciones como include, include_once, require o require_once, que son utilizadas para incluir en una misma página ficheros o código fuente de otros servicios web. Esta vulnerabilidad tiene un gran riesgo, ya que puede permitir a un atacante: Introducir código ejecutable en una aplicación web. Subir archivos maliciosos al servidor. Acceder a datos privados del servidor como logs, contraseñas, información de sesión… Actualmente ya no se encuentra en el Top 10 de OWASP pero siguen existiendo muchas páginas con esta vulnerabilidad. Para descubrir estas páginas vulnerables debemos fijarnos en las URL. Aquellas que tengan el formato: http://www.pagina_vulnerable.com/index.php?page=plantilla.html

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

34

Análisis de Vulnerabilidades

En la plataforma DVWA tenemos de nuevo una sección vulnerable a este fallo, en la pestaña File Inclusion. Nos encontraremos con la siguiente URL:

Figura 40. URL de la pestaña vulnerable.

Podemos comprobar que si modificamos el parámetro page por “/etc/group” el servidor nos volcará en la página web el fichero de grupos de este, por lo que la página será vulnerable a una inclusión local.

Figura 41. Volcado de /etc/group.

Para comprobar también si la página es vulnerable a una inclusión remota tendremos que probar insertar una un enlace a una página web como http://www.google.es.

Figura 42. Inclusión de la página www.google.es.

Se puede ver que se ha incrustado el código de la página www.google.es en la página de DVWA. Esto indicará que también será vulnerable a una inclusión remota.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

35

Análisis de Vulnerabilidades

Nota: en muchos casos no funcionará, ya que servidores como Apache, por defecto, tienen un parámetro que evita que se pueda realizar esta llamada a otras páginas web. Para desactivarlo (en el caso de Kali Linux) deberemos ir al fichero: /etc/php5/apache2/php.ini Buscar y poner a «On» la opción: allow_url_include Reiniciaremos el servicio apache2 y ahora nos debería funcionar correctamente. En caso de no usar Kali Linux y Apache2 como servidor, deberemos buscar el archivo php.ini del que usemos y modificar el mismo parámetro. Nuestro objetivo será ejecutar una webshell en la página vulnerable, así que crearemos una (o la descargaremos). En nuestro caso hemos copiado el código fuente de la webshell desde pastebin.com y hemos creado el archivo c99.txt en la carpeta falsa de nuestro servidor (para simular una página web ajena al servidor). http://pastebin.com/JK2AaELL A continuación se explicarán los dos tipos de inclusión de ficheros que hay: remota y local. Remote File Inclusion (RFI) Consiste en llamar desde la página web a un fichero que está situado en otro servidor. El fichero al que queramos llamar no debe acabar en .php, ya que este tipo de fichero se ejecuta en el servidor en el que esté; por ello lo hemos llamado c99.txt.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

36

Análisis de Vulnerabilidades

En el nivel bajo de DVWA realizamos la petición a través de la URL y obtenemos:

Figura 43. Webshell por RFI.

Esta webshell será solo de lectura, pero podremos obtener mucha información del servidor, así como descargar el código fuente de las páginas. Local File Inclusion (LFI) En este caso consiste en llamar desde la página web a un fichero local, es decir, que ya esté en el servidor (en cualquier lugar de este) y ejecutarlo. Por ejemplo si ya hemos conseguido subir una webshell al servidor por algún método, podremos llamarlo utilizando su ruta absoluta o relativa. Podemos ver un ejemplo con el nivel medio de DVWA. En este nivel la página comprueba antes de hacer el include(), pues no permite la introducción de «http» o «https» para poder hacer una inclusión remota (aunque podríamos llamar a un archivo de un servidor ftp, ya que no lo bloquea).

Figura 44. Webshell por LFI.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

37

Análisis de Vulnerabilidades

En este caso hemos llamado directamente al archivo de la webshell c99.php que teníamos en una carpeta local. También hay otra forma para realizar esta inclusión local sin necesidad de tener el archivo de la webshell cargado en la máquina del servidor. Para ello usaremos el esquema URL «data» (disponible a partir de PHP 5.2). Un ejemplo del funcionamiento es: ?page=data:,

Figura 45. Prueba del esquema data.

Nosotros lo que queremos es ejecutar comandos como si fuera una shell, así que llamaremos a una de forma local con la llamada system(). ?page=data:, &cmd=ls

Figura 46. Llamada a una shell con LFI.

De nuevo esta shell que obtenemos solo tendrá permisos de lectura. Para evitar estas vulnerabilidades: No se debe incluir rutas a ficheros en la URL. Si se incluye la ruta, es necesario tener una lista blanca de ficheros, como el nivel alto de la plataforma DVWA, que solo permite include.php. Tener especial cuidado con los formularios que permitan a los usuarios subir ficheros a la aplicación: o Almacenar los ficheros en una ruta distinta de la raíz. TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

38

Análisis de Vulnerabilidades

o Validar la ruta y la extensión del fichero. o Implementar un sistema de Sandbox o chroot que limite el acceso. 5. Cross Site Scripting (XSS) Este tipo de vulnerabilidad web consiste en la ejecución de código en algún lenguaje de script (JavaScript normalmente) en el navegador de la víctima cuando esta visite alguna aplicación web vulnerable. Podemos encontrar esta vulnerabilidad en aplicaciones web disponibles en Internet, en aplicaciones locales e incluso en el navegador en sí, pues ocurre cuando una aplicación no valida la entrada de datos del usuario correctamente o no sanea la salida adecuadamente, permitiendo que se introduzca código malicioso. Un atacante puede realizar peligrosas acciones con XSS como: Robar información delicada. Secuestrar sesiones del usuario. Defacement de páginas web, es decir, modificar de manera intencionada una página web cuando se haya obtenido algún tipo de acceso a ella, bien por algún error de programación de la página, por algún bug en el propio servidor o por una mala administración de este. Comprometer el navegador e introducir malware en la máquina víctima. Este tipo de vulnerabilidad se suele encontrar en sitios donde se permita introducir contenido (campos de texto, libros de visitas…). Se suele esconder el vector de ataque en tags HTML como iframes o imágenes que permitan ocultar el contenido al usuario y además se puede codificar (en formato UNICODE) para que no sea tan sospechoso. Existes varios tipos de XSS: Reflejado (No persistente). Los ataques llegan a la víctima a través de una URL maliciosa con los parámetros directamente modificados (por algún enlace en otra página, email…). Almacenado (Persistente). El código se almacena en un servidor de manera permanente (en una base de datos, foro, libro de visitas…) y cuando un usuario acceda a la página vulnerable se ejecutará el código malicioso.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

39

Análisis de Vulnerabilidades

Inyección DOM. En este tipo de ataques el código inyectado manipula el código JavaScript del sitio Web y sus variables son manipuladas, en lugar de los elementos HTML. Se puede ver que el segundo tipo de XSS es muy peligroso, ya que, si algún sitio web que reciba millones de visitas al día es vulnerable a un XSS almacenado se podrían comprometer todas las máquinas para cualquier fin: robo de datos, botnets, etc. XSS Reflejado Volvemos a fijarnos en la plataforma DVWA, en la pestaña XSS Reflected.

Figura 47. Pestaña de XSS Relejado.

En el nivel fácil vemos que no realiza comprobación alguna del texto que introduzcamos.

Figura 48. Código nivel fácil.

Entonces podremos introducir código JavaScript en la página, como una alerta: ?name=javascript:alert("XSS!!");

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

40

Análisis de Vulnerabilidades

Figura 49.Alerta por XSS.

También podremos realizar la inserción de imágenes o de formas de HTML.

Figura 50. Imagen insertada por XSS.

En el nivel medio encontramos que el código no permite que utilicemos la cadena (cuando encuentra esta cadena la quita directamente), por lo que «supuestamente» no dejaría que ejecutáramos código en el cliente.

Figura 51. Código del nivel medio.

Existen muchas técnicas para saltarnos este tipo de controles mediante listas negras de palabras o expresiones. Un par de ejemplos pueden ser: Usar mayúsculas: ?name=javascript:alert("XSS!!") TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

41

Análisis de Vulnerabilidades

Aprovecharnos del reemplazo de la cadena : ?name=javascript:alert("XSS!!") Hay muchas más formas de evadir estos filtros, como otras combinaciones o codificar las URL. Podemos encontrar ejemplos en las siguientes direcciones web: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet http://ha.ckers.org/xsscalc.html XSS Almacenado En este caso nos fijaremos en la pestaña de XSS Stored.

Figura 52. Libro de firmas en la pestaña de XSS almacenado.

Nos encontramos con un libro de visitas en el cual podemos introducir texto en dos campos. Si nos fijamos y comenzamos a poner caracteres en ellos veremos que el primero solo acepta 10 y el segundo 50. Podemos introducir de nuevo el código que queramos, ya sea para generar una alerta, inyectar una foto, redirigir a otra página… pero a diferencia del caso anterior, se quedará guardado y siempre que carguemos la página el código se ejecutará. Para el ejemplo vamos a ver el nivel bajo e intentaremos hacer que la página nos redireccione a otra que queramos, es decir, que siempre que accedamos a la pestaña XSS Stored nos redireccionará a otra página. Para ello usaremos:

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

42

Análisis de Vulnerabilidades

El número indica el tiempo que tardará en refrescar la página y la URL a qué página deberá redireccionar. Cuando queramos insertar el código en el mensaje veremos que no entra todo, por lo que deberemos usar Tamper Data.

Figura 53. Tamper Data para hacer un ataque de XSS almacenado.

Cuando aceptemos el envío de la petición nos enviará a la página de Google, al igual que cuando pulsemos la pestaña de XSS Stored. Nota: para eliminar las entradas del libro de visitas que hayamos creado será necesario resetear la base de datos de la página. Para ello iremos a la pestaña Setup y pulsaremos en «Create/Reset Database». En el nivel intermedio el campo de mensaje no permitirá la introducción de símbolos HTML como «» por lo que no podremos utilizarlo, pero el campo de nombre si permitirá. Podremos hacer lo mismo que hemos hecho en el ejemplo del nivel fácil pero usando el otro campo, incluyendo el uso de Tamper Data, ya que este campo de nombre solo permitirá 10 caracteres. Hay varias formas de evitar las vulnerabilidades de XSS: Eliminar los fallos o evitar incluir aplicaciones propensas a XSS. Filtrar las salidas convirtiendo el texto o datos que podrían contener scripts maliciosos a un formato codificado: o ‘’ -> ‘<’ y ‘>’ o ‘(’ y ‘)’ -> ‘(’ y ‘)’ o ‘#’ y ‘&’ -> ‘#’ y ‘&’

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

43

Análisis de Vulnerabilidades

Utilizar validación de entrada mediante una lista blanca y no una lista negra. Podemos ver que usando una lista negra, en el ejemplo de XSS Reflejado filtrando por , somos capaces de saltárnoslo. Para grandes cantidades de información que procede de usuarios se puede utilizar la API

AntiSamy

de

OWASP

que

permite

sanear

las

entradas:

https://www.owasp.org/index.php/AntiSamy. 6. Referencia directa insegura a objetos Este tipo de vulnerabilidad sucede cuando un desarrollador deja referencias a objetos implementados de manera interna en un URL o como un parámetro en un formulario. Estos objetos pueden ser: Un fichero o directorio. Una URL. Una clave de base de datos. Otros objetos de una base de datos, como por ejemplo el nombre de una tabla. Si una aplicación web no ha implementado correctamente la gestión de sesión o una autentificación segura se podrá cambiar el valor de estos parámetros y objetos, permitiendo a los atacantes referenciar objetos para los que no tengan autorización y manipular información restringida. Podemos ver un sencillo ejemplo: Tenemos una cuenta en la página online de un banco y al conectarnos nos aparece una URL como esta: http://www.mibanco.com/usuario/cuentas.php?cuenta=1234 Si ahora cambiamos el parámetro cuenta de la URL, por ejemplo por 1235, esta vulnerabilidad nos permitiría acceder a la página del banco de la persona que tenga la cuenta 1235, así como realizar acciones en ella.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

44

Análisis de Vulnerabilidades

Otro ejemplo de esta página del banco puede ser: http://www.mibanco.com/descarga.php?dir=nomina&file=123123.pdf Podríamos cambiar el valor de estos parámetros «dir» y «file» y acceder a archivos del servidor. http://www.mibanco.com/descarga.php?dir=../../../etc&file=passwd Como se puede ver, no se está haciendo ningún tipo de inyección como en el caso de XSS; simplemente estamos modificando el parámetro a buscar, por lo que filtrar parámetros y usar listas blancas no serviría. Para evitar este tipo de vulnerabilidad podemos: Eliminar la referencia al objeto. Sustituir la referencia por un valor temporal de referencia (1, 2, 3, 4…). Aunque implicaría implementar algún mapa de referencia que permita traducir de uno a otro. http://aplicacion?fichero=imagen1.jpg -> http://aplicacion?fichero=1 Validar la referencia directa al objeto. o Verificar que el valor del parámetro está correctamente formado. o Verificar si el usuario tiene permiso para acceder al parámetro. o Verificar si el modo de acceso está permitido (lectura/escritura). 7. Configuraciones inseguras Los fallos de configuración pueden estar presentes en cualquier nivel de un servicio de red, incluyendo la plataforma, el servidor web, el servidor de aplicación, la base de datos, el código… Tanto los desarrolladores como los administradores de sistemas deben trabajar juntos para asegurarse que todos los niveles se configuran apropiadamente. Una mala configuración puede tener todo tipo de consecuencias: revelar directorios, datos de conexión, credenciales, información de la base de datos, modificar ficheros… Instalación de puertas traseras debido a la falta de parches. Explotación de XSS debido a falta de parches de seguridad. Acceso no autorizado a cuentas por defecto.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

45

Análisis de Vulnerabilidades

Obtener información del funcionamiento del sistema privado. Es importante tener en cuenta si el código fuente de la aplicación es público o privado y si es el caso, estar atentos a cualquier actualización de seguridad que pueda surgir. En el caso de ser un código fuente privado hay que considerar todos los sitios donde se almacena este código. Como norma general, que el código sea privado o no, no debería afectar a la seguridad del sistema. Al portar un sistema de desarrollo a producción se deberían cambiar todas las credenciales por seguridad. Un par de escenarios de ejemplo pueden ser: Un servidor web que disponga de una webshell para administrar el sitio que no disponga de contraseña o utilice una por defecto. Si un atacante descubre su existencia podría tener control total del sitio web. Una aplicación web que cuando surja cualquier error en una página porque no ha podido cargar el contenido, muestre una traza de directorios y del error. Un atacante podría obtener información de esta manera. Para

evitar

las

configuraciones

inseguras

es

necesario

verificar

todas

las

configuraciones de todas las aplicaciones y servicios, tanto de cara al usuario (públicos), como de cara al administrador (privados). Escaneos automáticos para detectar parches, malas configuraciones, uso de cuentas por defecto, servicios innecesarios. Guías de hardening. Estar al día en todas las actualizaciones de seguridad. Tanto para bibliotecas, aplicaciones, sistema operativo… Analizar las implicaciones de seguridad que traen consigo estos cambios. Adaptar las aplicaciones para que generen reportes para poder analizarlos posteriormente. Verificar la implementación mediante software de análisis de vulnerabilidades, configuración y parches.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

46

Análisis de Vulnerabilidades

El hardening (endurecimiento) es el proceso de asegurar un sistema mediante la reducción de vulnerabilidades en el mismo. Esto se logra eliminando software, servicios y usuarios innecesarios en el sistema, manteniéndolo actualizado, configurándolo

correctamente,

instalando

software

de

seguridad,

realizando

auditorías… En conclusión, haciéndole la vida más difícil al atacante reforzando el sistema. 8. Inyección La inyección consiste en manipular las entradas de una aplicación para mandar texto de una forma concreta y que los intérpretes de órdenes lo tomen como comandos y los ejecuten. Los intérpretes más comunes son SQL, shell del sistema operativo, LDAP, XPath… La causa más común es la falta de saneamiento en la entrada de datos o parámetros, es muy sencillo de evitar, pero ocurre en un gran número de aplicaciones web. Tienen también un impacto muy grave pues: Permite a un atacante leer una base de datos entera y en algunos casos modificarla y/o borrarla. Permite el acceso al esquema de la base de datos y a sus cuentas. Permite acceso al mismo sistema operativo (si hablamos de un intérprete como una shell). La inyección está en la primera posición del Top 10 de OWASP de 2013, pues es la vulnerabilidad que más podemos encontrar. Es relativamente fácil explotarla (solo necesita insertar texto en los intérpretes), no es muy difícil encontrar puntos de explotación (usando fuzzers o escáneres) y tiene un gran impacto como hemos visto. Vamos a ver en profundidad dos tipos de inyecciones en particular, las más usuales, la inyección de comandos en shell y la inyección SQL. Inyección de comandos A veces las páginas web utilizan llamadas a programas en el mismo servidor para permitir ejecutar al usuario diversas tareas o servicios, como las típicas páginas que permiten hacer ping a una dirección IP. Pero, ¿qué ocurre si estas páginas no comprueban la entrada de texto antes de realizar la llamada? TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

47

Análisis de Vulnerabilidades

Podemos ver un ejemplo en la plataforma DVWA, en la pestaña de Command execution. Tanto el nivel bajo como el intermedio serán vulnerables. Consiste en una aplicación para hacer ping a una dirección IP mediante la llamada «shell_exec()» que ejecuta un programa en la consola del servidor, en este caso ping.

Figura 54. Código de la pestaña Command execution.

El nivel bajo no realiza comprobación alguna del texto que se introduce por pantalla, por lo que podríamos usar símbolos de consola para ejecutar una sentencia detrás de otra como ‘;’ (Linux) o ‘&&’ (Windows).

Figura 55. Ejemplo de inyección de comandos.

En este caso hemos ejecutado ls ../.. para ver el contenido de la carpeta /var/www/dvwa del servidor. En el caso del nivel intermedio la página cuenta con un par de restricciones que son: eliminar los ‘;’ y ‘&&’ que encuentre en el texto introducido. Pero podremos seguir ejecutando texto a través de las tuberías en Linux ‘|’ o el OR en Windows ‘||’.

Figura 56. Inyección de comandos en el nivel intermedio.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

48

Análisis de Vulnerabilidades

No solo los servicios que hacen ping pueden ser vulnerables. Cualquier función que realice una llamada a algún programa dentro del servidor del estilo cmd(), shell_exec() o system() y permita al usuario introducir valores dentro, podría serlo. Inyección SQL Casi la totalidad de las aplicaciones web en Internet poseen una base de datos, ya sea para almacenar las credenciales de acceso como para guardar información del contenido de las páginas. Para acceder a estas bases de datos es necesario un lenguaje específico para realizar las consultas, así como un intérprete que entienda las consultas y nos devuelva un resultado. El lenguaje más común de todos, en el ámbito de aplicaciones web, es SQL y la base de datos más común es MySQL, por eso este tipo de inyección es la más común. Podemos encontrar muchas clasificaciones de tipos de inyección SQL, pero nosotros nos vamos a centrar en una, dependiendo de si la aplicación web nos devuelve información con los fallos o no. Nos encontraremos ante una inyección clásica si nos muestra estos errores y ante una inyección a ciegas (Blind SQL injection) si solo nos muestra información cuando realizamos una consulta correcta y hay información que mostrar (no es lo mismo hacer correctamente una consulta pero que una tabla o columna no existan, que hacer mal la consulta directamente). Para ambos tipos de SQL injection usaremos como ejemplo la plataforma DVWA, en las pestañas SQL Injection y SQL Injection (Blind), en las que será vulnerable tanto el nivel bajo como el nivel medio. En ambas solo dispondremos de un campo de texto. Comenzaremos con inyección SQL clásica. El código fuente de la entrada de texto y la consulta, del nivel bajo, es:

Figura 57. Código fuente del nivel bajo de inyección SQL.

Nosotros podremos cambiar el parámetro id, por lo que podemos realizar varios test para comprobar la explotación de la base de datos y averiguar más cosas sobre ella. TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

49

Análisis de Vulnerabilidades

Test positivo:

’or‘1’=‘1

Test negativo: ’or‘1’=‘0

Siempre será cierto. Siempre será falso.

El test positivo nos deberá devolver un resultado, mientras que el negativo no debería devolver nada. Con ello comprobamos si estamos ante un caso de inyección clásica o a ciegas.

Figura 58. Inyección SQL siempre positiva.

Podemos averiguar también el número de columnas de la tabla que obtiene de respuesta, es decir, el número de atributos diferentes que nos va a devolver (esto será necesario a la hora de concatenar consultas). Una columna como mínimo:

a’ ORDER BY 1;#

Dos columnas como mínimo:

a’ ORDER BY 2;#

Podremos ir realizando indefinidas consultas así, hasta encontrar el

número de

columnas. Cuando sobrepasemos el límite de columnas nos mostrará un error, en caso de ir acertando puede o no mostrar información (dependiendo del valor que le demos a id, en estos casos le hemos dado ‘a’).

Figura 59. Error al sobrepasar el máximo de columnas.

En este caso podemos ver que la respuesta devuelve un error para 3 columnas, por lo que tendrá 2 (hemos visto en el código fuente que es así, «first name» y «last name»). TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

50

Análisis de Vulnerabilidades

Ahora empezaremos a utilizar consultas concatenadas y para ello utilizaremos la orden UNION ALL SELECT. UNION será para concatenar las consultas y que la respuesta de la segunda consulta se sume a la primera; ALL la usaremos por si hace falta que se repitan resultados y la consulta inicial tenía DISTINCT puesto; y SELECT es el inicio de la nueva consulta como si fuera normal. El único problema a la hora de realizar esta segunda consulta es que el número de columnas de la respuesta debe ser el mismo número que en la primera, por ello necesitamos saber el número de columnas con el comando anterior. Para obtener la versión de la base de datos (podemos ver como se utilizan 2 columnas, una para la versión y otra siempre con un ‘1’ para que sea correcta la consulta): a' UNION ALL SELECT 1, @@version;# Podemos también obtener archivos del servidor: ' UNION ALL SELECT load_file('/var/www/dvwa/.htaccess'), '1 Ahora veremos el nivel medio e intentaremos sacar más información, como el nombre de la base de datos o el nombre de sus atributos. En este caso vemos que la entrada de texto está un poco más saneada y no permite utilizar algunos símbolos como las comillas simples.

Figura 60. Nos da error porque el servidor codifica las comillas dobles.

Para solucionarlo tendremos que introducir un valor válido en id, es decir, un número entero.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

51

Análisis de Vulnerabilidades

Figura 61. Introducimos un valor válido de ID y luego la inyección.

Deberíamos repetir los pasos del ejemplo anterior para obtener de nuevo las columnas, aunque en este caso siguen siendo 2. El primer paso para obtener toda la información de una base de datos será obtener su nombre: 0 UNION ALL SELECT null, database();#

Figura 62. Consulta del nombre.

El nombre de la base de datos será «dvwa». Para intentar obtener las tablas de esta base de datos, probaremos accediendo al esquema por defecto de las tablas de las bases de datos MySQL «information_schema.tables». La consulta sería así: 0 UNION SELECT table_schema, table_name FROM information_schema.tables WHERE table_schema =‘dvwa’# Pero obtendremos un error ya que no podemos utilizar las comillas en las consultas por el saneamiento de la entrada de texto. Así que tendremos que obtener el esquema de

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

52

Análisis de Vulnerabilidades

todas las tablas de la base de datos, en lugar de solo la que nos interesa y buscar después la que nos interesa. 0 UNION SELECT table_schema, table_name FROM information_schema.tables#

Figura 63. Buscamos el nombre que nos interesa.

Encontramos que tiene dos tablas: guestbook (que podemos suponer que será la que usa como libro de visitas para la pestaña de XSS almacenado) y users (que podemos suponer que será donde guarda la información de los usuarios). El siguiente paso será intentar averiguar el nombre de las columnas (atributos) de la tabla de usuarios. Para hacerlo tendremos que usar el método de prueba y error. Usaremos consultas del estilo: 1 or NombrePrueba = z

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

53

Análisis de Vulnerabilidades

Donde NombrePrueba será el nombre de la columna que pensamos que puede existir en la base de datos. Podremos encontrar dos tipos de respuesta por parte de la base de datos, que exista el nombre o que no:

NO EXISTE

EXISTE

Consultas de columnas existentes e inexistentes.

Una vez descubiertas las columnas, realizamos la consulta final para obtener la información que queremos. 0 UNION ALL SELECT user, password from dvwa.users;#

Figura 64. Información de usuarios de la base de datos.

Ahora vamos a ver un poco blind SQL injection. El problema que nos ocasiona es que no podremos ver los errores como hemos hecho con la inyección clásica. Aunque podremos realizar las mismas acciones pero con algunos matices: Hay que suponer que realizamos correctamente las consultas y cuando no nos devuelve nada es porque algo a lo que hemos hecho referencia en la consulta no existe.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

54

Análisis de Vulnerabilidades

Podemos hacer consultas de tal manera que devuelva valores booleanos. Si por ejemplo no nos dice la versión de la base datos podemos preguntar carácter a carácter. 1 AND 1=0 UNION SELECT null, substring(@@version,1,1)=5#

1 -> Correcto 0 -> Incorrecto

Nos devuelve valores booleanos.

A la hora de descubrir las tablas y las columnas podemos utilizar de nuevo los esquemas por defecto, pero podemos codificar en hexadecimal los nombres en lugar de ponerlos entre comillas (también lo podemos hacer en las inyecciones clásicas). dvwa = 0x64767761

Figura 65. Codificamos los nombres de tablas.

Además podemos concatenar más columnas de las iniciales usando la expresión concat(). 1 AND 1=0 UNION SELECT null, concat(table_name, 0x0a, column_name) from information_schema.columns where table_name=0x7573657273 users = 0x7573657273

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

55

Análisis de Vulnerabilidades

Figura 66. Utilizamos concat().

Las técnicas para realizar consultas SQL más importantes (algunas de ellas ya las hemos estado usando) son: o UNION query-based. Realizar consultas concatenando con la expresión UNION (la que hemos estado usando). o Error-based. Cuando no podemos utilizar técnicas como UNION se puede intentar provocar errores y enviarnos el resultado del error. o Out-of-Band. Similar al anterior pero intentando enviar todo, tanto errores como resultados. o Boolean-based. Se realiza una consulta que devuelve un valor booleano, utilizando expresiones como LENGTH, ASCII o SUBSTRING. o Time-based. Esta técnica consiste en enviar una consulta inyectada con la condición a true y monitorizar el tiempo que tarda un servidor en responder. Si hay algún retraso, se puede asumir que el resultado de una consulta condicional es verdadero. Como ya hemos visto, disponemos de una herramienta para realizar inyecciones SQL, tanto clásicas como blind: esta es sqlmap, disponible en Kali Linux. Vamos a hacer una prueba de nuevo con la plataforma DVWA y esta herramienta para sacar las bases de datos y las tablas de estas. sqlmap --url=“http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --dbs

Al ejecutarlo nos dirá que nos ha redirigido a la página de login, por lo que tendremos que utilizar una cookie de la sesión que tengamos abierta. sqlmap --url=“http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie=“security=medium; PHPSESSID=8k2kj7a9454b18lbojv87jc7d6” --dbs

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

56

Análisis de Vulnerabilidades

Obteniendo en nuestro caso:

Figura 67. Obteniendo las bases de datos con sqlmap.

Finalmente obtendremos las tablas de las bases de datos con: sqlmap --url=“http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie=“security=medium; PHPSESSID=8k2kj7a9454b18lbojv87jc7d6” --schema --exclude-sysdbs

Figura 68. Obtenemos las columnas con sqlmap.

Para evitar las vulnerabilidades de inyección (tanto las de inyección de comandos como las de SQL) hay algunas recomendaciones: Evitar utilizar un intérprete, en los casos que sea posible. Utilizar una interfaz que implemente variables vinculadas (bind). o Sentencias preparadas. o Procedimientos almacenados. o Las variables vinculadas permiten al intérprete distinguir entre código y datos.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

57

Análisis de Vulnerabilidades

Codificar todas las entradas antes de que lleguen al intérprete, quitando símbolos que puedan afectar a una consulta. Validar todas las entradas que provengan del usuario mediante una lista blanca, es decir, denegar todo por defecto y definir los casos que sí son válidos. Depurar los privilegios del usuario con el que se accede a la base de datos. Solamente permitir la lectura de las tablas necesarias (sobretodo restringir el acceso a las tablas con los esquemas por defecto que hemos visto). Desactivar la escritura donde sea posible. Deshabilitar la conexión remota a la base de datos (o filtrarla mediante IP) para que un atacante no se pueda conectar remotamente. 9. Redirecciones y reenvíos Muchos sitios web utilizan parámetros de redirección en sus URL; esto se suele utilizar para redirigir a un usuario a otra página tras realizar una operación. Si el parámetro no está correctamente validado, un atacante podría redirigir el navegador de una víctima a una página maliciosa bajo el pretexto de una URL válida, ya que el usuario confiará en la página al venir de un sitio de confianza. Se podría redirigir a: Páginas de phishing como páginas de login falsas. Páginas de malware (instalación de toolbars, adware, plugins…). Exploits para el navegador. En muchos casos se utiliza la ingeniería social para conseguir que la víctima abra el enlace, ya sea por email, foros, chats… Para un ejemplo podemos suponer un escenario en el que la página de PayPal, cada vez que haces Log out de tu cuenta te reenvía de nuevo a la página de login de la forma: https://www.paypal.es?dest=www.paypal.es/login.php Un atacante podría aprovecharse de esto y enviar un correo haciéndose pasar por PayPal e introduciendo un enlace modificado: https://www.paypal.es?dest=www.paypalFalso.es/login.php

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

58

Análisis de Vulnerabilidades

La URL inicial corresponde con la página oficial por lo que un usuario descuidado podría fácilmente caer en el intento de phishing.

Para eliminar esta vulnerabilidad se debe: Evitar utilizar redirecciones y reenvíos en la medida de lo posible. Si se usa, evitar incluir la redirección como un parámetro de la URL. Si es indispensable incluir el parámetro en la URL: o Validar cada parámetro para asegurar que es una redirección permitida y autorizada para el usuario en cuestión, y a un sitio válido y de confianza. o Utilizar parámetros locales y mapear estos en el lado del servidor. Validar la URL después de que la página de destino se haya determinado, para asegurar que el destino es correcto. Validar la redirección mediante un filtro externo como Siteminder. Comprobar siempre que el usuario tenga permisos para ver tanto la página original como la redirigida. Si no se hace correctamente podría permitir accesos no autorizados y escalada de privilegios en la página. 10. Subida de archivos sin restricción Subir archivos representa un riesgo para las aplicaciones. Muchos ataques contra aplicaciones web consisten en dos fases, la primera es conseguir algún código en el sistema a atacar y la segunda encontrar una manera de ejecutar ese código. Con la subida de archivos se ayuda a un atacante a conseguir la primera fase. Las consecuencias de la subida de archivos sin restricción pueden ser variadas, dependiendo de que la aplicación permita subir archivos y dónde se almacenen, pero el riesgo es muy alto: Pérdida total del sistema (Denegación de servicio o robo de información). Sobrecarga de archivos en el sistema o la base de datos. Defacement. Almacenamiento de virus para infectar el sistema y a los usuarios de la aplicación web. Hay dos tipos de problemas con la subida de archivos. El primero son los metadatos de archivos, como el path o el nombre. Estos podrían modificarse al realizarse la petición TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

59

Análisis de Vulnerabilidades

de envío HTTP con proxys como Tamper Data, pudiendo subir archivos no permitidos o sobrescribiendo archivos críticos del servidor. El segundo tipo de problema es el tamaño del archivo o su contenido. De nuevo se podría modificar con un proxy permitiendo la subida de archivos maliciosos. Podemos ver un ejemplo en la plataforma DVWA en la pestaña de Upload. Nota: para que pueda funcionar la subida de archivos es necesario dar permisos 777 a la carpeta /var/www/dvwa/hackable/uploads con chmod. En el nivel bajo vamos a insertar subir una webshell como la c99, ya que no tiene protección alguna contra ningún tipo de archivo. Pero al intentarlo vemos que no nos deja, así que vamos a probar utilizar Tamper Data para ver qué ocurre.

Figura 69. Subida errónea de la webshell.

Vemos que tiene un tamaño máximo de archivo, así que vamos a probar modificarlo.

Modificamos el tamaño máximo con Tamper Data.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

60

Análisis de Vulnerabilidades

Ahora si nos dejará subir la webshell y podremos acceder a ella (¡y con permisos de escritura!):

Figura 70. Webshell con permisos de lectura y escritura.

En el nivel medio no podremos, aunque codifiquemos el parámetro del tamaño, pues el propio código de la aplicación comprobará el tamaño y no nos dejará subir archivos grandes. Pero sí podremos subir una pequeña shell del tipo:

También nos dará error, pues la aplicación comprueba el tipo de archivo que se sube, permitiendo solo aquellos que sean del tipo «image/jpeg». De nuevo usaremos Tamper Data para intentar modificar este valor.

Cambiamos el valor del tipo de archivo.

TEMA 3 – Ideas clave

© Universidad Internacional de La Rioja, S. A. (UNIR)

61

Análisis de Vulnerabilidades

Finalmente podremos acceder a ella y ejecutar comandos con permisos de lectura, escritura y ejecución:

Figura 71. Podemos ejecutar comandos en el servidor.

Para evitar este tipo de vulnerabilidades debemos: Comprobar las extensiones y utilizar listas blancas para los valores. Filtrar los archivos por tamaño y establecer un límite de tamaño en la carpeta donde se almacenen los archivos. Sanear la entrada de caracteres de los archivos subidos, evitando símbolos como “;”, “:”, “>”, “ ‘admin OR 1 = 1’; parámetro2 -> ‘OR 1 = 1’; B. parámetro1 -> admin’OR’1’=’0; parámetro2 -> admin’OR’1’=’1; C. parámetro1 -> Indiferente parámetro2 -> admin‘OR’1’=’1; D. parámetro1 -> admin‘OR’1’=’1; parámetro2 -> Indiferente 10. Dentro de las vulnerabilidades web, cuál de las siguientes no existe: A. RFI. B. XSS Stored. C. Reload injection. D. Session Hijacking.

TEMA 3 – Test

© Universidad Internacional de La Rioja, S. A. (UNIR)

78