Unintended Data Leakage

Unintended Data Leakage:

Seguimos enganchados a las aplicaciones móviles en este descanso universitario! En esta ocasión, realizamos los tres retos de la máquina virtual de OWASP SHEPERD, consisten en encontrar logs con información sensible en nuestro dispositivo Android.

A continuación, os dejo unas diapositivas explicando un poco la materia por encima:

Retos de la máquina virtual:

LEVIATHAN

Nueva entrada en la sección Wargames de OverTheWire. Resolvemos todos los retos del subapartado Leviathan. No son retos muy complicados, pero si que implican leer un poco en google, para ver como gestionar los diferentes problemas que nos vamos encontrando.

Podéis disfrutar de los retos en este enlace:

Leviathan Walkthroughts

Un saludo, hasta la próxima!

REVERSE ENGINEERING 1

Uno de los principales peligros de las aplicaciones móviles es el llamado reverse engineering. Fácilmente, y mediante una serie de aplicaciones, podemos adivinar código, api keys, encription keys, usernames, contraseñas etc..

Los desarrolladores,  usan ProGuard para ofuscar el código y viene por defecto con Android SDK, aunque sea una fabulosa herramienta, no asegura que el código carezca de vulnerabilidades. Otra manera de ofuscar el código es hacerlo difícil de leer y más confuso a la vista del atacante.

Para este reto necesitaremos la instalación de dos aplicaciones, para hacer  el llamado reverse engineering a una APK. Estas son Dex2jar y JDGUI.

Con la primera de ellas, la llamada dex2jar, convertiremos el APK en un fichero java (jar). Posteriormente lo abriremos con JD-GUI y trataremos de buscar las vulnerabilidades o cualquier pista de código que nos facilite acabar el reto.

Tenemos que investigar sobre el código y sacar la key

1.Conectamos por adb:
logan@loganayala:~$ adb connect 192.168.1.46
connected to 192.168.1.46:5555

2.Pasamos el fichero a nuestro ordenador:
logan@loganayala:~$ adb pull /sdcard/com.mobshep.reverseengineer-1.apk /home/logan
/sdcard/com.mobshep.reverseengineer-1.apk: 1 file pulled. 11.3 MB/s (2010243 bytes in 0.169s)

3.Convertimos el fichero en .jar con Dex2Jar:
logan@loganayala:~/MobilePentesting/Retos/ReverseEngineer/dex2jar-2.0$ sudo sh d2j-dex2jar.sh -f /home/logan/MobilePentesting/Retos/ReverseEngineer/1/reverseengineer-1.apk
dex2jar /home/logan/MobilePentesting/Retos/ReverseEngineer/1/reverseengineer-1.apk -> ./reverseengineer-1-dex2jar.jar

4.Una vez tenemos el .jar, lo abrimos con JD-GUI:
logan@loganayala:~/MobilePentesting/Retos/ReverseEngineer/jd-gui/build/libs$ java -jar jd-gui-1.6.6.jar

Por último vemos que en la clase Reverse_Engineering.class, tenemos el secret string con la clave DrumaDrumaDrumBoomBoom.

INSECURE DATA STORAGE 1

Insecure data storage ocurre cuando la aplicación guarda información sensible, como pueden ser user credentials, passwords, API keys etc.. de manera insegura. Normalmente las aplicaciones móviles usan una  base de datosSQLIte.

En Android las aplicaciones guardan su base de datos en el directorio:
/data/data/com.app.exampleApp/database/, cualquiera que tenga acceso root accederia sin problemas.

Para empezar con este reto, primero convendría sabernos manejar con la consola de comandos de adb (android debug bridge), ya que nos facilitará mucho la existencia.

Este reto lo realizaremos de dos maneras, una accediendo en modo debug y la otra mucho más clara conectando por adb. Empezamos accediendo desde el modo debug de inicio de la VM Android.

Primero, entramos en modo debug, escapamos a shell con exit y nos dirigimos al directorio de la aplicación:

En la tabla Members sacamos el pass que nos piden:

AdminBattery777
User: Admin
Password: Battery777

Esta manera de realizarlo es un poco engorroso, ya que la shell a veces se queda parada o imprime los carácteres por pantalla de manera defectuosa, por lo tanto ahora lo haremos mediante adb.

En primer lugar, localizamos nuestra máquina virtual, y conectamos a ella mediante:
adb connect 192.168.1.44

Una vez hemos conectado, abrimos shell para empezar a interactuar con el dispositivo android:
adb shell

Muy importante comprobar con que usuario estamos logueados.. En este caso vemos que estamos logueados como shell que será un usuario con pocos privilegios, por lo tanto escalamos con el comando su:
su root

Una vez como root navegamos hasta el directorio donde estan almacenadas las claves y con el comando cat las imprimimos por pantalla.

A continuación,  les dejo un video con toda la secuencia de comandos :D, espero que les guste, nos vemos en el próximo reto!

XML INJECTION

Hola a todos!, en esta ocasión os presento otra nueva inyección llamada XML Injection o XML Tag Injection.

Para introducirnos en el mundo XML realizaremos una breve introducción para aquellos que desconozcan esta lenguaje de estructura de datos “Extensible Markup Language”.
Hay muchos campos que aprovechan XML, estos incluyen PDF, RSS, OOXML, SVG y también protocolos de redes como pueden ser XMLRPC, SOAP, WEBDAV etc..
Este lenguaje es muy parecido al HTML pero con una implementación mucho más ligera.

EL Document Type Definition (DTD) define la utilización correcta de los bloques en un documento XML. Estos bloques son los siguientes:
*Elementos *Etiquetas *Atributos *Entidades *PCDATA *CDATA

Una cosa muy importante al proceder con los ataques XML, es que el DTD lo podemos definir tanto externamente como internamente, eso quiere decir que tenemos la opción de importar externamente el DTD si internamente no es posible y asi bypassear según que tipo de protecciones.
Después de esta breve introducción os dejo los primeros ejemplos, espero que sean de vuestro agrado 😀

Ejemplos: XML Injection

WEBDAV -Apache DAV-

Nueva entrada en Hacking Web Technologies, en la sección de PROOF OF CONCEPTS. En esta ocasión vulneramos un servidor WEBDAV concretamente el Apache DAV y logramos el acceso remoto a la computadora :D.

Aquí tenéis la guía de explotación: APACHE DAV -PWNED-

SALUDOS!

CSRF -Resumen-

Hola a todos, después de haber realizado todos los ejercicios del CourseWork de HackerOne, iremos haciendo un breve resumen de las vulnerabilidades encontradas y de como facilitar la localización y explotación.

CSRF

En estos ataques, el atacante crea un código HTML que obliga al navegador del usuario a realizar una acción directa a la aplicación vulnerable, pudiendo ser agregar, eliminar usuarios, autenticarse con otro usuario, cambiar opciones en la aplicación vulnerable, etc..

Para identificar una aplicación vulnerable a CSRF lo primero que debemos tener en cuenta es que el 90% de las aplicaciones que simplemente tienen HTTP cookies para trackear las sesiones pueden ser vulnerables.

Normalmente, para realizar un ataque CSRF hay que tener en cuenta que:

  • En primer lugar, fijarse en la petición y si a través de esta se puede realizar una acción con supuestos privilegios.
  • En segundo lugar y de los más a tener en cuenta es si la aplicación solamente sigue las sesiones con HTTP cookies y si no existen tokens adicionales de protección.
  • En tercer lugar, si mediante la petición se pueden observar todos los parámetros necesarios para realizar el ataque.

Si se cumplen los tres requisitos anteriormente mencionados, significa que tenemos vía libre para construir nuestro código HTML y vulnerar la aplicación.

Ya solamente nos faltaría crear el código HTML y modificar los parámetros. Yo utilizo la herramiente en BurpSuite que esta en Engagement Tools que se llama Generate CSRF POC. Esta herramienta te crea el código HTML y luego simplemente tenemos que pasarlo a nuestro editor de textos y modificar los parámetros que queramos, para luego ejecutar la petición.

PERO… no todo es de color de rosa..

Hoy en día, existen pocas aplicaciones web que no utilizan tokens adicionales anti-CSRF, envíados por hidden fields mediante HTML forms. Cabe la posibilidad que el atacante no sepa el camino para determinar el valor del token y por este motivo no podría ejecutar el ataque satisfactoriamente.

Cuando nos encontramos ante este tipo de situaciones, tenemos las mismas opciones de bypass que con los tokens de sesión normales:

  • En primer lugar, si un atacante puede predecir los valores de los tokens que son enviados a otros usuarios, puede determinar todos los parámetros requeridos para un ataque CSRF.
  • En segundo lugar, si los tokens anti-CSRF no están vinculados a la sesión del usuario al que se emitieron, un atacante puede obtener un token válido en su sesión y utilizarlo en un ataque CSRF, en una sesión de un usuario diferente.

A continuación os dejo un video de ejemplo:

Hasta la próxima 😀