Lo hemos comentado en infinidad de ocasiones. Lo importante de las actualizaciones de un sistema operativo (cualquiera, no solo iOS) no son tanto las nuevas funciones o acceso a nuevas características que se incorporan. Lo realmente importante es la seguridad y el arreglo de fallos de esta que pueden poner en peligro nuestros sistemas de una forma en la que ninguno está a salvo.
Hoy vamos a intentar explicaros una sucesión de errores pasados y ya solventados hace meses en iOS, que el equipo de Google Project Zero ha hecho públicos y que nos demuestran lo importante que es la investigación en seguridad y el aplicar actualizaciones que corrijan errores en los sistemas.
Lo primero que tenemos que entender a nivel de seguridad es la diferencia de las diferentes posibles amenazas que pueden tener nuestros sistemas:
- Virus: programas que se ejecutan sin nuestro consentimiento, ocultos en la ejecución y que se propagan sin nuestro conocimiento por diferentes medios. Solo un programa que busque la cadena del mismo será capaz de encontrarlo. Estos no existen en macOS y Linux porque su arquitectura impide que existan.
- Troyanos: programas que nosotros ejecutamos creyendo que harán otra cosa pero contienen una función maliciosa. Como un instalador de Flash falso que pone un RAT (herramienta de administración remota) para tomar el control de nuestro equipo sin que lo sepamos. En macOS y Linux existen (vaya que sí). En iOS existen y no: es la revisión del App Store quien impide que estos lleguen al sistema, pero si algún desarrollador consigue colar uno sin que el equipo de review lo detecte, lo habrá. No obstante, la ejecución de las apps en iOS impide que puedan acceder al sistema, pero sí (con nuestro previo consentimiento) podrían acceder y usar nuestros datos y robarlos. Son casos muy aislados, pero no podemos negar categóricamente que no existan.
- Exploits: o fallos de seguridad o zero-days. En realidad el exploit sería la capacidad de explotar un fallo de seguridad. De estos no se libra absolutamente nadie. Son fallos en el software, fallos que ha cometido un programador al crear el código de un programa o sistema, y que pueden ser explotados para que un código malicioso consiga hacer cosas que no debería por cómo se define la seguridad de un sistema.
Aclarado el tema, vamos a hablar de fallos de seguridad. Fallos graves que permiten a través de errores de programación, explotar y obtener privilegios en el sistema que no deberían tener y que los aprovechan para "hacer el mal". Privilegios como acceder al sistema de archivos general en iOS, salir del sandbox de las apps o deshabilitar la comprobación de firma de código.
Los fallos de seguridad en iOS 12.1.4
Project Zero, una división de Google, es la responsable en los últimos años de encontrar infinidad de fallos de seguridad tanto en productos propios como ajenos. Ellos encontraron las vulnerabilidades de los chips de Intel (y resto de empresas) conocidos como Spectre y Meltdown y otros muchos grandes errores tanto en Android, como iOS, Windows... hacen un trabajo sumamente profesional y siempre respetando la privacidad de los afectados, informando sin publicidad y sacando a la luz sus descubrimientos cuando estos ya han sido solventados convenientemente.
En esta ocasión, el equipo de Google Project Zero ha sacado a la luz los descubrimientos sobre varios fallos en iOS que nos permiten ver claramente cómo el tema de la seguridad afecta a todos por igual y hay que tomárselo muy en serio. Os pasamos a relatar y explicar.
El equipo TAG (grupo de análisis de amenazas de Google) detectó a comienzos de este año una serie de páginas web maliciosas que estaban explotando una serie de agujeros de seguridad en iOS. Algunos de ellos, zero-days o día 0, porque aún no habían sido descubiertos por el equipo responsable del software.
Simplemente con visitar una página web concreta, miles de iPhones cada semana eran atacados y se les instalaba un software de monitorización remota. Hasta 5 exploits diferentes encontró Google en esta página que permitían poner en peligro todas las versiones de iOS desde la 10 a la 12. Un trabajo hecho por un equipo de expertos ciberdelicuentes en un trabajo que se calcula ha podido llevarles unos dos años de investigación continuada.
Trabajando con el equipo de amenazas, Google Project Zero encontró un total de 14 vulnerabilidades en el software del sistema a través de una cadena de 5 exploits diferentes. Siete de los errores son del navegador Safari, cinco del kernel o núcleo del sistema y dos errores que permitían a cualquier app o proceso saltarse el sandbox que protege al kernel para que las apps no lleguen a él y consigan permiso completo de modificación y acceso a este. Es decir, acceso raíz o root.
En concreto se detectó que una cadena de exploits que usaba la web, en últimas versiones de iOS, seguían sin parchear y no estaban en conocimiento de Apple así que el 1 de febrero se notificó a Cupertino. Los fallos en cuestión, que Apple reportó en este informe de seguridad son errores de elevación de permisos de ejecución.
- CVE-2019-7286: Una app podía conseguir privilegios elevados a través de una corrupción de la memoria, por una entrada de datos no validada correctamente.
- CVE-2019-7287: La misma corrupción de memoria podía afectar a la librería de gestión de entrada y salida del sistema, y permitir a esa app que ha conseguido privilegios elevados, ejecutar código arbitrario con permisos de kernel (de propietario del sistema).
Y nos vamos a poner muy serios con esto, porque esta elevación de permisos permite instalar y ejecutar de forma permanente un software de monitorización en nuestro dispositivo. Software que permite extraer todos sus datos, grabar llamadas y enviar dichas grabaciones a servidores remotos (u oírlas en tiempo real), obtener la localización exacta, activar las cámaras y obtener vídeo o foto de lo que hay delante de ellas, activar y oír los micrófonos y lo que pasa alrededor del dispositivo obteniendo grabaciones... todo sin que el usuario sea en absoluto consciente de esto salvo por un curioso gasto inusual de la batería en su dispositivo.
Cadena de exploits
El primero de los exploits, según la investigación de Google, es de la época de iOS 10 y permite, básicamente, hacer jailbreak al dispositivo. Google, en un extenso artículo que podéis leer aquí nos da el detalle exhaustivo sobre cómo explotar esta vulnerabilidad con todo el detalle técnico. Al final, el ataque a la capa de entrada-salida al sistema conseguía lo que hemos comentado: circunvenir la comprobación de firma de código que es comprobada por el proceso amfid o Apple Mobile File Integrity Daemon. Este proceso es el encargado que cada código que vaya a ejecutarse en memoria provenga de una fuente firmada digital por Apple y validada.
¿Y qué es la firma? Es obtener un hash o dato de comprobación de un código y cifrarlo para una comprobación posterior. Si yo tengo un programa, este son datos. Le calculo un hash o código de comprobación que valide su autenticidad. Un dato único extraído de una serie de operaciones aritméticas con todos sus datos y que en el momento que un solo número de esos datos cambia, obtenemos un hash diferente.
Cifro ese dato con el certificado de Apple, con la parte de la clave privada que solo Apple tiene. Un certificado digital tiene siempre dos partes: la parte privada que permite cifrar y la pública que permite solo descifrar aquello que la parte privada cifró. Cuando tengo ese hash, lo cifro y lo pongo junto a la app. El sistema vuelve a calcular el hash de un código que vaya a ejecutarse, se descifra el valor cifrado con anterioridad y si el hash calculado y el guardado coincide, la firma es correcta y se autentica que el código no se modificó en forma alguna desde que Apple cifró esa comprobación. Esa es la esencia.
Pero si consigo pasar por encima de ese proceso, lo que obtengo es que puedo ejecutar cualquier código de cualquier fuente sin restricción alguna (lo que conocemos como un jailbreak) además de poder acceder a cualquier parte del sistema sin restricciones y de su memoria. Algo sumamente peligroso. Por eso cuando la gente habla libremente del jailbreak y de lo maravilloso que es, no se dan cuenta del problema de seguridad tan importante que es para nosotros y cómo con la simple visita de una web o un email que nos envíen o una app que nos bajemos que nadie ha supervisado previamente, podemos abrir nuestro dispositivo a cualquiera que quiera monitorizarlo y/o extraer toda su información con cualquier propósito poco ético.
Otro de los exploits, fue hecho para atacar a sistemas desde iOS 10.3 y fue parcheado en iOS 11.2 por Apple. Podéis leer la información aquí. Este permitía leer y escribir la memoria del kernel del sistema (del núcleo del mismo). Normalmente esta memoria está protegida por unas tablas que usan la técnica KASLR o Kernel Address Space Layout Randomization, un método por el que la memoria que es reservada por las operaciones del núcleo están en zonas aleatorias de la misma, nunca en el mismo sitio, y por lo tanto para un atacante es más difícil deducir cuál será la dirección donde pueda haber tal dato u otro que resulta de una ejecución de un proceso del kernel. Acceder a esta memoria, es un paso más para conseguir saber donde está el proceso del amfid que permite saltar la comprobación de firma del sistema.
El siguiente y tercero, cuya información está aquí, permite engañar al sistema para colocar un código en la carpeta temporal del mismo /tmp, y conseguir privilegios de ejecución cuando cualquier contenido en esta ruta no debería tenerlos por sistema. Básicamente, accede a la caché de la base de datos de confianza del kernel (ahí el fallo) y sustituye las credenciales de un proceso permitido por las de este código puesto en la carpeta temporal. Y esto engaña al sistema permitiendo a la app que se ha cargado desde web y que no debería poder ejecutarse (pero se ha conseguido que se ejecuta porque ya no comprobamos la firma), escapar del sandbox de las apps.
El cuarto, es la forma en que se accede a la tabla de KASLR y así poder determinar dónde el sistema guardará la información importante de los procesos que se ejecutan en el núcleo y poder cambiarla para desviar el flujo hacia un código malicioso. La información esta aquí.
Y el último, es un fallo de seguridad encontrado a la vez por un miembro del equipo de Google Project Zero (que fue acreditado por Apple en las notas de iOS 12.1.3 donde fue parcheado el fallo) y por el hacker @S0rryMyBad que ganó un premio de 200.000 dólares en la Conferencia de Seguridad TianFu Cup PWN. Un fallo que, de nuevo, por un error en la validación de los datos en C, permitía que una app pudiera ejecutarse fuera del sandbox del sistema. Un error en el uso de la cartera de certificados. El fallo está explicado aquí.
Todos estos fallos en cadena, básicamente estaban pensados para que una visita de un dispositivo, con versiones de iOS 10 a iOS 12, con versiones no parcheadas, encontraran la forma de ser explotados. Por el aprovechamiento de uno o varios de los 14 errores de seguridad.
Resumiendo todo
Si miramos el timeline publicado por Google de los errores bajo estas líneas, veremos fácilmente que hablamos de 5 fallos que fueron explotados en diferentes momentos de tiempo y que fueron cerrados por diferentes parches por parte de Apple.
En el diagrama vemos claramente el espacio de tiempo que los sistemas fueron vulnerables, en el caso más largo de unos 9 meses. Es importante notar que estos fallos, cuando fueron encontrados por Google al detectar la web que los aprovechaba, ya estaban subsanados 3 de ellos como hemos comentado, por parte de Apple. Solo los últimos dos de los que hemos hablado en detalle fueron los arreglados en iOS 12.1.4 el 7 de febrero de 2019, justo una semana después que Google informara de los mismos.
Como podéis ver, nadie está seguro. Sería absurdo pensar que iOS es un mal sistema operativo por todo lo que puede llegarse a conseguir con fallos como los que hemos comentado, a pesar de todo el esfuerzo que ponga Apple. Como ya hemos dicho, nadie está a salvo y usar un dispositivo conectado a la red nos expone a estos errores con cualquier sistema.
Cualquier sistema operativo, móvil o de escritorio, servidor web, app... cualquier software es susceptible de tener una vulnerabilidad y que esta sea explotada. El esfuerzo de grupos como Google Project Zero es encomiable y digno de aplauso porque nos ayudan a que estemos cada día un poco más a salvo. Pero "los malos" siguen trabajando y son muy buenos en lo suyo. Hoy día, un zero-day de iOS puede llegar a cotizarse en "el mercado negro" en millones de dólares, pero lo importante es la ética de no querer aprovecharse y que las compañías, como Apple, ofrezcan recompensas y reconocimiento a aquellos investigadores que con mucho esfuerzo, encuentran esos agujeros por los que no debería pasar nadie.
¿Esto puede solucionarse algún día? ¿Se podrá hacer código seguro? Cada día el código es más seguro, pero siempre habrá o se podrá encontrar un camino por el que pasar por encima de la seguridad. Es imposible, y cualquier consultor en seguridad como yo te lo confirmará: hacer un código perfecto es imposible porque el código lo hace un ser humano y los ataques son tan específicos y enfocados que no hay herramientas hoy día capaces de localizarlos.
Solo la investigación de expertos hace posible que estemos algo más protegidos. Eso y actualizar todo a la última versión. Porque son decenas y cientos de agujeros los que se tapan cada año en todos los sistemas. Muchos que nunca llegan a la opinión pública. No subestimemos la necesidad de actualizar por nuestra seguridad.
Ver 27 comentarios