Análisis de múltiples vulnerabilidades en AirDroid

Reportado por: simone margaritelli
Investigador de seguridad en Zimperium zLabs

Editar: 11:02 a. m. PDT: código POC de explotación agregado debajo de la línea de tiempo de divulgación.
Edición 2: 06:01 p. m. PDT: cronograma editado para reflejar las fechas de lanzamiento de 4.0.0 y 4.0.1 y confirmar que ambas versiones aún son vulnerables.
Edit3: 12 de diciembre de 2016, 10:41 a. m. PDT: línea de tiempo editada para reflejar las pruebas de seguridad en 4.0.2 y 4.0.3. la versión 4.0.3 es más segura de usar y recomendamos actualizar su aplicación AirDroid.

Antecedentes
AirDroid es una popular herramienta de administración remota para Android. Tiene una base de usuarios estimada de más de 50 millones de dispositivos según Google Play Store.
Nuestra investigación destaca cómo los canales de comunicación inseguros hacen que millones de usuarios sean vulnerables a los ataques Man-in-the-Middle (MITM), la fuga de información y el secuestro remoto de APK de actualización, lo que lleva a la ejecución remota de código por parte de una parte malintencionada. El atacante explota las funcionalidades integradas de la aplicación y las usa contra sus usuarios.

Productos afectados

Criptografía de bricolaje y canales de comunicación inseguros

Video de Youtube

Resumen
AirDroid se basa en canales de comunicación inseguros para enviar los mismos datos utilizados para autenticar el dispositivo a su servidor de estadísticas. Dichas solicitudes se cifran con DES (modo ECB), sin embargo, la clave de cifrado está codificada dentro de la propia aplicación (lo que un atacante conoce). Cualquier parte malintencionada en la misma red del dispositivo de destino podría ejecutar un ataque man in the middle para obtener credenciales de autenticación y hacerse pasar por el usuario para futuras solicitudes.

Impacto
Una parte maliciosa podría realizar un ataque de red MITM y obtener la información de autenticación del dispositivo como se muestra en la sección «Detalles» desde la primera solicitud HTTP que realiza la aplicación.
Esta solicitud HTTP se puede descifrar en tiempo de ejecución utilizando el 890jklms clave codificada dentro de la aplicación y los campos de autenticación analizados a partir del JSON resultante.
Con esta información, el atacante ahora puede hacerse pasar por el dispositivo de la víctima y realizar varias solicitudes HTTP o HTTPS en su nombre a los puntos finales de la API de AirDroid.
Por ejemplo, una carga útil como la siguiente (encriptada en DES con la misma clave exacta) se puede enviar al https://id4.airdroid.com/p14//user/getuserinfoviadeviceid.html punto final:

Foto 1

El servidor responderá con la información del usuario, incluido su correo electrónico y hash de contraseña:

foto2

Este es el registro de salida de nuestro módulo proxy POC bettercap:

foto3

Además, un atacante que realice un ataque MITM y redireccione el tráfico HTTP a un proxy transparente malicioso podría modificar la respuesta para el /teléfono/vncupgrade solicitud que normalmente utiliza la aplicación para buscar actualizaciones de complementos:

OBTENER /p14/teléfono/vncupgrade/?q=[DES ENCRYPTED PAYLOAD]&ver=20151 HTTP/1.1
Anfitrión: srv3.airdroid.com
Conexión: cerrar
Agente de usuario: Apache-HttpClient/NO DISPONIBLE (java 1.4)

Inyectando una nueva actualización, ejecutando así de forma remota código personalizado en el dispositivo de destinoes solo cuestión de modificar esta respuesta:

imagen4-apng

A algo como lo siguiente:

foto4b

AirDroid notificará al usuario sobre una actualización disponible, descargará el paquete RCE.apk y eventualmente solicitará al usuario su instalación en el dispositivo de destino.

Detalles
AirDroid se basa en puntos finales API HTTPS seguros para la mayoría de sus funcionalidades, pero durante nuestro análisis descubrimos que se utilizan otros canales inseguros para tareas específicas. Por ejemplo, la aplicación envía estadísticas a http://stat3.airdroid.com como podemos ver en el com.sand.airdroid.configs.urls.ReleaseUrls clase:

foto5a

Cuando se usa este punto final, la aplicación se basa en cargas JSON cifradas con DES para agregar una capa mínima de seguridad. Puedes ver en el com.sand.common.Jsonable El objeto se usa como clase base para cada carga JSON que se envía al servidor de estadísticas:

foto5b

Una vez el buildParamQ se ejecuta en la carga útil, toda la solicitud HTTP se verá así:

OBTENER /teléfono/abrir/?q=[HEX ENCODED DES ENCRYPTED PAYLOAD]&ver=20151 HTTP/1.1
Anfitrión: stat3.airdroid.com
Conexión: cerrar
Agente de usuario: Apache-HttpClient/NO DISPONIBLE (java 1.4)

Desafortunadamente, siendo la clave utilizada para el cifrado DES codificada dentro del APK, puede ver en el com.sand.common.DesCrypto clase:
foto6

A pesar de su nombre, el sandDecrypt El método invierte esos números y los decodifica hexadecimalmente, devolviendo la clave de cifrado final: 890jklms

Una vez descifrado, la carga útil se envía al servidor de estadísticas. Tal carga útil se ve así:

foto7

Él ID de la cuenta, androidid, Identificación del dispositivo, imei, imsi, clave_logica y Identificación única Los campos se utilizan para cualquier otra solicitud de API, en HTTP o HTTPS, para autenticar el dispositivo e identificarlo de forma única.

Mitigaciones

  • Use solo canales de comunicación seguros (HTTPS)
  • Verifique la clave pública remota (key pinning) para evitar SSL MITM.
  • Para un cifrado adicional, utilice mecanismos seguros de intercambio de claves como Diffie-Hellman en lugar de claves de cifrado codificadas dentro de la aplicación.
  • Aproveche y verifique las firmas digitales para actualizar los archivos.

Recomendaciones

  • Use una solución de protección contra amenazas móviles como Zimperium zips para prevenir de forma proactiva los ataques de manipulación de la red y proporcionar análisis forenses para comprender el impacto potencial en el dispositivo de los empleados.
  • Desinstale o deshabilite AirDroid hasta que haya una solución disponible.

Cronograma de divulgación

  • 24 de mayo de 2016: correo electrónico de divulgación inicial enviado.
  • 30 de mayo de 2016: Acuse de recibo del proveedor.
  • 10 de agosto de 2016: Seguimiento.
  • 17 de agosto de 2016: Seguimiento.
  • 22 de agosto de 2016: Seguimiento.
  • 28 de agosto de 2016: Seguimiento.
  • 06 de septiembre de 2016: Seguimiento.
  • 07 de septiembre de 2016: Obtuve una respuesta sobre el próximo lanzamiento.
  • 28 de noviembre de 2016: lanzamiento de AirDroid 4.0.0, aún vulnerable.
  • 30 de noviembre: lanzamiento de AirDroid 4.0.1, aún vulnerable.
  • 1 de diciembre de 2016: Divulgación completa
  • 6 de diciembre de 2016: AirDroid 4.0.2 probado, usa SSL pero no aplica la fijación de certificados.
  • 12 de diciembre de 2016: AirDroid 4.0.3 probado: usa SSL pero no aplica la fijación de certificados. ¡El problema principal de actualización RCE descrito anteriormente ahora está solucionado!

Explotar POC
Descargue los últimos módulos de Bettercap de github (https://github.com/evilsocket/bettercap-proxy-modules).
POC de fuga de información de AirDroid:
sudo bettercap -T TARGET_IP –proxy-module airdroid_info.rb –no-sslstrip
AirDroid RCE POC:
sudo bettercap -T TARGET_IP –proxy-module airdroid_rce.rb –no-sslstrip –httpd
Para que el módulo RCE funcione correctamente, coloque los archivos «update.apk» y «changelog.html» en el directorio de trabajo actual.

Por:simone margaritelli
Zimperium zLabs

Reportado por: simone margaritelli
Investigador de seguridad en Zimperium zLabs

Deja un comentario