Perché tutti sono così preoccupati per etc / passwd?

Ecco il contenuto della mia macchina vagabonda di questo particolare file:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/us$
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
syslog:x:100:103::/home/syslog:/bin/false

Qualcuno potrebbe spiegarmi perché è un male se qualche malvagio potesse ottenere questo file del mio server di produzione?

security passwd-file

— funguy
fonte

Ai vecchi tempi conteneva le password crittografate per ogni utente - dove ora è: x :. Se l'hai ottenuto (il che è stato facile in quanto è leggibile da tutti, quindi hai solo bisogno di un login) potresti forzare la forza di crackare le password. Ora sono memorizzati in / etc / shadow che non è leggibile da tutti così meno probabilità di "uscire", ma che avrebbe lo stesso problema se lo facesse.

— Mark Smith,

Per uno posso dire che hai un server web su questa macchina. In combinazione con il tuo indirizzo IP potrebbe essere hackerabile>: - D

— Rinzwind

@MarkSmith Contiene password crittografate quando? AFAIK ha iniziato la sua vita come password con hash. Certamente da quando ho usato Unix per la prima volta nel 1982.

— user207421

@funguy: l'utente www-data viene solitamente utilizzato dai server web. Ubuntu e probabilmente Debian hanno usato questo utente come utente predefinito di Apache.

— Sdraiati Ryan il

@funguy www-data è l'utente apache predefinito. Ci sono altri: uucp è unix per unix copy; ciò significa che si copiano i file tra i sistemi. E "irc" e "moscerini" sono anche facili da individuare.

— Rinzwind,

Risposte:

Il punto chiave è che Pentesteri / cappelli bianchi / hacker etici e target black hat /etc/passwd come proof of concept, come prova della possibilità di ottenere l'accesso a un sistema.

Tecnicamente /etc/passwdnon è così spaventoso. In passato era solito archiviare dati privati, password ovviamente, ma al giorno d'oggi dovresti essere più preoccupato /etc/shadow: la maggior parte dei sistemi Linux oggi utilizza shadowsuite di utility per mantenere una password con hash e salata /etc/shadow, che a differenza del /etc/passwdmondo non è -leggibile. (a meno che non si usi il pwunconvcomando, che in realtà riporta le password con hash in `/ etc / passwd).

L'unica informazione più o meno sensibile è il nome utente. Se hai sshdo telnetsul server e un nome utente con password debole, esiste la possibilità di un attacco di forza bruta.

A proposito, la tua stessa domanda è stata posta prima . Qui ho semplicemente riaffermato alcuni dei concetti già citati.

Piccola aggiunta: questo è un po 'inverosimile, ma ho notato che hai bashcome shell root. Supponiamo ora che tu abbia un utente sul sistema che ha bashcome shell, peggio ancora: quell'utente è sudoer. Ora, se bash è obsoleto o senza patch, un utente malintenzionato potrebbe tentare di sfruttare la vulnerabilità di Shellshock per rubare dati o eseguire una bomba a forcella per far crollare temporaneamente il sistema. Quindi sì, tecnicamente /etc/passwdnon è un grosso problema, ma dà a un aggressore un'idea di alcune delle informazioni su cosa tentare

Modifica aggiuntiva, 18/11/2016

Avendo usato un server Ubuntu su Digital Ocean per un po ', mi è venuto in mente che la maggior parte degli attacchi di forza bruta contro il mio server sono stati effettuati per l' rootutente - il 99% delle voci per password non riuscite /var/log/auth.logera per root. /etc/password, come ho accennato in precedenza, offre agli autori degli attacchi l'elenco degli utenti e non solo degli utenti di sistema, ma anche degli utenti umani, il che significa più potenziali luoghi di attacco. Ricordiamo che non tutti gli utenti sono attenti alla sicurezza e non creano sempre password complesse, quindi la scommessa di un utente malintenzionato su errore umano o overconfidence ha una probabilità abbastanza elevata di essere jackpot.

— Sergiy Kolodyazhnyy
fonte

+1, ottima risposta. Aggiungendo a questo, vorrei dire anche che, in generale, l'informazione è potere; tralasciando il famigerato Shellshock, si potrebbero raccogliere, ad esempio, informazioni sui processi in esecuzione, che potrebbero anche essere sfruttate; per esempio, sulla macchina di OP, Apache è in esecuzione, e questo è un altro foro potenziale lasciata scoperta

— kos

Hmm ... Quindi suggeriresti di cambiare i nomi utente predefiniti per confondere un attaccante?

— Freedo,

@Freedom Non aiuta. Gli ID utente e di gruppo rimangono invariati se si modifica l'accesso. Per esempio, ecco la mia testuser: testuser1:x:1001:1001:,,,:/home/testuser:/bin/bash. Dopo Corro sudo usermod testuser1 -l testuser2 sudo usermod testuser1 -l testuser2 , la voce ha nome utente diverso, ma gid e uid sono gli stessi: testuser2:x:1001:1001:,,,:/home/testuser:/bin/bash. Se la password non viene modificata, l'utente malintenzionato può fare un'ipotesi e comunque rompere il sistema. Richiedere la scadenza della password e la modifica di tanto in tanto è un approccio migliore, ma anche non a prova di proiettile.

— Sergiy Kolodyazhnyy,

La modifica dei nomi utente predefiniti è utile per quegli account che dispongono di accessi SSH (o altri accessi remoti). Quindi, ovviamente, sta cambiando le porte predefinite per questi accessi. Qualsiasi cosa che ti consenta di mantenere i tuoi registri liberi da miliardi di scansioni drive-by casuali da parte di script-kiddie significherà che puoi concentrarti sugli attacchi più deliberati. Se i tuoi nomi personalizzati compaiono nei log di accesso non riusciti, sai che è un serio tentativo di accesso, piuttosto che un drive-by.

— Dewi Morgan,

Per accedere a una macchina è necessario conoscere sia il nome utente che la password.

/etc/passwd fornisce informazioni sugli utenti che forniscono la metà delle informazioni necessarie e utilizzate per includere un hash della password.

Un hash è qualcosa calcolato dalla tua password. È difficile trovare una password da un hash ma non viceversa. Se hai entrambi puoi provare i tentativi di forza bruta per trovare la password offline, quindi prova a connetterti al computer solo dopo averlo trovato.

Oggi la sicurezza è migliorata perché gli hash sono memorizzati in un file diverso /etc/shadowche per impostazione predefinita non è leggibile dalla maggior parte degli utenti.

Ma se avessi accesso ad entrambi /etc/passwde /etc/shadowprobabilmente potrei trovare la tua password usando un attacco "dizionario" a forza bruta. Dal momento che posso farlo localmente sulla mia macchina, non noteresti molti tentativi falliti di trovare la tua password e dovrei riconnettermi alla tua macchina solo dopo aver conosciuto la password. Sono quindi libero di fare tutto ciò che voglio.

Ulteriori informazioni qui su Wikipedia

— Warren Hill
fonte

Sembra che dovresti probabilmente menzionare "tavoli arcobaleno" qui solo per dare un'idea di come funziona quell'attacco di forza bruta.

— Rick Chatham,