Introducción al Testing de Seguridad con OWASP ZAP

En este post quiero compartir una breve introducción a un mundo enorme que es el testing de seguridad. Para ser un tester de seguridad hace falta especializarse mucho para poder hacer un buen trabajo y alertar de los riesgos asociados a este factor de calidad. En este artículo, realizado por Alejandro Sagrera y Santiago Cabrera de Abstracta, a quienes les agradezco las ganas de escribirlo y compartirlo, se brinda una introductoria a la temática, a OWASP y a la herramienta ZAP. Creo que lo más rico de esto es que ayuda a entender el mindset que debe tener un tester con foco en la seguridad.

---

---

¿Qué es el testing de seguridad?

Las pruebas de seguridad buscan brindar información sobre la Confidencialidad, Integridad y Disponibilidad de los datos, buscando identificar amenazas y riesgos de un sistema. Una vez ejecutadas las pruebas de seguridad es posible medir y cuantificar los riesgos a los cuales se ven expuestos los aplicativos tanto en la infraestructura interna como externa. Estas pruebas consisten en revisar las aplicaciones en búsqueda de vulnerabilidades. Este proceso se realiza bajo diferentes fases tales como el diseño de amenazas de acuerdo al tipo de aplicación, la ejecución de las pruebas, el análisis de los resultados y posteriormente la entrega de los hallazgos encontrados junto con el análisis de impacto que puede generar cada vulnerabilidad.

Se realiza para:

• Identificar posibles amenazas y riesgos a nivel aplicación.
• Establecer umbrales y criterios de aceptación.
• Identificar vulnerabilidades y puntos de acceso a nivel infraestructura.
• Analizar impacto de no cumplimiento sobre el negocio.
• Implementar buenas prácticas para prevenir ataques.

¿Quiénes lo pueden realizar? La persona encargada de ejecutar pruebas de seguridad debe contar con conocimientos sobre programación, arquitecturas y redes.

En este informe nos centraremos en el análisis de los resultados provistos por la herramienta OWASP Zed Attack Proxy (ZAP).

¿Que es OWASP (Open Web Application Security Project)?

OWASP es un proyecto abierto de seguridad en aplicaciones Web. Es una comunidad abierta dedicada a habilitar a las organizaciones para desarrollar, comprar y mantener aplicaciones confiables. Todas la herramientas, documentos, foros y capítulos de OWASP son gratuitos y abiertos a cualquier interesado en mejorar la seguridad de aplicaciones.

¿Qué es el TOP 10 de OWASP?

Es un documento que especifica los diez riesgos de seguridad más importantes en aplicaciones web según esta organización. Esta lista se publica y actualiza cada 3 años. La lista al día de la fecha es la siguiente:

OWASP TOP 10 – 2017 RELEASE

A1 – Injection

A2 – Broken Authentication and Session Management

A3 – Cross-Site Scripting (XSS)

A4 – Broken Access Control

A5 – Security Misconfiguration

A6 – Sensitive Data Exposure

A7 – Insufficient Attack Protection

A8 – Cross-Site Request Forgery (CSRF)

A9 – Using Components with Known Vulnerabilities

A10 – Underprotected APIs

El enlace a la información completa se encuentra aquí.

¿Que es ZAP?

Esta es una herramienta utilizada para simular ataques a sitios web y encontrar vulnerabilidades que pueden ser utilizadas por atacantes externos, por lo tanto, es útil para hacer testing de seguridad en un sistema web.

Los siguientes esquemas muestran las principales características de ZAP:

Puesta en práctica

Se realizó un ejercicio haciendo uso de la herramienta ZAP (en el modo ataque por defecto), en el cual se ingresa una URL y la aplicación inicialmente adquiere la lista de posibles request que puede realizar (realizando un crawling automático a partir de la URL provista) para luego tratar generar ataques sobre las mismas que confirmen vulnerabilidades, como también verificar configuraciones correctas de los headers http según el contenido de los mismos y de su cuerpo.

La página que se utilizó como ejemplo es la del sitio de prueba http://opencart.abstracta.us/.

Las vulnerabilidades se dividirán según su riesgo y luego según su tipo.

RIESGO	VULNERABILIDAD
RIESGO GRAVE	XSS (Cross-Site Scripting) attacks Redirecciones Externas Inclusión Archivos Remotos
RIESGO MEDIO	Alteración de Parámetros
RIESGO BAJO	Cookies Header Tipo de Contenido Autocompletado Contraseña Inclusión Archivos JavaScript Protección XSS

Riesgo Grave: XSS (Cross-Site Scripting) attacks

ZAP encontró 12 instancias de una vulnerabilidad de Cross Site Scripting Tipo 2 o Reflected. Este tipo de vulnerabilidad permite a un atacante crear links con código malicioso embebido o crear un formulario malicioso el cual luego puede ser posteado al sitio real. Ambos casos tienen como fin por parte del atacante el robo de información ya sea cookies, cuentas, tarjetas, datos personales, entre otros. En el caso de robar cookies el atacante podrá impersonar al usuario real y en el caso del robo de información los usos son virtualmente ilimitados.

Para ejemplificar ZAP inserto un simple “alert(1);” dentro de varias solicitudes y dicho código no fue filtrado por el servidor y por lo tanto devuelto al usuario (ej.: http://opencart.abstracta.us/admin/index.php?route=%27%3Balert%281%29%3B%27).

Posibles Soluciones:

Este tipo de vulnerabilidades se puede solucionar de varias maneras, ya sea mediante el uso de frameworks o librerías que generen salida correctamente encodeada como Apache Wicket o Microsoft Anti-XSS, como también mediante la especificación del encoding de los caracteres de la página a mostrar al usuario. Otra forma de solucionar este problema es mediante el uso de una lista blanca de validación de inputs de entrada, de forma tal de evitar direcciones potencialmente maliciosas, o mejor aún, limpiar dichas entradas antes de enviarlas como respuesta.

Riesgo Grave: Redirecciones Externas

Se encontró una instancia de esta vulnerabilidad la cual es bastante simple. Es muy común en sitios embeber redireccionamiento dentro de las propias rutas, por ejemplo, indicando a dónde dirigirse cuando se finaliza correctamente una operación. En este caso se hace un redireccionamiento a “common/currency/currency”. Si bien esta redirección es correcta, la misma podría ser utilizada por un atacante para obtener acceso a alguna parte del sitio en la cual no debería tener acceso, como puede ser un área de administración interna o también incluir una redirección a un sitio malicioso creado por un atacante.

Para ejemplificar ZAP hace un llamado a la dirección http://opencart.abstracta.us/index.php?route=common/currency/currency e incluye en la solicitud “code=&redirect=7887900092566031091.owasp.org” esto genera que el sitio resultante responda con el header de ubicación 7887900092566031091.owasp.org lo cual es incorrecto y podría ser abusado por un atacante.

Posibles Soluciones:

Las soluciones a este problema son usar listas blancas de valores aceptados como entrada por parte del servidor, como también validaciones sobre composición, largo, sintaxis, etc., de los valores de entrada. Otra solución en caso de ser necesario redireccionar a sitios externos, es incluir una página previa que advierta al usuario que está a punto de ser redirigido a otro sitio y que tenga el cuidado necesario ya que no se tiene control de lo que suceda en dicho sitio externo.

Riesgo Grave: Inclusión Archivos Remotos

Se encontró una instancia de esta vulnerabilidad, la misma permite explotar la inclusión dinámica de archivos de forma tal de incluir archivos maliciosos con contenido que robe información del usuario. La inclusión de archivos es utilizada principalmente para separar código en diferentes archivos para luego ser referenciado por los módulos principales. Las vulnerabilidades de este tipo son posibles siempre y cuando las referencias a los módulos a cargar formen parte de la solicitud http. Las aplicaciones que utilizan PHP son particularmente vulnerables a este tipo de ataque (https://en.wikipedia.org/wiki/File_inclusion_vulnerability).

En este caso ZAP utilizó un request a la dirección http://opencart.abstracta.us/index.php?route=common/currency/currency con los parámetros “code=&redirect=http%3A%2F%2Fwww.google.com%2F”. Esto hizo que en la página resultante se incluya el código HTML de la página principal de google lo cual no debería ocurrir.

Posibles Soluciones:

Esta vulnerabilidad se puede solucionar de varias maneras, las más populares son utilizar un mapa clave valor el cual a partir de una clave dada se haga referencia a un archivo dado a incluir. De esta forma se evita incluir referencias maliciosas, ya que si la clave no se encuentra en el mapa entonces no se hace la inclusión de ningún archivo. Otra forma es incluir archivos, pero solamente aquellos que estén localmente en el servidor y no externos, por ejemplo, en PHP con “open basedir”. También es posible ejecutar el código del sitio en un ambiente sandbox de forma tal de limitar el acceso únicamente a ciertos archivos o la ejecución de una lista dada de comandos.

Riesgo Medio: Alteración de Parámetros

Se encontraron 38 instancias de este error, el cual consiste en enviar un valor no esperado en un parámetro de la URL, por ejemplo, un % o algún carácter especial, lo cual genera un error que se muestra por pantalla de forma incorrecta. Este error que se muestra por pantalla puede potencialmente contener información que puede ayudar al atacante, como parámetros, tablas en la base, directorios o cualquier otra información.

ZAP envió el siguiente request http://opencart.abstracta.us/admin/index.php?route=%00 y en la página de respuesta al principio de la misma se muestra “Warning: is_file() expects parameter 1 to be a valid path, string given in /opt/bitnami/apps/opencart/htdocs/system/engine/action.php on line 15”. En este caso se ve claramente en qué lugar del servidor están alojados los archivos del sitio, lo cual es una gran ayuda para el atacante ya que en este caso sabe que es una aplicación alojada en Bitnami, que corre sobre un Linux. Esto a priori puede no parecer útil, pero al no ser posible conocer todos los tipos de ataque, cuanta menos información privilegiada se divulgue al atacante, más seguro será el sitio.

Posibles Soluciones:

Estas vulnerabilidades se solucionan con captura de excepciones del lado del servidor. Una buena práctica es realizar validaciones del lado del servidor, sin importar que haya validaciones del lado del cliente. Esto es necesario porque lo que finalmente se envíe al servidor puede cambiar ya sea antes de ser enviado por el usuario, por un script malicioso o en tránsito por algún salto malicioso.

Riesgo Bajo: Cookies

Se encontraron 512 instancias de esta vulnerabilidad. Ésta indica que las cookies no se establecieron como exclusivos para HTTP, lo cual permite que las cookies sean accedidas por código JavaScript. Esto podría permitir a un atacante inyectar código malicioso y robar las cookies del usuario, como las cookies de sesión, y con eso luego impersonar al mismo.

Posibles Soluciones:

La solución a esta vulnerabilidad es establecer el flag HTTPOnly al establecer la cookie del usuario en el comando Set-Cookie del cabezal de la respuesta http.

Conclusiones

La primera conclusión y tal vez la más relevante, es que la seguridad de software es algo muy importante y que día a día aumenta el impacto de los riesgos que se generan a partir de las vulnerabilidades. Es por esto por lo que el uso de herramientas como ZAP se vuelven fundamentales, ya que no solo son útiles para poder detectar estas vulnerabilidades, sino que fue desarrollado por una comunidad de expertos en el área, lo cual incrementa la confianza que se puede tener en ella. Cabe destacar que OWASP es probablemente el grupo más importante y referencia en lo que se refiere a temas de seguridad en páginas web.

Otro aspecto importante es la capacidad de la herramienta de no solo detectar el problema, sino de sugerir soluciones al mismo en las diferentes etapas del ciclo de vida de la aplicación web, ya sea durante el diseño, desarrollo, arquitectura, etc.

Es importante también el hecho de que la herramienta puede ser utilizada sin ningún conocimiento formal de seguridad, simplemente se ingresa una URL y se da clic en el botón atacar. Luego para poder analizar los resultados sí es necesario interiorizarse en las formas en las cuales se puede dar un ataque explotando una vulnerabilidad dada. Para esto también se vuelve necesario tener conocimiento sobre protocolo http, headers http, JavaScript, HTML y las tecnologías asociadas al sitio web que se prueba, que pueda vulnerarse.

Otra cosa importante, es que la herramienta ZAP hace una simulación de ataque, pero a fin de cuentas es un ataque. Entonces, puede generar daños en los datos o su funcionalidad. Por esto se debe hacer en un ambiente de pruebas, o sino se debe configurar en “Safe mode”.

Analizando los resultados se puede ver que el sitio tiene varias vulnerabilidades, pero no hay que olvidar que el mismo es una página de pruebas y no un sitio real de producción. Sin embargo, de los tres errores graves encontrados uno es consecuencia del uso de PHP (inclusión de archivos remotos) y los otros dos pueden ser arreglados fácilmente, mediante el uso de listas blancas de caracteres admitidos en requests http. El resto de los errores encontrados son menores (autocompletado de contraseña, inclusión archivos JavaScript, etc.) salvo el de excepciones que se muestran en pantalla. Este último tipo de errores pueden parecer inofensivos, pero en ciertas instancias se puede mostrar información que puede ser útil para el atacante y su solución es muy simple como para correr el riesgo.

Por último, realizar este tipo de ejercicios son sumamente útiles para entender el mindset que debe tener un tester de seguridad, por más que el trabajo diario de uno no sea enfocado específicamente en esta área, creo que aporta muchísimo a la visión de un Quality Engineer.