Ya está aquí Checkra1n, el primer jailbreak permanente basado en checkm8

Uno de los jailbreaks más esperados del año ya está aquí, esto es una buena noticia para toda la comunidad del jailbreak y para aquellos a los que les gusta acabar con las limitaciones que Apple impone en sus dispositivos. El jailbreak en cuestión es el conocido Checkra1n, se trata del primer jailbreak basado en el exploit checkm8, el que se hizo público hace unos meses. Este nuevo jailbreak llega de la mano de Luca Todesco y su equipo de desarrolladores. Con checkra1n podrás instalar Cydia y otros administradores de archivos con los que disfrutar de una gran variedad de aplicaciones no firmadas por Apple.

Gracias al soporte de inyección de tweaks los usuarios podrán disfrutar de sus tweaks favoritos en iOS 13 y personalizar varias características de su dispositivo. La llegada de checkra1n supone un lavado de cara para la comunidad del jailbreak y animará a numerosos desarrolladores a añadir soporte para iOS 13 en sus herramientas. Como checkm8 es una vulnerabilidad permanente Apple no podrá parchear el jailbreak en futuras actualizaciones (para poder hacerlo tendría que arreglar la memoria de arranque de todos los dispositivos afectados, algo imposible una vez que han abandonado la fábrica). Este jaillbreak es compatible con las versiones más nuevas de los sistemas operativos de Apple (iOS 13.2.x e iPadOS 13.2.x).

Figura 1: Checkra1n ejecutandose en un iPhone.

En cuanto a compatibilidad con dispositivos checkra1n es compatible con todos los modelos de iPhone comprendidos entre el iPhone 6 y el iPhone X y con los iPad comprendidos entre el iPad Air 2 y el iPad Pro de segunda generación (que son los que montan el chip A11 o versiones anteriores). Si quieres adquirir este jailbreak podrás hacerlo desde su página oficial, por el momento la herramienta está disponible únicamente para macOS pero no tardará mucho en salir su versión para Windows. En este caso en concreto es recomendable extremar precauciones a la hora de realizar la descarga debido a que hace un par de meses se descubrió una página fraudulenta que ofrecía la posibilidad de descargar este jailbreak antes de su lanzamiento y que acabó con la inyección de malware en miles de equipos por todo el mundo. Desde Seguridad Apple aprovechamos para recordaros que hacer jailbreak a vuestros dispositivos os ofrece grandes posibilidades de personalización a cambio de una pérdida importante de seguridad. 

Apple almacena en texto plano los correos cifrados de Apple Mail (al menos en dos bases de datos)

El investigador Bob Gendler ha escrito un artículo en su blog donde cuenta algo realmente sorprendente e inseguro que afecta al sistema operativo macOS. Al parecer los correos S/MIME que están cifrados en Apple Mail, aparecen en ciertas bases de datos completamente en texto plano. Algo realmente preocupante. Además de explicar el problema, el autor también nos ofrece la solución para mitigar lo máximo posible este problema de seguridad. Vamos a verlo en profundidad.

En macOS existe una base de datos llamada snippets.db la cual contiene información para que Siri pueda realizar sugerencias más precisas cuando le preguntamos. En esta misma base de datos también se almacenan correos electrónicos como fuente de información. El problema es que estos correos que están almacenados cifrados, en esta base de datos no lo están. Es decir, están totalmente accesibles en texto plano. Incluso con Siri desactivado.

Pero esta base de datos no es la única, entities.db almacena registros de nombres de personas, correos electrónicos, números de teléfono y otra información personal. Además de estos datos no son adquiridos solamente de los contactos, también de la información que podamos tener de este tipo en el correo electrónico. Es decir, tenemos al menos dos bases de datos con información critica que podría ser accesible y lo más importante, no estar cifrada.

Figura 1. Primera medida para mitigar este problema, deshabilitar "Mail" de las opciones de sugerencias de Siri. Fuente.

Según el autor, hay tres formas de solucionar este problema y evitar que este proceso de "aprendizaje de Siri" no recopile información del Apple Mail. La primera sería deshabilitar la opción de que Siri realice sugerencias: Preferencias del sistema → Siri →Recomendaciones de Siri y Privacidad → Deshabilitar la opción de Apple Mail. La segunda implica ejecutar el siguiente comando desde el terminal (usuario normal, no elevado):

defaults write com.apple.suggestions SiriCanLearnFromAppBlacklist -array com.apple.mail

La tercera opción es un poco más compleja pero es la única que permite deshabilitar por completo y de forma definitiva esta opción de recopilar datos del Apple Mail para todos los usuarios. En el artículo se explica en profundidad cómo realizar esta operación que requiere de una aplicación externa para poder llevarla a cabo.

Figura 2. Imagen donde se muestran algunos de los problemas comentados en el artículo. Fuente.

Bob Gendler también comenta que Apple ha sacado muchas actualizaciones desde que lo comunicó pero no ha solucionado este problema todavía, y ya han pasado más de 100 días. Es un problema bastante desconcertante, ya que una información que en principio debería de estar cifrada se pasa a otra ubicación sin cifrar. Es decir, un sistema operativo debe de cifrar y proteger la información a toda costa, no lo contrario. Estamos seguros que pronto veremos nueva información sobre este problema.

Esta es la razón por la que Apple no podrá parchear Checkm8

Hace cosa de una semana, el investigador de seguridad conocido como axi0mX publicó en su cuenta de Twitter el descubrimiento de un nuevo exploit para iOS 13 con el que se podía realizar jaibreak a todos los modelos de iPhone desde el 4s hasta el iPhone X  (solo los modelos con chip A12 o A13 no son vulnerables). El exploit en cuestión recibe el nombre de Checkm8 y actúa sobre la memoria de arranque de los dispositivos, esta memoria de solo lectura hace que sea imposible para Apple solucionar este problema ya que se trata más bien de un problema de hardware y no puede solucionarse con una actualización convencional.

Durante la historia de iOS han ido apareciendo numerosas vulnerabilidades, algunas de las cuales han abierto la posibilidad a jailbreaks (en algunos modelos o versiones concretas) pero nunca se había descubierto una vulnerabilidad que afectase a tal variedad de dispositivos y versiones del sistema operativo. Al contrario de lo sucedido en otras ocasiones, una actualización de seguridad no puede solucionar el problema causado por Checkm8. Como una actualización de firmware no puede actuar sobre la memoria de arranque del iPhone Apple no podrá hacer nada al respecto. En el video publicado por axi0mX en Twitter se puede observar como arranca un iPhone X en modo DFU (Device firmware Upgrade) y tarda apenas 2 segundos en realizarle el jailbreak.

Figura 1: Tweet de axi0mX.

Por el momento el investigador solo ha publicado el exploit (y no el jailbreak) en su GitHub  pero para sacarle el máximo partido es necesario tener acceso físico al dispositivo para conectarlo a un ordenador y trabajar desde ahí. El desarrollador también ha explicado que la vulnerabilidad no es suficiente por si sola para instalar malware de forma permanente en los dispositivos y que para que el jailbreak sea permanente es necesario aplicarlo cada vez que se reinicie el equipo. Según axi0mX el riesgo que supone este exploit para los usuarios depende de la antigüedad de su dispositivo, ya que los dispositivos que no cuenten con Secure Enclave no ofrecerán ninguna clase de resistencia al intentar acceder a sus datos. Por suerte para los propietarios de dispositivos más modernos con Secure Enclave es necesario utilizar un código PIN para acceder a los datos ya que esta función depende de otro subsistema dentro de iOS.

Vulnerabilidad en Airdrop y BLE pone en riesgo tu dispositivo

AirDrop es un viejo conocido de los usuarios de iOS y en este blog. Actualmente la mayoría de dispositivo de Apple lo soporta y es un protocolo muy eficaz a la hora de transferir archivos entre dispositivos de manera local y rápida. Desafortunadamente, no es la primera vez que atacantes usan este protocolo para el mal, y es que recientemente se ha encontrado una vulnerabilidad que permite que cualquier persona con un ordenador y un software específico puedan ver el número de teléfono de tu dispositivo.

Según los investigadores de Hexway si el bluetooth the tu dispositivo Apple está encendido y cercano, cualquier persona puede obtener el estado del dispositivo, información de la batería, el nombre del dispositivo, el estado del Wi-Fi, versión del Sistema Operativo e incluso el número de teléfono.

BLE

Esto es debido a cómo funciona Bluetooth LE. Los dispositivos que cuentan con ello mandan constantemente paquetes de datos para el servicio Discovery, así es como otros Macs, iPhones y iPads pueden saber la localización de los dispositivos colindantes. Conociendo esta propiedad estos investigadores han creado un script que saca toda la información de estos paquetes y los traduce para que cualquier atacante vea el estado del dispositivo. 

AirDrop 

Por otro lado, dentro del apartado de Airdrop, han descubierto que este protocolo puede ser menos anónimo de lo que los usuarios creen. Los investigadores declaran que es posible identificar al usuario a través del hash SHA256 que se genera a los usuarios de alrededor cada vez que el dispositivo entra en modo búsqueda de Airdrop. Así, con un poco de ingenio se puede obtener el número de la persona de la siguiente manera:

• Crear una base de datos con el formato SHA256(numero_telefono):numero:telefono por cada región, por ejemplo en españa sería +34……., en EEUU sería +1-…….. 
• Correr el script y esperar a que alguien entre en modo discovery de Airdrop. 
• Al obtener el hash, compararlo con la base de datos para recuperar el móvil. 
• Debido al formato de iMessage, podremos obtener el nombre del usuario a través de la función TrueCaller. 

Envío contraseña Wi-Fi 

Los mismos investigadores también han encontrado que en la función de envío de contraseñas Wi-Fi presentada en iOS 13 también envía paquetes a través de Bluetooth LE pidiendo la contraseña. Cuando un usuario de iOS selecciona una Wi-Fi que no conoce entra automáticamente en este modo, mandando paquetes pidiendo la contraseña, pero, ¿cómo es posible que el usuario que nos da la contraseña sepa que somos nosotros?. Esto es porque en el hash SHA256 de envío se encuentra nuestro número de telefono, AppleID y mail. Solo los tres primeros bytes de los hashes se envían pero es lo suficiente para identificar el número de teléfono.

Envíos Bidireccionales 

Pero estos investigadores no se han quedado ahí, también se han aprovechado de otras propiedades Bluetooth de los iDevices para hacerse pasar por dispositivos BLE como los AirPods y establecer una conexión.

Como dicen estos investigadores, muchos de estas vulnerabilidades podrían ser consideradas features del sistema operativo, por lo que es muy probable que no se cambien en un futuro cercano. De momento todos los dispositivos desde iOS 10.3.1 a iOS 13 beta son vulnerables a estos ataques y la única manera de protegernos es desactivar el Bluetooth.

Una vulnerabilidad en la beta de iOS 13 permite acceder a los usuarios y contraseñas almacenadas en la App de Ajustes

iOS 13 sigue en fase beta por lo tanto es comprensible que existan algunos fallos en esta versión del sistema operativo, recientemente se ha descubierto una importante vulnerabilidad que facilita el acceso a los datos almacenados en la configuración relativos a los usuarios y contraseñas de aplicaciones y servicios web. Esto significa que esta versión beta bypassear la autenticación biométrica resulta bastante sencillo para acceder a los datos almacenados en el Keychain de iCloud (usuarios y contraseñas). La vulnerabilidad descubierta se dio a conocer a través de la red social Reddit.

Como ha detallado el usuario iDeviceHelp en su canal de YouTube, puedes acceder a todos los usuarios y contraseñas almacenados en los ajustes pulsando repetidamente el menú de “website y app passwords” saltándote así la autenticación con biometría. Tras unos cuantos intentos, iOS 13 te mostrará todas tus contraseñas y logins incluso aunque no llegases a autenticarte con Face o Touch ID. Según el blog 9to5mac se ha confirmado que esta vulnerabilidad se encuentra presente en la última versión de la beta de iOS 13 para desarrolladores. Apple ya ha sido informado de este incidente a través de la nueva app de feedback de iOS 13. El fallo también se ha encontrado en la beta de iPadOS 13.

Figura 1: Acceso a contraseñas del Keichain desde la App de Ajustes.

Por suerte para poder llevar a cabo este robo de contraseñas es necesario tener el dispositivo desbloqueado, algo que no es posible en caso de no conocer la contraseña o no habernos autenticado antes con Face iD o Touch ID. Al convertirte en Betatester aceptas un cierto nivel de riesgo y esta vulnerabilidad no puede ser mejor ejemplo del mismo, hay que recordar que al probar una nueva versión de un sistema operativo es normal encontrar fallos o brechas de seguridad, no se puede esperar que na beta sea completamente segura y estable, especialmente cuando solo lleva en proceso de prueba unas 6 semanas aproximadamente. La beta 3 de iOS 13 salió el día 2 de julio, lo que quiere decir que Apple pronto lanzara su beta 4, una actualización en la que podrían resolverse este y otros pequeños problemas del sistema operativo aun en desarrollo.

Un fallo de seguridad en la aplicación Zoom (videoconferencias) permite activar la cámara web de forma remota sin consentimiento

Los problemas de seguridad en entornos Apple no aparecen únicamente en el software desarrollado por la compañía de la manzana. Ya hemos visto muchos casos de apps o programas los cuales tienen alguna vulnerabilidad y esta puede ser explotada para conseguir activar funcionalidades (como la cámara web en este caso que vamos a ver) o incluso para ejecutar algún tipo de malware. La conocida aplicación Zoom para videoconferencias tiene una de estas vulnerabilidades que ha puesto en alerta a toda la comunidad Apple.

El investigador Jonathan Leitschuh ha descubierto una forma de forzar prácticamente a cualquier Mac a unirse a una videollamada con la app de Zoom enviando un simple enlace como este: https://zoom.us/j/492468757. Es decir, puede hacer que un usuario que tenga la aplicación instalada se una a la videollamada (sin ningún proceso de validación o aceptación) lo que implica la activación de la cámara web sin su consentimiento (CVE-2019–13450). Hay que destacar que esta vulnerabilidad está en conocimiento de la empresa Zoom desde el mes de marzo sin que haya sido solucionada por completo. De hecho (y esto es una funcionalidad) la aplicación permite habilitar una opción que activa la cámara web por defecto de los integrantes de la videoconferencia (Figura 1), aunque esta vulnerabilidad permite activarla incluso con esta opción desactivada.

Figura 1. Activación automática de la cámara cuando se crea una videollamada con Zoom. Fuente.

La app crea un servidor web en cada dispositivo utilizando para ello el puerto 19421 y de esta forma, facilitar todo el proceso de videollamada. En este servidor web es el lugar en el cual recae la vulnerabilidad que puede ser explotada para controlar la webcam, simplemente insertando el código malicioso en dicho servidor web "oculto" que se instala en cada máquina cada vez que se une a una videollamada. La solución para evitar que alguien pueda explotar esta vulnerabilidad en nuestro equipo es sencilla, ya que sólo hay que desactivar la opción "Turn off my video when joining a meeting" (Figura 2).

Figura 2. Activación de la opción para evitar que se active el vídeo por defecto al unirse a una videollamada. Fuente.

Pero además, el investigador ha descubierto que dicho servidor web persiste en el Mac incluso si la aplicación se ha desinstalado por completo, lo que implica que la única forma de eliminarlo sea manualmente. Por otro lado, también ha encontrado una forma de ataque DoS con CVE-2019–13449 el cual sí que fue solucionado por Zoom en mayo. En cambio, este otro, relacionado con la cámara web, continua activo ya que la empresa no le otorga mucha importancia a este problema. En el blog del investigador se encuentra toda la información detallada e incluso una PoC. Parece que al final no es mala idea eso de tener una pegatina que tape la webcam ;)

Un 0-day en Firefox ha revelado un backdoor en macOS

Hace unos días un usuario alertó a los investigadores de que a través de un 0-day ya conocido en Firefox habían logrado ejecutar código en su Mac (corriendo macOS 10.14.5). Cuando la víctima contactó con los investigadores no les proporcionó mucha más información acerca del 0Day de Firefox utilizado en el ataque, por suerte ya se conocen más detalles acerca del incidente. Cuando un atacante dispone de un 0day de navegador, necesita también una forma de “entregárselo" al objetivo. Cuando la victima escogida es una persona concreta en lugar de una empresa u organización es habitual el uso de e-mails como gancho para llevar a la víctima a una página maliciosa en la que se pueda lanzar el exploit.

La supuesta víctima aseguraba que el exploit había logrado instalar en su equipo un malware llamado Finder.app. Curiosamente apenas unos días después de la notificación de este malware el investigador de Coinbase, Philip Martin alertó en Twitter que la empresa había sido atacada utilizando un 0-day de Firefox que tenía como objetivo los empleados de la empresa. Philip también advirtió que otras compañías relacionadas con la criptografía habían sido atacadas pero que desconocía el impacto que podía haber tenido este ataque. Tras hacerse pública esta información, la victima aclaró que hacia un tiempo había estado involucrado en operaciones relacionadas con el cambio de criptodivisas, algo que hace muy razonable el hecho de que el 0-day mencionado anteriormente sea el mismo que el detectado por Coinbase. Esta vulnerabilidad de Firefox ya ha sido solucionada y ha recibido el código CVE-2019-11707.

Figura 1: Aplicación maliciosa Finder.app

Al echar un vistazo a Finder.app (la aplicación maliciosa instalada por el exploit) se puede comprobar que contiene uno de los hash que Philip Martin compartió en sus tweets alertando del 0-day. Tras analizar un poco más la herramienta (a través de virustotal), se descubrió que esta guardaba relación con Wirenet, el primer troyano capaz de robar contraseñas de Linux y mac OS X conocido. De hecho es muy posible que esta variación del malware haya sido obra del mismo ciberdelincuente o equipo que lanzó Wirenet en 2012. En su correo la victima aseguraba que la aplicación instalada había logrado bypasear el Gatekeeper, algo que resulta normal si tenemos en cuenta que el malware fue entregado a través de un 0-day de navegador. Gatekeeper solo analiza las herramientas o aplicaciones cuando las descargamos de una forma “normal”, aquellos archivos o apps descargados a través de un payload no utilizan el atributo de cuarentena o lo eliminan directamente para no alertar al Gatekeeper. Estaremos al tanto de más noticias acerca de este tema.

El caso de WhatsApp sigue dando que hablar: Si no has actualizado, ¡actualiza!

La semana pasada os hablamos acerca de un spyware de origen israelí que había causado el caos en WhatsApp al transmitirse a través de llamadas sin dejar rastro de las mismas. Tras una semana investigando el descubrimiento de este spyware en la red social perteneciente a Facebook se ha llegado a la conclusión de que cualquier aplicación en los dispositivos de las víctimas pudo haber sido o puede haberse convertido en un nuevo vehículo para la carga maliciosa de malware y ejecución de código. Según los análisis de la firma de seguridad Lookout, Pegasus sería capaz de robar la lista de contactos, localización a través del GPS y contraseñas de redes Wi-Fi o personales.

La infección se llevaba a cabo a través de una llamada realizada desde la famosa red social, al recibirla los dispositivos quedaban infectados independientemente de si esta era aceptada o rechazada, de hecho el spyware era capaz de borrar los registros de llamadas de la aplicación para no dejar rastro alguno. Este método de infección resulta aterrador ya que la infección se lograba sin necesitar la interacción de las víctimas, en la mayoría de ataques es necesario que la víctima realice algún tipo de acción, por ejemplo, pinchar sobre un enlace. Según los expertos la vulnerabilidad fue descubierta por la propia empresa de WhatsApp, sin embargo su cifrado no se había visto afectada y la infección no se debía a un fallo en el código, sino que se trata de una herramienta externa (en este caso desarrollada por el NSO Group) que ha podido utilizar cualquier otra aplicación como vehículo para llegar hasta WhatsApp.

Pegasus y las posibilidades

El cifrado es una función de seguridad vital a la hora de establecer una comunicación segura, sin embargo no puede protegernos si un atacante o herramienta gana acceso a nuestro dispositivo. La única forma de evitar el acceso por completo seria evitar el uso de tecnología algo que resulta imposible de creer en la sociedad actual. El año pasado un estudio realizado por la universidad de Toronto revelo que al menos 45 países habían sido infectados por software Pegasus a través de al menos 36 gobiernos.

Desde Seguridad Apple os recordamos la importancia de mantener vuestro software, dispositivos y aplicaciones actualizados ya que en las actualizaciones se añaden parches de seguridad que nos ayudan a protegernos contra todo tipo de ataques.

Zombieload: Una nueva vulnerabilidad que afecta a los chips de Intel posteriores a 2011

Los investigadores han descubierto un nuevo set de vulnerabilidades que afectarían a los chips fabricados por Intel a partir del año 2011, incluyendo algunos de los chips que ha utilizado Apple durante los últimos años en sus dispositivos. Este conjunto de vulnerabilidades ha recibido el nombre de ZombieLoad y se basa en cuatro bugs que permitirían a los ciberdelincuentes extraer información sensible directamente desde el procesador. Tras analizar estas vulnerabilidades a fondo se ha podido comprobar que son tan serias como Meltdown o Spectre, de las cuales ya os hablamos hace unos meses en el blog.

En este caso las vulnerabilidades también se aprovechan del mismo proceso que las dos anteriormente mencionadas, un proceso diseñado para acelerar el funcionamiento y el procesamiento de datos en los dispositivos. En un whitepapper publicado por varios investigadores entre los que se encuentran algunos de los que trabajaron en su día para frenar Spectre y Meltdown se explica con detalle cómo funciona ZombieLoad, también se ha añadido una demo en YouTube que muestra su capacidad de espiar lo que estás haciendo en tu ordenador además de su facilidad a la hora de robar contraseñas. Por suerte para todos, Daniel Gruss, uno de los descubridores de ZombieLoad ha asegurado que aunque esta vulnerabilidad sea más fácil de explotar que Spectre se necesitan una serie de conocimientos avanzados para ello lo que reduce bastante el riesgo de un ataque.

Figura 1: Intel afectado por ZombieLoad

Zombieload afecta a todos los chips Intel a partir de 2011, sin embargo los chips AMD y ARM no se encuentran afectados. Por el momento no se han conocido casos en los que se haya usado ZombieLoad para realizar ataques e Intel ya ha lanzado un micro-código para proteger los procesadores afectados. Apple también ha lanzado un parche para esta vulnerabilidad en su actualización para macOS Mojave 10.14.5 y versiones anteriores, además ha añadido un documento en su página de soporte en el que se explica cómo pueden proteger sus equipos aquellos usuarios que utilicen software que no sea de confianza en su Mac. Según Intel la actualización de micro-código lanzada puede afectar en el rendimiento de sus procesadores, pero no será notable para aquellos equipos que estén corriendo macOS Mojave 10.14.5.

Whatsapp revela una vulnerabilidad que permitia la instalación de Spyware en iPhone

En un artículo publicado hace escasos días por The Financial Times se ha revelado una vulnerabilidad de WhatsApp que permitía a los atacantes inyectar un spyware de origen israelí en algunos dispositivos. El código del spyware en cuestión fue escrito por la compañía israelí NSO Group y su vía de transmisión era a través de llamadas de WhatsApp a usuarios de iPhone o Android. El principal riesgo de este spyware es que el código malicioso podía ser transmitido aunque la persona que recibiese la llamada no contestase, además la llamada no quedaba almacenada en el registro de llamadas haciendo posible infectar a miles de usuarios sin que se diesen cuenta.

Todavía no se conocen todos los detalles acerca de esta vulnerabilidad, pero el informe sugiere que ha podido estar activa durante varias semanas.

“este ataque tiene todas las características de una empresa privada conocida por trabajar con gobiernos entregando spyware que supuestamente asume las funciones de los sistemas operativos de algunos teléfonos móviles, hemos informado a varias organizaciones de derechos humanos para que compartan esta información y que se lo notifiquen a la sociedad". Ha dicho WhatsApp.

Figura 1: Grupo NSO

Según el artículo, WhatsApp todavía no ha podido estimar el número de clientes afectados, aunque el alcance ha sido grande ya que la compañía propiedad de Facebook tiene alrededor de 1,5 billones de usuarios a lo largo del mundo. Por el momento se sabe que la empresa denunció el incidente al Departamiento de Justicia Estadounidense y comenzó a trabajar en la reparación de sus servidores lanzando un parche de seguridad dos días después. Por lo general el NSO Group desarrolla herramientas de este tipo para que los gobiernos de algunos países puedan controlar a algunas organizaciones criminales o terroristas, pero cuando estas herramientas caen en malas manos pueden convertirse en una amenaza para los usuarios de los servicios atacados.

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.

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.

Otro adolescente encuentra una vulnerabilidad (esta vez en macOS) y no quiere contar cómo lo hizo

Hace tan sólo una semana ya vimos que un adolescente fue el que encontró el fallo de FaceTime e incluso Apple iba a recompensarle por la acción. Pues esta semana, otro adolescente, un aleman de 18 años llamado Linus Henze, ha encontrado una vulnerabilidad que afecta a la última versión del sistema operativo macOS que permite que algunas apps accedan a las contraseñas almacenadas. Y además, este adolescente no quiere compartir como lo hizo. Ahora veremos el motivo.

Este problema de acceso a las contraseñas permitiría, por ejemplo, que una aplicación maliciosa tuviera acceso a las contraseñas almacenadas del banco, Amazon, Netflix o cualquier otra almacenadas en el llavero (keychain). Pero incluso, si utilizas el llavero desde iCloud, este también podría estar afectado por este problema. Al estar todo sincronizado desde la nube de Apple, las contraseñas de otros dispositivos como el iPad y el iPhone también estarían comprometidas. A pesar de lo grave de la vulnerabilidad, de momento no hay ninguna solución prevista. En el siguiente vídeo podemos ver el exploit en acción:

Henze descubrió que es posible crear una app capaz de leer el contenido del llavero sin permisos previos. Es decir, no requiere de privilegios especiales de administrador para explotar la vulnerabilidad. Por lo tanto, sacar partido de este bug es tan simple como ejecutar la aplicación, nada más. Además, una aplicación legítima ya instalada podría ser infectada e insertar el código para explotar la vulnerabilidad del llavero o también el usuario podría ser engañado para que accediera una web desde la cual se ejecutara el exploit.

Figura 1. Aplicación creada por Linus Henze para extraer las contraseñas. Fuente.

Viendo la gravedad de este fallo de seguridad, es vital estudiar la técnica utilizada pero ¿por qué no quiere publicar cómo lo ha hecho? Según comenta él mismo, no lo hace con maldad sino como protesta. De hecho, sí que ha avisado del problema y eso ya es más que suficiente para que Apple tome nota. Su protesta está enfocada a la falta de un programa de bug bounty exclusivo para macOS. Recordemos que este programa de recompensas sólo se aplica a dispositivos iOS. Esperemos que Apple tome nota y abra uno enfocado a su sistema operativo de escritorio o veremos como la empresa Zerodioum aumenta su colección de exploits.

Bypass al bloqueo de iOS 12. No dejes tu iPhone solo

Un nuevo caso, y van unos cuantos en la historia de iOS, sobre un bypass del bloqueo de pantalla de iOS. Se descubrió una vulnerabilidad en el bloqueo del dispositivo en iOS 12, el cual permite a un atacante tener acceso a las fotos y a los datos de contacto del dispositivo bloqueado. El método para llevar a cabo el bypass fue compartido por el investigador José Rodríguez, quién descubrió errores de iOS en el pasado. Con acceso físico al dispositivo bloqueado, el atacante le pide a Siri que active VoiceOver, entonces apaga el dispositivo con el botón lateral y luego llama al iPhone utiliando otro dispositivo. 

Una vez que aparece la pantalla de llamada, el atacante toca el botón Message, optando por crear un mensaje pesonalizado y luego toca el icono con un '+'. En el teléfono, el atacante envía un texto o iMessage al iPhone de destino, cuya pantalla se presiona dos veces cuando aparece la notificación del mensaje. Esto causa un comportamiento extraño en la interfaz del usuario, ya que resalta el icono. Después de un momento, la pantalla se pone blanca y la notificación desaparece, pero aparentemente el recuadro de selección de texto de VoiceOver aún puede tocarse y ahora se puede utilizar para acceder a la interfaz de Message. Después de varios deslizamientos de pantalla, se escucha que VoiceOver dice 'Cancelar', el cual revela la pantalla de Mensajes original. 

Agregar un nuevo destinatario y seleccionar el número del teclado virtual revela una lista de contactos del teléfono. Además, si uno de los números o contactos incluye un botón de información, deshabilitar VoiceOver y tocar el botón muesta la información del contacto. En un conjunto similarmente complejo de pasos que involucran un menú de usuario invisible, un atacante para acceder a la Camera Roll del iPhone bloqueado y a otras carpetas de fotos. El método de bypass funciona en todos los modelos de iPhone, incluida la línea de iPhone XS, pero Apple no ha solucionado nada en la última versión beta de iOS 12.1. Seguramente se acabe incluyendo. Estaremos atentos.

Safari víctima de un nuevo ataque spoofing

Hace unos meses un investigador descubrió una vulnerabilidad no parcheada en el navegador web de Safari. La vulnerabilidad en cuestión permitiría a un atacante controlar el contenido mostrado en la barra de direcciones. Este bug si es explotado correctamente podría permitir la construcción de un buen ataque phishing que resultaría muy difícil de identificar por cualquier usuario. Esta brecha de seguridad ha sido generada por un fallo en la actualización de la barra de búsqueda. El navegador de Apple permite a javascript actualizar la información de la barra de direcciones antes de que la página buscada acabe de cargar por completo.

El investigador Rafay Baloch ha sido capaz de reproducir esta vulnerabilidad únicamente en los buscadores Safari de Apple y Edge de Microsoft. Tras su descubrimiento Rafay no dudó en informar a los responsables de cada compañía, sin embargo solo Microsoft ha respondido con un parche de seguridad lanzado el pasado 14 de agosto que formaba parte de sus actualizaciones de seguridad. Apple recibió el aviso el día 2 de junio y 90 días después tras superar el periodo de no divulgación el bug se ha dado a conocer públicamente. 

Esta vulnerabilidad ya es conocida como CVE-2018-8383 y está esperando para ser puntada. Explotar esta vulnerabilidad requiere que el atacante engañe a la víctima para acceder a una página diseñada especialmente para suplantar la página buscada, algo que no resulta muy complicado. Retrasando la actualización de la barra de direcciones un atacante podría suplantar cualquier página web mientras que la víctima ve el dominio legítimo con sus respectivas marcas de autenticación. En la mayoría de los casos el cambio en la barra de direcciones se puede apreciar perfectamente, sin embargo esto pasa también con muchas páginas legitimas que aprovechan para cargar algunos elementos secundarios en background, haciendo que no resulte nada sospechoso.

Vulnerabilidad en el cliente de correo Airmail 3

Una vulnerabilidad que afecta a Airmail 3, un cliente de correo electrónico que es una alternativa al Mail de Apple para macOS, puede permitir a un atacante robar correos electrónicos y archivos adjuntos de un usuario, sin requerir, en algunos casos, la interacción del usuario más allá de abrir un mensaje malicioso. El resumen es que un atacante puede abusar de peticiones URL procesadas por la aplicación de correo electrónico para robar archivos de la víctima, incluso, en algunos casos, sin interacción del usuario. 

La empresa Versprite ha generada un WriteUp explicando los detalles de la vulnerabilidad. Los analistas de seguridad de la empresa dijeron que descubrieron que las solicitudes de URL procesadas por Airmail 3 pueden ser objeto de abuso para robar archivos de la víctima, mientras que requieren, además, de poca habilidad para hacerlo. Un atacante, simplemente, puede enviar un correo electrónico a un usuario de Airmail 3 que contenga un enlace a una URL que active la función de "envíar correo". Sin que el usuario lo sepa, si se hace clic en este enlace se abre y envía un nuevo mensaje de correo desde la cuenta de la víctima al atacante. Otros elementos también pueden estar incrustados en el correo electrónico de ataque. Este caso provocará que Airmail 3 adjunte archivos a ese mensaje saliente. 

Figura 1: Vulnerabilidad en Airmail 3

Los investigadores y analistas de seguridad de la empresa recomiendan actualizar, en cuanto sea posible, la aplicación para no tener problemas y estar expuestos a esta amenaza. Una vulnerabilidad que tener en cuenta para los usuarios de la aplicación.

Guía de seguridad para tu Secure Summer! (Parte 3)

Con este artículo completamos y damos por finalizada la serie Guía de seguridad para tu Secure Summer! A continuación, incluiremos los últimos términos en nuestro abecedario de amenazas y concluiremos con algunas recomendaciones básicas tanto para minimizar las posibilidades de ser objeto de las amenazas mostradas como de mitigar las consecuencias de los ataques enumerados a lo largo de esta serie.

Guía de seguridad para tu Secure Summer! (Parte 2)

En este post continuamos con la segunda parte de la Guía de seguridad para tu Secure Summer! Recogemos el testigo del post anterior y procedemos a expandir nuestro diccionario de términos.

Como introducíamos en el primer artículo, Las técnicas de ciberataques han evolucionado mucho durante los últimos años, desde simples estrategias de engaño haciendo uso del email hasta hasta malware que detecta las pulsaciones del teclado de la máquina atacada. Debido a la importancia y al valor de la información a la que los atacantes se esfuerzan por tener acceso, todo lo relacionado con la privacidad del usuario y la protección de los datos personales ha aumentado considerablemente. 

Un bug para engañar a aplicaciones de seguridad haciéndose pasar por software firmado por Apple

Recientemente se ha sabido de la existencia de un bug en algunos programas de seguridad de terceros para Mac, algunos de estos programas provienen de Facebook, Google o VirusTotal y permitirían la aparición de malware simulando ser programas legítimos y firmados por Apple. Cuando un desarrollador firma una aplicación, esto integra en ella una firma que puede utilizarse para verificar que la aplicación es legítima, que no ha sido manipulada y que pertenece a la organización o al developer que esperabas. Algunas herramientas de seguridad se basan en estas firmas para añadir a su “lista blanca” varios programas o ejecutables para asegurar a sus usuarios que no correrán ningún riesgo a la hora de ejecutarlos.

Si el software que queremos instalar está firmado por Apple esto nos generará una sensación de seguridad ya que aparentemente no dañaremos nuestro dispositivo, en cambio si el software que queremos instalar no está firmado nos lo pensaremos dos veces. Según Josh Pitts, investigador de seguridad en Okta, este bug podría utilizarse para desarrollar malware especializado capaz de engañar a varias aplicaciones de terceros haciéndolas pensar que está firmado por Apple. Según Pitts solo sería necesario un archivo FAT malicioso ya que estas aplicaciones no analizan todos los componentes de este tipo de archivos para comprobar si la firma es válida, lo que hacen estos programas es comprobar solo el primero de los binarios del archivo FAT, el cual sí que será legítimo y firmado por Apple, confiando ya en el resto de binarios y añadiéndola a la whitelist.

Figura 1: CVE del bug asociado a la aplicación de Google

Tras su descubrimiento Pitts contactó con Apple para informar a la compañía californiana del problema, a lo que Apple respondió diciendo que los desarrolladores de las aplicaciones de terceros necesitan realizar trabajos adicionales para verificar que todos los binarios de un FAT son legítimos. Después de esto, tanto Okta como Pitts contactaron con el CERT para que este informase del incidente y proporcionase a todas las aplicaciones de terceros un paquete FAT modificado con el que poder probar la seguridad de sus productos. Tras comprobar que se habían visto afectadas, algunas de las compañías, entre las que se encuentran Facebook o Google, lanzaron una actualización de seguridad para solucionar este problema.

El 'troleo' se apodera de los clientes de mensajería con el caracter telugu

La semana pasada surgió un error que provocaba el crasheo del terminal debido a un caracter del idioma indio. Esta semana ha sido, sin duda, la semana del 'troleo' y las risas en diferentes grupos. Es cierto que el caracter no afectaba al sistema desde cualquier app, pero al recibir un mensaje había que echarse a temblar. Este hecho ha hecho que Apple lanzara actualizaciones, con lo que este tema parece cerrado. 

Aunque el tema parece cerrado, sigue habiendo muchos usuarios de iOS que no han actualizado a la versión 11.2.6, aunque se recomienda que lo hagan lo antes posible. La broma no solo ha estado ocurriendo a través de iMessage, si no que también afectaba a mensajería de terceros, por ejemplo, WhatsApp o aplicaciones de correo electrónico. Las bromas en los grupos de amigos han sido infinitas, aunque no se tiene claro el daño que ello podría proporcionar. Incluso, hay usuarios de reddit que han sufrido las bromas a través del uso del caracter en la aplicación, incluso a través de mensajes directos. 

Figura 1: Inserción del caracter telugu

Lo que muchos no sabían es que si el dispositivo tiene una versión a iOS 11.1.2 o disponen de Jailbreak, el dispositivo puede reiniciarse hasta que se tenga que restaurar. Este hecho obligar a actualizar a la última versión de iOS, perdiendo los posibles Jailbreak y la posibilidad de llevarlo a cabo. El 'troleo' puede que quede aquí o siga hasta que los usuarios de iOS actualicen y dejen de ser vulnerables a este caracter.