TEST DE PENETRACIÓN USANDO ZAP APLICACIÓN: BADSTORE
by Gottlieb Leberecht Müller Versión Documento: 1.0 Fecha: Febrero 2018
Contenidos 1. Alcance del proyecto ........................................ 2 2. Herramientas utilizadas ..................................... 3 2.1. ZAP 2.7.0 ...................................................... ........................................................... ..... 3 2.2. Emulación de aplicación BadStore a través de máquina virtual ........ 6
3. Aplicación BadStore ......................................... 9 3.1. Función de búsqueda ...................................... ................................................ .......... 10 3.2. Función carrito de compra .......................................... .......................................... 10 3.3. Función libro de visitas ....................................... ........................................... .... 11 3.4. Función vista de pedidos anteriores ................................ 12 3.5. Función de información de la empresa ............................... 13 3.6. Función Mi cuenta ........................................ .................................................. .......... 13 3.7. Función Logueo/Registro ............................................ ............................................ 15 3.8. Función Logueo de proveedor ..................................... ........................................ ... 16 3.9. Función Web Services ..................................... ............................................... .......... 18 3.10. Función RSS ....................................................... ....................................................... 18
4. Vulnerabilidades ........................................... 19 4.1. Vulnerabilidades reportadas ........................................ ........................................ 19 4.2. Auditoría de vulnerabilidades vulnerabilidades ...................................... ...................................... 23 4.2.1 Inyección SQL .................... .......................................... ........................................ .................. 23 4.2.2 XSS .................... ......................................... ........................................... ............................. ....... 25 4.2.3 Autenticación .................... .......................................... ........................................ .................. 27
5. Medidas a adoptar .......................................... 36 5.1. Inyección .......................................................... .......................................................... 37 5.2. XSS ................................................................ ................................................................ 37 5.3. Autenticación ...................................................... ...................................................... 37
6. Anexos ..................................................... 38 7. Glosario ................................................... 39
1
1. Alcance del proyecto Se pretende auditar la seguridad de una aplicación que implementa un portal de compras a través de tecnologías web. Al objeto de no auditar directamente la aplicación en producción, se dispone un entorno de virtualización en el que se instalan las herramientas y los servicios que posteriormente funcionarán en producción. Con ello, la explotación de las posibles vulnerabilidades que se encuentren servirán para fortalecer la aplicación una vez que se ponga a funcionar de cara al público. Se sigue en la elaboración de este documento la metodología propuesta en el marco de trabajo que define la guía de testeo de Open Web Application Security Project (OWASP1), concretamente de la versión 4 de esta guía, disponible desde
agosto de 2015.
Fig. 1. Flujo de trabajo OWASP
1
https://www.owasp.org/index.php/Main_Page
2
En la Fig. 1 se presenta el flujo de trabajo que propone la metología OWASP. Dado que la aplicación a testear ya se encuentra desarrollada, las fases de Definición y Diseño del SDLC quedan ya establecidas, puesto que no se pretende
rediseñar la aplicación sino testear su seguridad una vez que se quiere empezar a utilizar en un entorno de producción. Por tanto, las tares que se abordan en este proyecto quedarían englobadas dentro de las fases de
Desarrollo e
Implementación propuestas en la figura anterior.
2. Herramientas utilizadas Para la realización del test de la aplicación se utilizará una herramienta que, en
primer
diferentes
lugar,
presente
tecnologías
las
usadas
vulnerabilidades en
el
desarrollo
que
pudieran
del
portal
tener web
y,
las con
posterioridad, que permita la explotación de dichas vulnerabilidades para atacar el sistema. El objeto fundamental, como ha quedado reseñado más arriba, es proponer mecanismos para evitar que un agente malicioso pueda hacer uso de las debilidades que se detecten.
2.1. ZAP 2.7.0 Zed Attack Proxy (ZAP), desarrollado por OWASP, es una de las herramientas de código abierto más populares para la realización de auditorías relacionadas con
aplicaciones
web.
Las
características
de
esta
aplicación
se
ven
continuamente mejoradas y mantenidas por cientos de voluntarios de todo el mundo. Actualmente la versión estable es la 2.7.0. Esta herramienta permite encontrar automáticamente vulnerabilidades en aplicaciones web durante las fases de desarrollo de las mismas y también tiene opciones para la realización de un testeo de seguridad manual. ZAP 2.7.0 se ha instalado sobre un anfitrión Ubuntu 16.04.3 LTS (Xenial) utilizando Docker 2, lo que permite resolver las dependencias que esta aplicación tiene con Java y con otros paquetes. En la Fig. 1 se puede ver cómo se ha realizado la instalación de Docker en el anfitrión. En la Fig. 2 se muestra la instalación de ZAP utilizando Docker.
2
https://www.docker.com/
3
Fig. 1. Instalación de Docker en Ubuntu 16.04.3
Fig. 2. Instalación ZAP con Docker
Una vez instalado, se localiza el script que lanza la ejecución de ZAP ( zap.sh según lo que se detalla en el proyecto zap2docker-stable3), como se ve en la Fig. 3.
Fig. 3. Localización del script de ZAP en el sistema de ficheros
Y con esto, se ejecuta dicho script para arrancar la herramienta (ver Fig. 4).
3
https://hub.docker.com/r/owasp/zap2docker-stable/
4
Fig. 4. Ejecución de ZAP
Finalmente, acabará cargándose el entorno gráfico de esta herramienta, que, como se ve en la Fig. 5, inicialmente pregunta sobre la posibilidad de guardar la sesión ZAP que se realice. Tal y como se detalla en la guía de comienzo de esta herramienta 4, por defecto las sesiones realizadas con ZAP se guardan de forma persistente en una base de datos HSQLDB. Si se elige en un primer momento no guardar la sesión, al salir de la herramienta nos dará la oportunidad de hacerlo.
Fig. 5. Entorno gráfico de ZAP
La interfaz de Usuario de ZAP se compone de los siguientes elementos:
4
https://github.com/zaproxy/zaproxy/releases/download/2.7.0/ZAPGettingStartedGuide-2.7.pdf
5
1. Barra de menús. Da acceso a la mayor parte de las herramientas automáticas y manuales. 2. Barra de Herramientas.
Con botones que dan acceso rápido a las caracterís-
ticas más utilizadas. 3. Ventana de árbol. Muestra el árbol de sitios testeados y el árbol de scripts utilizados. 4. Espacio de trabajo.
Muestra las peticiones, las respuestas, los scripts
con posibilidad de editar los mismos. 5.
Ventana de información. Muestra los detalles proporcionados por las
herramientas automáticas y manuales que se hayan utilizado. 6. Pie. Muestra un resumen de las alertas encontradas y del estado de las principales herramientas automáticas. Además, ZAP incluye una CLI muy poderosa en la que se pueden ejecutar manualmente herramientas de testeo de aplicaciones web.
2.2. Emulación de aplicación BadStore a través de máquina virtual La aplicación que se pretende testear es un portal web que permite la venta de productos. Los usuarios que quieran comprar desde Internet, podrán registrarse en el portal y ver los pedidos que hayan realizado con anterioridad. La aplicación ya está desarrollada y la empresa que va a ponerla en funcionamiento quiere testear la seguridad de la misma. Se ha preparado un servicio virtualizado (OVA) en VirtualBox, de forma que haciéndolo
correr
sobre
ese
entorno
de
virtualización
se
emula
el
comportamiento que realmente tendría el portal web de la empresa y se pueden chequear todas las vulnerabilidades de la aplicación instalada. Se ha utilizado la versión 5.2.6 r120293 de VirtualBox corriendo sobre el mismo anfitrión en el que se instaló ZAP (Ubuntu 16.04.3). Para virtualizar la aplicación web, se hace que arranque desde una unidad de CD-ROM ejecutándose como una distribución Trinux y con un Apache implementando el servidor web. En la Fig. 6 se muestra la configuración de los dispositivos de almacenamiento para la aplicación virtualizada. Como se ve, se arrancará directamente desde una imagen iso cargada en una unidad de CD IDE.
6
Fig. 6. Configuración soportes de almacenamiento de aplicación virtualizada
Para interaccionar con el anfitrión, se prepara una conexión de red ex profeso que localizará al nuevo adaptador (vboxnet0) en la dirección 192.168.56.1/24 como se muestra en la Fig. 7. Además, y como se ve en la Fig. 8, se configura un servidor DHCP en la dirección 192.168.56.2/24 que gestiona un pool de 91 direcciones dentro de la red de clase C privada (de la 192.168.56.110 a la 192.168.56.200).
Fig. 7. Configuración adaptador vboxnet0 (red anfitrión)
7
Fig. 8. Pool DHCP
Con esto, al arrancar la máquina virtual que emula la apliación, es de esperar que al adaptador eth0 de la misma se le asigne la primera dirección del pool DHCP, como efectivamente sucede.
Fig. 9. Dirección IP asociada el interfaz de la aplicación
Para referirnos a la aplicación con el nombre de dominio que se asociará al portal web, editamos en el anfitrión el fichero /etc/hosts y registramos la dirección asociada al nombre de dominio www.badstore.net.
8
Fig. 10. Configuración archivo /etc/hosts
3. Aplicación BadStore Una vez configurados los pasos detallados en 2.2, desde el anfitrión se podrá acceder a la aplicación web haciendo uso de un navegador y refiriéndonos al dominio estipulado en /etc/hosts. En la Fig. 11 se ve la página inicial que se sirve.
Fig. 11. Página inicial BadStore
La auditoría de seguridad sobre esta aplicación se aborda desde un enfoque de caja negra, en el que inicialmente se desconoce por completo la forma en que se ha implementado. No obstante, un primer vistazo a la aplicación sin utilizar herramientas de análisis revela deficiencias que no se pueden pasar por alto.
9
3.1. Función de búsqueda Al escribir un filtro cualquiera en la función Quick Item Search que aparece en la parte superior izquierda, la aplicación revela la sentencia SQL que construye en la consulta, como se ve en la Fig. 12. Además de dar detalles sobre
los
campos
de
la
tabla
y
del
nombre
de
la
tabla
( itemdb),
una
implementación tan deficiente de esta función sugiere que no está protegida frente a una inyección SQL.
Fig. 12. Función Quick Item Search
3.2. Función carrito de compra Haciendo click en el enlace
What’s
se presentan una serie de artículos que New
se pueden añadir directamente a un carrito de compra. La adición de productos es correcta: a medida que se agregan el carrito totaliza los importes de los productos que se van sumando, si bien se echa en falta el hecho de que se puedan marcar cantidades de esos productos. No obstante, la eliminación de productos ya añadidos parece que funciona en un principio (se descuentan los importes de los que se desmarcan) pero al eliminar el último elemento, la aplicación genera un error que aparece superpuesto en la página de productos e informa de la versión de servidor web que se está utilizando (Apache 1.3.8). Esto se muestra en la Fig. 13.
10
Fig. 13. Error en la implementación del carrito de compra
3.3. Función libro de visitas En la opción Sign Our GuestBook se presenta la posibilidad de dejar un registro en un libro de visitas del portal.
Fig. 14. Libro de visitas
En esa utilidad se avisa de que el e -mail no es necesario, pero que ayuda para una realimentación por parte de los propietarios de la aplicación. Sin embargo, no existe ningún mecanismo que controle que el correo que se inserta es válido, y llama también la atención los mensajes que han dejando algunos usuarios anteriormente.
11
Fig. 15. Registro de mensajes en libro de visitas
Cabe pensar, en este sentido, en la posibilidad de inyectar un script utilizando el campo de comentarios que se muestra en la Fig. 14, implementando así un ataque XSS. Además, se revelan nombres de usuarios que pueden estar reg istrados ya en la aplicación.
3.4. Función vista de pedidos anteriores Bajo el epígrafe View Previous Orders se podrá acceder a los pedidos que se realizaron anteriormente, se supone que cuando un usuario se haya registrado y esté logueado en el sistema.
Fig. 16. Pedidos anteriores
12
Si el registro de usuarios no tiene las suficientes garantías, podría revelar información de pedidos a un atacante que falseara las credenciales.
3.5. Función de información de la empresa Picando en About Us se puede leer un mensaje en el que los propietarios del sitio animan a los usuarios a dar su opinión sobre el servicio. Es significativo que al hacer click en Send us an email! la dirección de correo destinatario sea
[email protected] (no deben tener un buen criterio formado de sus clientes). Además, se presume con ostentación del trabajo que dedican cada ‘pocos años’ a conseguir un certificado de seguridad. Y acaban dejando un mensaje para hackers donde advierten de que utilizan criptografía. Desde el punto de vista de la seguridad informática, es conveniente evitar un efecto de llamada a usuarios experimentados que puedan exponer las vulnerabilidades de la aplicación, por lo que este mensaje debería redactarse de otra forma.
Fig. 17. About us
3.6. Función Mi cuenta Bajo el título My Account un usuario tiene la posibilidad de recuperar una contraseña de acceso olvidada y también de picar en un enlace que llevaría a una función de logueo o de nuevo registro (ver siguiente apartado).
13
Fig. 18. My Account
Llama la atención el procedimiento tan poco seguro que implementa el reseteo de la password de un usuario: basta con introducir la dirección de correo electrónico (que tampoco se valida en ningún momento) y definir cuál fue el color preferido que se eligió en la creación de la cuenta (además, el valor por defecto de este color coincide con el valor por defecto del proceso de registro). Con eso, y como se ve en la siguiente figura, se resetearía la password del usuario a ‘Welcome’.
Fig. 19. Reseteo de password
Para más inri, la introducción en este apartado de un carácter no válido en una sentencia SQL como una comilla simple en el campo de Email Address genera
14
la siguiente respuesta, que informa claramente de cuál es el motor de base datos sobre el que se implementa la aplicación (MySQL).
Fig. 20. Mensaje de error por una mala sintaxis SQL
3.7. Función Logueo/Registro La función Login/Register permitirá a un usuario ya registrado loguearse en la aplicación con la dirección de correo electrónico y contraseña o bien, en caso de ser un usuario nuevo, registrar una nueva cuenta.
Fig. 21. Logueo/Registro
La funcionalidad de registrar una nueva cuenta tiene una implementación muy deficiente, pues se comprueba que basta reseñar un solo carácter en el campo de Full Name para que la cuenta se cree, sin necesidad de especificar correo
15
electrónico y contraseña. Además, nótese que el color por defecto para recuperar una contraseña olvidada es el mismo que el que permite la recuperación (ver apartado 3.6).
Fig. 22. Especificación de un nuevo usuario con un solo caracter
Fig. 23. Usuario nuevo creado con un solo caracter
3.8. Función Logueo de proveedor Hay una parte específica en el portal que se refiere a proveedores ( SUPPLIERS ONLY ). Desde ahí, existe una función que permite a un proveedor loguearse en
la web (Supplier Login).
16
Fig. 24. Función que permite a un proveedor loguearse en el sistema
Se ha intentado el logueo en esta pantalla con las credenciales de un usuario normal declarado previamente y se muestra el siguiente mensaje de error.
Fig. 25. Logueo como proveedor usando una cuenta de usuario creada anteriormente
A partir de esta funcionalidad se pueden deducir varias cosas que afectan a la seguridad de la aplicación: 1) Existen varios roles de usuarios en el sistema, al menos dos: a) Un usuario normal que puede registrarse en el mismo según lo reseñado en 3.7. b) Un usuario de tipo proveedor que debe estar ya declarado en el sistema,
puesto
que
no
hay
una
utilidad
para
registrase
como
proveedor.
17
2) La declaración de proveedores se deberá llevar a cabo por parte de un administrador del sistema que de alguna forma tipificará en las tablas de usuarios de la base de datos que dicho usuario es un proveedor, para distinguirlo de un usuario normal.
3.9. Función Web Services Junto a una etiqueta que anuncia servicios XML, la función Web Services incita al usuario (se supone que proveedor) a utilizar sus nuevos servicios Web. Cuando se clica en esta opción, se muestra la pantalla que se ve a continuación:
Fig. 26. Web Services
Tal y como se puede apreciar se da acceso, sin necesidad de aportar credenciales para ello, a una carpeta ws que contiene una serie de scripts escritos en PERL y en Java (ejecutándose estos sobre una implementación de Axis sobre Apache ). Además, y como ocurría en 3.2, se informa de la versión del servidor Apache sobre la que se monta la aplicación.
3.10. Función RSS La
aplicación
incorpora
un
servicio
RSS
de
forma
que
un
usuario
puede
suscribirse a un canal de noticias relacionadas con el portal. Permite la suscripción
mediante
el
uso
de
un
marcador
dinámico
que
se
incorpora
directamente al navegador que se use. Entre otras cosas, este canal registra las búsquedas que hagan los diferentes usuarios a través de la función Quick Item Search, como se puede ver en la siguiente figura.
18
Fig. 27. Servicio RSS
4. Vulnerabilidades Una vez analizado el funcionamiento básico de la aplicación desde el punto de vista de un usuario estándar, se va a proceder a la búsqueda sistemática de vulnerabilidades en la misma. Para ello, se utilizará la herramienta ZAP (Zed Attack Proxy), desarrollada por OWASP, en su versión 2.7.0.
4.1. Vulnerabilidades reportadas Se lanza ZAP a la dirección de la página inicial de la aplicación BadStore: http://www.badstore.net/cgi-bin/badstore.cgi, en
primera
instancia
con
el
ataque que tiene parametrizado ZAP por defecto, que utiliza exclusivamente técnicas pasivas. El proxy de ataque reporta un total de 9 alertas, 2 de las cuales las clasifica con un nivel de riesgo medio (en naranja) y otras 7 con un nivel de riesgo bajo (en amarillo).
19
Fig. 28. Alertas reportadas por ZAP
Acudiendo a cada una de las alertas que se reseñan al pie, aparece información relacionada con la misma. Por ejemplo, en la Fig. 29 se muestra información en relación a la alerta Application Error Disclosure.
Fig. 29. Información detallada sobre una alerta
En la información que se despliega, se da un CWE ID y un WASC ID, que nos sirven para orientarnos sobre la vulnerabilidad y los procedimientos de ataque propuestos por la Common Weakness Enumeration (CWE) de MITRE 5 y por la WASC Threat Classification propuesta por el Web Application Security Consortium 6.
Se
incluye
como
Anexo
I
la
última
versión
de
esta
última
lista
de
vulnerabilidades (v2.00 del 1/1/2010). Asimismo, también se tendrá muy en cuenta la lista Top 10 de vulnerabilidades propuesta por OWASP en 2017, enfocada en identificar los riestos más críticos en aplicaciones web (se incluye como Anexo II a este proyecto). Al objeto de analizar con más profundidad las vulnerabilidades de la aplicación, se lanza ZAP en modo ataque, como se ve en la Fig. 30.
5 6
https://cwe.mitre.org/index.html http://projects.webappsec.org/w/page/13246978/Threat%20Classification
20
Fig. 30. ZAP en modo ataque
En este método de sondeo, que ya utiliza una serie de técnicas activas que interactúan con la aplicación, se descubren nuevas vulnerabilidades como se aprecia en la gráfica siguiente.
Fig. 31. Gráfico de respuestas con ZAP en modo ataque
21
Concretamente, con este método de sondeo se obtienen 3 alertas críticas (ZAP las marca en rojo) y una nueva alerta de tipo medio que no aparecían en un análisis pasivo de la aplicación. El conjunto de alertas reportadas se muestra en la siguiente tabla:
#
NOMBRE ALERTA
Riesgo
CWE ID
WASC ID
1
Cross Site Scripting (Persistente)
Alto
79
8
2
Cross Site Scripting (Reflejada)
Alto
79
8
3
Falla por Inyección SQL
Alto
89
19
4
Application Error Disclosure
Medio
200
13
5
Exploración de Directorios
Medio
548
48
6
X-Frame-Options Header Not Set
Medio
16
15
7
Cookie No HttpOnly Flag
Bajo
16
13
8
Cookie Without Secure Flag
Bajo
614
13
9
Incomplete or No Cache-control and Pragma HTTP
Bajo
525
13
Header Set 10
Password Autocomplete in Browser
Bajo
525
15
11
Private IP Disclossure
Bajo
200
13
12
Web Browser XSS Protection Not Enabled
Bajo
933
14
13
X-Content-Type-Options Header Missing
Bajo
16
15
ZAP incluso reseña en el detalle de las alertas los vectores de ataque utilizados para poner de manifiesto las vulnerabilidades. Por ejemplo, en las Fig. 32 y 33 se pueden ver los vectores utilizados para los ataques XSS persistente y de inyección SQL respectivamente.
Fig. 32. Vector de ataque para alerta XSS persistente
Fig. 33. Vector de ataque para alerta inyección SQL
En
el
Anexo
III
se
presenta
un
documento
html
con
un
reporte
de
las
vulnerabilidades encontradas con ZAP.
22
4.2. Auditoría de vulnerabilidades Partiendo de las vulnerabilidades encontradas en 4.1, y atendiendo a la guía propuesta en OWASP para las diez amenazas más críticas en aplicaciones web actuales (ver Anexo II), se procede a auditar manualmente un conjunto de las mismas para comprobar la respuesta de la aplicación.
4.2.1 Inyección SQL Los problemas derivados de técnicas de inyección aparecen como la prioridad A1 en el OWASP Top 10 2017. Las fallas de inyección, como SQL, NoSQL, OS o LDAP ocurren cuando se envían datos no confiables a un intérprete, como parte de un comando o consulta. Los datos dañinos del atacante pueden engañar al intérprete para que ejecute comandos involuntarios o acceda a los datos sin la debida autorización7.
Fig. 34. Clasificación de riesgos en aplicaciones web según metodología OWASP
Atendiendo a metodología que propone OWASP para clasificar los riesgos que plantean el uso de aplicaciones web en las organizaciones (ver Fig. 34), los problemas de inyección (y entre ellos el específico de inyección SQL) tiene los valores más altos de riesgo, puesto que según la ficha correspondiente en la guía OWASP Top 10 2017 (A1) es fácilmente explotable (casi cualquier fuente de datos puede ser un vector de inyección), es un riego bastante difundido (asignan un nivel 2 en prevalencia), la vulnerabilidad es fácil de detectar (examinando el código y utilizando escáneres y fuzzers) y el impacto técnico que provoca es severo. Además, puede suponer la divulgación, péridida o modificación de los datos de la organización, como se reseña en la Fig 35.
7
Extraído literalmente de OWASP Top 10 2017
23
Fig. 35. Evaluación del riesgo de inyección según OWASP Top 10 2017
Utilizando los ejemplos de ataque propuestos en la guía OWASP Top 10 2017, así como en el detalle de la vulnerabilidad WASC-19 (ver Anexo I) referida expresamente a inyección SQL, y el vector de ataque propuesto por ZAP en la detección de la alerta correspondiente (ver Fig. 33), se procede a testear la aplicación BadStore para comprobar si es vulnerable a una inyección SQL. Como se vio en 3.1, al utilizar la función de búsqueda aparecía en pantalla la sentencia SQL que se formaba para la consulta de artículos. También se vio en 3.2 que bajo el epígrafe de
What’s New se
muestran una serie de artículos
ordenados por numero de item, el primero con un identificador 1000 ( Snake Oil), el segundo con un identificador 1003 ( Magic Rabbit). Aprovechando que se puede observar cómo se construye la sentencia SQL utilizando la búsqueda rápida, se va a introducir como cadena de búsqueda la propuesta típica que se recoge en los ejemplos de escenarios de ataque en la guía OWASP: ' or '1'='1. Con esto estaremos añadiendo al WHERE de la sentencia SQL una condición que siempre se cumple: 1=1 y con una lógica inclusiva (OR), por lo que debería mostrar todos los registros que en este caso estén en la tabla itemdb. Y, en efecto, como se muestra
en
la
Fig.
36,
aparecen
anteriormente cuando se picaba en
nuevos
registros
que
no
se
mostraban
. What’s New
24
Fig. 36. Resultado de la inyección SQL mostrando todos los registros de itemdb
La inyección también se puede llevar a cabo en los procesos de login, tanto de un usuario normal como de un proveedor, tal y como revela la alerta de ZAP. Luego es evidente que esta aplicación es vulnerable a una inyección SQL, que en el mejor de los casos está permitiendo ver información reservada.
4.2.2 XSS La secuencia de comandos en sitios cruzados (XSS) está marcado como el séptimo riesgo en importancia en el OWASP Top 10 2017. Los XSS ocurren cuando una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada; o actualiza una página web existente con datos suministrados por el usuario utilizando una API que ejecuta
JavaScript
en el navegador. Permiten ejecutar comandos en el navegador de la víctima y el atacante puede secuestrar una sesión, modificar ( defacement) los sitios web, o redireccionar al usuario hacia un sitio malicioso 8. Según la metodología OWASP para la evaluación de riesgos, un ataque por XSS (en cualquiera de sus variantes) supone también una vulnerabilidad de alto riesgo, como se puede ver en la siguiente figura. Además, y como se dice expresamente en la guía, XSS es la segunda vulnerabilidad más frecuente, encontrándose en aproximadamente dos de cada tres aplicaciones. Como se ha visto en 4.1, ZAP ha reportado vulnerabilidad de la aplicación a XSS persistente y reflejado. Puesto que la variante persistente permite la
8
Extraído literalmente de OWASP Top 10 2017
25
ejecución de secuencias de comandos en el navegador de la víctima dando lugar a
un
impacto
severo
en
el
sistema
atacado,
se
procede
a
auditar
esta
vulnerabilidad.
Fig. 37. Evaluación del riesgo XSS OWASP Top 10 2017
Según se detalla en la WASC Threat Classification, concretamente en la WASC -08 a que enlaza la alerta reportada por ZAP, la catalogación de persistente se debe al hecho de que la carga del ataque se almacena del lado del servidor. Un ejemplo claro se da en algunos sitios web con utilidades que permiten a usuarios registrados dejar mensajes que son almacenados de alguna forma en una base de datos. Es justo lo que permite la función libro de visitas (ver apartado 3.3). Para testear si el sistema es vulnerable a XSS persistente, basta dejar un comentario en el libro de visitas con un pequeño script en JavaScript que muestre un mensaje en una ventana emergente.
alert("Oooops… Parece que BadStore no protege frente a XSS")
El resultado, como se aprecia en las siguientes figuras, es que BadStore tampoco tiene protección frente a XSS, por lo que puede utilizarse esta característica para ataques maliciosos de tipo phising, robo de credenciales o incluso ejecución de software malicioso.
26
Fig. 38. Firma en el libro de visitas con un script
Fig. 39. Resultado de la ejecución del código del script
4.2.3 Autenticación Los
riesgos
derivados
de
una
mala
implementación
de
los
procesos
de
autenticación también tienen una importancia crítica en el OWASP Top 10 2017, como se ve en la Fig. 40. Tal y como se adelantó en los apartados 3.6 a 3.8, el procedimiento de logueo y recuperación de contraseñas definido en la aplicación no parece demasiado adecuado. Además, ZAP ha revelado una serie de alertas que tienen que ver también con estos procesos de autenticación: -
Fallas de inyección SQL en el procedimiento de login.
27
-
Vulnerabilidad en cookies que no tienen el atributo HttpOnly, de forma que se podría inyectar una cookie capturada para conseguir loguearnos como un usuario.
Fig. 40. Evaluación del riesgo Autenticación OWASP Top 10 2017
Se pretende demostrar, no obstante, que a veces la aplicación del sentido común en un sistema que no parece muy robusto puede dar lugar a conseguir el control total sobre la aplicación. Se podrían utilizar herramientas de ataque de fuerza bruta para intentar conseguir una combinación adecuada de login y contraseña, máxime cuando la aplicación no limita el número de veces que se puede probar. Sin embargo, aprovechando la utilidad de reseteo de password proporcionando un color que es, además, el que aparece por defecto cuando el usuario se crea, se ha intentado resetear la contraseña de un usuario llamado ‘admin’, teniendo en cuenta que hay muchos sitios con cuentas de administración que usan este login (ver Fig. 41). Curiosamente, la aplicación parece que reconoce a ese usuario y resetea la contraseña a su valor por defecto: ‘Welcome’, como se ve en la Fig 42. Como consecuencia, ahora se puede entrar en la aplicación con un usuario que existe y que se llama ‘admin’, con la password ‘Welcome’ (Figuras 43 y 44). Además, al parecer, se trata del usuario que administra el sitio, como era de prever. Pero no nos detenemos aquí. Observando la aplicación, se advierte que la implementación de los diferentes enlaces de la misma que quedan en el menú de la izquierda se realiza a través de métodos cgi de nombres muy predecibles: action=whatsnew para
What’s
New ,
action=guestbook para Sign Our GuestBook,
action=viewprevious para View Previous Orders, action=aboutus para About Us… ¿Y si hubiese programado un método para administrar dicho sitio a través de la interfaz web? ¿Cuál sería el nombre de la acción siguiendo su lógica? En efecto,
28
hay un action=admin que abre la caja de Pandora de esta aplicación. Basta con llamar a esa acción desde el navegador para que se muestre lo que aparece en la Fig. 45. Estando logueado como admin se tiene acceso a todo el menú de administración del sitio.
Fig. 41. Intento de resetear la password de un posible usuario ‘admin’
Fig. 42. La aplicación reconoce al usuario ‘admin’ y resetea su password a ‘Welcome’
29
Fig. 43. Logueo como usuario admin
Fig. 44. Acceso con usuario admin
30
Fig. 45. Acceso al menú de administración del sitio
Las diferentes opciones de administración del portal son:
1)
View Sales Reports: Permite ver un listado de las ventas realizadas, donde se muestran los números de las tarjetas de crédito utilizadas.
Fig. 46. Listado de ventas realizadas
2)
Reset User Password: Resetea la contraseña de cualquiera de los usuarios registrados a ‘Welcome’.
31
Fig. 47. Reseteo de password de usuario
3)
Add User: Permite la creación de nuevos usuarios asignándole un rol. Como se adelantaba en 3.8, desde aquí es desde donde se pueden crear nuevos suministradores. Los roles que se permiten son: A (administrador), S (suministrador) y U (usuario normal).
Fig. 48. Creación de nuevo usuario
4)
Delete User: Para borrar el usuario que se seleccione. En este sentido, la aplicación está tan mal hecha que permite el borrado de un usuario con rol de administrador sin ni siquiera advertir de lo que se va a hacer, como se ve en la Fig. 50. Sin embargo, luego permite seguir utilizando el panel de administración como si el usuario no se hubiese borrado, pudiéndolo crear otra vez.
32
Fig. 49. Borrado de usuario
Fig. 50. Eliminación del usuario admin
5)
Show Current Users: Muestra un listado de todos los usuarios registrados en la aplicación, con las contraseñas que utilizan con un hash MD5 calculado.
Fig. 51. Listado de usuarios
33
Se sabe que MD5 es una función de hash bastante débil, dado que existen herramientas como John The Ripper que pueden craquearlas con facilidad. Incluso hay sitios web con diccionarios en los que obtener la contraseña limpia es cuestión de segundos 9. Por ejemplo, se presentan las contraseñas de los primeros diez usuarios en la siguiente tabla.
Usuario
e-mail
Password MD5
Password
Tipo
Test User
AAA_Test_User
098F6BCD4621D373CADE4E832627B4F6
test
U
admin
admin
83218ac34c1834c26781fe4bde918ee4
Welcome
A
Joe Supplier
[email protected]
62072d95acb588c7ee9d6fa0c6c85155
iforgot
S
Big Spender
[email protected]
9726255eec083aa56dc0449a21b33190
money
U
Ray Supplier
[email protected]
99b0e8da24e29e4ccb5d7d76e677c2ac
supplier
S
Robert Spender
[email protected]
e40b34e3380d6d2b238762f0330fbd84
cheap
U
Bill Gander
[email protected]
5f4dcc3b5aa765d61d8327deb882cf99
password
U
Steve Owner
[email protected]
8cb554127837a4002338c10a299289fb
profit
U
Fred Wholesaler
[email protected]
356c9ee60e9da05301adc3bd96f6b383
whole
U
Debby Supplier
[email protected]
2fbd38e6c6c4a64ef43fac3f0be7860e
helpme
S
Esto plantea el problema adicional de que los usuarios registrados acostumbren a usar las mismas credenciales para acceder a distintos sitios, lo que, teniendo en cuenta que se tienen las direcciones de correo de los mismos, da pie a probar esas contraseñas con otros servicios.
Fig. 52. Descifrado MD5
6)
Troubleshooting: Muestra la configuración de las distintas características y servicios que configuran la aplicación, de cara a una posible resolución de problemas.
9
http://www.md5online.es/
34
Fig. 52. Descifrado MD5
7)
Backup Databases: Permite generar una copia de la base de datos y volcarla sobre un directorio llamado /backup. Concretamente, se hace una copia de las tablas de usuarios y pedidos, como se puede ver.
Fig. 53. Backup de las tablas orderdb y userdb
Además de lo anterior, existen otras cuatro utilidades que permiten gestionar las comunicaciones con los proveedores: -
Supply Chain: Manage Open Orders: para gestionar las órdenes abiertas con proveedores.
-
Supply Chain: Place Order with Supplier: para abrir una nueva orden a un proveedor.
-
Supply Chain: Check Credit with Supplier: comprueba el crédito que se tiene con un proveedor.
-
Supply Chain: Check Status of RMA: comprueba el estado del RMA (Return Merchandise Authorization) o autorización de retorno de mercancía, usado como parte del proceso de devolución de un producto.
35
Fig. 53. Abrir una nueva orden a un proveedor
Fig. 54. Estado del RMA
5. Medidas a adoptar Se ha demostrado en el apartado anterior que la aplicación BadStore tiene vulnerabilidades muy graves con las que se puede llegar a controlar incluso la administración del sitio. Se proponen a continuación una serie de medidas encaminadas a resolver, a la mayor brevedad posible, los agujeros de seguridad detectados. Se siguen los criterios propuestos en OWASP Top 10 2017 para cada uno de los riesgos identificados.
36
5.1. Inyección La inyección de cualquier tipo se previene separando los datos de los comandos y consultas. Para ello: -
Usar una API segura que evite el uso de un intérprete y que proporcione una interfaz parametrizada.
-
Realizar validaciones de entradas de datos en el servidor, usando listas blancas.
-
Usar controles que limiten la salida de una consulta a un número de registros determinado.
5.2. XSS Se procurará mantener los datos no confiables separados del contenido activo del navegador. Para ello: -
Usar frameworks seguros que codifiquen automáticamente el contenido para prevenir XSS (Ruby 3.0 o React JS).
-
Codificar los datos de requerimientos HTTP no confiables en los campos de salida HTML para evitar XSS reflejado y persistente.
-
Habilitar una política de seguridad de contenido donde se detalle qué tipo de datos se pueden colocar en el servidor.
5.3. Autenticación Básicamente habrá que habilitar mecanismos de autenticación robustos que eviten ataques de fuerza bruta automatizados o utilizando configuraciones por defecto: -
No
usar
credeciales
por
defecto,
especialmente
en
el
caso
de
administradores. -
Implementar controles contra contraseñas débiles.
-
Establecer
una
política
de
seguridad
en
lo
relativo
a
longitud,
complejidad y rotación de contraseñas alineándose con recomendaciones basadas en evidencias. -
Limitar o incrementar el tiempo de respuesta de cada intento fallido de inicio de sesión. Hacer un registro de los fallos que se produzcan para detectar ataques de fuerza bruta.
-
Utilizar un gestor de sesión integrado en el servidor que permita identificar a la misma con un ID aleatorio y que se invalide una vez que se cierre
37
6. Anexos I.
WASC-TC-v2_0.pdf
II.
OWASP Top 10 2017 [es].pdf
III.
BadStore_Vulnerabilidades.html
38
7. Glosario [1] Axis. Apache Axis es un framework de código abierto, basado en XML para servicios web. Consiste en una implementación en Java y otra en C++ del servidor SOAP, así como diversas utilidades y APIs para generar y desplegar aplicaciones de servicios web. Por medio de Apache Axis, los desarrolladores pueden crear aplicaciones computacionales interoperables y distribuidas. Axis se desarrolla bajo los auspicios de la Apache Software Foundation. [Fuente: Wikipedia] [2] CLI. Command Line Interface. Término usado habitualmente para referirse a una consola de comandos en contraposición a GUI (Graphical User Interface). [3] Docker. Es una herramienta que permite empaquetar una aplicación y sus dependencias en un contenedor virtual que se puede ejecutar en cualquier servidor Linux, contribuyendo así a aumentar la flexibilidad y portabilidad de la misma. [4] CGI. Common Gateway Inteface. Método para la transmisión de información hacia un compilador instalado en el servidor. Su función principal es la de añadir una mayor interacción a los documentos web que por medio del HTML se presentan de forma estática. [5] HSQLDB. Hyperthreaded Structured Query Language Database. Es un sistema gestor de bases de datos libre escrito en Java. [6] RSS. Really Simple Syndication es un formato XML para distribuir contenido en la web. Se utiliza para difundir información actualizada frecuentemente a usuarios que se han suscrito a la fuente de contenidos. El formato permite distribuir contenidos sin necesidad de un navegador, utilizando programas llamados agregadores de noticias, diseñados para leer contenidos RSS, tales como Mozilla Firefox, Thunderbird o Akregator, entre otros. A pesar de eso, es posible utilizar el mismo navegador para ver los contenidos RSS. Las últimas versiones de los principales navegadores permiten leer los RSS sin necesidad de programas adicionales. RSS es parte de la familia de los formatos XML, desarrollado específicamente para todo tipo de sitios que se actualicen con frecuencia y por medio del cual se puede compartir la información y usarla en otros sitios web o programas. A esto se le conoce como redifusión web o sindicación web (una traducción incorrecta muy extendida). [Fuente: Wikipedia] [7] SDLC. Software Development Life Cycle. Ciclo de vida de un desarrollo de software, que implicaría, según terminología OWASP, cinco fases: Definición, Diseño, Desarrollo, Implementación y Mantenimiento. [8] SOAP. Originalmente las siglas de Simple Object Access Protocol. Es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un
39
