Un Exploit que permite escapar del Sandbox de safari con una sola línea de código

Hace escasos días un investigador descubrió un exploit con el que escapar del sandbox de Safari utilizando una sola línea de código, el exploit solo está disponible para algunas versiones del sistema operativo macOS y fue parcheado con la última actualización de Mojave, la versión más reciente del sistema operativo que se veía afectada por este problema es macOS High Sierra 10.13.6. Esto se debe a que a partir de esta versión es necesario utilizar otro exploit para Safari que nos permita obtener acceso a la ejecución de Shellcode.

De no ser así es necesario deshabilitar SIP para poder debuguear, adjuntar lldb a un com.apple.WebKit.WebContent.xpc en ejecución y utilice el siguiente comando:

"po CFPreferencesSetAppValue(@"Label", @"You know what should be put here",[(id)NSHomeDirectory() 
stringByAppendingPathComponent:@"Library/LaunchAgents/evil.plist"])"

Al introducir esa línea de código se generará generará un nuevo plist que con los argumentos adecuados puede lanzar una calculadora o cualquier elemento que se desee tras volverse a logar en el sistema. Esto no debería de suceder ya que se supone que la escritura de plist está bloqueada por la sandbox de Safari. El truco reside en las utilidades y preferencias de CoreFoundation para leer y guardar determinados plist en macOS ya que disponen de un argumento explícito para acceder a datos de otras aplicaciones.

El fallo consiste en que se toma por error el resultado de sandbox_check desde el principio, y después se sigue confiando en él durante toda la sesión. Cuando un proceso inicia por primera vez una conexión XPC con cfprefsd, el estado del sandbox se comprueba con la función sandbox_check. y el resultado se almacena en caché durante el resto de la sesión de XPC. Por lo tanto, es posible realizar nuevas operaciones CFPreference incluso después de que se haya bloqueado el sandbox. Por el momento se ha sabido que este bug afecta desde macOS El Capitan hasta macOS High Sierra (10.13.6) y a pesar de su importancia no ha recibido un código CVE.

Guía de seguridad en macOS (Parte 3)

Llegamos al final de nuestra serie de artículos sobre la seguridad en macOS con una entrada sobre las conexiones de red, el control de dispositivos hardware y la política de privacidad que impera en Apple. Con esto hemos tratado todas las aristas que componen la seguridad y fortificación del sistema operativo de Mac.

Guía de Seguridad en macOS (Parte 2)

En este segundo post continuamos detallando todos los elementos referentes a la seguridad de nuestro Mac. En el artículo anterior hablamos sobre la seguridad del núcleo del sistema, el almacenamiento de claves y credenciales y la autenticación mediante contraseñas o certificados digitales, en esta ocasión nos centraremos en cifrado y los mecanismos que se aplican para fortificar las aplicaciones de terceros instaladas en macOS.

Guía de seguridad en macOS (Parte 1)

Después de haber nombrado términos generales de ciberseguridad en la Guía de Seguridad para tu Secure Summer, vamos ahora a mostraros en los siguientes posts una guía general sobre toda la seguridad que concierne a macOS.

En esta guía profundizaremos en todas las areas implicadas en la securización del sistema operativo de nuestros Macs, desde la seguridad del sistema y redes, cifrado, autenticación y limitaciones de aplicaciones externas.

Estos artículos están divididos según las diversas areas antes mencionadas, dando una breve explicación sobre los elementos que conciernen a cada apartado.

macOS Mojave dificultará la instalación de malware en los dispositivos (o eso se espera)

Hace un par de lunes Apple anunció la nueva iteración de su sistema operativo de escritorio, macOS 10.14 Mojave, con una cantidad de mejoras dirigidas a la seguridad, estabilidad y funcionalidades de todos los dispositivos que reciban la actualización este otoño. Además de presentar un rediseño integro de su tienda de aplicaciones, un nuevo modo oscuro y novedades en finder, Apple mostró en el evento posterior a la Keynote principal nuevas medidas de seguridad que dificultarán aún más la instalación de malware en nuestros dispositivos.

Como ya se ha comentado en este blog, Gatekeeper fue presentado en OS X Moutain Lion para prevenir malware y apps dañadas descargadas desde internet. Desde su presentación han aparecido varios métodos para saltar sus comprobaciones, pero cada año Apple trae interesantes novedades para aumentar la seguridad de la herramienta. En esta edición no se han quedado atrás y han mostrado tres nuevas características que incorporará el nuevo sistema operativo macOS Mojave:

• Consentimiento de Usuario: Como ya venían haciendo discretamente en aplicaciones instaladas desde la Mac App Store, todas las aplicaciones que requieran el uso de algún recurso crítico del sistema deberán pedir el consentimiento previo del usuario. Algunos de estas autorizaciones se mostrarán para el uso de localización, fotos, contactos, mensajes, bases de datos de mail, etcétera.
• Protecciones en tiempo de ejecución: A partir de ahora añadirán SIP a las aplicaciones firmadas con el Apple ID, además aumentan las medidas de validación de código y protección ante inyección de código.
• Validación de aplicaciones: “Notarized apps” es una evolución a la firma de aplicaciones externas a través del Apple ID que ya existía y trae como objetivos detectar el malware rápidamente antes de ser distribuido a los usuarios y proveer de un método optimizado para revocar aplicaciones. 

Figura 1: WWDC y las mejoras en seguridad

Implementar la validación es importante ya que este método será obligatorio en un futuro para todas las aplicaciones firmadas con Apple ID. Para ello, es necesario seguir estos pasos: 

• Una vez desarrollada la aplicación, será necesario firmarla con el certificado de desarrollador de Apple ID.
• Antes de distribuirla, habrá que validar la aplicación a través del “Apple Notary Service” de Apple para que quede registrada en sus servidores. 
• Una vez notificada, la aplicación puede ser distribuido por el canal elegido por el desarrollador. 
• Cuando el usuario ejecute la aplicación, macOS Mojave determinará la validez y origen de la app comprobando la firma de la aplicación con la registrada en el servicio de validación.

Este proceso descrito no está sujeto a cumplir las guías internas de la Mac AppStore, solo busca aplicar una capa extra de seguridad a aplicaciones externas independientemente de su funcionamiento por lo que cualquier aplicación podrá incorporar este servicio independientemente de su funcionamiento. Poco a poco Gatekeeper se está convirtiendo en una herramienta esencial y robusta dentro de macOS, reflejando la voluntad de Apple de aumentar la seguridad de sus plataformas cada año.

Secure Kernel Extension Loading: La nueva caracterísitica de seguridad de High Sierra está rota (Parte II)

En el artículo anterior veíamos qué era el Secure Kernel Extension Loading de macOS High Sierra. Es una interesante característica de seguridad, pero qué, como veremos, ha tenido ya un bypass por parte de la gente de Objective-See. Según indican los investigadores de Objective-See, la actual implementación de SKEL no proporciona las suficientes garantías y los bad boys no tendrán ningún problema para evadirlo. Para ilustrarlo se puede hacer una prueba de concepto como ha hecho la gente de Objective-See. 

El objetivo de la prueba es cargar de forma programa un kext firmado y que nunca ha sido instalado o cargado en el sistema High Sierra. Este kext podría ser malicioso o vulnerable y permitir a un potencial atacante ejecutar código sin restricciones a través de dicha explotación. Por supuesto, ambos ataques derían ser bloqueados por SKEL. Este será un bypass trivial de SKEL. El primer intento es el más obvio, se puede intentar modificar la base de datos Kext Policy y 'pre-aprobar' los kexts que interesen. Para evitar esto, Apple protege la base de datos con la protección de integridad del sistema SIP. 

Figura 1: Comprobación de SIP sobre la base de datos de SKEL

Como la base de datos se encuentra protegida con SIP no se puede modificar. Otro vector de ataque obvio sería interactuar con la interfaz de usuario, tal vez mediante programación enviar un evento de clic de ratón al botón 'Permitir' en el panel de Preferencias del sistema y 'Seguridad y privacidad'. Sin embargo, este panel está diseñado para frustrar dichas interacciones en versiones recientes de macOS. A continuación se muestra un ejemplo frustrado de dicha intención.

Figura 2: Comprobación de envío de clic contra el Panel de Preferencias de macOS

Sorprendentemente, si tu intentas hacer una captura de pantalla de la ventana del panel de seguridad y privacidad a través de Grab.app también fallaría. Los ataques obvios contra SKEL fallan, como se puede ver.

La gente de Objective-See no ha dado detalles de la vulnerabilidad, ya que ésta está en manos de Apple, si que han mostrado una prueba del bypass realizado a SKEL. Estos investigadores explotan una vulnerabilidad de implementación de SKEL que permite cargar un nuevo kext no aprobado sin interacción por parte del usuario.

Figura 3: Prueba de bypass de SKEL

Como se puede ver hay una vulnerabilidad crítica en SKEL. Todo hace indicar que Apple está arreglando la vulnerabilidad y que, seguramente, esté solucionada con la liberación de la versión final de High Sierra.

Cómo habilitar (o deshabilitar) SIP o Rootless en tu OSX

Apple ha añadido una nueva característica de seguridad, bastante importante, para los usuarios de OS X El Capitan. El mecanismo de protección denominado SIP o Sistema de Protección de la Integridad permite que el malware no modifique ciertos archivos, denominados raíz en este contexto, y de este modo evitar que alguien pueda aprovecharse de ciertas ejecuciones de binarios. El modo "sin raíces" se puede utilizar para cualquier usuario o administrador del sistema.

Es totalmente recomendable que cualquier usuario del sistema lo utilice y lo tenga activo, ya que es una medida de protección. En algunas ocasiones la ejecución de ciertos programas o la configuración y utilización de servicios públicos hacen que sea necesario deshabilitar SIP, pero debemos ser conscientes de los riesgos. Si eres usuario de OS X El Capitan o de MacOS Sierra puedes habilitar y deshabilitar el modo Rootless desde un terminal del sistema operativo. Tanto para la activación como la desactivación del modo Rootless se deben seguir los mismos pasos, solo cambiará el último comando, es decir cambiar un enable por un disable.

1. Reiniciar el Mac y antes de que OS X arranque pulsar Command + R desde el teclado. Esto hará que entremos en modo de recuperación.
2.  Al entrar en el modo de recuperación se puede ver en la barra superior la etiqueta Utilities y entrar en el Terminal.
3. En el terminal ejecutar csrutil enable y de este modo se habilitará SIP en el sistema. Si se quiere deshabilitar se puede ejecutar csrutil disable.
4. Una vez que se vea el mensaje Successfully [enabled|disabled] System Integrity Protection en el terminal. Reinicia la máquina. 

Figura 1: Habilitar / Deshabilitar SIP

Como se ha mencionado anteriormente es totalmente recomendable tener activado SIP o Rootless debido a que es un mecanismo de protección que nos ayudará a tener nuestro Mac menos vulnerable. Por defecto, lo encontramos activo tanto en OS X El Capitan como en MacOS Sierra.

Bug en SIP: Otro exploit para OS X que cabe en un tweet

Apple ha tenido un fallo de seguridad en SIP, el sistema que protege la integridad de ciertos archivos o rutas del sistema que se ha liberado con la última versión de OS X. Como ya pudimos ver en Seguridad Apple, existe la posibilidad de realizar un bypass a SIP, tanto en OS X como en iOS. Esto parecía resuelto con la liberación de la versión OS X 10.11.4 e iOS 9.3, y en su CVE-2016-1757 se detallaba la vulnerabilidad. Se habló mucho sobre lo que la vulnerabilidad permitía a los atacantes, a fin de cuentas una elevación de privilegio y una persistencia en el equipo, es más que suficiente para ver la gravedad del asunto.

Lo ocurrido no es nuevo para Apple. Cuando parece que se saca un parche y se arregla el problema pasa lo siguiente: según varios expertos el parche es ineficaz y aún se puede elevar privilegios y realizar el bypass de SIP. Estamos hablando de un fallo que expone a más de 130 millones de usuarios en el mundo. Lo más curioso de todo esto, es que el investigador Stefan Esser publicó un tuit dónde propone un exploit que se aprovecha del fallo. Esto es otro ejemplo de un exploit que cabe en un tuit. 

Figura 1: Publicación del exploit mediante un tuit de Stefan Esser

No hace ni dos semanas que Apple liberó las actualizaciones de OS X 10.11.4 e iOS 9.3 y parece que el parche es ineficaz. El código del exploit para eludir la última versión parcheada de SIP es sencillo y pequeño, como se pudo ver en la publicación del tuit original. Seguramente, veamos pronto una versión del exploit para Metasploit. Estaremos atentos en Seguridad Apple a estos posibles movimientos.

Bypass a la última protección de Apple en OS X e iOS

Investigadores de seguridad han descubierto una vulnerabilidad que afecta a SIP, System Integrity Protection, el nuevo sistema de protección de integridad desarrollado por Apple con el que se pretende evitar que el software malicioso modifique archivos y carpetas protegidas. La tecnología SIP está presente en OS X El Capitan y está diseñado para proteger el sistema de cualquier usuario que tenga acceso a la raíz, autorizada o no. SIP es una característica clave en la seguridad del sistema OS X. El CVE-2016-1757 detalla la vulnerabilidad.

El ataque consiste en elevar los privilegios eludiendo SIP y evitando la integridad del sistema. De este modo se abre una puerta a que un atacante pueda dar persistencia a un malware en los dispositivos comprometidos. Para aprovechar esta vulnerabilidad, un atacante debe comprometer en primer lugar el sistema. Esto podría lograrse, por ejemplo, mediante un ataque de phishing o explotando alguna vulnerabilidad en el navegador del usuario.

Figura 1: Detalles CVSS de la vulnerabilidad

El investigador Pedro Vilaça indica que la vulnerabilidad es un tipo de elevación de privilegios locales, lo cual signfinca que se necesita un vector inicial para ejecutar el exploit. El vector podría ser, como se indicó anteriormente, un ataque de phishing o una actualización falsa de Flash, el cual permite ejecución de código remoto. Una vez se tenga control o posibilidad de ejecución de código se puede llevar a cabo el bypass de SIP. El bug está presente en todas las versiones del sistema operativo hasta la versión 10.11.4 recientemente publicada, dónde ha sido parcheado. En iOS también se encontraba presente y fue parcheada en la nueva versión 9.3.