Que peuvent faire les pirates informatiques pour lire / etc / passwd?
Sur les sites d'exploitation, je vois des analystes de sécurité et des pirates ciblant le fichier / etc/passwd lorsqu'ils montrent la preuve de concept.
Si vous avez une vulnérabilité d'inclusion de fichier local ou de traversée de chemin sur votre serveur et que les pirates peuvent accéder (afficher, lire, mais PAS modifier) le fichier/etc/passwd, quelles sont les répercussions de cela? Tous les mots de passe ne sont-ils pas obscurcis par conception?
La seule répercussion réelle 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 fichier.
Une des raisons à cela est que, il y a environ 20 ans, la plupart des variantes Unix ont abandonné la conservation des mots de passe hachés dans le /etc/passwd fichier et les a déplacés vers /etc/shadow. La raison en était que /etc/passwd devait être lisible par tout le monde pour que des outils comme "doigt" et "ident" fonctionnent. Une fois les mots de passe séparés en /etc/shadow, ce fichier a été rendu lisible uniquement par root.
Cela dit, /etc/passwd reste un "drapeau" populaire pour les analystes de sécurité et les pirates, car il s'agit d'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 (par exemple) /etc/yum.conf si vous ne savez pas si yum est sur le système; /etc/passwd est toujours là et est un test fiable pour savoir si l'accès a fonctionné.
Autrement dit, la répercussion implicite d'obtenir /etc/passwd est que l'attaquant a contourné les contrôles et peut obtenir des fichiers lisibles arbitrairement, ce qui signifie "Je gagne!" *
* Aucune garantie réelle de gain, explicite ou implicite
Alors que @gowenfawr touche les points principaux, j'en ai quelques-uns à ajouter:
La plupart des systèmes, mais pas tous, masquent les mots de passe réels dans /etc/shadow. Pour voir si votre système est vulnérable, vérifiez un compte d'utilisateur réel. Si ça ressemble
stighemmer:x:...
Ensuite, vos mots de passe sont en sécurité.
Si ça ressemble
stighemmer:kjsaashgdkwqvbm:...
Vos mots de passe sont alors PAS sûrs.
Oui, le mot de passe est masqué à l'aide d'une fonction de hachage unidirectionnelle, mais cela ne suffit pas. La possession de 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 a été lente et les choses étaient raisonnablement sûres. Aujourd'hui, un pirate peut vérifier des millions de mots de passe par seconde. Si n de vos utilisateurs a un mot de passe devinable, le compte de cet utilisateur sera piraté. Et la limite de 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. Bon, problème résolu.
Pas assez. /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 "Hé Stig, j'ai oublié le mot de passe postgres. Pourriez-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 éloigné. 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 à effectuer une attaque par force brute dans les faibles temps, 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 cachés, l'accès à /etc/passwd N'est pas le risque énorme que le nom de fichier impliquerait (et si vous n'utilisez pas de mots de passe cachés de nos jours, vous avez un problème).
Les premiers systèmes Unix stockaient en fait des mots de passe dans /etc/passwd, C'est pourquoi le fichier est appelé ainsi. Il a également stocké d'autres aspects des métadonnées utilisateur, comme le répertoire personnel de l'utilisateur, 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 pouvoir lire /etc/passwd Afin d'obtenir ces données.
Les mots de passe dans /etc/passwd Ont été chiffrés à l'aide des algorithmes de l'époque, mais l'inclusion des mots de passe chiffrés constituait toujours un risque d'exposition inutile, et des mots de passe fantômes ont donc été implémentés pour résoudre ce problème. Le format de /etc/passwd N'a pas pu 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 seule la racine peut lire.
Cela ne veut pas dire que l'accès à /etc/passwd Est complètement inoffensif. Il donne toujours une liste de noms d'utilisateur, et bien que cela 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 mériter un essai.
De plus, le champ GECOS dans /etc/passwd Contient souvent des métadonnées comme les vrais noms des utilisateurs. Cela peut être utile pour des suppositions rapides en soi ou pour effectuer des recherches détaillées qui peuvent donner des suppositions plus probables. Il s'agit cependant de choses assez sophistiquées, qui vont bien au-delà (et ne nécessitent même pas forcément) d'avoir accès à /etc/passwd Lui-même
Lors de l'évaluation des vulnérabilités pour les clients, j'utilise /etc/passwd Comme "hé, j'ai obtenu LFI dans cette application et vous devez ê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 les fichiers. Étant donné qu'il s'agit d'une évaluation de 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 qu'il ne contienne 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 les fichiers 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 possibilité 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 les webapps disponible sur la machine. SSH n'est pas la seule cible!
Ces informations sont utiles non seulement pour la force brute générique, mais également pour chaque attaque pouvant 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 savoir 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 de privilèges locale.
Je vous recommande de lire certains guides linux privesc (mubix & g0tmilk pour les démarreurs) et de mettre la main sur des vidéos vulnérables pour une formation pratique privesc (vulnhub.com/kioptrix est un bon point de départ).