Analizando la grave vulnerabilidad "I Am Root" en macOS High Sierra

El 28 de noviembre se hizo pública una de las mayores vulnerabilidades nunca vista en un sistema operativo de Apple. Básicamente, cualquier usuario podía utilizar la cuenta "root" sin contraseña para acceder con estos derechos de administrador al sistema, es decir, con acceso total al equipo. Una vez solucionado el problema (este error fue resuelto en la actualización de seguridad 2017-001)  es interesante echar la mirada atrás para intentar comprender los orígenes de esta grave vulnerabilidad.

Este bug se llamó "#IAmRoot" o "#rootgate" y funcionaba en las versiones de macOS High Sierra 10.13 o 10.13.1 sin parchear, haciendo posible que cualquier atacante pudiera abrir una ventana de autenticación y utilizar la cuenta "root" sin contraseña. Realmente no se estaba accediendo sin contraseña, lo que ocurría es que se estaba habilitando la cuenta "root" y al no poner contraseña, estábamos asignado una contraseña en blanco como clave de dicha cuenta. Si la cuenta "root" ya estaba activada previamente, este problema de seguridad no aparecía.

Figura 1. Demostración de acceso root sin contraseña. Fuente.

Este acceso requería estar físicamente delante del ordenador para poder acceder aunque más tarde se demostró una forma de acceder remotamente, siempre y cuando se cumplieran alguna condiciones de configuración en el equipo víctima. Por ejemplo, si el Mac tenía activada la opción de compartir pantalla (Screen Sharing), entonces era posible el acceso por cualquier persona dentro la misma red local. Una vez conseguido este acceso era posible también activar el acceso remoto o la compartición de ficheros.

La primera noticia que tenemos de esta vulnerabilidad apareció en un hilo dentro del foro de desarrolladores de Apple, el 13 de noviembre de 2017. No se habla directamente del problema "root" en sí, sino que aparece después de que un usuario preguntara algunas dudas sobre errores de instalación en la nueva versión de macOS Sierra (aquí podéis ver todo el hilo). Abajo podéis ver una captura de la respuesta dada por un usuario llamado "chethan177", que dice literalmente y parece ser que sin ser consciente del problema "introduce el nombre de usuario: root y deja la contraseña vacía. Pulsa enter (inténtalo dos veces)".

Figura 2. Respuesta en foro de desarrolladores de Apple que delata el problema de #IAmRoot. Fuente.

A partir de aquí empieza una cadena de respuestas centrándose en esa última frase la cual desata y pone en evidencia el problema del "#IAmRoot". Más tarde, una semana después, aparece un video en Twitter donde se demuestra la vulnerabilidad, pero Apple no respondió ni tomo ninguna medida. El problema comenzaría de verdad cuando un desarrollador desde Turquía publicó un tweet donde explicaba con todo detalle cómo explotar la vulnerabilidad. Esta actitud se criticó bastante ya que no es precisamente la mejor práctica publicarlo en Twitter sin antes haberlo discutido internamente con Apple, ya que estaba publicando un ataque "zero day" en toda regla al resto del mundo sin dar tiempo de reacción a solucionarlo.

Otro punto interesante a analizar es cómo ha podido ocurrir este grave problema desde el punto de vista de código. Al parecer, esta vulnerabilidad catalogada como CVE-2017-13872, es un error lógico de programación (un error a la hora de comprobar el resultado de una comparación) del equipo de desarrollo de Apple. En este enlace podéis encontrar un magnífico análisis exhaustivo centrado en el demonio "opendirectory". El problema se basa en el estado "deshabilitado" de la cuenta "root", ya que un error de código el cual verifica las contraseñas de las cuentas, no realizaba correctamente esta comprobación en las cuentas deshabilitadas, dando por lo tanto la opción de dejarla en blanco o introducir una nueva contraseña. La solución a este problema era realmente simple, sólo había que comparar la contraseña con la variable correcta. En esta captura se puede apreciar perfectamente la corrección (arriba la parte sin parchear y abajo parcheada), en la cual se añaden y modifican sólo un par de líneas de código:

Figura 3. Parte desensamblada del código que muestra el problema y la solución a #IAmRoot. Fuente.

Esta vulnerabilidad en el código se parece bastante a otra llamada "goto fail", que apareció en 2013 en las versiones tempranas de OS X Mavericks. Este error fue incluso más simple que el fallo "root", y se debió a la inclusión de una línea de código duplicada la cual permitía realizar un ataque tipo "man in the middle" para interceptar tráfico https. De nuevo, un fallo de programación que no fue detectado por los exhaustivos controles de calidad de Apple y que sólo se detecto una vez el sistema operativo (o la actualización correspondiente) se hizo público.