La seule véritable répercussion est la reconnaissance - l'attaquant peut apprendre les noms de connexion et les champs gecos (qui aident parfois à deviner les mots de passe) à partir du / etc / passwd .

L'une des raisons à cela est que, il y a environ 20 ans, la plupart des variantes d'Unix ont cessé de conserver les mots de passe hachés dans le fichier / etc / passwd et les ont déplacées à / etc / shadow . La raison en était que / etc / passwd devait être lisible partout dans le monde pour que des outils comme «finger» et «ident» fonctionnent. Une fois que les mots de passe ont été séparés dans / etc / shadow , ce fichier a été rendu lisible uniquement par root.

Cela dit, / etc / passwd reste un «flag» pour les analystes de sécurité et les pirates parce que c'est un fichier traditionnel «hé, j'ai ce que je ne devrais pas». Si vous pouvez lire cela, vous pouvez également lire d'autres choses sous / etc, dont certaines peuvent être utiles à un attaquant. Mais il est plus difficile de tester (disons) /etc/yum.conf si vous ne savez pas si yum est sur le système; / etc / passwd est toujours présent et constitue un test fiable pour savoir si l'accès a fonctionné.

En d'autres termes, la répercussion implicite d'obtenir / etc / passwd est que l'attaquant a contourné les contrôles et peut obtenir des fichiers lisibles arbitraires, ce qui signifie "je gagne!" *

* Aucune garantie réelle de victoire, express ou implicite

Bien que @gowenfawr touche les points principaux, j'en ai quelques-uns à ajouter:

La plupart des systèmes, mais pas tous , cachent les mots de passe réels dans / etc / ombre . Pour voir si votre système est vulnérable, vérifiez un compte d'utilisateur réel. Si cela ressemble à

  stighemmer: x: ...  

Alors vos mots de passe sont sûrs.

Si cela ressemble à

stighemmer:kjsaashgdkwqvbm:...

Alors vos mots de passe ne sont PAS sûrs.

Oui, le mot de passe est obscurci à l'aide d'une fonction de hachage à sens unique, mais cela ne suffit pas. Avoir ce fichier permet au pirate de vérifier si un utilisateur donné a un certain mot de passe sans vraiment essayer de se connecter.

En 1970, cette vérification était lente et les choses étaient raisonnablement sûres. Aujourd'hui, un hacker peut vérifier des millions de mots de passe par seconde. Si l'un de vos utilisateurs possède un mot de passe devinable, le compte de cet utilisateur sera piraté. Et la limite pour ce qui est "devinable" est repoussée à chaque génération de processeur.

Vous avez maintenant vérifié et constaté que vos mots de passe sont stockés en toute sécurité dans / etc / shadow . Bien, problème résolu.

Pas tout à fait. / etc / passwd contient plus d'informations.

Il contient le nom complet de chaque utilisateur. Ceci est très utile pour les attaques d'ingénierie sociale.

Il contient une liste d'utilisateurs du système, qui indique quel logiciel est installé.

Donc, je reçois un e-mail qui me dit "Hey Stig, je avez oublié le mot de passe postgres. Pouvez-vous me le rappeler? Signé, autre utilisateur réel ". Étant donné que mon client de messagerie utile n'affiche pas l'adresse e-mail complète, je ne remarquerai pas que cet e-mail provient d'un pays distant. Je réponds: "C'est" S3CR37 "". Oups, la base de données de l'entreprise vient d'être piratée.

Bien sûr, ce n'est pas la seule façon dont les noms complets sont exposés, vous devez quand même enseigner aux utilisateurs les attaques d'ingénierie sociale.

Cela peut aider un attaquant à faire une attaque par force brute dans les temps difficiles, donc l'attaquant n'a pas besoin de découvrir les noms d'utilisateur car il les a déjà mais il ne peut viser l'attaque que pour découvrir les mots de passe.

Sauf si vous n'utilisez pas de mots de passe masqués, l'accès à / etc / passwd n'est pas le risque énorme que le nom de fichier impliquerait (et si vous n'utilisez pas shadow passwords de nos jours, vous avez un problème).

Les premiers systèmes Unix stockaient les mots de passe dans / etc / passwd , c'est pourquoi le le fichier s'appelle ainsi . Il stockait également d'autres aspects des métadonnées utilisateur, comme le répertoire personnel de l'utilisateur, le shell, etc. Rétrospectivement, ce n'était pas la plus grande décision de conception jamais prise, car cela signifiait que les programmes qui utilisaient ces métadonnées devaient être capables de lire / etc / passwd afin d'obtenir ces données.

Les mots de passe dans / etc / passwd étaient chiffrés à l'aide des algorithmes de l'époque, mais l'inclusion des mots de passe chiffrés représentait toujours un risque d'exposition inutile , et donc les mots de passe masqués ont été mis en œuvre pour résoudre ce problème. Le format de / etc / passwd ne pouvait pas changer, pour des raisons historiques, mais les systèmes modernes y mettent simplement un espace réservé ( x est courant). Les informations relatives au mot de passe (les hachages réels, l'âge du mot de passe, etc.) sont stockées dans un autre fichier, / etc / shadow , que seul root peut lire.

Cela ne veut pas dire que l'accès à / etc / passwd est complètement inoffensif . Cela donne toujours une liste de noms d'utilisateur, et bien que ce soit théoriquement inoffensif (puisque les noms d'utilisateur ne sont pas censés être secrets), il peut être déprimant d'apprendre combien de personnes utilisent leur nom d'utilisateur comme mot de passe. Cela arrive moins souvent de nos jours, mais cela arrive encore assez souvent pour valoir la peine d'être essayé.

De plus, le champ GECOS dans / etc / passwd contient souvent des métadonnées comme les vrais noms d'utilisateurs. Cela peut être utile pour des estimations rapides en soi, ou pour effectuer des recherches détaillées susceptibles de générer des suppositions plus probables. Il s’agit de choses assez sophistiquées, cependant, qui vont bien au-delà (et ne nécessitent même pas potentiellement) l’accès à / etc / passwd lui-même

Lorsque j'effectue des évaluations de vulnérabilité pour les clients, j'utilise / etc / passwd comme un "hé, j'ai LFI dans cette application et vous devriez être au courant". Il s'agit d'un fichier simple et bien connu qui dispose généralement d'autorisations suffisantes sur le système de fichiers pour montrer que je peux lire des fichiers. Étant donné qu'il s'agit d'une évaluation de la vulnérabilité, moi et le client ne nous soucions que de la vulnérabilité présente, des preuves fournies et des conseils sur la façon de résoudre le problème.

Lorsque j'effectue un pentest pour un client , ce fichier, bien que ne contenant normalement pas de mots de passe, me donne beaucoup d'informations. À partir de là, j'ai des noms de connexion pour commencer à deviner les mots de passe et je peux utiliser le LFI existant pour ensuite essayer de lire des fichiers hors des homedirs de l'utilisateur.

Ce même raisonnement s'applique à la preuve de concepts XSS et <script>alert (1) < / script> . Ce n'est pas la pire chose que vous puissiez faire avec XSS, mais c'est la preuve qu'en tant qu'attaquant j'ai la capacité d'exécuter JavaScript sous mon contrôle.

Un attaquant peut regarder les utilisateurs créés manuellement (UID> 500 ou> 1000 sur la plupart des Linux que j'ai touchés jusqu'à présent) et également regarder les shells attribués (/ bin / ba (sh)) pour savoir quels utilisateurs pourraient travailler sur les services et / ou webapps disponibles sur la machine.SSH n'est pas la seule cible!

Ces informations sont non seulement utiles pour la force brute générique mais aussi pour toute attaque qui pourrait impliquer la connaissance d'un nom d'utilisateur valide (soyez créatif).

Comme mentionné ci-dessus: lorsqu'un attaquant peut lire / etc / passwd, il peut également en lire beaucoup plus sur le système et déterminer systématiquement s'il existe des moyens d'obtenir des shells inversés et une escalade des privilèges locaux.

Je vous recommande de lire quelques guides privesc Linux (mubix & g0tmilk pour les débutants) et de mettre la main sur des vms vulnérables pour une formation pratique privesc (vulnhub.com / kioptrix est un bon point de départ).