sideeffect42/rootpipetesterRootPipe (CVE-2015-1130) y Phoenix (CVE-2015-3673) utilidad de prueba de vulnerabilidades para Mac OS X 10.2.8 y posteriores
RootPipe Tester es una pequeña aplicación que se ejecuta en tu Mac (Mac OS X 10.2.8 o superior, tanto PowerPC como Intel) e intenta usar tanto el exploit RootPipe (CVE-2015-1130) como Phoenix (CVE-2015-3673) para producir una escalada de privilegios.
Si tu Mac es vulnerable depende de la versión de Mac OS X que estés ejecutando, pero su éxito también depende de las preferencias que hayas establecido.
Con RootPipe Tester he creado una solución de un solo clic para que verifiques si eres vulnerable sin tener que hacer pruebas exhaustivas y ensayos.
Descarga la imagen de disco desde la página de lanzamientos de este repositorio o compílala por tu cuenta si lo prefieres.
Monta la imagen de disco y ejecuta la aplicación que contiene (es seguro ejecutar RootPipe Tester desde la imagen de disco).
Haz clic en "Iniciar prueba" y deja que la prueba se ejecute (puedes saber si ha terminado por el mensaje "Ejecutándose…" en el título de la ventana).
Para obtener resultados precisos, recomiendo reiniciar tu Mac y ejecutar la prueba nuevamente en un "inicio de sesión limpio".
Si al menos una de las pruebas detectó un sistema vulnerable, es posible que quieras consultar la sección PÁNICO.
¡No! Mantén la calma y lee la guía adecuada para la versión de tu sistema.
Nota: "No vulnerable" en autorización de usuario significa que el sistema no otorgará acceso o mostrará un cuadro de diálogo de autorización que te solicita autenticarte como usuario administrador.
Hasta cierto punto, esto también es una escalada de privilegios, porque el grupo de administradores no tiene tantos derechos como root, pero en la configuración predeterminada de sudo, todo usuario del grupo "admin" puede obtener root ingresando su contraseña, por lo que el mismo efecto también se puede lograr simplemente ejecutando sudo.
Actualiza a 10.10.3 lo antes posible para asegurarte de que el sistema aplique correctamente los derechos (entitlements) en el binario writeconfig (al menos eso es lo que dice Apple).
Si por alguna razón no puedes actualizar a 10.10.3, consulta la sección para OS X 10.9 Mavericks.
Mavericks permite que un atacante pase con autorización nula, por lo que te encuentras en una situación mucho más difícil que con versiones anteriores de Mac OS X.
Puede que quieras echar un vistazo a can_I_suid.
Resultados de la prueba:
Vulnerable
Deberías habilitar "Requerir contraseña para desbloquear cada panel de Preferencias del Sistema" en el panel de preferencias de Seguridad.
Resultados de la prueba:
No vulnerable
¡Felicidades! Tienes una de las versiones más seguras de Mac OS X (al menos en lo que respecta a RootPipe).
En estos sistemas, la casilla "Requerir contraseña para desbloquear cada panel de Preferencias del Sistema" ("Requerir contraseña para desbloquear cada preferencia segura del sistema" en Tiger) en el panel de preferencias de Seguridad funciona correctamente y debería estar realmente habilitada!
Nota: Si la casilla "Requerir contraseña" no está marcada, el sistema desbloqueará los paneles de preferencias seguros en cada inicio de sesión. Si usas una cuenta de administrador, esto hará que tu sistema sea vulnerable hasta que hayas cerrado manualmente el candado en Preferencias del Sistema después de cada inicio de sesión.
Resultados de la prueba:
No vulnerable
A diferencia de sistemas posteriores, en Panther, la casilla "Requerir contraseña para desbloquear cada preferencia segura del sistema" en el panel de preferencias de Seguridad no tiene el efecto de impedir completamente que este exploit funcione. Aun así, recomiendo marcarla.
Para asegurar tu sistema, recomiendo encarecidamente que solo uses una cuenta de usuario estándar y que siempre "cierres el candado" manualmente después de cambiar preferencias en Preferencias del Sistema.
Cerrar Preferencias del Sistema solo no invalidará correctamente la autorización y este exploit funcionará hasta que cierres sesión, aunque la interfaz gráfica de Preferencias del Sistema muestre un candado cerrado como usuario estándar.
Resultados de la prueba:
No vulnerable
A diferencia de sistemas posteriores, Jaguar no proporciona una casilla "Requerir contraseña para desbloquear cada preferencia segura del sistema", pero aún así desbloquea los paneles de preferencias seguros al iniciar sesión para todos los usuarios administradores.
Para asegurar tu sistema, recomiendo encarecidamente que solo uses una cuenta de usuario estándar.
Nota: Jaguar no bloquea los paneles de preferencias seguros cuando se cierra Preferencias del Sistema, por lo tanto, siempre bloquea los paneles seguros manualmente. Si no lo haces, el exploit funcionará hasta que cierres sesión.
Nota: Si no puedes cambiar a una cuenta de usuario estándar, un simple AppleScript que bloquee los paneles de preferencias seguros como elemento de inicio podría hacer el trabajo.
Nota: La versión normal de RootPipe Tester no se ejecutará en Jaguar. Descarga la versión Legacy de RootPipe Tester si deseas ejecutarlo en Jaguar.
La versión Legacy de RootPipe Tester tiene la misma funcionalidad que la versión normal, pero está compilada con GCC 3.1 en lugar de GCC 4.0.
Resultados de la prueba:
No vulnerable
Un exploit para Puma parece factible, porque utiliza los mismos pasos para autenticar Preferencias del Sistema y la mayoría de los componentes necesarios están presentes.
Lo único que dificulta un exploit es que Puma no tiene SecurityFoundation.framework, que se utiliza en versiones posteriores para autorizar.
En su lugar, utiliza un PrivateFramework llamado NIInterface.framework que necesita ser sometido a ingeniería inversa primero.
De todas formas, buenas noticias: nadie va a invertir tiempo en explotar una base de usuarios probablemente insignificante.
Para mejorar la seguridad, se recomienda solo usar una cuenta de usuario estándar y bloquear manualmente los paneles de preferencias seguros.
Nota: Toma este párrafo con cautela. Hice todo lo posible para descubrir qué está sucediendo realmente, pero como todo son PrivateFrameworks, nunca se puede saber al 100% qué están haciendo estos métodos, especialmente a lo largo de tantas versiones de Mac OS X como intento cubrir.
La forma en que funciona el exploit RootPipe es básicamente la misma que usa Preferencias del Sistema para escribir archivos de configuración (de ahí el nombre WriteConfig), con la excepción de que los usuarios de este exploit no deben ser la aplicación Preferencias del Sistema.
Hasta ahora no es tan horrible, y en realidad todo el exploit tampoco es tan horrible.
Pero veamos el código.
// Authorization
SFAuthorization auth = [SFAuthorization authorization];
id authenticator = [Authenticator sharedAuthenticator];
[authenticator authenticateUsingAuthorizationSync:auth];
// Profit?
id sharedLiaison = [ToolLiaison sharedToolLiaison];
id tool = [sharedLiaison tool];
Como puedes ver, este es código de "estilo antiguo", pero el principio para el nuevo estilo es más o menos el mismo.
Las primeras tres líneas de este fragmento son autorización y las dos últimas son la parte divertida.
Si un panel de preferencias en Preferencias del Sistema necesita realizar operaciones que deben ejecutarse con privilegios, colocará una SFAuthorizationView (el símbolo del candado) en la esquina inferior izquierda. Esta SFAuthorizationView manejará la adquisición y destrucción del derecho system.preferences.
Hasta aquí todo bien, pero ¿qué es este system.preferences?
Los derechos que Apple usa y cómo están configurados han cambiado con el tiempo, pero el principio se ha mantenido igual. A continuación se muestra un extracto de la Base de Datos de Políticas de Servicios de Autorización.
system.preferences en 10.5.8
{
"allow-root" = 1;
class = user;
comment = "Checked by the Admin framework when making changes to certain System Preferences.";
group = admin;
shared = 1;
}
Como puedes ver, es un derecho compartido. Esto significa que una vez que este derecho ha sido adquirido por cualquier proceso, cualquier otro proceso puede usarlo mientras la sesión no sea destruida (cuando cierras sesión).
Esto por sí mismo no es tan malo, porque tienes que autorizar la primera vez que una aplicación quiere usar system.preferences, desafortunadamente el sistema lo autoriza automáticamente al iniciar sesión (para usuarios administradores).
Esto significa que nuestro RootPipe Tester no tendrá que ser autorizado y en su lugar puede usar la autorización del sistema.
Los usuarios estándar están seguros, porque el sistema no autoriza el derecho system.preferences al iniciar sesión.
Con la autorización adecuada adquirida, es un juego bastante fácil escribir archivos de configuración (o cualquier otro archivo) con derechos arbitrarios.
ToolLiaison felizmente configurará un NSDistantObject para writeconfig y writeconfig escribirá felizmente el archivo para ti, porque en su mente, te has autorizado correctamente.
Marcar la casilla "Requerir contraseña para desbloquear cada panel de Preferencias del Sistema" en Preferencias del Sistema corrige RootPipe en todas las versiones de Mac OS X desde 10.4 hasta 10.8.
Marcar esta casilla modificará el derecho system.preferences y establecerá shared en falso.
Si un derecho no es compartido, significa que cada proceso debe obtener su propia autorización. Debido a que obtener autorización requiere que el usuario ingrese la contraseña de un administrador, el ataque puede ser notado por el usuario.
Además, simplemente ejecutar sudo tendrá el mismo efecto, lo que hace que este ataque sea inútil.
En realidad no. A primera vista podría parecerlo, porque está en un PrivateFramework que se ejecuta como root y no realiza una autenticación adecuada.
Pero el verdadero problema aquí es más bien de mal diseño. Apple quería asegurarse de que todo usuario administrador tenga la capacidad de usar Preferencias del Sistema al máximo, y en Unix todo necesita un archivo de configuración y estos deben escribirse (la mayoría de las veces como root).
Se podría argumentar que esto es una mala idea (estaría de acuerdo), pero no lo consideraría una puerta trasera, ya que la autenticación funciona correctamente y todo administrador tiene la capacidad de obtener root mediante sudo de todas formas.
El problema principal aquí es que Apple priorizó la comodidad sobre la seguridad, pero esto tampoco es algo muy especial para ellos.