Por que todo mundo está tão preocupado com o etc / passwd?

Aqui está o conteúdo da minha máquina vagante desse arquivo específico:

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

Alguém poderia me explicar por que é ruim se um cara mau conseguir esse arquivo do meu servidor de produção?

security passwd-file

— cara engraçado
fonte

Antigamente, continha as senhas criptografadas para todos os usuários - onde o: x: está agora. Se você o adquiriu (o que foi fácil, pois é legível para todos, então você só precisa de um login), poderá violar com força bruta as senhas. Agora eles estão armazenados no / etc / shadow, que não é legível por todos com menos probabilidade de "sair", mas que teria o mesmo problema se o fizesse.

— Mark Smith

Por um lado, posso dizer que você tem um servidor web nesta máquina. Combinado com o seu endereço IP, pode ser hackável>: - D

— Rinzwind

@ MarkSmith Continha senhas criptografadas quando? AFAIK começou a vida como senhas com hash. Certamente desde que eu usei o Unix pela primeira vez em 1982.

— user207421

@ fununy: o usuário www-data é geralmente usado por servidores web. O Ubuntu e provavelmente o Debian usaram esse usuário como o usuário padrão do Apache.

— Lie Ryan

@funguy www-data é o usuário apache padrão. Há mais: uucp é unix para cópia unix; isso significa que você copia arquivos entre sistemas. E "irc" e "gnats" também são fáceis de detectar.

— Rinzwind

Respostas:

O ponto principal é que os Pentesters / white- hat / hackers éticos, bem como o black-hat , têm /etc/passwd como alvo proof of concept, como um teste de possibilidade de obter acesso a um sistema.

Tecnicamente, /etc/passwdnão é tão assustador. No passado, costumava armazenar dados privados, senhas, obviamente, mas hoje em dia você precisa se preocupar mais /etc/shadow- a maioria dos sistemas Linux hoje em dia usa um shadowconjunto de utilitários para manter uma senha salgada e com hash /etc/shadow, o que ao contrário do /etc/passwdmundo não é mundial. -legível. (a menos que você use o pwunconvcomando, que na verdade move as senhas com hash de volta para `/ etc / passwd).

A única informação mais ou menos sensível são os nomes de usuário. Se você possui sshdou telnetno servidor e um nome de usuário com senha fraca, há um potencial para um ataque de força bruta.

A propósito, sua mesma pergunta já foi feita antes . Aqui apenas refiz alguns dos conceitos mencionados lá.

Pequena adição: isso é um pouco exagerado, mas notei que você tem bashcomo shell raiz. Agora, suponha que você tenha um usuário no sistema que tenha bashcomo shell, ainda pior - esse usuário é sudoer. Agora, se o bash estiver desatualizado ou sem patch, um invasor poderá tentar explorar a vulnerabilidade do Shellshock para roubar dados ou executar uma bomba de forquilha para desativar temporariamente o sistema. Então, sim, tecnicamente /etc/passwdnão é grande coisa, mas dá ao invasor uma idéia de algumas informações sobre o que tentar

Edição adicional, 18/11/2016

Depois de usar um servidor Ubuntu no Digital Ocean por um tempo, percebi que a maioria dos ataques de força bruta contra o meu servidor era realizada pelo rootusuário - 99% das entradas de senha com falha /var/log/auth.logeram para root. /etc/password, como mencionei antes, fornece ao invasor a lista de usuários, e não apenas os usuários do sistema, mas também os usuários humanos, o que significa mais possibilidades de ataque. Lembre-se de que nem todos os usuários têm consciência de segurança e nem sempre criam uma senha forte; portanto, a aposta de um invasor em erro humano ou excesso de confiança tem uma probabilidade muito alta de ser jackpot.

— Sergiy Kolodyazhnyy
fonte

+1, ótima resposta. Além disso, gostaria de dizer também que, em geral, informação é poder; deixando de lado o famoso Shellshock, pode-se reunir, por exemplo, informações sobre os processos em execução, que também podem ser explorados; por exemplo, na máquina do OP, o Apache está em execução, e esse é outro buraco potencial ainda descoberto

— kos 31/07

Hum ... Então, você sugeriria alterar os nomes de usuário padrão para confundir um invasor?

— Freedo 31/07

@Liberdade Isso não ajuda. Os IDs de usuário e grupo permanecem os mesmos se você alterar o login. Por exemplo, aqui está o meu testuser: testuser1:x:1001:1001:,,,:/home/testuser:/bin/bash. Depois eu executar sudo usermod testuser1 -l testuser2 sudo usermod testuser1 -l testuser2 , a entrada tem nome de usuário diferente, mas gid e uid são os mesmos: testuser2:x:1001:1001:,,,:/home/testuser:/bin/bash. Se a senha não for alterada, o invasor poderá adivinhar e ainda quebrar o sistema. Exigir que a senha expire e seja alterada de vez em quando é uma abordagem melhor, mas também não é à prova de balas.

— Sergiy Kolodyazhnyy 31/07/2015

Alterar nomes de usuário padrão É útil para as contas que possuem logins SSH (ou outros logons remotos). O mesmo acontece com a alteração das portas padrão para esses logins. Qualquer coisa que permita manter seus registros longe de bilhões de verificações aleatórias de drive-by por crianças de script significa que você pode se concentrar nos ataques mais deliberados. Se seus nomes personalizados aparecerem nos logs de logon com falha, você sabe que é uma tentativa séria de entrar, em vez de um drive-by.

— Dewi Morgan

Para fazer logon em uma máquina, é necessário conhecer o nome do usuário e a senha.

/etc/passwd fornece informações sobre os usuários, fornecendo metade das informações necessárias e usadas para incluir um hash da sua senha.

Um hash é algo calculado a partir da sua senha. É difícil encontrar uma senha de um hash, mas não o contrário. Se você possui os dois, pode tentar tentativas de força bruta para encontrar a senha offline e tente se conectar ao computador depois de encontrá-la.

Hoje a segurança é aprimorada porque os hashes são armazenados em um arquivo diferente /etc/shadowque, por padrão, não é legível para a maioria dos usuários.

Mas, se eu tivesse acesso a ambos /etc/passwde /etc/shadowprovavelmente pudesse encontrar sua senha usando um ataque de dicionário de força bruta. Como eu posso fazer isso localmente na minha máquina, você não notaria muitas tentativas fracassadas de encontrar sua senha e eu só precisaria me conectar à sua máquina novamente quando soubesse a senha. Eu sou livre para fazer o que eu quiser.

Há mais informações aqui na Wikipedia

— Warren Hill
fonte

Parece que você provavelmente deveria mencionar 'tabelas arco-íris' aqui apenas para ter uma idéia de como esse ataque de força bruta funciona.

— Rick Chatham