----- Forwarded message from feedblas...@hcg.sld.cu -----
Date: Thu, 18 Jun 2015 23:01:08 -0400
From: feedblas...@hcg.sld.cu
To: laz...@hcg.sld.cu
Subject: Cajas rotas, arena derramada [Hispasec @unaaldia]
X-Mailer: feedblaster.rb - ruby 2.2.2p95 (2015-04-13 revision 50295)
[x86_64-linux]
Cajas rotas, arena derramada
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.
[apple-logo-2]
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.
[caja_arena_2]
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
[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
https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view [PDF]
David García
dgar...@hispasec.com
Twitter: @dgn1729
*
----- End forwarded message -----
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
