News

Android 4.3 y SELinux

Hace apenas algunas semanas Google publicó una nueva revisión de su abanderado sistema operativo móvil, Android 4.3. Aunque algunos dicen que esta vez las actualizaciones escasearon bastante, desde la perspectiva de la seguridad cibernética se han visto innegables mejoras, como es el caso de la vulnerabilidad “MasterKey”, que finalmente se reparó. Una de las mejoras más significativas es SELinux. Muchos saludaron este paso tan esperado, mientras que otros lo criticaron. En mi opinión, el impacto no es fácil de evaluar, especialmente en lo que se refiere a los beneficios para los usuarios. Para aclarar un poco el panorama analizaremos un poco más SELinux y su modelo de amenaza.



Android JellyBean 4.3 logo

Comencemos por lo básico: la seguridad de los sistemas Linux descansa en el concepto del control de acceso discrecional (DAC, por sus siglas en inglés), lo que significa que cada usuario decide a cuáles de sus propios archivos pueden acceder otros usuarios (lectura, escritura, o ejecución). El sistema está protegido contra alteraciones ya que todos los archivos del sistema pertenecen al usuario administrador conocido como ‘raíz’ (root).

Androide se fundamenta en los mismos conceptos, con una pequeña pero persuasiva adición: a cada aplicación se le asigna una ID de usuario diferente (aunque pueden darse algunas excepciones), por lo que los datos de la aplicación quedan aislados y protegidos de cualquier otra aplicación. Es por esta razón que en dispositivos que no tienen un usuario raíz resulta difícil, sino imposible, que una aplicación legítima robe los datos confidenciales utilizados por otra aplicación (salvo, obviamente, que la configuración de esos datos permita su acceso público para lectura).

DCA significa que el acceso al archivo y a los recursos está definido por el usuario y los modos archivo/directorio.

SELinux se basa en eso (y en 15 años de investigación en seguridad del sistema operativo de NSA) e introduce otra capa de seguridad llamada Control de acceso obligatorio (MAC, por sus siglas en inglés). Esta capa, configurada por las amplias políticas del sistema, regula también la manera en que los usuarios (y por ende las aplicaciones en los dispositivos Android) acceden a sus datos y a los del sistema, siempre de forma transparente. En términos más técnicos, es posible diseñar políticas que sean capaces de especificar los tipos de interacciones que puede realizar o no un proceso configurado para ser parte de un contexto de seguridad. Un ejemplo sencillo pero eficaz es el caso de un system log daemon que se ejecuta con privilegios de raíz. Con SELinux podemos configurar todo el sistema de manera que el proceso no pueda acceder a nada salvo al archivo de registro: sólo hay que asignar una etiqueta específica al archivo de registro y escribir una política que permita al log daemon acceder sólo a aquellos archivos con dicha etiqueta (como siempre, tengamos en cuenta de que hay cosas un poco más complejas que esta 🙂 ). Observemos las dos ventajas que se desprenden de este esquema: (1) la política es algo que puede aplicarse a todo el sistema (incluyendo la raíz); (2) los permisos son mucho más específicos que los aplicados por el DAC.

La habilidad de limitar lo que el superusuario puede hacer (cualesquiera que sean sus privilegios), es esencial para proteger el sistema contra los ataques que se dan por falta de privilegios. En realidad es en esto en lo que sobresale SELinux. Tomemos el caso de Gingerbreak, un conocido exploit para obtener privilegios en los sistemas con Gingerbread. El exploit envía al volumen daemon (vold) un mensaje netlink cuidadosamente elaborado que se ejecuta como raíz. Gracias a la falta de algunas verificaciones de límites, el mensaje puede dar lugar a la inyección de códigos y su ejecución. Puesto que el proceso se ejecuta como raíz, es innecesario generar una consola con raíz setuid para controlar el dispositivo. SELinux detendría este exploit negando el mensaje mismo: la política por defecto (al menos en el paquete de parches original) niega la apertura de ese tipo de socket, por lo que el problema queda resuelto. Por si eso no fuese suficiente, otra política de SELinux también puede negar la ejecución de sistemas no binarios en ese proceso daemon.

FS sin etiqueta después de una actualización OTA.

¿No es asombroso? Por desgracia, la realidad es otra muy distinta. A la implementación de SELinux que actualmente se ejecuta en el stock de imágenes de Android 4.3 le faltan varias características importantes. En primer lugar, SELinux está configurado sólo en modo Permisivo, lo que significa que las políticas no se aplican, y las violaciones sólo quedan registradas (solo sirve para pruebas). En segundo lugar, como se mostró arriba, la actualización OTA no etiqueta correctamente la partición del sistema (mi dispositivo de pruebas me dejó muy confundido por un buen rato hasta que averigüé que el investigador Pau Oliva había publicado exactamente el mismo hallazgo en DEF CON 21), lo que significa que un desarrollador está obligado a restaurar el stock si quiere someterlo a pruebas. Finalmente, además del hecho de que las políticas provistas no son nada restrictivas, no existe un MAC para el middleware Android (una característica parte del paquete de parches

Android 4.3 y SELinux

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

 

Informes

MosaicRegressor: acechando en las sombras de UEFI

Encontramos una imagen de firmware de la UEFI infectada con un implante malicioso, es el objeto de esta investigación. Hasta donde sabemos, este es el segundo caso conocido en que se ha detectado un firmware malicioso de la UEFI usado por un actor de amenazas.

Dark Tequila Añejo

Dark Tequila es una compleja campaña maliciosa que tiene por objetivo a los usuarios ubicados en México, con el propósito principal de robar información financiera, así como credenciales de acceso a sitios populares que van desde versionado de código fuente a cuentas de almacenamiento de archivos en línea y de registro de dominios web.

De Shamoon a StoneDrill

A partir de noviembre de 2016, Kaspersky Lab observó una nueva ola de ataques de wipers dirigidos a múltiples objetivos en el Medio Oriente. El programa malicioso utilizado en los nuevos ataques era una variante del conocido Shamoon, un gusano que tenía como objetivo a Saudi Aramco y Rasgas en 2012.

Suscríbete a nuestros correos electrónicos semanales

Las investigaciones más recientes en tu bandeja de entrada