Warum ein kompromittiertes Root-Konto bedeutet, den Server neu aufzubauen, nicht zu säubern.
Ein UID-0-Konto ohne Anlageeintrag im Log wurde nicht angelegt, es wurde geschrieben. Wie Sie ein verstecktes Root-Konto finden, und warum eine Kompromittierung von Root Neuaufbau bedeutet, nicht Säubern.
In diesem Artikel 5 Abschnitte
Jedes Konto auf einem Unix-System hat eine Geburtsurkunde. Eine Zeile im Authentifizierungslog, die festhält, wer es angelegt hat, wann und mit welchem Werkzeug. Ein Konto ohne eine solche Zeile wurde durch kein Werkzeug angelegt. Es wurde geschrieben, von Hand, direkt in die Benutzerdatei. Wenn dieses Konto zusätzlich die UID 0 trägt, ist die fehlende Zeile keine Lücke in Ihren Aufzeichnungen. Sie ist das Beweisstück.
- Ein verstecktes Root-Konto ist die am schwersten zu sehende Hintertür, weil Root unter Unix eine Zahl ist, kein Name. Jedes Konto mit der UID 0 hat volle Root-Rechte. Geben Sie einem solchen Konto einen Namen, der sich um ein Zeichen von einem legitimen System-Daemon unterscheidet, und es übersteht einen flüchtigen Blick auf die Benutzerliste. Das Auge liest es als Tippfehler, nicht als Bedrohung.
- Zwei gewöhnliche Beobachtungen schicken einen Responder in die falsche Richtung: Der getarnte Name sieht aus wie ein Schreibfehler eines echten Daemons, und eine automatisierte Gesundheitsprüfung hat bereits Erfolg gemeldet. Entwarnung.
- Das Merkmal, das beides durchschneidet: Es gibt überhaupt keinen Eintrag zur Kontoerstellung in den Logs. Der Angreifer hat das Werkzeug zur Kontoerstellung nie benutzt. Der Passwort-Hash wurde direkt in die Benutzerdatei geschrieben, und zwar in die Benutzerdatei, nicht in die Shadow-Datei, was für sich allein ein zweiter Indikator ist.
- Die Doktrin: Suchen Sie unabhängig von den Anlage-Logs nach UID-0-Konten, behandeln Sie einen Hash in der falschen Datei als Befund, betrachten Sie nie eine einzelne automatisierte Prüfung als Beweis, und wenn Root für irgendein Zeitfenster erreichbar war, bauen Sie von einem nachweislich sauberen Punkt vor der Kompromittierung neu auf. Säubern Sie nicht vor Ort.
UID 0 ist eine Zahl, kein Name
Root ist nicht das Konto, das root heißt. Root ist jedes Konto, dessen User-ID 0 ist. Der Kernel vergibt Rechte anhand der Zahl, und der Name ist Dekoration. Eine Hintertür muss also weder das Root-Konto anfassen noch ein Passwort erraten. Sie braucht eine weitere Zeile in der Benutzerdatei mit einer 0 im dritten Feld.
Geben Sie dieser Zeile einen Namen, der sich um ein Zeichen von einem legitimen System-Daemon unterscheidet, und sie verschwindet vor aller Augen. Eine Benutzerliste ist lang, die Namen sind von Haus aus kryptisch, und ein Responder, der sie überfliegt, liest einen bekannten Daemon, leicht verschrieben, und geht weiter. Die Tarnung ist nicht raffiniert. Sie muss nur einen Blick überstehen.
# Root is a UID, not a name. List every account with UID 0.
awk -F: '$3 == 0 { print $1 }' /etc/passwd
# Exactly one line should come back: root. Any second line is a
# full-privilege account, whatever it calls itself.Zwei Gründe weiterzugehen. Beide falsch.
Ein guter Responder kann durch zwei vernünftige Beobachtungen geradewegs an einem versteckten Root-Konto vorbeigeführt werden. Beide sind von der Art, bei der man nickt und weitergeht. Keine übersteht einen zweiten Blick.
| Wie es aussieht | Was es ist |
|---|---|
| Der Kontoname liest sich wie ein Tippfehler eines legitimen System-Daemons | Ein vollwertiges UID-0-Konto, so benannt, dass es einen Blick übersteht, ein Zeichen entfernt von einem echten Daemon |
| Eine automatisierte Prüfung meldet Erfolg. | Eine automatisierte Prüfung ist kein Beweis. |
“Eine einzelne automatisierte Prüfung ist kein Beweis. Bestätigen Sie sie mit einer unabhängigen Suche.”
Das Konto ohne Geburtsurkunde
Jedes Konto, das mit den Standardwerkzeugen angelegt wird, hinterlässt eine Zeile im Authentifizierungslog: angelegt von wem, wann, mit welchem Befehl. Ein eingepflanztes Konto hat keine. Keine gelöschte Zeile, gar keine Zeile, weil der Angreifer das Werkzeug nie benutzt hat. Der Passwort-Hash wird von Hand direkt in die Benutzerdatei geschrieben, und deshalb gibt es nichts zu protokollieren.
Und er wird in die falsche Datei geschrieben. Auf jedem modernen Unix-System ist das Passwortfeld der Benutzerdatei an die Shadow-Datei delegiert. Es enthält einen Platzhalter, nie einen echten Hash. Ein echter Hash in der Benutzerdatei ist keine Konfigurationsentscheidung und keine alte Eigenheit, die Sie abtun können. Er ist der Fingerabdruck einer manuellen Bearbeitung, und er ist für sich allein ein Indikator.
Ohne Logzeile muss die tatsächliche Anlagezeit des Kontos aus Seitenkanälen rekonstruiert werden: Dateizeitstempel und die Spuren, die andere Ereignisse rund um das Konto hinterlassen haben. Das Fehlen einer Geburtsurkunde hindert Sie nicht daran, die Geburtszeit festzustellen. Es bedeutet nur, dass Sie dafür arbeiten müssen.
# The password field in /etc/passwd should be a placeholder (x),
# never a hash. The real hash lives in /etc/shadow.
awk -F: '$2 != "x" && $2 != "*" && $2 != "!" { print $1 }' /etc/passwd
# A name that comes back here has its hash in the wrong file.
# That is a manual edit, not a managed account.“Ein UID-0-Konto ohne Anlageeintrag wurde nicht angelegt. Es wurde geschrieben.”
Wenn ein Update den Angreifer versehentlich aussperrt
Das Seltsamste an diesem Fehlerbild ist, was ein routinemäßiges automatisches Update damit anstellen kann. Ein unbeaufsichtigtes Update kann einen eingepflanzten Hash als Nebeneffekt überschreiben und den Angreifer aus seiner eigenen Hintertür aussperren. Das Konto bleibt. Der Zugang ist weg. Die Hintertür kann dann unbegrenzt ruhen: eine unverschlossene Tür zu einem Raum, dessen Schlüssel sich nicht mehr drehen lässt. Das sieht nach Sicherheit aus. Das ist es nicht.
Eine Hintertür, die nicht mehr funktioniert, ist keine Hintertür, die verschwunden ist. Ein ruhendes UID-0-Konto ist immer noch ein UID-0-Konto, das jemand eingepflanzt hat. Die Anwesenheit ist die Kompromittierung, nicht das Login.
Sie säubern ihn nicht. Sie bauen ihn neu auf.
Der verlockende Abschluss lautet «das böse Konto löschen, den Patch einspielen, fertig». Lehnen Sie ihn ab. Root-Zugang für irgendein Zeitfenster, selbst eines, das das Glück später zugeschlagen hat, bedeutet, dass jedes Byte auf dieser Maschine jetzt verdächtig ist: Binaries, Cron-Jobs, Bibliotheken und genau die Werkzeuge, mit denen Sie sie untersuchen würden. Sie können sich auf einem System, dessen Prüfwerkzeugen Sie nicht mehr trauen, nicht zurück zum Vertrauen prüfen.
Suchen Sie unabhängig von den Logs nach Root.
Listen Sie jedes UID-0-Konto mit awk auf. Verlassen Sie sich nicht auf das Anlage-Log, auf eine einzelne automatisierte Prüfung oder darauf, dass die Benutzerliste normal aussieht.
Behandeln Sie einen Hash in der falschen Datei als Befund.
Ein echter Hash in der Benutzerdatei statt in der Shadow-Datei ist eine manuelle Bearbeitung. Untersuchen Sie ihn, reden Sie ihn nicht klein.
Bestätigen Sie jede automatisierte Prüfung unabhängig.
Wenn eine automatisierte Prüfung «sauber» sagt und Ihre eigene Suche ein unerklärtes UID-0-Konto findet, verfolgen Sie den Befund, nicht die Beruhigung.
Bestimmen Sie den Zeitpunkt der Kompromittierung, nicht den Zeitpunkt, an dem Sie es bemerkt haben.
Rekonstruieren Sie die früheste plausible Kompromittierung aus Seitenkanälen. Ihr sauberer Wiederherstellungspunkt muss davor liegen, nicht vor der Entdeckung.
Bauen Sie von einem nachweislich sauberen Punkt neu auf.
Stellen Sie aus einem bekannt guten Image von vor der Kompromittierung wieder her, rotieren Sie jedes Zugangsdatum, das die Maschine erreichen konnte, und prüfen Sie erneut. Säubern Sie nicht vor Ort.
Root für irgendein Zeitfenster bedeutet ein nicht vertrauenswürdiges System. Ein nicht vertrauenswürdiges System säubern Sie nicht. Sie bauen es von einem Punkt neu auf, von dem Sie beweisen können, dass er sauber war, vor der Kompromittierung, nie danach.
“Root für eine Minute ist Root bis zum Neuaufbau. Diese Maschine säubern Sie nicht. Sie bauen sie von einem Punkt neu auf, von dem Sie beweisen können, dass er sauber war.”
Klare Antworten
Wie finde ich ein verstecktes Root-Konto unter Linux?+
Listen Sie jedes Konto mit UID 0 auf, nicht nur das, das root heißt: awk -F: '$3 == 0 {print $1}' /etc/passwd. Der Kernel vergibt Root anhand der UID, nicht anhand des Namens, jede zweite Zeile ist also ein Konto mit vollen Rechten, wie auch immer es sich nennt. Suchen Sie direkt danach. Verlassen Sie sich nicht darauf, dass die Benutzerliste normal aussieht, oder auf eine einzelne automatisierte Prüfung, die «sauber» meldet.
Was bedeutet ein Passwort-Hash in /etc/passwd statt in /etc/shadow?+
Auf jedem modernen Unix-System ist das Passwortfeld in /etc/passwd ein Platzhalter, meist x, und der echte Hash liegt in /etc/shadow. Ein echter Hash in /etc/passwd ist keine normale Konfiguration. Er ist der Fingerabdruck einer manuellen Bearbeitung der Benutzerdatei, und er ist für sich allein ein Indikator für eine Kompromittierung.
Warum gibt es keinen Logeintrag für ein Konto, das eindeutig existiert?+
Weil es nicht mit den Standardwerkzeugen für Konten angelegt wurde, und die sind es, die das Authentifizierungslog schreiben. Wenn jemand die Benutzerdatei von Hand bearbeitet, existiert das Konto ohne jeden Anlageeintrag. Ein UID-0-Konto ohne Anlageeintrag wurde durch kein Werkzeug angelegt. Es wurde geschrieben.
Kann ich das bösartige Konto nicht einfach löschen und den Server patchen?+
Nein. Root-Zugang für irgendein Zeitfenster bedeutet, dass das ganze System nicht vertrauenswürdig ist: Binaries, Cron, Bibliotheken und die Werkzeuge, mit denen Sie es untersuchen würden. Das Konto zu löschen und zu patchen lässt Sie einer Maschine vertrauen, die Sie nicht mehr verifizieren können. Bauen Sie von einem Wiederherstellungspunkt vor der Kompromittierung neu auf, rotieren Sie die Zugangsdaten und prüfen Sie erneut.
Das Hintertür-Konto sieht inaktiv aus. Ist es trotzdem ein Problem?+
Ja. Ein ruhendes oder ausgesperrtes UID-0-Konto ist immer noch ein Konto mit vollen Rechten, das jemand eingepflanzt hat. Seine Anwesenheit ist die Kompromittierung, nicht irgendein Login. Ein automatisches Update oder eine Konfigurationsänderung kann eine Hintertür versehentlich deaktivieren, ohne den zugrunde liegenden Einbruch zu beseitigen. Behandeln Sie die Anwesenheit als Auslöser, nicht die Aktivität.
Ein Root-Konto, das Sie nicht erklären können?
Wenn Sie ein UID-0-Konto ohne Anlageeintrag gefunden haben, oder nicht sicher sind, ob Ihr letzter sauberer Wiederherstellungspunkt vor dem Problem liegt, säubern Sie es nicht vor Ort. Sprechen Sie mit einem Ingenieur, der den Zeitverlauf aus Seitenkanälen rekonstruiert und von einem Punkt neu aufbaut, von dem Sie beweisen können, dass er sauber war.
Mit einem Ingenieur sprechenSie haben das Ende erreicht.
Setzen Sie das Gelesene um
Was betreiben Sie?
Erzählen Sie uns von Workload, Traffic und Anforderungen an die Wiederherstellung. Beginnen Sie mit dem Server-Konfigurator oder besprechen Sie die Details mit einem Ingenieur.
Geschrieben von den Ingenieuren, die die beschriebene Infrastruktur bauen und betreiben.Mit einem Ingenieur sprechen