Introducción al pentesting de aplicaciones móviles sin morir en el intento. Parte II
.jpg)
Hace algunos artículos os hicimos una primera introducción al pentesting de aplicaciones móviles en donde asentábamos las primeras bases entre lo que es un análisis estático de la aplicación y un análisis dinámico. Hoy os hablaremos sobre las actividades exportables:
La clase Activity es fundamental para una App de Android, como los paradigmas de programación en los que los programas se ejecutan con el método main(), el sistema Android se inicia en una instancia de Activity.
Una actividad básicamente proporciona la ventana en la que las Apps dibujan su IU, la existencia de las actividades nos permite realizar varias acciones dentro de la misma ventana, ya que una actividad puede invocar otras para mostrarnos diferentes pantallas. Es el punto de entrada de una aplicación, son las pantallas visibles con las que interactúa el usuario.
Una actividad exportable en aplicaciones de Android es aquella que puede ser accedida por otras aplicaciones, similar a una clase pública en Java. Para identificar si una actividad es exportable, se pueden considerar los siguientes casos:
- Una actividad exportable tiene asignado el atributo Android:exported= “true” en el fichero AndroidManifest.xml
- Cuando este atributo no está definido, pero tiene existe <intent-filter>, el valor de Android:exported es true por defecto.
Una configuración deficiente de estas actividades, sin protección adecuada, podría ser una entrada muy favorable para los atacantes. Esto les permitiría obtener información sensible o incluso ejecutar ataques como XSS.
Usaremos la aplicación InsecureBankv2 como ejemplo. Si entramos a la aplicación, nos encontraremos con la ventana principal de la aplicación, una ventana de login donde nos pide un usuario y una contraseña para autenticarnos. Ahora bien, como atacantes, queremos evadir esta actividad de login, de la cual no conocemos las credenciales.
Podemos usar Drozer para sacar vulnerabilidades o configuraciones inadecuadas de la aplicación:
Una vista previa de la superficie de ataque usando Drozer:
Run app.package.attacksurface com.android.insecurebankv2
Podemos observar que hay una actividad muy interesante PostLogin, además no se necesita ningún permiso para invocar esta actividad.
Por otra parte, aunque es más tedioso, también podemos hacer la búsqueda de forma manual, revisar en AndroidManifest.xml para encontrar actividades exportables.
Con jadx se puede abrir la APK y en AndoridManifest.xml podemos encontrar la actividad exportable PostLogin:
Una vez que tengamos identificado la actividad que nos interesa, usaremos adb para exportar la dicha actividad:
‘abd -s 172.16.20.175 shell’
Efectivamente, hemos conseguido hacer el bypass del Login. Ya estamos dentro de la aplicación bancaria, desde la cual podríamos hacer transferencias, cambiar la contraseña, ver estado de cuenta, etc.
Por otro lado, podemos observar que la aplicación tiene antiroot configurado. Este mecanismo de seguridad implementado por el desarrollador es una buena práctica para complicar los ataques de reversing, en próximos capítulos hablaremos más acerca de ello y como evadir este tipo de mecanismos de seguridad.
Lo que debería realizar un desarrollador para corregir esta vulnerabilidad seria cambiar el valor de este atributo para de esta forma deshabilitar el permiso. En este caso vamos a hacerlo nosotros para comprobar si realmente corrige el acceso a esta última actividad (PostLogin) como debería.
A continuación, procedemos a decompilar la aplicación con apktool, y modificar el atributo exported.
Descompilamos el APK:
Apktool d app.release.apk -o insecureBank-apktool
Una vez que tengamos la APK decompilada, procedemos a modificar el AndroidManifest.xml (exported=”false”):
Después de modificar la aplicación, tenemos que compilarla:
Apktool b insecureBank-apktool –o insecureBank.apk
Para poder instalar la aplicación es necesario firmar la aplicación, en este caso lo haremos mediante un certificado auto firmado (este certificado no está aceptado en los market de aplicaciones), pero para este ejemplo nos vale.
Generamos certificado:
keytool -genkey -v -keystore my-release-key.keystore -alias insecureBank-no-gpu -keyalg RSA -keysize 2048 -validity 10000
Firmamos la apk con el certificado anterior:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore insecureBank.apk insecureBank-no-gpu
Instalamos la nueva aplicación en el dispositivo (desinstalando previamente la versión anterior).
De nuevo usaremos Drozer para detectar actividades vulnerables, se puede observar que ya no está exportada la actividad PostLogin.
Sudo docker run –net host –it withsecurelabs/drozer console connect –server 172.16.20.75
Para comprobar si realmente hemos mitigado esta vulnerabilidad vamos a probar invocar la actividad con adb.
Se puede observar que con el atributo exported= “false” ya no podemos acceder a la actividad PostLogin.
Adb –s 172.16.20.75:43139 shell
Sin embargo, en el resultado mostrado por Drozer se puede ver más actividades vulnerables, por ejemplo, la actividad DoTransfer.
Procedemos a lanzar la dicha actividad, y vemos que, aunque ya no tengamos acceso a la actividad PostLogin, seguimos teniendo acceso a la actividad DoTransfer, ya que cada actividad en Android se gestiona de forma independiente, por lo tanto, a la hora de mitigar esta vulnerabilidad hay que tenerla en cuenta en todas las actividades.
Esta última actividad nos lleva al panel de transferencias desde la cual podremos emitir una transferencia en nombre de otro usuario (si lo hubiera).
Por otra parte, vamos a provechar las actividades exportables para atacar el componente WebView.
WebView es un componente de Android que permite a los desarrolladore presente contenidos de web dentro de la aplicación, algo así como un navegador web embebido dentro de la app.
Si la actividad cuenta con Webview y JavaScript habilitado, podríamos aprovechar esto para ejecutar un XSS sobre esa misma actividad:
Teniendo en cuenta esto, podemos invocar esta actividad pasándole una url vulnerable a ataques XSS.
Am start –n com.tmh.vulnwebview/.SupportWebView –es support_url http://172.16.20.110:8080
Se puede observar en la siguiente imagen el resultado de la ejecución del XSS sobre la app:
Con esto comprobamos de que se puede replicar los mismos ataques de una página web en una aplicación con WebView.
Os recomendamos las siguientes aplicaciones vulnerables con las que podrás practicar los que acabáis de aprender:
Esperamos que os haya gustado esta segunda parte introductoria sobre pentesting de aplicaciones móviles sin morir en el intento. Si tenéis alguna duda, siempre podéis volver a repasar la primera parte.
Xuquiang Liu Xu, Pentester Jr. at Zerolynx y Alejandro Auñón, Offensive Security Analyst at Zerolynx.
Powered by WPeMatico
