Come posso disabilitare o rimuovere l'account di root creato come effetto collaterale da questo bug di sicurezza di High Sierra?


40

Questo articolo descrive un bug in cui l'inserimento di root quando viene richiesto di sbloccare consente a qualsiasi utente di sbloccare le preferenze di sistema. Avverte che:

Non è necessario farlo da soli per verificarlo. In questo modo si crea un account "root" che altri potrebbero essere in grado di sfruttare se non lo si disabilita.

L'articolo non descrive cosa fare se un ingegnere troppo desideroso ha riprodotto il problema e ora deve rimuovere o disabilitare l'account di root.

In che modo questo account può essere disabilitato o rimosso in modo sicuro?

Questa pagina Apple descrive come disabilitare l'account ma ciò non protegge dall'errore perché l'errore può semplicemente riattivare l'account. Funzionerà per ripristinare il sistema al suo stato normale con root disabilitato una volta corretto il bug di sicurezza.

Aggiornamento 29/11/2017 16:43 UTC

Consulta Informazioni sul contenuto di sicurezza dell'aggiornamento di sicurezza 2017-001 per aggiornare macOS High Sierra per proteggere dall'esclusione dell'autenticazione dell'amministratore senza fornire la password dell'amministratore.


Il titolo di questa domanda è un XY come attualmente indicato, in quanto non si desidera rimuovere o disabilitare l'account.
Monty Harder,

Risposte:


40

Patch disponibile, fai clic qui o aggiorna semplicemente sulla macchina

È interessante notare che non ci sono patch per la versione beta e per gli sviluppatori di OSX, per quanto ne so. Aggiornerò questa risposta non appena ne avrò sentito parlare.

Scarica la patch sopra. Lasciando il resto del post per la storia :-)

Il CVE è CVE-2017-13872 e il NIST aggiornerà l'analisi nel prossimo futuro.

Risposta originale, pertinente senza patch

Prima di tutto, non disabilitare l'account root tramite la GUI, avendo un account root "disabilitato" è la causa del problema.

Devi abilitare l'utente root e dargli una password. Questo è importante , poiché la vulnerabilità è disponibile anche in remoto, tramite VNC e Apple Remote Desktop (solo per citarne alcuni) (un'altra fonte) .

Esistono due modi di base per farlo; GUI e terminale.

Prima di tutto, GUI

Per abilitare l'account root, vai su "Directory Utility", ovvero cmd + spazio e cerca. Premi il lucchetto per sbloccare la "modalità amministratore", quindi abilita l'account root tramite modifica -> "Abilita utente root".

Come abilitare root

Dovrebbe richiedere una password di root, per ora inserisci la tua normale password (in modo da non dimenticarla). Se non richiede una password, usa Modifica -> "Cambia password di root ..." sopra.

terminale

Se sei più di una persona terminale, utilizza quanto segue:

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

Questo è abbastanza con un terminale, il problema con la GUI è che dobbiamo abilitare l'account a impostare una password, cosa che non dobbiamo fare con il terminale.

Gli appunti

Anche se hai impostato una password per l'account di root, il tuo computer diventerà vulnerabile se disabiliti l'account di root. L'azione di disabilitare l'account di root sembra essere il colpevole. Quindi ripeto, l'utente root dovrebbe essere abilitato e avere una password se usa la GUI, mentre tramite il terminale solo usare "passwd" è "ok" (sebbene questo stato non sia raggiungibile solo attraverso la GUI). Sembra che "Disabilita utente root" in "Directory Utility" rimuova la password per l'account root, in un certo senso dandoti un account root senza password che è vulnerabile.

Sembra che provare ad accedere con "root" in una finestra di login del sistema abiliti l'account root se è stato disabilitato in precedenza. Vale a dire con un account root disabilitato è necessario inserire due volte root in una finestra di login di sistema per ottenere l'accesso root e (secondo i miei test) al primo tentativo l'account root è abilitato (senza password se non impostato tramite passwd), e al secondo tentativo si passa attraverso.

Sembra che il problema sia stato scoperto almeno dal 13-11-2017 (13 novembre), quando è menzionato nel forum di supporto Apple .

Per favore, dimostrami che mi sbaglio, apprezzerei davvero essere in questo momento.

Aggiornamento spaventoso

Dopo aver abilitato l'account root senza password (cioè attraverso il pannello delle preferenze di sistema e facendo clic su un "blocco" e immettendo "root" con una password vuota una, due o tre volte (il numero di volte dipende dallo stato iniziale)) è possibile accedere a il computer dalla schermata di accesso principale utilizzando "root" e una password vuota (!). SSH / Telnet non sembra funzionare, ma Apple Remote Desktop, Screen Sharing e VNC sono vulnerabili.

Pertanto, per gli amministratori di reti potrebbe essere interessante rilasciare temporaneamente i pacchetti alle seguenti porte:

  • 5900-5905 (ish, per essere ninja sicuri) per ottenere le porte VNC più comuni. VNC inizia per impostazione predefinita a 5900 ed enumera verso l'alto se si utilizzano più display (non comune però). Anche Screen Sharing e Apple Remote Desktop sembrano usare queste porte ( elenco delle porte del software Apple )
  • 3283 e 5988 per Apple Remote Desktop ( elenco delle porte del software Apple )

Letture addizionali:

Un coraggioso tentativo di fare riferimento ad altre fonti che affrontano il problema. Modifica e aggiorna la mia risposta se ne hai di più.


5
Ok, vedo perché la risposta è sbagliata. La disabilitazione di root non serve fino a quando l'errore non viene risolto poiché l'errore stesso riattiverà l'account. Avere alcuni voti in modo da poter commentare!
Freiheit,

1
Non sono un tipo mac, ma nel mondo * nix, disabilitare la password di root non dovrebbe essere meno sicuro di avere una password sicura. In effetti, è molto comune disabilitare la password e impostare la shell su /dev/nullper root. In questo modo l'accesso all'account root avviene tramite susyscalls per gli utenti con tale autorizzazione.
Crasic il

1
@crasic AFAIK OSX fa qualcosa di strano con le finestre di accesso al sistema. Apparentemente abilitano gli account in generale o root in specifici se provati. E praticamente non c'è documentazione disponibile per questo comportamento. Si noti che le specifiche di BSD (ovvero l'utilizzo della riga di comando / bash) non sono problematiche.
flindeberg,

Quindi, con il comando Terminale, puoi impostare la password di root senza abilitare root? Sembra l'opzione più sicura.
Wisbucky

1
@jcm Nah, in realtà non lo è, è solo una parola molto male dopo aver spostato un po 'il testo. Proverò a cancellarlo un po ', dai un'occhiata tra un minuto?
flindeberg,

10

Se non riesci a installare la patch ufficiale o non vuoi fidarti che abbia funzionato, allora

Non si desidera disabilitare l'utente root solo su High Sierra.

Per proteggere il tuo Mac, abilita root con una password sicura lunga.

Non lo cambieremo sul lavoro fino a quando non verrà rilasciata la prossima versione completa per macOS che probabilmente sarà la 10.13.2


A meno che tu non agisca, l'utente root è disattivato e questo è un male se il tuo Mac non è corretto correttamente.

Se lo desideri, opzionalmente indurisci la shell fino a quando Apple non avrà una patch o correzione ufficiale.

Ecco un ottimo script per impostare una password di root casuale e modificare / impostare la shell di root in /usr/bin/falsemodo che, anche se la password è indovinata, la shell di root non riesca ad accedere:

Fondamentalmente fa tre cose chiave:

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

La creazione di UserShell si verifica se la shell non è impostata e lo script completo controlla la presenza di una shell esistente ed -changeè invece di sostituirla -create.

Come proteggermi dalla vulnerabilità di root in macOS High Sierra?


1
È generalmente preferibile non memorizzare una password anche temporaneamente come questa. La pagina man di dcsl suggerisce "non fornire la password come parte del comando e ti verrà chiesto in modo sicuro"
Josh Caswell,

1
Concordato su @JoshCaswell: averlo in uno script è meglio poiché la variabile non viene esportata ed è generata. La buona notizia è che Apple ha una patch ufficiale che rende questo hack una necessità di breve durata - l'abbiamo eseguito come profilassi per il danno molto maggiore di codificare hard la stessa password in tutta la flotta o di non avere alcuna password. Era sicuramente un compromesso e non una soluzione.
bmike

Per pura curiosità, perché hai un link a questa domanda alla fine della tua risposta?
reirab

1
@reirab totalmente incasinato. Vedi modifica per correggere il collegamento corretto. Grazie!
bmike


0

Devi accedere come utente root e cambiare la password in qualcosa di forte. Se in realtà crea un nuovo account (anziché abilitare l'account root già esistente) è necessario prima eliminare tale account.


Vedi la mia risposta. Il tuo consiglio di impostare una password complessa è ragionevole ma disabilitare completamente l'account sembra una protezione ancora più rigorosa e ripristina OS X al suo stato predefinito. support.apple.com/en-us/HT204012 . L'impostazione di una protezione password sicura contro lo sfruttamento del bug descritto, anche se l'account di root fosse riattivato?
Freiheit,

Su High Sierra, 10.13.0 e 10.13.1, non vuoi assolutamente disabilitare l'account di root. Il problema è che se il root è disabilitato e si tenta di utilizzare qualsiasi finestra di login per accedere come root, la finestra di login abiliterà l'account root con una password vuota. Se root è già abilitato con una password complessa, la finestra di accesso non cancella la password. L'unica soluzione è abilitare il root con una password complessa .
Brian Reiter,

0

Apple ha appena rilasciato un aggiornamento per risolvere il problema.

Aggiornamento della sicurezza 2017-001 https://support.apple.com/en-us/HT208315

Inoltre, per impedire l'accesso non autorizzato ai computer Mac, è necessario abilitare l'account utente root e impostare una password specifica per l'utente root.

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

Se il tuo account utente root è già attivo, assicurati di cambiare la password solo per assicurarti che la vulnerabilità della password vuota non sia impostata.


0

No! Non rimuovere l'account di root!

Innanzitutto, rootè stato presente in tutte le versioni di macOS, Mac OS X, Mac OS e persino nelle versioni antiche del sistema operativo. macOS non ha creato di recente questo account a causa di una vulnerabilità. Lo ha semplicemente esposto per caso.

Rimozione rootsarebbe una pessima idea e lascia che ti dica perché.

Paralizzerebbe completamente macOS, dal momento che non ci sarebbero account con privilegi sufficienti per eseguire servizi critici (come WindowServer, che esegue la GUI). Esistono misure di sicurezza per impedire la rimozione di utenti senza informazioni roote non si dovrebbe tentare di ignorarli.

Scopriamo chi esegue i primissimi processi nel sistema, i processi più importanti (utilizzando Activity Monitor):

kernel_task e launchd sono anch'essi di proprietà di

Ehi, è di rootnuovo il nostro quartiere amichevole ! Il primo processo (con PID 0) è attualmente controllato dal kernel e probabilmente avrà comunque le autorizzazioni complete, ma il suo processo figlio launchd(responsabile dell'avvio di servizi come la finestra di accesso e il server di finestre stesso) viene avviato con i privilegi di root. Se rootnon esistesse, questo processo non sarebbe mai stato avviato o non avrebbe autorizzazioni.

Protezione dell'account di root

Altre risposte hanno fornito una patch rilasciata da Apple che dovrebbe risolvere il problema. Tuttavia, se non sei in grado o non sei disposto a installarlo ...

Funziona perché macOS ricodifica la password inserita come "aggiornamento" perché l'account disabilitato (root) è stato erroneamente rilevato come avente un vecchio hash. Dirà comunque che non è corretto, ma la prossima volta gli hash corrisponderanno (perché macOS l'ha cambiato) e ti farà entrare.

Per proteggere root, dovrai usare Utility Directory. Esistono due modi per accedervi:

  1. Usa Spotlight. Avvio dell'utilità di directory tramite Spotlight
  2. Usa il Finder. Apri Finder, premi Comando + Maiusc + G (o seleziona, entra /System/Library/CoreServices/Applications/e premi Vai (o premi Invio). Quindi apri Utility Directory da lì.Selezionando Vai Selezionando dove andare Apertura dell'utilità di directory

Dopo aver aperto Directory Utility, dovrai farlo fai clic sul lucchetto per apportare modifiche

Dopo averlo fatto, seleziona Change Root Passwordo Enable Root Userdal menu Modifica. Lo mostro Change Root Passwordpoiché il mio account di root è già abilitato con una password complessa.

Selezione di Cambia password di root

Scegli una password e ora la password vuota non funzionerà più.

Scegliere una password

Congratulazioni! Non sei più vulnerabile all'hack root.


"Indovinando per pura speculazione, il sistema probabilmente riabilita l'account di root perché hai inserito la password corretta (vuota in questo caso)." - Non del tutto giusto. Esiste un percorso di migrazione per aggiornare le password utilizzando un vecchio meccanismo di hashing e non gestisce !(che, come tipo UNIX, probabilmente riconoscerai) correttamente.
Charles Duffy,

Consulta goal-see.com/blog/blog_0x24.html per un'analisi della causa principale.
Charles Duffy,

Giusto - quindi la mia speculazione non era accurata. Quindi rielabora una password vuota come "upgrade" perché l'account disabilitato è stato erroneamente rilevato come avere un vecchio hash? Ho ragione?
Dev

In teoria, ciò che dovrebbe fare in questo codepath è verificare che il vecchio algoritmo hash convalida la password inserita, quindi aggiornarlo con un nuovo hash (della password inserita, che è noto per corrispondere a quella precedente). In pratica, non controlla gli errori della funzione che dovrebbe recuperare il vecchio hash dal campo "ShadowHash" (o, piuttosto, controlla solo il valore di ritorno, ma non il valore di riferimento passato usato per restituire il risultato del confronto), quindi genera un nuovo hash dalla password (vuota o no!).
Charles Duffy,

... quindi, praticamente, hai ragione. :)
Charles Duffy il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.