Wie deaktiviere oder entferne ich das Root-Konto, das als Nebeneffekt dieses Sicherheitsfehlers in High Sierra erstellt wurde?


40

Dieser Artikel beschreibt einen Fehler, bei dem die Eingabe von root bei Aufforderung zum Entsperren jedem Benutzer ermöglicht, die Systemeinstellungen zu entsperren. Es warnt, dass:

Sie müssen dies nicht selbst tun, um es zu überprüfen. Auf diese Weise wird ein Root-Konto erstellt, das andere möglicherweise nutzen können, wenn Sie es nicht deaktivieren.

Der Artikel beschreibt nicht, was zu tun ist, wenn ein eifriger Ingenieur das Problem reproduziert und nun das Root-Konto entfernen oder deaktivieren muss.

Wie kann dieses Konto sicher deaktiviert oder entfernt werden?

Auf dieser Apple-Seite wird beschrieben, wie Sie das Konto deaktivieren. Dies schützt jedoch nicht vor dem Fehler, da der Fehler das Konto nur erneut aktivieren kann. Sobald der Sicherheitsfehler behoben ist, wird das System wieder in den normalen Zustand versetzt und der Root deaktiviert.

Update 29.11.2017 16:43 UTC

Siehe über den Sicherheitsinhalt von Security Update 2017-001 macOS High Sierra zu aktualisieren Administrator - Authentifizierung zum Schutz von unter Umgehung ohne die Administrator-Kennwort eingeben.


Der Titel dieser Frage ist wie derzeit angegeben ein XY, da das Entfernen oder Deaktivieren des Kontos nicht erwünscht ist.
Monty Harder

Antworten:


40

Patch verfügbar, hier klicken oder einfach auf dem Computer aktualisieren

Interessanterweise gibt es meines Wissens noch keinen Patch für die Beta- und Entwicklerversionen von OSX. Ich werde diese Antwort aktualisieren, sobald ich davon höre.

Laden Sie den obigen Patch herunter. Den Rest des Beitrags für die Geschichte verlassen :-)

CVE ist CVE-2017-13872 und NIST wird die Analyse in naher Zukunft aktualisieren .

Originalantwort, relevant ohne Patch

Zunächst einmal, Sie nicht deaktivieren Sie das root - Konto über die grafische Benutzeroberfläche, einen „disabled“ root - Account ist die Ursache für das Problem.

Sie müssen den Root-Benutzer aktivieren und ihm ein Passwort geben. Dies ist wichtig , da die Sicherheitsanfälligkeit auch remote über VNC und Apple Remote Desktop (um nur einige zu nennen) (eine andere Quelle) verfügbar ist .

Es gibt zwei grundlegende Möglichkeiten, dies zu tun; GUI und Terminal.

Zunächst einmal GUI

Um das Root-Konto zu aktivieren, gehen Sie zu "Directory Utility", dh cmd + space und suchen Sie. Drücken Sie die Sperre, um den "Admin-Modus" zu entsperren, und aktivieren Sie dann das Root-Konto über Bearbeiten -> "Root-Benutzer aktivieren".

So aktivieren Sie root

Es sollte nach einem root-Passwort fragen, geben Sie jetzt Ihr normales Passwort ein (damit Sie es nicht vergessen). Wenn Sie nicht nach einem Passwort gefragt werden, klicken Sie oben auf Bearbeiten -> "Root-Passwort ändern ...".

Terminal

Wenn Sie eher eine Terminalperson sind, verwenden Sie Folgendes:

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

Dies ist bei einem Terminal ausreichend. Das Problem mit der grafischen Benutzeroberfläche besteht darin, dass wir dem Konto das Festlegen eines Kennworts ermöglichen müssen, was bei dem Terminal nicht erforderlich ist.

Anmerkungen

Selbst wenn Sie ein Kennwort für das Root-Konto Ihres Computers festgelegt haben, wird es anfällig, wenn Sie das Root-Konto deaktivieren. Das Deaktivieren des Root-Kontos scheint der Schuldige zu sein. Also wiederhole ich, der Root-Benutzer sollte aktiviert sein und ein Passwort haben, wenn er die GUI verwendet, während über das Terminal nur "passwd" "ok" ist (obwohl dieser Status nur über die GUI nicht erreichbar ist). Es scheint, dass der Befehl "Root-Benutzer deaktivieren" im "Verzeichnisdienstprogramm" das Kennwort für das Root-Konto entfernt, sodass Sie ein kennwortloses Root-Konto haben, das anfällig ist.

Es scheint, als würde der Versuch, sich mit "root" in einem System-Anmeldefenster anzumelden, das Root-Konto aktivieren, wenn es zuvor deaktiviert wurde. Dh mit einem deaktivierten Root-Konto müssen Sie in einem System-Anmeldefenster zweimal root eingeben, um Root-Zugriff zu erhalten, und (laut meinen Tests) beim ersten Versuch wird das Root-Konto aktiviert (ohne Passwort, wenn nicht über festgelegt passwd), und beim zweiten versuch gehst du durch.

Es scheint, dass das Problem seit dem 13.11.2017 (13. November), als es im Apple-Support-Forum erwähnt wurde, offen ist .

Bitte beweise mir das Gegenteil. Ich würde mich sehr freuen, wenn ich mich jetzt irre.

Gruseliges Update

Nach dem Aktivieren des kennwortlosen Root-Kontos (dh durch Klicken auf ein "Schloss" und Eingeben von "root" mit einem leeren Kennwort ein, zwei oder drei Mal (die Anzahl hängt vom Ausgangszustand ab) ist die Anmeldung bei möglich den Computer vom Hauptanmeldebildschirm aus mit "root" und einem leeren Passwort (!). SSH / Telnet scheint nicht zu funktionieren, aber Apple Remote Desktop, Screen Sharing und VNC sind anfällig.

Daher kann es für Administratoren von Interesse sein, Pakete vorübergehend an die folgenden Ports zu senden:

  • 5900-5905 (ish, um ninja sicher zu sein), um die gängigsten VNC-Ports zu erhalten. VNC startet standardmäßig bei 5900 und zählt aufwärts auf, wenn Sie mehrere Bildschirme verwenden (jedoch ungewöhnlich). Screen Sharing und Apple Remote Desktop scheinen ebenfalls diese Ports zu verwenden ( Liste der Apple Software-Ports )
  • 3283 und 5988 für Apple Remote Desktop ( Liste der Apple Software-Ports )

Zusätzliche Lektüre:

Ein tapferer Versuch, auf andere Quellen zu verweisen, die sich mit dem Problem befassen. Bearbeiten und aktualisieren Sie meine Antwort, wenn Sie mehr haben.


5
Ok, ich verstehe, warum die Selbstantwort falsch ist. Das Deaktivieren von root bringt nichts, bis dieser Fehler behoben ist, da der Fehler selbst das Konto nur wieder aktiviert. Habe ein paar Upvotes, damit du einen Kommentar abgeben kannst!
Freiheit

1
Ich bin kein Mac-Typ, aber in der * nix-Welt sollte das Deaktivieren des Root-Passworts nicht weniger sicher sein als ein sicheres Passwort. Tatsächlich ist es sehr verbreitet, das Passwort zu deaktivieren und die Shell auf /dev/nullroot zu setzen. Auf diese Weise erfolgt der Zugriff auf das Root-Konto über suSyscalls für Benutzer mit dieser Berechtigung.
Crasic

1
@crasic AFAIK OSX macht etwas Seltsames mit ihren Systemanmeldefenstern. Sie aktivieren anscheinend Konten im Allgemeinen oder root im Besonderen, wenn dies versucht wird. Und es gibt praktisch keine Dokumentation zu diesem Verhalten. Beachten Sie, dass die BSD-Besonderheiten (dh die Verwendung von Kommandozeilen / Bash) unproblematisch sind.
Flindeberg

Also können Sie mit dem Terminal-Befehl das root-Passwort festlegen, ohne root zu aktivieren? Das scheint die sicherste Option zu sein.
wisbucky

1
@jcm Nein, eigentlich ist es nicht nur sehr schlecht formuliert, nachdem der Text ein bisschen verschoben wurde. Ich werde versuchen, es ein bisschen zu klären, in einer Minute nachsehen?
Flindeberg

10

Wenn Sie den offiziellen Patch nicht installieren können oder nicht vertrauen möchten, dass er funktioniert hat, dann

Sie möchten den Root-Benutzer nicht nur in High Sierra deaktivieren.

Um Ihren Mac zu schützen, aktivieren Sie root mit einem langen sicheren Passwort.

Wir werden dies erst ändern, wenn das nächste vollständige Release für macOS verfügbar ist, das voraussichtlich 10.13.2 sein wird


Sofern Sie keine Maßnahmen ergreifen, ist der Root-Benutzer standardmäßig deaktiviert. Dies ist schlecht, wenn Ihr Mac nicht korrekt gepatcht ist.

Wenn Sie möchten, können Sie die Shell optional härten, bis Apple einen offiziellen Patch oder Fix hat.

Hier ist ein großartiges Skript, mit dem Sie ein zufälliges Root-Passwort festlegen und die Root-Shell /usr/bin/falseso ändern / einstellen können, dass sich die Root-Shell selbst dann nicht anmelden kann, wenn das Passwort erraten wurde:

Grundsätzlich macht es drei wichtige Dinge:

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

Die UserShell-Erstellung erfolgt, wenn die Shell nicht festgelegt ist, und das vollständige Skript prüft, ob eine Shell vorhanden ist, und -changees, anstatt -createsie zu erstellen .

Wie schütze ich mich vor der Sicherheitslücke in macOS High Sierra?


1
Es ist im Allgemeinen vorzuziehen, ein Passwort auch nur vorübergehend so zu speichern. Die dcsl-Manpage schlägt vor: " Geben Sie das Kennwort nicht als Teil des Befehls an, und Sie werden sicher dazu aufgefordert"
Josh Caswell,

1
Zustimmend @JoshCaswell - es ist besser, es in einem Skript zu haben, da die Variable nicht exportiert und generiert wird. Die gute Nachricht ist, dass Apple einen offiziellen Patch hat, der diesen Hack zu einer kurzlebigen Notwendigkeit macht - wir haben dies als Prophylaxe für den weitaus größeren Schaden angesehen, wenn wir das gleiche Passwort in der gesamten Flotte fest codieren oder überhaupt kein Passwort haben. Es war sicherlich ein Kompromiss und keine Lösung.
bmike

Warum haben Sie aus reiner Neugier am Ende Ihrer Antwort einen Link zu dieser Frage?
Reirab

1
@ Reirab total durcheinander. Siehe Bearbeiten, um den richtigen Link zu reparieren. Vielen Dank!
bmike


0

Sie müssen sich als Root-Benutzer anmelden und das Kennwort in ein sicheres Kennwort ändern. Wenn tatsächlich ein neues Konto erstellt wird (anstatt das bereits vorhandene Root-Konto zu aktivieren), sollten Sie dieses Konto zuerst löschen.


Siehe meine Selbstantwort. Ihr Rat, ein sicheres Kennwort festzulegen, ist vernünftig, aber die vollständige Deaktivierung des Kontos scheint noch strenger zu sein und setzt OS X auf den Standardzustand zurück. support.apple.com/de-de/HT204012 . Würde ein starker Passwortschutz gegen das Ausnutzen des beschriebenen Fehlers eingerichtet, selbst wenn das Root-Konto wieder aktiviert würde?
Freiheit

In High Sierra 10.13.0 und 10.13.1 möchten Sie das Root-Konto auf keinen Fall deaktivieren. Das Problem ist, dass, wenn root deaktiviert ist und Sie versuchen, sich mit einem beliebigen Anmeldefenster als root anzumelden, das Anmeldefenster das root-Konto mit einem leeren Kennwort aktiviert . Wenn root bereits mit einem sicheren Passwort aktiviert ist, löscht das Anmeldefenster das Passwort nicht. Die einzige Abhilfe besteht darin , root mit einem starken Passwort zu aktivieren .
Brian Reiter

0

Apple hat gerade ein Update veröffentlicht, um das Problem zu beheben.

Sicherheitsupdate 2017-001 https://support.apple.com/de-de/HT208315

Um auch den unbefugten Zugriff auf Ihre Mac-Computer zu verhindern, sollten Sie das Root-Benutzerkonto aktivieren und ein spezielles Kennwort für den Root-Benutzer festlegen.

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

Wenn Ihr Root-Benutzerkonto bereits aktiv ist, stellen Sie sicher, dass Sie das Kennwort ändern, um sicherzustellen, dass die Sicherheitsanfälligkeit für leere Kennwörter nicht festgelegt ist.


0

Nein! Entfernen Sie nicht das Root-Konto!

Erstens rootwar es in allen Versionen von macOS, Mac OS X, Mac OS und sogar in früheren Versionen des Betriebssystems vorhanden. macOS hat dieses Konto vor kurzem aufgrund einer Sicherheitsanfälligkeit nicht erstellt. Es hat es nur zufällig bloßgestellt.

Entfernen rootwäre eine sehr schlechte Idee, und lassen Sie mich erklären, warum.

Es würde macOS komplett lahm legen, da es kein Konto mit ausreichenden Berechtigungen für die Ausführung kritischer Dienste gibt (z. B. WindowServer, auf dem die grafische Benutzeroberfläche ausgeführt wird ). Es gibt Sicherheitsvorkehrungen, die verhindern, dass ahnungslose Benutzer entfernt werden root, und Sie sollten nicht versuchen, sie zu umgehen.

Lassen Sie uns herausfinden, wer die allerersten Prozesse im System ausführt, die wichtigsten Prozesse (mithilfe des Aktivitätsmonitors):

kernel_task und launchd gehören ebenfalls

Hey, es ist wieder unsere freundliche Nachbarschaft root! Der erste Prozess (mit PID 0) wird tatsächlich vom Kernel gesteuert und hat wahrscheinlich ohnehin volle Berechtigungen, aber sein untergeordneter Prozess launchd(der für das Starten von Diensten wie dem Anmeldefenster und dem Fensterserver selbst verantwortlich ist) wird mit den Berechtigungen von gestartet root. Wenn rootes diesen Prozess nicht gegeben hätte, hätte er nie begonnen oder keine Berechtigungen.

Sichern des Root-Kontos

Andere Antworten haben einen von Apple veröffentlichten Patch bereitgestellt, mit dem das Problem behoben werden soll. Wenn Sie es jedoch nicht installieren können oder möchten ...

Es funktioniert, weil macOS das eingegebene Passwort als "Upgrade" neu hascht, weil das deaktivierte Konto (root) fälschlicherweise als ein altes Hash erkannt wurde. Es wird immer noch angezeigt, dass es falsch ist, aber beim nächsten Mal stimmen die Hashes überein (weil macOS sie geändert hat) und Sie werden hereingelassen.

Zum Sichern rootmüssen Sie das Verzeichnisdienstprogramm verwenden. Es gibt zwei Möglichkeiten, darauf zuzugreifen:

  1. Verwenden Sie Spotlight. Starten des Verzeichnisdienstprogramms mit Spotlight
  2. Verwenden Sie den Finder. Öffnen Sie den Finder, drücken Sie Befehlstaste + Umschalttaste + G (oder wählen Sie, geben Sie ein /System/Library/CoreServices/Applications/und drücken Sie Los (oder drücken Sie die Eingabetaste). Öffnen Sie dann das Verzeichnisdienstprogramm.Go auswählen Auswählen, wohin es gehen soll Verzeichnisdienstprogramm öffnen

Sobald Sie das Verzeichnisdienstprogramm geöffnet haben, müssen Sie Klicken Sie auf das Schloss, um Änderungen vorzunehmen

Danach wählen Sie Change Root Passwordoder Enable Root Useraus dem Menü Bearbeiten. Ich zeige, Change Root Passwordda mein Root-Konto bereits mit einem starken Passwort aktiviert ist.

Auswahl von Change Root Password

Wählen Sie ein Passwort und das leere Passwort funktioniert nicht mehr.

Passwort wählen

Herzliche Glückwünsche! Sie sind für den Root-Hack nicht mehr anfällig.


"Durch reine Spekulation erraten, aktiviert das System wahrscheinlich das Root-Konto erneut, weil Sie das richtige Passwort eingegeben haben (in diesem Fall leer)." - nicht ganz richtig. Es gibt einen Migrationspfad zum Aktualisieren von Kennwörtern mithilfe eines alten Hashing-Mechanismus, der !möglicherweise nicht richtig funktioniert (was Sie als UNIX-Typ wahrscheinlich erkennen werden).
Charles Duffy

Siehe objective-see.com/blog/blog_0x24.html für eine Ursachenanalyse.
Charles Duffy

Richtig - meine Spekulation war also nicht korrekt. Also wird ein leeres Passwort als "Upgrade" neu gehasht, weil das deaktivierte Konto fälschlicherweise als ein alter Hash erkannt wurde? Hab ich recht?
Dev

Theoretisch sollte in diesem Codepfad überprüft werden, ob der alte Hash-Algorithmus das eingegebene Passwort validiert, und dann mit einem neuen Hash (des eingegebenen Passworts, von dem bekannt ist, dass es mit dem alten übereinstimmt) aktualisiert werden. In der Praxis wird nicht nach Fehlern in der Funktion gesucht, die den alten Hash aus dem Feld "ShadowHash" abrufen soll. Stattdessen wird nur der Rückgabewert überprüft, nicht jedoch der Referenzwert, der für die Rückgabe verwendet wird das Vergleichsergebnis) und generiert dann einen neuen Hash aus dem Passwort (leer oder nicht!).
Charles Duffy

... also ziemlich genau, ja, du hast recht. :)
Charles Duffy
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.