Cosa possono fare gli hacker con la possibilità di leggere / etc / passwd?

L'unica reale ripercussione è ricognizione: l'attaccante può imparare i nomi di login e i campi gecos (che a volte aiutano a indovinare le password) dal file /etc/passwd .

Una ragione di ciò è che, 20 anni fa circa, la maggior parte delle varianti di Unix si è spostata dal mantenere le password con hash nel file /etc/passwd e spostate in /etc/shadow . La ragione di ciò era che /etc/passwd doveva essere leggibile a livello mondiale per strumenti come "finger" e "ident" per funzionare. Una volta che le password sono state segregate in /etc/shadow , quel file è stato reso leggibile solo da root.

Detto questo, /etc/passwd rimane una popolare "bandiera" per gli analisti e gli hacker della sicurezza perché è un file tradizionale "hey, ho ottenuto quello che non dovrei". Se puoi leggerlo, puoi leggere anche altre cose sotto / etc, alcune delle quali possono essere utili a un utente malintenzionato. Ma è più difficile testare per (dire) /etc/yum.conf se non sai se yum è sul sistema; /etc/passwd è sempre presente ed è un test affidabile per verificare se l'accesso ha funzionato.

In modo diverso, la ripercussione implicita di ottenere /etc/passwd è che l'autore dell'attacco ha aggirato i controlli e può ottenere file leggibili arbitrariamente, il che significa "vinco!" *

* Nessuna garanzia effettiva di vincita, espressa o implicita

Mentre @gowenfawr raggiunge i punti principali, ne ho aggiunti alcuni:

La maggior parte dei sistemi, ma non tutti , nasconde le password effettive in /etc/shadow . Per vedere se il tuo sistema è vulnerabile, controlla un account utente reale. Se sembra

stighemmer:x:...

Quindi le tue password sono al sicuro.

Se sembra

stighemmer:kjsaashgdkwqvbm:...

Quindi le tue password sono NOT safe.

Sì, la password è offuscata utilizzando una funzione hash unidirezionale, ma ciò non è sufficiente. Avere questo file consente all'hacker di verificare se un determinato utente ha una certa password senza effettivamente tentare di accedere.

Nel 1970, questo controllo era lento e le cose erano ragionevolmente sicure. Oggi un hacker può controllare milioni di password al secondo. Se one dei tuoi utenti ha una password indovinabile, l'account dell'utente verrà violato. E il limite per ciò che è "ipotizzabile" viene spinto con ogni generazione di processore.

Ora hai controllato e hai trovato che le tue password sono archiviate in modo sicuro in /etc/shadow . Bene, problema risolto.

Non proprio. /etc/passwd contiene ulteriori informazioni.

Contiene il nome completo di ogni utente. Questo è molto utile per gli attacchi di social engineering.

Contiene un elenco di utenti del sistema, che indica quale software è installato.

Quindi, ricevo una email "Hey Stig, ho dimenticato la password di Postgres. Potresti ricordarmi di aver firmato Signed, Other Real User". Dal momento che il mio utile client di posta elettronica non mostra l'indirizzo email completo, non noterò che questa email proviene da un paese remoto. Rispondo, "È 'S3CR37'". Oops, il database aziendale è stato appena violato.

Ovviamente, questo non è l'unico modo in cui i nomi completi vengono esposti, devi comunque insegnare agli utenti gli attacchi di social engineering.

Questo può aiutare un attaccante a fare un attacco di forza bruta in tempi bassi, quindi l'attaccante non ha bisogno di scoprire i nomi utente perché li ha già ma può mirare l'attacco solo per scoprire le password.

A meno che tu non stia usando password shadow, l'accesso a /etc/passwd non è il grosso rischio che il nome del file implicherebbe (e se non usi le password shadow in questo giorno ed età, hai un problema).

I primi sistemi unix hanno effettivamente memorizzato le password in /etc/passwd , motivo per cui il file è chiamato così . Ha anche memorizzato alcuni altri aspetti dei metadati dell'utente, come la home directory dell'utente, la shell e così via. In retrospettiva, questa non è stata la più grande decisione progettuale mai realizzata, perché significava che i programmi che utilizzavano questi metadati dovevano essere in grado di leggere /etc/passwd per ottenere quei dati.

Le password in /etc/passwd sono state crittografate utilizzando gli algoritmi del tempo, ma includere le password crittografate era ancora un rischio di esposizione inutile , pertanto sono state implementate password shadow per risolvere il problema. Il formato di /etc/passwd non può essere modificato, per ragioni storiche, ma i sistemi moderni mettono semplicemente un segnaposto lì ( x è comune). Le informazioni relative alla password effettiva (gli hash effettivi, la password precedente e così via) sono memorizzate in un altro file, /etc/shadow , che solo la root può leggere.

Questo non vuol dire che l'accesso a /etc/passwd sia completamente innocuo . Rende comunque un elenco di nomi utente, e sebbene ciò sia teoricamente innocuo (dal momento che i nomi utente non dovrebbero essere segreti), può essere deprimente sapere quante persone usano il loro nome utente come password. Succede meno spesso in questo giorno ed età, ma succede ancora abbastanza spesso per essere degno di un tentativo.

Inoltre, il campo GECOS in /etc/passwd spesso contiene metadati come i nomi reali degli utenti. Ciò può essere utile per le ipotesi rapide di per sé o per effettuare ricerche dettagliate che potrebbero fornire ipotesi più probabili. Si tratta di cose abbastanza sofisticate, che vanno ben oltre (e potenzialmente non richiedono nemmeno) l'accesso a /etc/passwd stesso

Quando eseguo valutazioni di vulnerabilità per i clienti, utilizzo /etc/passwd come "hey, ho LFI in questa applicazione e dovresti essere consapevole". È un file semplice e conosciuto che generalmente ha sufficienti autorizzazioni sul filesystem per mostrare che posso leggere i file. Poiché si tratta di una valutazione della vulnerabilità, io e il cliente ci preoccupiamo solo della vulnerabilità presente, delle prove fornite e delle indicazioni su come risolvere il problema.

Quando eseguo un pentest per un client, questo file, sebbene normalmente non contenga password, mi fornisce molte informazioni. Da lì, ho i nomi di accesso per iniziare a indovinare le password e posso usare l'LFI esistente per poi tentare di leggere i file fuori dagli utenti degli utenti.

Questo stesso ragionamento si applica alla dimostrazione dei concetti XSS e <script>alert(1)</script> . Non è la cosa peggiore che puoi fare con XSS, ma è la prova che io come attaccante ho la possibilità di eseguire JavaScript sotto il mio controllo.

Un utente malintenzionato può guardare gli utenti creati manualmente (UID > 500 o > 1000 sulla maggior parte degli linux che ho toccato fino a quel momento) e guardare anche le shell assegnate (/ bin / ba (sh)) per imparare a cosa potrebbero funzionare gli utenti servizi e / o webapp disponibili sulla macchina. SSH non è l'unico obiettivo!

Queste informazioni non sono utili solo per la bruteforce generica ma anche per ogni attacco che potrebbe implicare la conoscenza del nome utente valido (essere creativi).

Come menzionato sopra: quando un attaccante può leggere / etc / passwd può anche leggere molto di più sul sistema e determinare sistematicamente se ci sono modi per ottenere inversioni di shell e escalation di privilegi locali.

Vi raccomando di leggere alcune guide di privesc di linux (mubix e g0tmilk per i principianti) e mettere le mani su alcuni vulnerabili vms per qualche addestramento privesc pratico (vulnhub.com / kioptrix è un buon punto di partenza).