Aprendizaje Basado en Retos de Hacking: 2º Reto

Desde que llevo dando clases en el Ciclo de Grado Superior de Administración de Sistemas Informáticos en Red (ASIR) en Salesianos de Villamuriel (PALENCIA), siempre intento, de manera transversal, introducir conceptos de Seguridad Informática, incluso en asignaturas como Física y Química de 4º de ESO, donde de vez en cuando hablo a mis chic@s de las CONs en las que participo, las cosas que contaré allí, de lo chulo de la programación con placas Microbit, etcétera.

Figura 1: Aprendizaje Basado en Retos de Hacking: 2º Reto

Es cierto que en curso 2010-2011 se introdujo el módulo de Seguridad y Alta Disponibilidad en 2º curso, pero los contenidos a nivel curricular no se han modificado desde la aparición del ciclo: Real Decreto 1629/2009, de 30 de octubre.

Figura 2: Fecha del Real Decreto donde se establecen los contenidos del título
de Técnico Superior en Administración de Sistemas Informáticos en Red.

Son contenidos propuestos antes de la existencia del iPhone 4, 24 de junio del año 2010. Considero importante que los chicos sepan qué herramientas, entornos, etc… se usan en entornos reales relacionados con los test de intrusión, fortificación de sistema y perimetral… además de fijar conceptos importantes relacionados con Redes, Bases de Datos, Programación Web, Sistemas Operativos, Programación, Servicios de Red….

La base a nivel conceptual es importante, saber por qué las cosas funcionan o no funcionan, entender por qué dos máquinas se pueden comunicar entre sí utilizando un cable de red… son cosas que considero fundamentales.

Figura 3: Libro de Hacking Web Technologies en 0xWord de los autores:
Amador Aparicio, Chema Alonso, Pablo González, Enrique Rando y Ricardo Martín.

Es por ello que me gusta de vez en cuando, trimestre por trimestre, plantear un “Reto Hacker” a mis chicos. Me ayuda a despertar el interés en ellos, detectar actitudes y pasión por la tecnología, ver quiénes echan horas de verdad sólo por el hecho de aprender, detectar habilidades en ellos que de otra forma sería más difícil y hacer una presentación pública de los resultados para que el resto también aprenda.

RETO HACKER DEL TRIMESTRE 2

El reto de este trimestre está relacionado son la explotación de Vulnerabilidades en Aplicativos Web. Algunas de las técnicas necesarias se encuentran recogidas en libros como el de Hacking Web Technologies que escribimos entre Chema Alonso, Pablo González, Enrique Rando, Ricardo Martín y yo mismo. El enunciado es el siguiente:

Figura 4: Enunciado del Reto hacker 2 de Amador Aparicio

Dado que el objetivo  es una máquina virtual, no se aceptarán como válidas aquellas soluciones como el acceso directo al disco de la máquina virtual en busca de la bandera. Tampoco se admitirán soluciones en las que se haya alterado el arranque de la máquina. Se considerarán válidas únicamente soluciones que utilicen los servicios TCP/UDP que el servidor exponga.

Autor: Amador Aparicio (@amadapa), escritor de libro "Hacking Web Technologies", CSE (Chief Security Envoy) de ElevenPaths. Puedes contactar con Amador Aparicio a través de su buzón público en MyPublicInbox.

Figura 5: Contactar con Amador Aparicio

Publicada OWASP Top Ten 2017 Release Candidate 1

El proyecto OWASP (Open Web Application Security Project) nació hace más de una década y desde entonces se ha dedicado a trabajar en la mejora de la seguridad de las aplicaciones web (y más tarde en las apps móviles que al final usan backends web). Entre las iniciativas que empujan la principal es la de la formación de los desarrolladores y expertos en seguridad, mediante conferencias, documentación y generación de herramientas que sirvan para auditar y mejorar la seguridad de las apps.

Figura 1: OWASP Top 10 - 2017 RC1
"The Ten Most Critical Web Application Security Risks"

Dentro de estas iniciativas, una de ellas es el proyecto OWASP TOP TEN, donde se recogen los 10 riesgos de seguridad más importantes en el mundo de la seguridad web. En él se enumeran de 1 a 10 en orden de importancia, cuales son los riesgos más críticos que un proyecto web debe atacar.

Figura 2: OWASP TOP TEN 2017 RC1

La nueva versión de la lista de OWASP TOP TEN ha sido publicada recientemente. Es la versión 2017 RC1 (aún está en proceso de debate y es susceptible de poder ser cambiada en algo). El documento completo de la guía lo he subido a SlideShare para verlo en este artículo y lo tenéis en la web del proyecto.

OWASP TOP TEN 2017 RC1

Los ataques de Inyección, donde se encuentran los de SQL Injetcion, LDAP Injection, XPath Injection, Command Injection, en todas sus variedades, es decir, Blind, Time-Based, In-band, Out-band, etcétera, siguen siendo los más importantes. Nada nuevo bajo el sol y en los libros de SQL Injection y Hacking Web Technologies los tratamos extensamente debido a su importancia.

Figura 3: A1 - Injection

En segundo lugar están los ataques que se producen por una mala gestión de la autenticación o de la gestión de las sesiones. Desde sesiones que no caducan que se envían por GET y quedan indexadas en buscadores y proxies, hasta zonas de la aplicación donde no se comprueba correctamente la autenticación de la sesión. Aquí son conocidos los ataques de Session Fixation, Pass-the-hash, Session Hijacking, etcétera.

Figura 4: A2 - Broken Authentication & Session Management

En tercer lugar, los populares Ataques de XSS que aún siguen apareciendo constantemente. Por GET, por POST, en formato HTML Injection donde hay que ingeniarse más la ejecución de comandos para saltarse los filtros Anti-XSS o las protecciones CORS, y donde también hay que poner los ataques de Cross-Site SWF Scripting.

Figura 5: A3 - Cross-Site Scripting (XSS)

En el número 4 está el Broken Access Control, o lo que es lo mismo, zonas de la aplicación que no están correctamente protegidas y usuarios no autenticados pueden acceder a ella y hacer cosas que no deberían. Yo os dejé un ejemplo de cómo pasé una tarde jugando con un panel de administración que tenía este tipo de fallo... allá por el año 2011. En el mundo del Big Data, son muchos los ejemplos que os he contado en los Big Security Tales.

Figura 6: A4 - Broken Access Control

En el quinto puesto, Fallos de la configuración de seguridad. Desde errores en los mensajes de error, hasta fallos en la configuración del servidor web. Ejemplos de estos hay muchos, desde el Multiple Choices de Apache, hasta el IIS Shortname de Microsoft, pasando por los errores no controlados de los frameworks o las configuraciones inseguras de paneles de administración.

Figura 7: A5 - Security Misconfiguration

El sexto es para la exposición de datos sensibles. Es decir, para entornos en los que los datos personales, datos médicos, etcétera, no están correctamente protegidos en las apps. Estos datos deben estar protegidos de una forma especial, con un cifrado mayor, con acceso más restringido utilizando segundos factores de autenticación o verificación robusta de accesos mediante sistemas de autenticación fuerte de las personas que acceden a ellos.

Figura 8: A6 - Sensitive Data Exposure

En la séptima posición tenemos "Protecciones frente a ataques insuficientes" donde se habla de la carencia de mecanismos de seguridad en las áreas de Prevención (con sistemas WAF, Anti-DDOS, sin auditoría/pentesting periódico o persistente), de Detección de ataques (sin sistemas de logs, SIEM, IDS, etc..) y de Respuesta (sin sistemas de respaldo, backups, cifrado de datos sensibles en la base de datos de forma robusta, etc...). Muy a tener en cuenta si tu aplicación es core para tu negocio.

Figura 9: A7 - Insufficient Attack Protection

En la posición 8 un viejo conocido. Fallos de Cross-Site Request Forgery. Aún es fácil localizar aplicaciones web sin ninguna protección anti-CSRF en sus enlaces internos. Así nos encontramos con que los APTs tienen un fuerte impacto en las grandes organizaciones con ataques de Spear-Phishing.

Figura 10: A8 - Cross-Site Request Forgery (CSRF)

En la posición novena se encuentra el Uso de componentes con vulnerabilidades conocidas. Esto es algo que hemos visto hasta en grandes compañías como Apple, que utilizaban para iTunes librerías con vulnerabilidades conocidas.

Figura 11: A9 - Using Components with Known Vulnerabilites

Y por último, en la posición décima, una novedad pero que lleva años explotándose. APIs mal protegidas. Esto es algo que hemos visto muchas veces. En las apps móviles, utilizando Tacyt nosotros localizamos gran cantidad de backends con APIs totalmente expuestas, como os dejé en los artículos de Dorking with Tacyt o en el artículo de localización de los backends con WebServices.

Figura 12: A10 - Underprotected APIs

La última versión que hubo de este proyecto fue en el año 2013, y si miramos la lista de diez riesgos en aquella versión y la nueva, podemos ver que no hay tantos cambios.

Figura 13: Comparación de riesgos entre OWASP TOP TEN 213 y 2017

Como se ve, los riesgos A7 - Insufficient Attack Protection y A10 - Underprotected APIs son nuevas en esa versión. Además, dos riesgos en la versión de 2013 se han juntado en una única nueva categoría, así que la mayoría sigue estando presente.

Saludos Malignos!

Cómo NO debes publicar y retirar una app de Google Play

Con tanto ajetreo de viajes casi no he tenido tiempo de sentarme un rato a disfrutar del placer de la tecnología durante las últimas dos semanas. Cada momento lo he llevado cronometrado, tanto que he tenido que quitarle tiempo a las horas de sueño y descanso. Una vez acabado mi periplo por latinoamérica, me queda aún conseguir adaptar mi cuerpo a los horarios de sueño de la franja horaria de España por lo que hoy he estado en pie desde las 5 de la mañana y me he puesto a leer un rato los RSS, contestar algunos de los cientos de correos electrónicos que tengo sin procesar y, cuando me he aburrido, he ido a probar alguna cosa que tenía en mente con los servidores LDAP y las apps de Android.

Figura 1: Cómo NO debes publicar y retirar una app de Google Play

Como sabéis, desde hace años me gusta jugar con las técnicas de LDAP Injection y quería buscar algún ejemplo con un tipo concreto de servidor LDAP para probar unas cosas. Para ello, haciendo uso de Dorking & Pentesting con Tacyt, me busqué algún backend que pudiera estar construido en LDAP y que tuviera alguna aplicación para consultarlo.

Figura 2: Buscando apps en Android con links a LDAP

Como se ve aparecen 14 apps, pero una de ellas me llamó especialmente la atención. Se trata de una app que tenía el backend de acceso a los servidores LDAP construido con WebServices, tal y como ya publicamos en un artículo anterior. 

Figura 3: Enlaces a un backend LDAP accedido vía WebServices

Por desgracia, la app parecía que había sido retirada de Google Play hacía algún tiempo, así que lo más probable es que no estuviera ya disponible el backend. Es lo que se debe hacer cuando se retira una app del mercado.

Figura 4: La app estaba retirada de Google Play

Sin embargo, al probar se puede alcanzar la información de los WebServices aún activados, así que si tenía un poco de suerte tal vez toda la infraestructura detrás de la app también estaría funcionando.

Figura 5: El backend aún activo

Al mirar WebsService concreto para obtener información de los usuarios se puede comprobar que necesitamos unas credenciales de acceso. Por supuesto se puede intentar hacer un ataque de LDAP Injection en el acceso, pero en esta ocasión lo que hace la aplicación es utilizar el usuario y contraseña para hacer un Bind contra el árbol LDAP y luego genera el LDAP Search Filter con el resto de los parámetros XML, con lo que se necesita un usuario y password sí o sí para poder hacer la consulta al árbol.

Figura 6: Petición SOAP al WebService para hacer un LDAP Search Filter al árbol LDAP

Por supuesto, aunque la app está retirada, nosotros tenemos copia en Tacyt, así que me la descargué, la descomprimí, la decompilé y llegué al fichero donde la app - ya retirada del market - tenía configurado el usuario y contraseña para hacer Binding en el árbol LDAP. No deberías poner tus passwords en tus apps.

Figura 7: Código de construcción de llamada al WebService en la app con datos de árbol LDAP

El resto es sencillo. La petición SOAP va por POST, así que basta con abrir una herramienta como Burp y usando el Repeater hacer la petición al WebService para consultar al árbol LDAP.

Figura 8: Construcción de petición SOAP en Repeater de Burp

Figura 9: Respuesta del WebService con la salida del LDAP Search Fileter

El resto ya es probar los LDAP Search Filters y comprobar si la aplicación web es o no vulnerable a LDAP Injection, que tal y como se puede ver es así ya que podemos incluir parámetros en la consulta para hacer las pruebas que quería hacer.

Figura 10: Respuesta de error forzada con filtro LDAP inyectado

Recapitulando, en un solo ejemplo nos hemos topado con una app publicada en el market que tiene los siguientes errores de publicación y retiro de la app:

1) Tiene los WebServices del Backend expuestos a Internet.
2) Son vulnerables a LDAP Injection por medio de la llamada SOAP.
3) Publicó la app con las credenciales hardcodeadas.
4) Retiró la app y no retiró el servicio de backend.
4) Retiró la app y no cambió las credenciales.

Nunca se debe hardcodear una credencial, pero especialmente si retiras la app deberías retirar todo y cambiar las contraseñas que utilizaste.

Saludos Malignos!