Si hay una máxima absoluta en el mundo de la tecnología es que nada es 100% seguro. Cualquier software, dispositivo, chip o componente es susceptible de ser vulnerado en su seguridad por una razón muy simple: todo está creado en primera instancia por humanos y estos se equivocan. Nada más simple.
Se ha demostrado varias veces cómo los hackers (investigadores de seguridad) han conseguido comprometer la seguridad de los SoC de Apple para sus dispositivos (los Ax) y hacer lo que se conoce coloquialmente como jailbreak. ¿Pero qué es esto técnicamente? Vamos a explicarlo y además os contaremos qué supone que se haya podido realizar esta técnica en los chips T2 que controlan la seguridad de los Mac lanzados en los últimos años, como el último iMac de 2020 que analizamos aquí.
Jailbreak, circunvenir la firma digital del sistema
El primer iPhone ya tenía un sistema de control de ejecución de apps por firma digital. Es decir, Apple creó una autoridad certificadora que genera dos certificados que van asociados: uno público y otro privado. En la forma en que Apple firma: usa la clave privada para cifrar los datos y estos luego pueden validarse con la clave pública. De esta manera, se certifica que el programa procede de Apple. Es una comprobación que hace el sistema incluso en cada página de ejecución de código en memoria.
Diagrama de firma digital de nuestro curso de Desarrollo Seguro en Apple Coding Academy.
A grandes rasgos, y por dejarlo aún más claro: al dato se le calcula un hash o huella digital, que permite verificar la integridad de los datos. Si un solo byte de los datos cambia, la huella digital es otra y entonces podremos saber que el dato ha sido modificado y no es el original del que se obtuvo el hash. Dicho hash se codifica con la clave privada de la autoridad certificadora de Apple. Esta clave privada es absolutamente secreta por razones obvias. Y además se va actualizando en el tiempo a nuevos algoritmos que la protegen aún más e incluso rota para que si se comprometiera dicha clave no pusiera en peligro todo el histórico de datos.
Cuando se coge un código o programa firmado, la parte que sí se distribuye es la clave pública del certificado. Una parte que no compromete la seguridad, que no permite cifrar (solo descifrar) y que se usa para descifrar el hash. Una vez descifrado, se calcula nuevamente el hash del dato y se compara. Si son el mismo, el dato está correctamente firmado digitalmente por la autoridad que cifro el hash la primera vez con la clave privada.
El jailbreak lo que persigue es circunvenir esa comprobación: saltarla. De esta forma, cuando un dispositivo tiene jailbreak, aunque el hash de un código o programa no coincida en forma alguna con el que se usó para cifrar, o incluso no vaya ni firmado, el sistema no comprobará este hecho y dejará ejecutar cualquier cosa en nuestro dispositivo.
En buena Ley y por seguridad, jamás deberíamos hacer jailbreak a un dispositivo pues podríamos comprometer la integridad del mismo abriéndolo a la ejecución de cualquier software, y con ello, no tenemos la garantía que cualquier app, tweak o juego pirata, tenga alguna modificación que instale en el sistema algún tipo de rastreador que envíe lo que escribimos a cualquier servidor, que habilite nuestras cámaras a voluntad, que extraiga los datos del mismo al tener acceso libre al sistema de archivos y muchos otros peligros.
El T2, comprometido por un método similar al jailbreak de los iPhone o iPad.
A primeros de octubre se hizo pública una noticia que derivaba de un descubrimiento que se hizo público en agosto sobre la seguridad de los chips T2 que controlan la seguridad de los Mac lanzados en los últimos años. Un chip que tiene su propio sistema operativo llamado BridgeOS y que se encarga del cifrado de los datos y del secure boot o arranque seguro de los Mac para evitar que sean comprometidos en una forma similar a los iPhone o iPad.
No podemos olvidar que los T2 están basados en un SoC Apple Silicon A10 Fusion, por lo que parece que parte de sus errores de diseño que permiten determinadas explotaciones en su seguridad, se han heredado por parte de los chips T2.
En agosto se hizo público el fallo conocido como Blackbird, la explotación de un fallo de seguridad en todos los chips de Apple hasta el A11 Bionic, que compromete al chip de seguridad Secure Enclave y que permite ejecutar código arbitrario (código sin firmar) cuando el dispositivo está en modo de recuperación de fábrica (o DFU). Este fallo no es un programa que se cargue sobre el Secure Enclave, es un fallo de diseño del software que corre en la ROM del propio chip (en su programa principal). Una memoria que no puede ser actualizada ni sobrescrita (es de solo lectura) y por lo tanto es imparcheable.
A este fallo del Secure Enclave hay que sumarle otro exploit usado para conseguir jailbreak a los dispositivos: el checkm8. Este se aprovecha de un fallo también imparcheable del arranque de los iPhone y iPad (en la BootROM). De forma que al comprobar que el sistema operativo que se arranca está correctamente firmado por Apple, puede saltarse esa comprobación y arrancar un sistema modificado (uno que no verifique firma alguna y esté abierto). Otro error que afecta a todos los dispositivos desde el A5 (iPhone 4s) hasta los iPhone 8 o iPhone X con el chip A11 Bionic. Este último se hizo público en septiembre del año pasado.
La suma de dos exploits para atacar al T2
Como ya hemos comentado, el T2 es una variación del A10 Fusion de Apple y también tiene estos errores. Así que se ha demostrado que el uso en común de Blackbird y Checkm8, permiten comprometer el chip y poner en peligro la seguridad de los Macs con este chip.
Es un fallo que no puede arreglarse en forma alguna, pero que por otro lado requiere de un acceso físico a la máquina. No podemos explotar estos fallos en remoto de forma alguna: debemos tener la máquina con nosotros para aprovechar ese error y conseguir alguna ventaja de los equipos.
¿Qué puede hacerse o qué consecuencias tiene? Podrían crear dispositivos (o incluso cables) que conectados por USB-C cuando el ordenador arranque, permitan ejecutar los exploits y básicamente, tomar el control de la máquina. Obtener acceso root y controlar o modificar el sistema en cualquiera de los dispositivos conectados a la misma y configurados (normalmente, el almacenamiento). Incluso si está cifrado.
No obstante, el acceso a discos cifrados no es trivial si usan FileVault 2 porque estos exploits no te permiten obtener la clave, aunque sí puede lanzarse un ataque por fuerza bruta que llegara a encontrar la clave del equipo con el tiempo necesario. Como cuando en las películas enchufan un pendrive y esperan a que "haga su magia". Porque lo que sí impide el ataque es que se aplican los plazos de seguridad en tiempo que normalmente tienen los equipos para evitar estas prácticas.
Si se toma el control de la máquina y se instala a nivel administrativo un software malicioso, podríamos tener casos de instalación de (por ejemplo) software RAT que pudiera controlar nuestro equipo (Remote Administration Tool) lo cual también es un peligro incipiente. Y tranquilos, si os encienden la webcam la luz siempre se encenderá pues en los Mac el LED no tiene un mecanismo independiente y está conectado al cable de alimentación eléctrica de la cámara. Así que es materialmente imposible encender la webcam sin que se encienda el LED.
Pero bueno... vamos a calmarnos un poco.
Lo mejor que podemos hacer si sentimos que podemos estar en peligro, es no dejar nuestro equipo "desprevenido". Y ponerle una buena clave en FileVault al mismo para, al menos, poner un poco más de pegas al acceso de los datos. Al no ser un ataque que pueda realizarse en remoto, el peligro es menor pero son esas cosas a las que siempre estamos expuestos con la tecnología porque nadie se salva y nada es 100% seguro.
Esta información, no obstante, no está libre de polémica pues incluso los equipos de seguridad tras los exploits en iOS ponen en duda que se haya podido realmente hacer este ataque y que no estemos hablando de una mera prueba de concepto o ruido para intentar ganar presencia en medios. No hablamos que no exista la posibilidad de hacer los ataques, que es algo muy real: hablamos que se haya conseguido realizar algún exploit real que lo aproveche y suponga un verdadero peligro. Es decir: el agujero está pero por sí solo no hace nada y la duda es si alguien ha conseguido realmente beneficiarse de estos fallos.
Si pensamos que nuestro equipo podría haber sido comprometido, existe una solución parcial que es reinstalar el sistema BridgeOS del chip T2, por lo que el atacante tendría que volver a comprometer nuestro equipo. Podéis seguir las instrucciones aquí. Podemos comprobar si hemos sido atacados, comprobando la integridad de los datos del SMC del equipo con esta utilidad y ver si hemos sido atacados.
Como Apple cambiará por completo la arquitectura de arranque y funcionamiento de los Mac con los Apple Silicon, es obvio que esto exploit no le afectará en forma alguna, aunque insisto, eso no quita que dentro de X tiempo se saquen otro fallo y vuelta a empezar. En seguridad, nunca podemos estar 100% seguros.
ACTUALIZACIÓN: Tras una investigación aún más exhaustiva de la documentación actualmente disponible, realizada también por otros expertos en seguridad, puedo afirmar que el error es MENOS preocupante aún (por mucho que en los comentarios algunos queráis quemar el Apple Park).
- Actualmente, como hemos indicado, la explotación del fallo solo se puede hacer en modo DFU, por lo que se ha demostrado que NO se puede acceder a los discos cifrados ni intentar comprometer su seguridad. Deberían saber nuestra clave para poder hacer algo. No se puede atacar por fuerza bruta aunque en un principio se pensó que sí y por eso lo reflejé en el artículo. Se ha demostrado que no se puede.
- Por defecto, los puertos USB-C de las máquinas con chip T2 tienen un sistema de seguridad que les impide arrancar ningún proceso si la máquina no está levantada, por lo que primero habría que tener la máquina encendida y con la clave puesta de desbloqueo del disco.
- Se requeriría el usuario y clave de un administrador para poder acceder al firmware y poder modificarlo.
- Habría que habilitar también las claves del firmware y montar el acceso root.
- Descubierto y reportado el error, los nuevos chips T2 vendrán con el error parcheado, para minimizar aún más los riesgos ya que es un simple cambio en la versión del firmware de la ROM del Secure Enclave y del propio chip en el Secure Boot.
En resumen, no solo hay que tener acceso físico al equipo, debemos ser administradores del mismo, tener el disco desbloqueado y con acceso, o dejar el Mac de fábrica sin información alguna.
Reitero: al igual que los famosos fallos Spectre y Meltdown, una cosa es un error grave y otra es las circunstancias que deben darse para que sea explotado. En ese sentido, las casualidades que deben darse para explotar el fallo de los T2 son bastante improbables.
Y no podemos olvidar que cada día, cientos de exploits son descubiertos y parchearos en todos los sistemas operativos: Windows, Linux, Android, iOS, Mac... como auditor de seguridad estos errores hay que tomarlos en serio y es lo que he hecho en el artículo: ser profesional y dar la información veraz como hago en muchos otros casos.** El que quiera ver suavidad a Apple, que deje atrás su espíritu hater** y que se informe por sí mismo como hemos hecho para este artículo.
Gracias a @Dekkar por la información aportada para este artículo.
Ver 44 comentarios