Recientemente, los investigadores de CheckPoint encontraron una falla en la forma en que las aplicaciones de Android usan recursos de almacenamiento. El uso descuidado del almacenamiento externo por las aplicaciones puede abrir la puerta a un ataque que da como resultado una cantidad de resultados no deseados, como la instalación silenciosa de aplicaciones no solicitadas y potencialmente maliciosas en el teléfono del usuario, denegación de servicio para aplicaciones legítimas e incluso causar aplicaciones a fallar, abriendo la puerta a una posible inyección de código que luego se ejecutaría en el contexto privilegiado de la aplicación atacada.
Estos ataques Man-in-the-Disk se hacen posibles cuando las aplicaciones son descuidadas con respecto al uso de almacenamiento externo, un recurso que se comparte en todas las aplicaciones y no disfruta de la protección incorporada de Sandbox. Al no utilizar las precauciones de seguridad por sí solos, las aplicaciones son vulnerables a los riesgos de manipulación de datos malintencionados.
¿Qué es almacenamiento externo?
Para explicar la deficiencia de seguridad en el diseño de Android, debemos entender un poco sobre los recursos de almacenamiento en un dispositivo Android.
Dentro del sistema operativo Android hay dos tipos de almacenamiento: almacenamiento interno, que cada aplicación usa por separado y está segregado por Android Sandbox y almacenamiento externo, a menudo sobre una tarjeta SD o una partición lógica dentro del almacenamiento del dispositivo, que es compartida por todos aplicaciones. De hecho, el almacenamiento externo se usa principalmente para compartir archivos entre aplicaciones o con una PC. Por ejemplo, para que una aplicación de mensajería comparta una foto de la galería del teléfono, la aplicación necesita tener acceso a los archivos multimedia almacenados en el Almacenamiento externo.
Sin embargo, existen otras razones por las que un desarrollador de aplicaciones elegiría usar almacenamiento externo en lugar de uno interno de espacio aislado. Tales razones van desde una falta de capacidad suficiente en el almacenamiento interno, consideraciones de compatibilidad hacia atrás con dispositivos más antiguos, no querer que la aplicación parezca usar demasiado espacio, o incluso simplemente la mera holgazanería del desarrollador.
Cualquiera que sea el motivo, cuando se utiliza el almacenamiento externo, se requieren ciertas precauciones.
De acuerdo con la documentación de Android de Google, a los desarrolladores de aplicaciones se les aconseja cómo deben usar el almacenamiento externo en sus aplicaciones. Estas pautas incluyen:
- "Realice la validación de entrada al manejar datos del almacenamiento externo"
- "No almacene archivos ejecutables o de clase en almacenamiento externo"
- "Los archivos de almacenamiento externo deben estar firmados y verificados criptográficamente antes de la carga dinámica"
Sin embargo, hemos visto algunos ejemplos donde las aplicaciones de Android, incluidas las aplicaciones de OEM conocidos e incluso Google, no siguen estas pautas. Y aquí se establece la superficie de ataque Man-in-the-Disk, que ofrece la oportunidad de atacar cualquier aplicación que descuidadamente contiene datos en el almacenamiento externo.
El ataque de Men in the Disk
La nueva superficie de ataque encontrada por los investigadores de Check Point, apodada 'Man-in-the-Disk', permite que un atacante ingrese e inmiscuya los datos almacenados en el Almacenamiento Externo.
A través del análisis de investigación, han sido testigos de casos en que una aplicación se descargó, actualizó o recibió datos del servidor del proveedor de la aplicación, que pasó a través del almacenamiento externo antes de enviarse a la aplicación, como se ve en el diagrama. Tal práctica ofrece una oportunidad para que un adversario manipule los datos almacenados en el almacenamiento externo antes de que la aplicación lo vuelva a leer.
Inmiscuirse con los datos ocurre usando una aplicación aparentemente inocente, ejemplo: una aplicación de linterna falsa, dentro de la cual se encuentra el script de explotación del atacante. El atacante persuade al usuario para que descargue esta aplicación de aspecto inocente, que a su vez solicita permiso al usuario para acceder al almacenamiento externo, algo que es perfectamente normal para las aplicaciones que lo soliciten, y es poco probable que despierte sospechas en nombre del usuario. A partir de ese punto, el atacante puede monitorear los datos transferidos entre cualquier otra aplicación en el dispositivo del usuario y el almacenamiento externo, y sobrescribirlo con sus propios datos de manera oportuna, lo que lleva al comportamiento no deseado de la aplicación atacada.
De esta forma, el atacante tiene su 'Hombre en el Disco' buscando maneras de interceptar el tráfico y la información requerida por las otras aplicaciones existentes del usuario, y ofrece una derivada cuidadosamente elaborada de los datos que conducirían a resultados perjudiciales
Los resultados de los ataques pueden variar, dependiendo del deseo y la experiencia del atacante. Nuestra investigación demostró la capacidad de instalar una aplicación no deseada en segundo plano, sin el permiso del usuario. También hemos demostrado la capacidad de bloquear la aplicación atacada, lo que provoca una denegación de servicio. Una vez bloqueado y con las defensas de la aplicación desactivadas, el atacante podría realizar una inyección de código para secuestrar los permisos concedidos a la aplicación atacada y escalar sus propios privilegios para acceder a otras partes del dispositivo del usuario, como la cámara, el micrófono, lista de contactos, etc.
Protegiendo contra 'El hombre'
Si bien está claro que estas deficiencias de diseño dejan a los usuarios de Android potencialmente vulnerables a las amenazas cibernéticas, lo que está menos claro es quién es realmente el culpable y dónde radica la responsabilidad de solucionarlos. Por un lado, aunque los desarrolladores de Android han creado pautas para los desarrolladores de aplicaciones sobre cómo garantizar que sus aplicaciones sean seguras, también deben ser conscientes de que es bien sabido que los desarrolladores no crean sus aplicaciones con la seguridad en mente. Por otro lado, y estando al tanto de este conocimiento anticipado, ¿podría haber más Android para proteger su sistema operativo y los dispositivos que lo usan?
Uno podría equiparar lo que estamos viendo aquí en el mundo de los sistemas operativos móviles con el diseño ingenuo de los viejos sistemas operativos, que solían permitir que los desbordamientos de los búfers se volvieran locos. Si bien las vulnerabilidades de desbordamiento de búfer fueron generadas por desarrolladores descuidados en todas partes, no fue hasta que los fabricantes de sistemas operativos y CPU se opusieron a esto, introduciendo las protecciones DEP y ASLR, que el problema fue evitado. En el corazón de esto, se dio cuenta de que no siempre se puede confiar en que los desarrolladores sigan las pautas de seguridad.
Por experiencia, parece que las simples directrices no son suficientes para que los vendedores de sistemas operativos se exoneren de toda responsabilidad por lo que diseñan los desarrolladores de aplicaciones. En cambio, asegurar el sistema operativo subyacente es la única solución a largo plazo para proteger contra esta nueva superficie de ataque descubierta por nuestra investigación.
Fuente: CheckPoint
