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.
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!
No comments:
Post a Comment