Perché un account root compromesso significa ricostruire il server, non pulirlo.
Un account UID 0 senza log di creazione non è stato creato, è stato scritto. Come trovare un account root nascosto, e perché una compromissione di root significa ricostruire, non pulire.
In questo articolo 5 sezioni
Ogni account su un sistema Unix ha un certificato di nascita. Una riga nel log di autenticazione che registra chi lo ha creato, quando, e con quale strumento. Un account senza quella riga non è stato creato attraverso alcuno strumento. È stato scritto, a mano, direttamente nel file degli utenti. Quando quell'account porta anche UID 0, la riga mancante non è una lacuna nei vostri archivi. È la prova.
- Un account root nascosto è la backdoor più difficile da vedere, perché su Unix root è un numero, non un nome. Qualsiasi account con UID 0 ha pieni poteri di root. Date a un account del genere un nome che differisce di un solo carattere da un daemon di sistema legittimo, e sopravvive a una scansione distratta della lista utenti. L'occhio lo legge come un refuso, non come una minaccia.
- Due osservazioni ordinarie mandano chi risponde nella direzione sbagliata: il nome camuffato sembra un errore di battitura di un daemon reale, e un controllo automatico di salute ha già riportato esito positivo. Un «tutto a posto».
- L'indizio che taglia entrambe: non esiste alcuna voce di creazione dell'account nei log. L'attaccante non ha mai usato lo strumento di creazione. L'hash della password è stato scritto direttamente nel file degli utenti, e nel file degli utenti, non nel file shadow, il che è un secondo indicatore di per sé.
- La dottrina: cercate gli account UID 0 indipendentemente dai log di creazione, trattate un hash nel file sbagliato come un reperto, non trattate mai un singolo controllo automatico come prova, e quando root è stato raggiungibile per qualsiasi finestra di tempo, ricostruite da un punto verificato come pulito, precedente alla compromissione. Non ripulite sul posto.
UID 0 è un numero, non un nome
Root non è l'account chiamato root. Root è qualsiasi account il cui user ID è 0. Il kernel concede il privilegio sul numero, e il nome è decorazione. Quindi una backdoor non ha bisogno di toccare l'account root o di indovinare una password. Le serve una riga in più nel file degli utenti con uno 0 nel terzo campo.
Date a quella riga un nome che differisce di un solo carattere da un daemon di sistema legittimo, e sparisce in piena vista. Una lista utenti è lunga, i nomi sono criptici per progetto, e chi la scorre legge un daemon noto, leggermente storpiato, e va avanti. Il camuffamento non è sofisticato. Deve solo sopravvivere a un'occhiata.
# 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.Due motivi per andare avanti. Entrambi sbagliati.
Anche un buon responder può essere condotto dritto oltre un account root nascosto da due osservazioni ragionevoli. Entrambe sono il tipo di cosa a cui si annuisce prima di passare oltre. Nessuna delle due regge a un secondo sguardo.
| Come appare | Cos'è |
|---|---|
| Il nome dell'account si legge come un refuso di un daemon di sistema legittimo | Un account UID 0 a pieni poteri, chiamato così per sopravvivere a un'occhiata, un carattere di distanza da un daemon reale |
| Un controllo automatico riporta esito positivo. | Un singolo controllo automatico non è una prova. |
“Un singolo controllo automatico non è una prova. Confermatelo con una scansione indipendente.”
L'account senza certificato di nascita
Ogni account creato attraverso gli strumenti standard lascia una riga nel log di autenticazione: creato da chi, quando, con quale comando. Un account piantato non ne ha nessuna. Non una riga cancellata, nessuna riga affatto, perché l'attaccante non ha mai usato lo strumento. L'hash della password viene scritto direttamente nel file degli utenti a mano, ed è per questo che non c'è nulla da registrare.
E viene scritto nel file sbagliato. Su qualsiasi sistema Unix moderno il campo password nel file degli utenti è delegato al file shadow. Contiene un segnaposto, mai un hash reale. Un hash autentico che sta nel file degli utenti non è una scelta di configurazione né una stranezza legacy che potete liquidare. È l'impronta di una modifica manuale, ed è un indicatore di per sé.
Senza una riga di log, il vero momento di creazione dell'account va ricostruito da canali laterali: i timestamp dei file e le tracce che altri eventi hanno lasciato intorno a esso. L'assenza di un certificato di nascita non vi impedisce di stabilire l'ora della nascita. Significa solo che dovete lavorare per averla.
# 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.“Un account UID 0 senza log di creazione non è stato creato. È stato scritto.”
Quando un aggiornamento chiude fuori l'attaccante per caso
La cosa più strana di questa modalità di guasto è ciò che un normale aggiornamento automatico può farle. Un aggiornamento non presidiato può riscrivere un hash piantato come effetto collaterale e chiudere l'attaccante fuori dalla propria backdoor. L'account resta. L'accesso è sparito. La backdoor può allora restare dormiente a tempo indefinito: una porta aperta su una stanza la cui chiave non gira più. Sembra sicurezza. Non lo è.
Una backdoor che ha smesso di funzionare non è una backdoor sparita. Un account UID 0 dormiente è ancora un account UID 0 che qualcuno ha piantato. La presenza è la compromissione, non il login.
Non lo pulite. Lo ricostruite.
La chiusura che tenta è «cancella l'account malevolo, applica la patch, fatto». Rifiutatela. L'accesso root per qualsiasi finestra di tempo, anche una finestra che la fortuna ha poi richiuso di colpo, significa che ogni byte su quella macchina è ora sospetto: binari, cron job, librerie, e gli stessi strumenti che usereste per ispezionarla. Non potete ricostruire la fiducia a forza di audit su un sistema di cui non potete più fidarvi degli strumenti di audit.
Cercate root indipendentemente dai log.
Elencate ogni account UID 0 con awk. Non affidatevi al log di creazione, a un singolo controllo automatico, o al fatto che la lista utenti sembri normale.
Trattate un hash nel file sbagliato come un reperto.
Un hash reale nel file degli utenti invece che nel file shadow è una modifica manuale. Indagatelo, non giustificatelo.
Confermate ogni controllo automatico in modo indipendente.
Se un controllo automatico dice pulito e la vostra scansione trova un account UID 0 inspiegato, inseguite il reperto, non la rassicurazione.
Fissate il momento della compromissione, non il momento in cui ve ne siete accorti.
Ricostruite la compromissione plausibile più antica dai canali laterali. Il vostro punto di ripristino pulito deve precedere quella, non la scoperta.
Ricostruite da un punto verificato come pulito.
Ripristinate da un'immagine nota come buona, precedente alla compromissione, ruotate ogni credenziale che la macchina poteva toccare, poi verificate di nuovo. Non ripulite sul posto.
Root per qualsiasi finestra di tempo significa un sistema non attendibile. Un sistema non attendibile non si pulisce. Lo si ricostruisce da un punto che potete dimostrare pulito, precedente alla compromissione, mai successivo.
“Root per un minuto è root fino alla ricostruzione. Quella macchina non la pulite. La ricostruite da un punto che potete dimostrare pulito.”
Risposte dirette
Come trovo un account root nascosto su Linux?+
Elencate ogni account con UID 0, non solo quello chiamato root: awk -F: '$3 == 0 {print $1}' /etc/passwd. Il kernel concede root per UID, non per nome, quindi qualsiasi seconda riga è un account a pieni poteri, comunque si chiami. Cercatelo direttamente. Non affidatevi al fatto che la lista utenti sembri normale o che un singolo controllo automatico riporti pulito.
Cosa significa un hash di password in /etc/passwd invece che in /etc/shadow?+
Su qualsiasi sistema Unix moderno il campo password in /etc/passwd è un segnaposto, di solito x, e l'hash reale vive in /etc/shadow. Un hash autentico che sta in /etc/passwd non è una configurazione normale. È l'impronta di una modifica manuale al file degli utenti, ed è un indicatore di compromissione di per sé.
Perché non c'è una voce di log per un account che chiaramente esiste?+
Perché non è stato creato con gli strumenti standard per gli account, che sono ciò che scrive il log di autenticazione. Se qualcuno modifica il file degli utenti a mano, l'account esiste senza alcuna traccia di creazione. Un account UID 0 senza log di creazione non è stato creato attraverso alcuno strumento. È stato scritto.
Posso semplicemente cancellare l'account malevolo e applicare le patch al server?+
No. L'accesso root per qualsiasi finestra di tempo significa che l'intero sistema non è attendibile: binari, cron, librerie, e gli strumenti con cui lo ispezionereste. Cancellare l'account e applicare le patch vi lascia a fidarvi di una macchina che non potete più verificare. Ricostruite da un punto di ripristino precedente alla compromissione, ruotate le credenziali e verificate di nuovo.
L'account backdoor sembra inattivo. È ancora un problema?+
Sì. Un account UID 0 dormiente o bloccato è ancora un account a pieni poteri che qualcuno ha piantato. La sua presenza è la compromissione, non un qualsiasi login. Un aggiornamento automatico o una modifica di configurazione possono disabilitare una backdoor per caso senza rimuovere la violazione sottostante. Trattate la presenza, non l'attività, come il fattore scatenante.
Un account root che non sapete spiegare?
Se avete trovato un account UID 0 senza log di creazione, o non siete sicuri che il vostro ultimo punto di ripristino pulito preceda il problema, non ripulitelo sul posto. Parlate con un ingegnere che ricostruirà la cronologia dai canali laterali e ripartirà da un punto che potete dimostrare pulito.
Parla con un ingegnereSiete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere