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.
Como todo sistema, como todo producto que lleve la consigna de la seguridad va a ser objeto de revisión por parte de la comunidad. La evasión de sandboxes no es noticia. En cada edición de Pwn2Ownpodemos ver como caen sistemáticamente las sandbox de los navegadores, la de Android ha sido desencajada varias veces a través de múltiples tipos de vulnerabilidades. Pon una puerta acorazada con una cerradura de última tecnología y cuando te des la vuelta tendrás a un señor en camiseta negra con un PowerPoint explicándote como la abrió de manera trivial. Nada nuevo bajo el sol.
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
Twitter: @dgn1729
Este comentario ha sido eliminado por un administrador del blog.