Un grupo de investigadores
de varias universidades estadounidenses y chinas, ha
publicado un interesante estudio en el que muestran los resultados de las
pruebas a las que han sometido el modelo de aislamiento de procesos de Apple.
Los resultados son cuanto menos inquietantes,
no solo por el hecho de la demostración en la que pudieron acceder al llavero del sistema y llevarse un buen botín,
sino que fueron capaces de evadir el
estricto proceso de aprobación de la App Store, publicando una aplicación
que era capaz de romper el aislamiento entre aplicaciones y acceder, o abusar
del acceso, a recursos privilegiados.
El modelo de seguridad basado en "sandbox" no es nuevo ni exclusivo
de Apple, obviamente. Desde hace ya bastante tiempo se intuyó la necesidad de
separar, más aun, los procesos, incluso aquellos que compartían privilegios y
propietario. De esta forma se protegen de manera más granular los recursos
propios de cada aplicación. El sistema, pensado en principio para limitar
programas en etapas experimentales que pudieran desestabilizar el sistema,
servía también para contener y aislar el impacto de un proceso malicioso,
impidiendo o dificultando su "onda
expansiva".
Existen múltiples aproximaciones y diferentes
implementaciones del modelo de sandboxing ("¿Cajarenización?"). Android, por ejemplo, asigna un UID de
usuario distinto a cada aplicación y corre esa aplicación bajo ese usuario. Un
uso curioso, quizás perverso en cuanto a costumbres, del modelo de permisos
basado en usuario de Unix donde es habitual que ciertos procesos tengan usuario
propio, pero solo unos pocos. Los recursos compartidos del sistema, esos que
requieren permisos del usuario al instalar la aplicación, se administran a
través de grupos. Toda aplicación o librería por encima del kernel Linux de un
sistema Android corre bajo esta premisa. El componente que permite el
sandboxing de procesos corre en espacio del kernel, por lo que muchas técnicas
de evasión pasan por explotar una debilidad o vulnerabilidad en dicho espacio. No
podemos evitar mencionar la utilidad de esta clase de arquitectura en el
análisis dinámico de malware, apoyado en la virtualización de sistemas
completos, dotando al analista de una herramienta sin par cuando necesita
evaluar un conjunto de muestras de manera masiva.
En esta ocasión, no solo ha sido la evasión
de este modelo en los sistemas operativos, cada vez más convergentes, de Apple.
Ya de por sí, el hecho de que una aplicación consiga acceder a los recursos de
otra aplicación resulta grave, ver esa aplicación publicada en el App Store es
un hecho que deshace el componente diferenciador de Apple respecto a los
mercados de aplicaciones. El control de aquello que se publica. Esa es la
confianza que deposita el usuario cuando se decide a descargar e instalar una
aplicación.
En palabras de los
propios investigadores:
"Our research leads to the discovery of a series of high-impact security weaknesses, which enable a sandboxed malicious app, approved by the Apple Stores, to gain unauthorized access to other apps’ sensitive data"
y más adelante:
"Note that all our attack
apps were uploaded to
the Apple App Stores"
Han demostrado que es posible
subir una aplicación a la App Store capaz de acceder a recursos para la cual no
estaba autorizada. Recursos que no deberían ser compartidos entre la aplicación
gestora y el resto.
Bien, ya tenemos una
aplicación maliciosa en el sistema ¿Cómo lo hace?
No se trata de explotación de
vulnerabilidades al estilo de desbordamientos o punteros caídos en desgracia.
Son fallos de diseño, de un diseño quizás excesivamente despreocupado, quizás
por la presencia de componentes de seguridad como la sandbox. Creer que el sistema
va a asumir el rol de guardaespaldas de todos los procesos es una temeridad. Es
como desarrollar una aplicación en C pretendiendo que un hipotético sistema
antiexploits cubra el riesgo de una gestión de memoria deficiente.
Acceso a los ítem de otra aplicación del llavero del sistema
El llavero del sistema, aunque no
forma parte estrictamente de la sandbox, se comporta de manera similar, incluso
desde el punto de vista de las aplicaciones la gestión de los recursos allí
almacenados es parecida. En principio el llavero del sistema solo da acceso a
las entradas guardadas por una misma aplicación, sin embargo es posible, cuando
se crea una entrada, agregar otras aplicaciones al estilo de una lista de
control de acceso.
Si una entrada en concreto no
está creada cuando la aplicación legítima solicita su uso se consulta su
existencia y si no existe se procede a su creación. El ataque se basa en la
posibilidad de crear esta entrada por una aplicación maliciosa ANTES de que
esta sea creada por la legítima. Cuando la aplicación maliciosa crea la entrada
agrega a la legítima a la lista de aplicaciones autorizadas para acceder a ese
llavero. Posteriormente, si el usuario instala dicha aplicación legítima, su
entrada ya habrá sido creada adrede. Cuando se introduzca, por ejemplo, una
contraseña, esa entrada seguirá siendo propiedad de la aplicación maliciosa y
podrá acceder al contenido para robarla. La aplicación legítima seguirá
creyendo que la entrada es suya, debido a que el sistema le permite el acceso
al haber sido agregada por la maliciosa. Ingenioso.
BID conflictivos
Las aplicaciones en un Mac se
presentan en un paquete de aspecto homogéneo pero en realidad son carpetas que
contienen una jerarquía de archivos con sus recursos, ejecutables y
bibliotecas. Cuando se genera una aplicación se asigna un identificador
denominado BID. Este identificador ha de ser único a ojos de la App Store para
que la aplicación sea aprobada, requisito, uno de muchos, indispensable.
Este BID también lo poseen los
recursos integrados y portados por la aplicación, por ejemplo, ciertos
ejecutables o conjunto de bibliotecas (denominados "frameworks" en Mac) necesarios para la aplicación principal,
este tipo de recursos se denominan ‘sub-targets’.
Como dijimos, Apple inspecciona
el BID de la aplicación principal, pero no efectúa esta comprobación en los
mencionados 'sub-targets'. Esto
permite a un atacante asignar el BID de un 'sub-target'
de otra aplicación sin que esta incongruencia sea detectada. Cuando la
aplicación maliciosa es ejecutada gana acceso a los recursos de la aplicación
legítima. Por ejemplo, los investigadores ganaron acceso a los recursos de
programas como Evernote, WeChat, QQ, etc.
Secuestro de WebSockets locales
Otro ataque que se basa en el
esquema de pillería lazarillesca. Determinadas aplicaciones poseen un esquema
cliente-servidor usando WebSockets a modo de comunicación IPC, desde una
extensión en el navegador web a un servidor local ejecutado por la aplicación.
En las pruebas realizadas sobre
la aplicación 1Password (gestor de contraseñas con integración en el
navegador), pudieron constatar que no se efectúa una identificación del
servidor a la escucha, la extensión de 1Password del navegador creía estar
hablando con su contraparte en el sistema.
El resultado fue que todas las
contraseñas se enviaban a una aplicación maliciosa que se encontraba a la
escucha. Es decir, si se consigue ejecutar antes la aplicación maliciosa, esta
se anticipa tomando el control del puerto acordado entre extensión-servidor. No
hay forma de que la extensión compruebe si el servidor a la escucha es o no
legítimo. No se trata de un fallo exclusivo de 1Password, el ataque es
extensible a toda aplicación que use un esquema similar.
Secuestro de esquemas URL
Como sabemos, ciertas
aplicaciones registran un 'handler' o
esquema URL para facilitar la gestión de ciertos tipos de recursos. Así por
ejemplo, si en el sistema, el esquema 'ftp://'
está registrado por una determinada aplicación, cuando abramos una URL el
sistema ejecutará la aplicación responsable de gestionar ese recurso y le
pasará la URL.
En este caso _y visto lo visto_
el ataque se basa de nuevo en la anticipación en la toma de un recurso, en este
caso las pruebas se hicieron registrando el esquema URL "wunderlist://" con el objeto de ser
gestionado por una aplicación maliciosa. Wunderlist es una aplicación para la
gestión de listas de tareas.
Cuando el usuario se autentifica
es redirigido a través de una URL del tipo "wunderlist://". El problema es que esta URL contendrá un token
secreto con la sesión del usuario, susceptible de ser interceptado para
secuestrar la sesión activa del usuario.
Este mismo ataque es extensivo a
aplicaciones como Pinterest o Facebook, las cuales usan un concepto similar de
integración en el sistema.
XARA
Con el propósito de determinar qué
tipos de aplicaciones contienen esquemas de funcionamiento similares a los
descritos, los investigadores crearon una serie de herramientas para señalar
aquellas que podrían ser objeto de alguno de estos ataques. El resultado fue
demoledor: De 1.612 aplicaciones, el 88.6% es vulnerable a alguno de los
ataques de este tipo.
El conjunto de ataques es denominado por los investigadores como XARA. (Unauthorized
Cross-App Resource Access). En el
documento publicado detallan las contramedidas y una propuesta de
mitigación para solucionar posibles abusos mientras el fabricante toma medidas
para paliar estas debilidades
Cajas rotas, arena derramada
Como hemos podido comprobar, no
se trata de vulnerabilidades o fallos de programación. Son fallos de diseño, debilidades, excesos de confianza y la temible
falsa sensación de seguridad. El hecho de que tu aplicación se ejecute en
un entorno protegido, aislado o confinado no significa que un vecino listo no
sepa arreglárselas para saltar la valla y fisgonear en tus dominios.
Programación defensiva y pesimista. En desarrollo cobra valor la máxima: Si algo puede salir mal, no va a salir mal,
probablemente saldrá bastante peor de lo que imaginas.
Más información:
Unauthorized Cross-App Resource Access on Mac
OS X and iOS
David García
