¿Cómo deshabilito o elimino la cuenta raíz creada como efecto secundario de este error de seguridad de High Sierra?


40

Este artículo describe un error en el que ingresar root cuando se le solicita un desbloqueo permite a cualquier usuario desbloquear las preferencias del sistema. Advierte que:

No hay necesidad de hacerlo usted mismo para verificarlo. Hacerlo crea una cuenta "raíz" que otros podrán aprovechar si no la deshabilita.

El artículo no describe qué hacer si un ingeniero demasiado ansioso reprodujo el problema y ahora necesita eliminar o deshabilitar la cuenta raíz.

¿Cómo se puede desactivar o eliminar esta cuenta de forma segura?

Esta página de Apple describe cómo deshabilitar la cuenta, pero esto no protege contra la falla porque la falla solo puede volver a habilitar la cuenta. Funcionará para restaurar el sistema a su estado normal con la raíz deshabilitada una vez que se solucione el error de seguridad.

Actualización 2017-11-29 16:43 UTC

Consulte Acerca del contenido de seguridad de la Actualización de seguridad 2017-001 para actualizar macOS High Sierra para evitar eludir la autenticación del administrador sin proporcionar la contraseña del administrador.


El título de esta pregunta es un XY como se indica actualmente, ya que no se desea eliminar o deshabilitar la cuenta.
Monty Harder

Respuestas:


40

Parche disponible, haga clic aquí, o simplemente actualice en la máquina

Curiosamente, todavía no hay parche para las versiones beta y de desarrollador de OSX, que yo sepa. Actualizaré esta respuesta tan pronto como escuche de ellos.

Descargue el parche de arriba. Dejando el resto de la publicación para la historia :-)

El CVE es CVE-2017-13872 y NIST actualizará el análisis en un futuro próximo.

Respuesta original, relevante sin parche

En primer lugar, no deshabilite la cuenta raíz a través de la GUI, tener una cuenta raíz "deshabilitada" es la causa del problema.

Deberá habilitar al usuario root y darle una contraseña. Esto es importante , ya que la vulnerabilidad también está disponible de forma remota, a través de VNC y Apple Remote Desktop (por nombrar algunos) (otra fuente) .

Hay dos formas básicas de hacer esto; GUI y terminal.

Primero apagado, GUI

Para habilitar la cuenta raíz, vaya a "Utilidad de directorio", es decir, cmd + espacio y busque. Presione el candado para desbloquear el "modo administrador", luego habilite la cuenta raíz mediante la edición -> "Habilitar usuario raíz".

Cómo habilitar root

Debería solicitar una contraseña de root, por ahora ingrese su contraseña normal (para que no la olvide). Si no solicita una contraseña, use Editar -> "Cambiar contraseña de root ..." arriba.

Terminal

Si eres más una persona terminal, usa lo siguiente:

sudo passwd -u root
## Enter passwords as needed.... 
## (if you are using the terminal you should know what you are doing...)

Esto es suficiente con un terminal, el problema con la forma de la GUI es que tenemos que habilitar la cuenta para establecer una contraseña, lo que no tenemos que hacer con el terminal.

Notas

Incluso si tiene una contraseña establecida para la cuenta raíz, su computadora se volverá vulnerable si deshabilita la cuenta raíz. La acción de deshabilitar la cuenta raíz parece ser la culpable. Entonces, repito, el usuario root debería estar habilitado y tener una contraseña si usa la GUI, mientras que a través de la terminal solo usando 'passwd' es "ok" (aunque este estado es inalcanzable solo a través de la GUI). Parece que el "Deshabilitar usuario raíz" en "Utilidad de directorio" elimina la contraseña de la cuenta raíz, en cierto sentido, proporcionándole una cuenta raíz sin contraseña que es vulnerable.

Parece que intentar iniciar sesión con "root" en una ventana de inicio de sesión del sistema habilita la cuenta root si está deshabilitada previamente. Es decir, con una cuenta raíz deshabilitada, debe ingresar la raíz dos veces en las ventanas de inicio de sesión de los sistemas para obtener acceso a la raíz, y (según mis pruebas) en el primer intento, la cuenta raíz está habilitada (sin contraseña si no se establece a través de passwd), y en el segundo intento que atraviesas.

Parece que el problema ha estado abierto desde al menos 2017-11-13 (13 de noviembre), cuando se menciona en el foro de soporte de Apple .

Por favor, demuéstrame que estoy equivocado, realmente agradecería estar equivocado en este momento.

Actualización de miedo

Después de habilitar la cuenta raíz sin contraseña (es decir, a través del panel de preferencias del sistema y hacer clic en un "bloqueo" e ingresar "root" con una contraseña en blanco una, dos o tres veces (el número depende del estado inicial)) es posible iniciar sesión en la computadora desde la pantalla de inicio de sesión principal usando "root" y una contraseña en blanco (!). SSH / Telnet no parece funcionar, pero Apple Remote Desktop, Screen Sharing y VNC son vulnerables.

Por lo tanto, para los administradores de redes puede ser interesante dejar temporalmente los paquetes en los siguientes puertos:

  • 5900-5905 (ish, para ser ninja seguro) para obtener los puertos VNC más comunes. VNC comienza en 5900 de forma predeterminada y enumera hacia arriba si está utilizando múltiples pantallas (aunque es poco común). Screen Sharing y Apple Remote Desktop también parecen usar estos puertos ( lista de puertos de software de Apple )
  • 3283 y 5988 para Apple Remote Desktop ( lista de puertos de software de Apple )

Lectura adicional:

Un valiente intento de hacer referencia a otras fuentes que tratan el tema. Edite y actualice mi respuesta si tiene más.


55
Ok, veo por qué la auto respuesta es incorrecta. Deshabilitar la raíz no sirve hasta que se solucione este error, ya que el error solo volverá a habilitar la cuenta. ¡Ten algunos votos para que puedas comentar!
Freiheit

1
No soy un tipo de Mac, pero en el mundo * nix, deshabilitar la contraseña de root no debería ser menos seguro que tener una contraseña segura. De hecho, es muy común deshabilitar la contraseña y configurar el shell /dev/nullpara root. De esta manera, el acceso a la cuenta raíz se produce a través de susyscalls para usuarios con ese permiso.
crasic

1
@crasic AFAIK OSX hace algo extraño con sus ventanas de inicio de sesión del sistema. Aparentemente habilitan cuentas en general o root en específico si se intenta. Y prácticamente no hay documentación disponible de este comportamiento. Tenga en cuenta que los detalles de BSD (es decir, uso de línea de comandos / bash) no son problemáticos.
Flindeberg

Entonces, con el comando Terminal, ¿puede establecer la contraseña de root sin habilitar root? Esa parece la opción más segura.
wisbucky

1
@jcm Nah, en realidad no es solo que está mal redactado después de mover un poco el texto. Trataré de aclararlo un poco, ¿mirar en un minuto?
flindeberg

10

Si no puede instalar el parche oficial o no quiere confiar en que funcionó, entonces

No desea deshabilitar el usuario root solo en High Sierra.

Para asegurar su Mac, habilite root con una contraseña segura larga.

No vamos a cambiar esto en el trabajo hasta que salga la próxima versión completa para macOS, que probablemente sea 10.13.2


A menos que tome medidas, el usuario root está deshabilitado de inmediato y esto es malo si su Mac no está parcheada correctamente.

Si lo desea, opcionalmente endurezca la carcasa hasta que Apple tenga un parche o corrección oficial.

Aquí hay un gran script para establecer una contraseña raíz aleatoria y cambiar / configurar el shell raíz para /usr/bin/falseque, incluso si se adivina la contraseña, el shell raíz no puede iniciar sesión:

Básicamente hace tres cosas clave:

rootpassword=$(openssl rand -base64 32)
/usr/bin/dscl . -passwd /Users/root "$rootpassword"
/usr/bin/dscl . -create /Users/root UserShell /usr/bin/false

La creación de UserShell es si el shell no está configurado, y el script completo busca un shell existente y -changelo encuentra en lugar de -createusarlo.

¿Cómo me protejo de la vulnerabilidad raíz en macOS High Sierra?


1
En general, es preferible no almacenar una contraseña, incluso temporalmente, como esta. La página de manual de dcsl sugiere "no proporcione la contraseña como parte del comando y se le pedirá de forma segura"
Josh Caswell

1
De acuerdo @JoshCaswell: tenerlo en un script es mejor ya que la variable no se exporta y se genera. La buena noticia es que Apple tiene un parche oficial que hace que este truco sea una necesidad de corta duración: lo ejecutamos como un profiláctico para el daño mucho mayor de codificar la misma contraseña en toda la flota o no tener ninguna contraseña. Seguramente fue un compromiso y no una solución.
bmike

Por pura curiosidad, ¿por qué tiene un enlace a esta pregunta al final de su respuesta?
reirab

1
@reirab totalmente en mal estado. Vea editar para arreglar el enlace apropiado. ¡Gracias!
bmike


0

Debe iniciar sesión como usuario root y cambiar la contraseña a algo seguro. Si realmente crea una nueva cuenta (en lugar de habilitar la cuenta raíz ya existente), primero debe eliminar esa cuenta.


Mira mi auto respuesta. Su consejo para establecer una contraseña segura es razonable, pero deshabilitar por completo la cuenta parece una protección aún más rigurosa y restaura OS X a su estado predeterminado. support.apple.com/en-us/HT204012 . ¿Establecer una protección de contraseña segura contra la explotación del error descrito incluso si la cuenta raíz se vuelve a habilitar?
Freiheit

En High Sierra, 10.13.0 y 10,13.1, absolutamente no desea deshabilitar la cuenta raíz. El problema es que si la raíz está deshabilitada e intenta usar cualquier ventana de inicio de sesión para iniciar sesión como root, la ventana de inicio de sesión habilitará la cuenta de root con una contraseña en blanco. Si la raíz ya está habilitada con una contraseña segura, la Ventana de inicio de sesión no borra la contraseña. La única mitigación es habilitar la raíz con una contraseña segura .
Brian Reiter

0

Apple acaba de lanzar una actualización para solucionar el problema.

Actualización de seguridad 2017-001 https://support.apple.com/en-us/HT208315

Además, para evitar el acceso no autorizado a sus computadoras Mac, debe habilitar la cuenta de usuario root y establecer una contraseña específicamente para el usuario root.

https://support.apple.com/en-ph/HT204012

Si su cuenta de usuario raíz ya está activa, asegúrese de cambiar la contraseña solo para asegurarse de que la vulnerabilidad de contraseña en blanco no esté establecida.


0

¡No! ¡No elimines la cuenta raíz!

En primer lugar, rootha estado presente en todas las versiones de macOS, Mac OS X, Mac OS e incluso en versiones antiguas del sistema operativo. macOS no creó recientemente esta cuenta debido a una vulnerabilidad. Simplemente lo expuso por accidente.

Eliminar rootsería una muy mala idea, y déjame decirte por qué.

Esto paralizaría por completo a macOS, ya que no habría una cuenta con suficientes privilegios para ejecutar servicios críticos (como WindowServer, que ejecuta la GUI). Existen medidas de seguridad para evitar que los usuarios despistados se eliminen root, y no debe intentar evitarlas.

Averigüemos quién ejecuta los primeros procesos en el sistema, los procesos más importantes (usando Activity Monitor):

kernel_task y launchd también son propiedad de

¡Hola, es nuestro vecindario amigable rootnuevamente! El primer proceso (con PID 0) en realidad está controlado por el kernel, y probablemente tendrá permisos completos de todos modos, pero su proceso hijo launchd(responsable de iniciar servicios como la ventana de inicio de sesión y el servidor de ventana en sí) se inicia con los privilegios de root. Si rootno existiera, este proceso nunca habría comenzado o no tendría permisos.

Asegurar la cuenta raíz

Otras respuestas han proporcionado un parche lanzado por Apple que debería solucionar el problema. Sin embargo, si no puede o no desea instalarlo ...

Funciona porque macOS vuelve a codificar la contraseña ingresada como una "actualización" porque la cuenta deshabilitada (root) se detectó incorrectamente como un hash antiguo. Todavía dirá que es incorrecto, pero la próxima vez, los hash coincidirán (porque macOS lo cambió) y le permitirá ingresar.

Para asegurar root, deberá usar la Utilidad de directorio. Hay dos formas de acceder a él:

  1. Use Spotlight. Inicio de la Utilidad de directorio con Spotlight
  2. Buscador de uso. Abre Finder, presiona Comando + Mayús + G (o selecciona, ingresa /System/Library/CoreServices/Applications/y presiona Ir (o presiona Intro). Luego, abre la Utilidad de directorio desde allí.Seleccionando Ir Seleccionar a dónde ir Utilidad de directorio de apertura

Una vez que haya abierto Directory Utility, deberá haga clic en el candado para hacer cambios

Una vez que hayas hecho eso, selecciona Change Root Passwordo Enable Root Userdesde el menú Editar. Lo muestro Change Root Passwordya que mi cuenta raíz ya está habilitada con una contraseña segura.

Seleccionar Cambiar contraseña de root

Elija una contraseña, y ahora la contraseña en blanco ya no funcionará.

Elegir una contraseña

¡Felicidades! Ya no eres vulnerable al hack de root.


"Adivinando por pura especulación, el sistema probablemente vuelve a habilitar la cuenta raíz porque ingresó la contraseña correcta (en blanco en este caso)", no del todo correcto. Hay una ruta de migración para actualizar las contraseñas utilizando un antiguo mecanismo de hashing, y no maneja !(que, como tipo UNIX, probablemente reconocerá) correctamente.
Charles Duffy

Ver Objective-see.com/blog/blog_0x24.html para un análisis de causa raíz.
Charles Duffy

Correcto, así que mi especulación no era precisa. Entonces, ¿vuelve a usar una contraseña en blanco como "actualización" porque la cuenta deshabilitada se detectó incorrectamente como si tuviera un hash anterior? ¿Estoy en lo correcto?
Dev

En teoría, lo que se supone que debe hacer en esta ruta de código es verificar que el antiguo algoritmo hash valide la contraseña ingresada y luego actualizar con un nuevo hash (de la contraseña ingresada, que se sabe que coincide con la anterior). En la práctica, no verifica los errores de la función que se supone que recupera el hash anterior del campo "ShadowHash" (o, más bien, verifica solo el valor de retorno, pero no el valor de referencia pasado utilizado para devolver el resultado de la comparación), y luego genera un nuevo hash de la contraseña (¡vacío o no!).
Charles Duffy

... entonces, más o menos, sí, tienes razón. :)
Charles Duffy
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.