Pourquoi tout le monde est-il si préoccupé par etc / passwd?


36

Voici le contenu de ma machine vagabonde de ce fichier particulier:

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

Quelqu'un pourrait-il m'expliquer pourquoi il est mauvais qu'un type maléfique puisse récupérer ce fichier de mon serveur de production?


19
À l'époque, il contenait les mots de passe cryptés pour tous les utilisateurs, là où se trouve le: x:. Si vous l'avez (ce qui est facile car lisible par tous, vous n'avez donc besoin que d'un seul identifiant), vous pouvez forcer le mot de passe brutalement. Maintenant, ils sont stockés dans / etc / shadow qui est illisible pour tous, donc moins susceptibles de "sortir", mais qui aurait le même problème s’il le faisait.
Mark Smith

8
Pour un, je peux dire que vous avez un serveur Web sur cette machine. Combiné avec votre adresse IP, il pourrait être piratable>: - D
Rinzwind

3
@MarkSmith Il contenait des mots de passe cryptés quand? Autant que je sache, il a commencé sa vie sous forme de mots de passe hachés. Certainement depuis que j'ai utilisé Unix pour la première fois en 1982.
user207421 Le

3
@funguy: l'utilisateur www-data est généralement utilisé par les serveurs Web. Ubuntu et probablement Debian ont utilisé cet utilisateur comme utilisateur Apache par défaut.
Lie Ryan

3
@funguy www-data est l'utilisateur par défaut d'Apache. Il y a plus: uucp est unix pour copier unix; cela signifie que vous copiez des fichiers entre systèmes. Et "irc" et "moucherons" sont également faciles à repérer.
Rinzwind

Réponses:


47

Le point clé est que les pentesters / chapeaux blancs / hackers éthiques ainsi que la cible black-hat en /etc/passwd tant proof of conceptque test de la possibilité d'accéder à un système.

Techniquement, /etc/passwdn'est-ce pas effrayant? Dans le passé , utilisé pour stocker des données privées, les mots de passe de toute évidence, mais de nos jours , vous aurez besoin d'être plus inquiet /etc/shadow- la plupart des systèmes Linux utilisent aujourd'hui shadowsuite d'utilitaires pour garder un mot de passe et haché salé /etc/shadow, qui , contrairement à /etc/passwdn'est pas monde -lisible. (sauf si vous utilisez la pwunconvcommande qui ramène les mots de passe hachés dans `/ etc / passwd).

Les noms d'utilisateur sont la seule information plus ou moins sensible. Si vous avez sshdou telnetsur le serveur et un nom d'utilisateur avec un mot de passe faible, une attaque par force brute est possible.

En passant, votre même question a déjà été posée . Ici, je me suis contenté de reformuler certains des concepts déjà mentionnés.

Petit ajout: c'est un peu tiré par les cheveux, mais j'ai remarqué que vous avez bashcomme shell racine. Supposons maintenant que vous avez un utilisateur sur le système qui a bashpour shell, pire encore: cet utilisateur est sudoer. Désormais, si votre bash est obsolète ou n’a pas été corrigé, un attaquant pourrait tenter d’exploiter la vulnérabilité de Shellshock afin de voler des données ou d’exécuter une bombe à la fourche afin d’arrêter temporairement votre système. Donc oui, techniquement, ce /etc/passwdn’est pas un gros problème, mais cela donne à l’attaquant une idée de certaines informations sur ce qu’il faut tenter.

Ajout supplémentaire, 18/11/2016

Après avoir utilisé un serveur Ubuntu sur Digital Ocean pendant un certain temps, il m’a été signalé que la plupart des attaques par force brute dirigées contre mon serveur étaient commises pour un rootutilisateur - 99% des entrées pour mot de passe ayant échoué /var/log/auth.logétaient destinées root. /etc/password, comme je l'ai déjà mentionné, donne à l'attaquant un aperçu de la liste des utilisateurs, et pas seulement des utilisateurs du système, mais également des utilisateurs, ce qui signifie davantage de lieux potentiels d'attaque. Rappelons-nous que tous les utilisateurs ne sont pas conscients de la sécurité et ne créent pas toujours un mot de passe fort. Par conséquent, le pari de l'attaquant sur une erreur humaine ou une confiance excessive a une probabilité assez élevée d'être un jackpot.


6
+1, bonne réponse. Ajoutant à cela, je voudrais également dire que, en général, l’information, c’est le pouvoir; en laissant de côté le tristement célèbre Shellshock, on pourrait recueillir, par exemple, des informations sur les processus en cours, qui pourraient également être exploitées; par exemple, sur la machine d'OP, Apache est en cours d'exécution, ce qui constitue un autre trou potentiel non découvert
kos le

1
Hmm ... Alors, suggéreriez-vous de changer les noms d'utilisateur par défaut pour confondre un attaquant?
Freedo

@ Liberté Cela n'aide pas. Les identifiants d'utilisateur et de groupe restent les mêmes si vous modifiez votre connexion. Par exemple, voici mon testuser: testuser1:x:1001:1001:,,,:/home/testuser:/bin/bash. Après avoir couru sudo usermod testuser1 -l testuser2 sudo usermod testuser1 -l testuser2 , l'entrée a autre nom d' utilisateur , mais GID et UID sont les mêmes: testuser2:x:1001:1001:,,,:/home/testuser:/bin/bash. Si le mot de passe est inchangé, l'attaquant peut faire une estimation et continuer à pirater le système. Exiger que le mot de passe expire et soit changé de temps en temps est une meilleure approche, mais n’est pas anti-balles.
Sergiy Kolodyazhnyy le

1
Changer les noms d'utilisateur par défaut est utile, pour les comptes ayant des connexions SSH (ou autres connexions distantes). Il en va de même pour les ports par défaut pour ces connexions. Tout ce qui vous permettra de garder vos journaux libres de milliards d'analyses aléatoires conduites par script-kiddies signifie que vous pourrez vous concentrer sur les attaques les plus délibérées. Si vos noms personnalisés apparaissent dans vos journaux de connexion échoués, vous savez que c'est une tentative sérieuse d'entrer, plutôt qu'un drive-by.
Dewi Morgan

11

Pour vous connecter à une machine, vous devez connaître à la fois le nom d'utilisateur et le mot de passe.

/etc/passwd fournit des informations sur les utilisateurs qui vous fournissent la moitié des informations dont vous avez besoin et incluaient un hachage de votre mot de passe.

Un hachage étant quelque chose calculé à partir de votre mot de passe. Il est difficile de trouver un mot de passe à partir d'un hachage, mais pas l'inverse. Si vous avez les deux, vous pouvez essayer avec une force brutale de trouver le mot de passe hors connexion, puis essayez uniquement de vous connecter à l'ordinateur une fois que vous l'avez trouvé.

Aujourd'hui, la sécurité est améliorée car les hachages sont stockés dans un fichier différent /etc/shadowqui, par défaut, n'est pas lisible par la plupart des utilisateurs.

Mais, si j'avais accès aux deux /etc/passwdet que /etc/shadowje pourrais probablement trouver votre mot de passe en utilisant une attaque par «dictionnaire» de force brute. Comme je peux le faire localement sur ma machine, vous ne remarquerez pas de nombreuses tentatives infructueuses pour trouver votre mot de passe et je n’aurais plus besoin que de vous reconnecter à votre machine une fois que je connaissais le mot de passe. Je suis alors libre de faire ce que je veux.

Il y a plus d'informations ici sur Wikipedia


On dirait que vous devriez probablement mentionner «tables arc-en-ciel» ici pour donner une idée du fonctionnement de cette attaque par force brute.
Rick Chatham
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.