Recientemente, Zimperium escribió en su blog sobre la nueva vulnerabilidad de WhatsApp revelada por Facebook el 13 de mayo. Según los informes, esta vulnerabilidad se explotó en la naturaleza y se designó como CVE-2019-3568. Una publicación anterior de Zimperium proporcionó información preliminar sobre la vulnerabilidad, los productos de WhatsApp afectados, un supuesto exploit y cómo Zimperium podría ayudar con los riesgos y amenazas asociados con la vulnerabilidad.
Esta publicación es el resultado de una investigación adicional de zLabs y está diseñada para agregar detalles técnicos y mostrar una demostración PoC de lo que puede hacer una ejecución remota de código (RCE) en WhatsApp al explotar la vulnerabilidad.
Primero, una palabra de precaución:
En el informe de la vulnerabilidad y el parche, Facebook revelado que la vulnerabilidad era una ejecución remota de código (RCE) que afectaba a las versiones de iOS y Android del cliente de WhatsApp. No se mencionó la plataforma de destino y se entregó un parche a todas las versiones: (actualizaciones de Android frente a iOS)
Dado que los detalles técnicos de la vulnerabilidad no se informaron públicamente, y para ser consistente con los hechos, esta publicación de blog será de naturaleza educativa. Me centraré selectivamente en varios aspectos teóricos del parche que se lanzó.
Intentaré deducir alguna información sobre la vulnerabilidad general, sus características, lógica y, lo que es más importante, el posible efecto de un RCE en un cliente de WhatsApp que se ejecuta en un dispositivo iOS y lo que podría lograr un adversario que explote la vulnerabilidad.
Es importante tener en cuenta que este análisis es solo preliminar y que también se deberán revisar otros aspectos del parche para comprender completamente el impacto de la vulnerabilidad parcheada.
Habeas Corpus – Análisis de Parches
Dado que esta vulnerabilidad se corrigió en ambas plataformas, y debido al hecho de que el análisis de aplicaciones de iOS y las publicaciones de blog inversas son escasos, he elegido apuntar a la versión de iOS de la aplicación en este blog. Espero que se beneficie del proceso y que sea un uso educativo y bueno de su tiempo.
Repasaré la versión iOS del cliente de WhatsApp. Si desea seguir, asegúrese de tener las versiones 2.19.50 (sin parchear) y 2.19.51 (parcheada). Examinando ambas versiones (IDA y BinDiff o Ghidra), se obtienen varios cambios en lo que parecen ser las funciones de procesamiento de paquetes, de las cuales dos funciones son dominantes (0x100c236b4 y 0x100c25b78). Voy a repasar estas funciones una a la vez.
Primero, inspeccionaremos la función en 0x0100C236B4 (llamada aquí processBrustPackets). La función parece estar a cargo de procesar ATURDIR y otras ráfagas de paquetes como parte de la pila VoIP de WhatsApp. Estas son las principales funciones que se eliminaron en la versión parcheada:
En la línea 716, hay una verificación de tamaño en packageSize y _Asize, ambos controlados por la persona que llama.
Si el tamaño del paquete es mayor que 0x7A120, provocará un subdesbordamiento de enteros y se ignorará el siguiente bloque:
Lo que lleva a lo que parecen ser llamadas controladas por dos personas a memcpy (resaltado).
Este bloque de ejecución se eliminó en la versión parcheada actualizada:
A continuación se muestra una representación gráfica de llamada BinDiff de la función parcheada:
Hábeas Corpus – Segunda Parte
La siguiente función parcheada que llamó nuestra atención está en 0x0100C25B78, llamada handle_incoming_traffic. Aquí está la parte de la función que ha sido parcheada:
En la línea 60, se llama a memcpy en los argumentos de la persona que llama proporcionados, el tamaño no se verifica y esto podría generar una vulnerabilidad de desbordamiento del búfer.
En la versión parcheada, se introduce una verificación de tamaño para asegurarse de que el tamaño sea <= 0x5c8:
Esta verificación de tamaño también se agregó en la primera función que cubrimos anteriormente (anotada a continuación):
Para concluir la segunda parte, entendemos que otra posible vulnerabilidad de desbordamiento de memoria ha sido parcheada mediante la introducción de controles de tamaño en estas dos funciones.
Es interesante señalar que ambas funciones parcheadas juegan un papel clave en el procesamiento de la comunicación dentro de la aplicación WhatsApp, como se puede ver en el gráfico de llamadas:
En este punto, sabemos que la versión parcheada ha eliminado las posibles vulnerabilidades de desbordamiento de búfer y subdesbordamiento de enteros, que podrían haberse explotado en una ejecución remota de código controlada por la persona que llama en la aplicación WhatsApp. A continuación, necesitaremos validar que esta función sea, de hecho, parte de la funcionalidad de llamada de voz informada que supuestamente se usó en el ataque.
Picar al oso con un hacha (código)
Para validar que esta función se invoque durante una llamada de voz, use Xcode para conectarse a la aplicación vulnerable de WhatsApp que se ejecuta en un dispositivo con jailbreak:
Establezca un punto de interrupción en la dirección de la función (base de la imagen y ubicación de la función) o use el de Jonatan Levin. Jtool2 para crear un comando de punto de interrupción para xCode:
Como esto:
Ahora, inicie una llamada de voz a la cuenta y, como asumimos, llegamos al punto de interrupción:
Ahora, retrocedamos del resto del análisis dinámico y comprendamos lo que hemos aprendido hasta este punto.
Una pista falsa: no saltar a conclusiones
Hasta ahora, no ha habido publicaciones de la carga útil completa del exploit, ni ninguna revisión técnica del análisis del exploit. ¿Podría ser esto una pista falsa?
Sin sacar conclusiones precipitadas, hemos podido validar los siguientes aspectos:
- Laboratorio ciudadano reportado sobre la posible vulnerabilidad, junto con el tiempo financiero.
- WhatsApp parchó al menos una (posiblemente más) vulnerabilidades potenciales de corrupción de memoria en su cliente iOS.
- Estos parches se realizaron en al menos dos funciones que están vinculadas a la funcionalidad de llamadas de voz.
- No se necesitó la interacción del usuario para alcanzar nuestro punto de interrupción.
- Proyecto cero de Google incluyó este ataque como «sospechoso» de ser utilizado en la naturaleza para la ejecución remota de código.
- El sistema operativo iOS no fue parcheado debido a la divulgación de esta vulnerabilidad.
Existe la posibilidad de que el ataque real no haya tenido lugar. Es posible que, por alguna razón, esta vulnerabilidad haya sido alertada, solo para crear una persecución inútil y generar globos oculares. Esto explicaría por qué no se reveló la carga útil y no se hizo público ningún análisis hasta la fecha.
Por otra parte, si el ataque tuvo lugar y fue real, teniendo en cuenta todos los puntos anteriores, es seguro suponer que se creó una carga útil complicada para la aplicación del cliente de WhatsApp, que se activará sin la interacción del usuario, lo que resultará en capacidades de ejecución remota de código. dentro de WhatsApp.
Uno puede detenerse en cómo un RCE en WhatsApp podría beneficiar a un atacante. Por supuesto, WhatsApp tiene acceso al micrófono, la cámara, la ubicación y las fotos, lo que lo convierte en un objetivo muy rico en aspectos de privacidad. Sin embargo, acceder a todo ese contenido requerirá muchos obstáculos para saltar, incluida la omisión de PAC en dispositivos nuevos, Stack-Checks y otras mitigaciones que se introdujeron en iOS. Además, el atacante deberá lograr la persistencia en los reinicios. Tal esfuerzo probablemente sería muy ruidoso, agotando las baterías, reinicios anormales, llamadas de voz de números desconocidos.
Si alguna entidad hiciera todo el esfuerzo de revertir, pivotar y parchear, crear cargas útiles, depurar y probar hasta llegar al resultado de una ejecución remota de código, tendría que establecer primitivas de lectura/escritura/ejecución, usar fugas de información y cálculos de tiempo de ejecución para tener éxito en su viaje.
Probablemente no lo arriesgarían todo, solo para ser revelados por el objetivo; por lo tanto, solo podíamos imaginar que para un ataque perfecto, se podrían haber atacado otros aspectos de WhatsApp.
¿Podría haber alguna forma rápida y efectiva de lograr la persistencia? ¿Alguna ruta que usaría las capacidades de ejecución de comandos en la lógica de la aplicación que sería lo más silenciosa posible, pero daría ventaja al adversario, sobreviviría a los reinicios y ofrecería monitoreo remoto de la actividad de la cuenta de WhatsApp objetivo?
Nuevamente, como no se informaron datos oficiales, con respecto al mecanismo práctico de explotación, nos dejamos con nuestras propias conjeturas.
Mi suposición, una que encajaría perfectamente con esa descripción, es explotar la función «WhatsApp Web».
WhatsApp Web: un trofeo para el adversario
WhatsApp tiene una función popular de cliente web, llamada «WhatsApp Web». Permite a los usuarios conectarse a su cuenta de WhatsApp desde cualquier parte del mundo utilizando un navegador simple, enviar y recibir mensajes, crear nuevos grupos, revisar mensajes antiguos y mucho más, como si estuvieran trabajando desde su dispositivo.
Para establecer esta funcionalidad de inicio de sesión remoto, el usuario debe seguir los sencillos pasos de navegar hasta https://web.whatsapp.com a partir de una computadora y escaneando un desafío generado por un código QR con su aplicación WhatsApp.
Una vez que se ha escaneado el desafío, el navegador se autentica:
De ahora en adelante, el cliente del navegador remoto puede leer cada mensaje, enviar mensajes y actuar como si estuviera conectado a la aplicación, en el dispositivo:
Ahora, aquí hay un hecho para que se detenga: en los dispositivos Android, el usuario recibe una notificación para cada cuenta conectada, como la siguiente:
Sin embargo, en iOS, el cliente de WhatsApp tiene menos visibilidad (hasta ahora). Si una sesión web remota está activa o si alguien ha secuestrado la sesión de WhatsApp, no se le solicitará ninguna notificación en iOS. Si desea ver si alguien está al acecho en su cuenta, deberá ir a Configuración:
Web de whatsap:
Y luego, se le presentará una lista de navegadores conectados:
No se proporciona IP u otros identificadores en iOS; solo el agente de usuario del navegador.
Por lo tanto, si su cuenta es secuestrada de forma remota, en iOS no recibirá notificaciones.
Ah, y hay más. WhatsApp Web puede ser persistente indefinidamente, siempre que el usuario tenga conectividad. Incluso si el objetivo reinicia su dispositivo.
Suena como un objetivo perfecto para usar, si tiene una vulnerabilidad RCE en WhatsApp.
Basta de hablar – Tiempo de demostración
Al invertir el proceso de autorización, descubrí que se puede usar un dispositivo para autorizar silenciosamente una sesión web remota al invocar una función en el dispositivo de destino:
-[WASettingsViewController qrCodeScannerViewController:didFinishWithCode: ]
Esta función se encarga de autenticar el reto presentado en una nueva sesión web. Si se ejecuta esta llamada, puede autorizar una conexión de sesión remota a la cuenta actual de WhatsApp.
Esto se puede simular con un trazador de líneas en Xcode:
- Abra la web de WhatsApp navegando a https://web.whatsapp.com
- Copie el desafío QR-Code y decodifíquelo en una cadena
- En Xcode, pausa WhatsApp y pega el siguiente comando:
(lldb) po [[WASettingsViewController new] qrCodeScannerViewController:[WAWebClientQRCodeScannerViewController new] terminó con el código:@”PUT_TARGET_TOKEN_HERE” ]
- Felicidades, acabas de secuestrar silenciosamente la cuenta de destino.
Aquí hay un video que demuestra cómo un atacante con capacidades de ejecución remota de código (simulado aquí como una simple sesión de depuración) en la aplicación WhatsApp puede usarlo para ejecutar CUALQUIER código en la aplicación cliente. En este caso, secuestrando la sesión de WhatsApp del cliente, sin ninguna notificación:
Conclusiones
Ya sea que el ataque haya tenido lugar como se sugirió, ya sea que se haya dirigido a Android o iOS, todavía nos faltan algunos datos. Dicho esto, espero que este blog le haya brindado un buen ejemplo de cómo observar un posible vector de ataque de iOS y comprender sus características y limitaciones, así como una mejor comprensión de cómo las vulnerabilidades de seguridad de las aplicaciones (como RCE) pueden explotarse en un dispositivo iOS actualizado para proporcionar capacidades de acecho sin afectar el estado del dispositivo y dejando poco o ningún rastro.
Relacionado:
