Los teléfonos inteligentes generalmente vienen con aplicaciones preinstaladas, algunas de las cuales son útiles y otras que nunca se usan en absoluto. Sin embargo, lo que un usuario no espera es que una aplicación preinstalada sea una responsabilidad real con respecto a su privacidad y seguridad.

Check Point Research descubrió recientemente una vulnerabilidad en una de las aplicaciones preinstaladas en uno de los proveedores de telefonía móvil más grandes del mundo, Xiaomi, que con casi el 8% de participación de mercado ocupa el tercer lugar en el mercado de teléfonos móviles. Irónicamente, fue la aplicación de seguridad preinstalada, «Guard Provider«, la que debería proteger el teléfono al detectar malware, lo que en realidad expone al usuario a un ataque.

Dicho brevemente, debido a la naturaleza no segura del tráfico de la red hacia y desde el proveedor de la Guardia, un actor de amenazas podría conectarse a la misma red Wi-Fi que la víctima y llevar a cabo un ataque Man-in-the-Middle (MiTM). Luego, como parte de una actualización del SDK de terceros, podría deshabilitar las protecciones de malware e inyectar cualquier código falso que elija para robar datos, implantar ransomware o rastrear o instalar cualquier otro tipo de malware.

Xiaomi ‘Guard Provider’ es una aplicación preinstalada en todos los teléfonos principales de Xiaomi que utiliza varios Kits de desarrollo de software (SDK) de terceros como parte del servicio de seguridad que ofrece, incluidos varios tipos de protección, compensación y mejora de dispositivos.

La aplicación incluye tres diferentes marcas de antivirus integradas que el usuario puede elegir para mantener su teléfono protegido: Avast, AVL y Tencent. Al seleccionar la aplicación, el usuario selecciona uno de estos proveedores como el motor antivirus predeterminado para escanear el dispositivo.

Antes de explicar el posible escenario de ataque, es importante señalar que en realidad existen algunas desventajas ocultas en el uso de varios SDK dentro de la misma aplicación. Debido a que todos comparten el contexto y los permisos de la aplicación, estas desventajas principales son que:

En el caso de Xiaomi Guard Provider, mostramos a continuación cómo un ataque de ejecución remota de código (RCE) es posible cuando se integran dos SDK con comportamiento problemático.

Dicho brevemente, debido a que el tráfico de la red del proveedor de la Guardia desde cualquier dispositivo Xiaomi no está protegido, esto permite que sea interceptado a través de un ataque Man-in-the-Middle (MiTM) e inyectar código fraudulento como parte de una actualización de SDK de terceros. Veamos el posible escenario de ataque.

De forma predeterminada, con Avast configurado como el escáner de seguridad de la aplicación, la aplicación actualiza periódicamente su base de datos de virus al descargar el archivo APK avast-android-vps-v4-release.apk en el directorio privado de Guard Provider: /data/data/com.miui. guardprovider / app_dex / vps_update_ <timestamp> .apk.

Avast SDK carga y ejecuta este archivo APK antes de la exploración del dispositivo y contiene la marca de tiempo cuando se descargó el archivo. Por ejemplo, vps_update_20190205-124933.apk.

Desafortunadamente, debido al hecho de que el mecanismo de actualización usa una conexión HTTP no segura para descargar este archivo, un actor de amenazas, a través de un ataque MiTM, puede detectar el momento de la actualización de Avast y predecir cuál será el siguiente nombre de archivo APK del disco. El atacante simplemente debe interceptar la parte de respuesta de la conexión http://au.ff.avast.sec.miui.com/android/avast-android-vps-v4-release.apk..

Por medio de la intercepción inicial, el atacante MITM puede evitar futuras actualizaciones de Avast respondiendo con un «error 404».

Una vez que el atacante comience a bloquear activamente las conexiones con el servidor Avast, el usuario cambiará el antivirus predeterminado a otro, en este escenario, AVL Anti-Virus. Recuerde, el antivirus SDK AVL también es una parte integrada de la aplicación Guard Provider.

Una vez que AVL se convierta en el antivirus predeterminado, actualizará inmediatamente la aplicación con su base de datos de virus. Para ello, verifica la existencia de nuevas firmas de virus solicitando un archivo de configuración

Después de procesar el archivo de configuración, AVL descarga el archivo de firmas indicado en el campo read_update_url y lo descomprime en el directorio Guard Provider. Resulta que el AVL SDK es vulnerable a otro problema de seguridad que ayuda al atacante a llevar a cabo la segunda etapa del ataque: un recorrido transversal durante el proceso de descompresión. Como resultado, el atacante puede usar un archivo creado para sobrescribir cualquier archivo en el recinto de seguridad de la aplicación, incluidos los archivos relacionados con otro SDK.

Por lo tanto, una APK diseñada, que se anexa como entrada en el archivo de firmas ZIP sobrescribiría con éxito la actualización descargada previamente de Avast, ya que ambos componentes antivirus SDK usan La misma caja de arena en sus respectivos SDK.

Todo lo que el atacante debe hacer ahora es liberar la comunicación de Avast y bloquear la comunicación de AVL hasta que el usuario elija nuevamente Avast como el antivirus activo. Cuando esto suceda, el Avast SDK cargará y ejecutará el archivo APK malicioso creado.

El ataque tuvo éxito porque el archivo de firma de la actualización Avast anterior no se verificó antes de cargarlo y Guard Provider ya lo verificó la primera vez que se descargó. Por lo tanto, asume que no hay razón para verificarlo nuevamente. De esta manera, el archivo malicioso creado se puede descargar y ejecutar, ya que esencialmente se ha escabullido por la espalda del guardia.

Es completamente comprensible que los usuarios confíen en las aplicaciones preinstaladas de los fabricantes de teléfonos inteligentes, especialmente cuando esas aplicaciones pretenden proteger el teléfono en sí. Esta vulnerabilidad descubierta en el «Proveedor de la Guardia» de Xiaomi, sin embargo, plantea la pregunta preocupante de quién está custodiando al tutor. Y aunque el tutor no debe necesariamente tener que protegerlo, claramente cuando se trata de cómo se desarrollan las aplicaciones, incluso las creadas por el proveedor de teléfonos inteligentes, no se puede ser demasiado cuidadoso.

El escenario de ataque anterior también ilustra los peligros de usar múltiples SDK en una aplicación. Si bien los errores menores en cada SDK individual a menudo pueden ser un problema independiente, cuando se implementan múltiples SDK dentro de la misma aplicación, es probable que aún más vulnerabilidades críticas no estén muy lejos.

Check Point SandBlast Mobile, si estuviera instalado en el dispositivo, detectaría y evitaría el ataque inicial de intermediarios, eliminando así la amenaza causada por esta vulnerabilidad en el proveedor de la Guardia de Xiaomi.