Question:
Comment un attaquant peut-il accéder aux mots de passe hachés?
JimmyJames
2016-08-23 19:30:08 UTC
view on stackexchange narkive permalink

La façon dont nous hachons les mots de passe et la force du mot de passe est importante car si quelqu'un accède aux mots de passe hachés, il est possible d'essayer des tas de mots de passe dans un laps de temps étonnamment court et de déchiffrer tout ce qui est faible.

Ma question est de savoir comment se fait-il que l'attaquant ait accès aux mots de passe hachés en premier lieu. S'ils ont accès au fichier / etc / shadow, par exemple, la partie n'est-elle pas déjà terminée? S'agit-il simplement de mauvais paramètres d'autorisations? Des sauvegardes? D'autres erreurs? Est-ce qu'une fois qu'un système est compromis, le mot de passe de là est utilisé pour tenter d'entrer dans d'autres systèmes?

Je suppose qu'en fin de compte, ma requête se résume à l'implication que j'obtiens en lisant sur ce sujet que c'est inévitable que l'attaquant aura accès aux hachages. Comment cela se passe-t-il dans la pratique?

Vous remarquerez également que le plus souvent, ce ne sont pas les mots de passe du système d'exploitation (`/ etc / shadow`) qui sont divulgués, mais les mots de passe d'une application / service Web.Ceux-ci sont normalement stockés dans une base de données et sont donc vulnérables aux violations de la base de données.
Certains protocoles (par exemple NTLM, WPA2-PSK) envoient des hachages de mot de passe sur le réseau
@paj28 en ce qui concerne NTLM, c'est la même chose qui permet de [passer le hachage] (https://dfir-blog.com/2015/11/08/protecting-windows-networks-defeating-pass-the-hash /) non?
Ce n'est * pas * inévitable, mais cela n'a pas d'importance.Une bonne conception de la sécurité * suppose * que toutes les autres défenses sont tombées et vise à trouver des moyens de continuer à sauver la ressource protégée.Alors pourquoi souhaitons-nous que les algorithmes de hachage soient résistants aux attaques?Parce que * par hypothèse *, cet algorithme est le dernier homme à défendre la ressource protégée.
Il est important de se rappeler que même si la plupart des problèmes qui révèlent des hachages de mots de passe peuvent signifier "game over" pour le serveur qui a été piraté, ce n'est pas nécessairement là que réside la valeur.Le serveur qui a été piraté peut être presque sans valeur pour le pirate informatique, mais si ces hachages peuvent être piratés (ou s'ils étaient en texte brut, etc.), la réutilisation du mot de passe signifie que le pirate peut avoir accès à des comptes de messagerie, des comptes bancaires, etc.
@EricLippert Votre point est pris, mais je veux juste préciser que je ne remets pas en question la nécessité d'avoir un hachage fort.J'essaie juste de mieux comprendre les mécanismes autour de telles attaques, car la plupart des publications sur le sujet semblent commencer par avoir les hachages en main.Les réponses sont utiles lorsque j'essaie d'expliquer pourquoi les mots de passe sont problématiques.
Habituellement, ils ne le font pas.* S'ils le font d'une manière ou d'une autre *, la force de hachage peut toujours vous sauver.
@JimmyJames - C'est définitivement lié, bien qu'il y ait deux problèmes distincts: 1) Le hachage transmis sur le réseau est vulnérable au reniflage et à la focalisation brute 2) Les hachages capturés sur des systèmes en direct peuvent être utilisés directement, sans avoir besoin de forcer le mot de passe.
À titre de comparaison, je pense que le système de connexion MySQL (sans ssl) est vulnérable à 1, mais pas à 2.
L'accès à / etc / shadow ne peut pas être terminé.Vous pourriez être en mesure d'exploiter une vulnérabilité de divulgation de fichiers dans un serveur Web qui s'exécute en tant que root (ce qu'il ne devrait pas, mais de toute façon).Comment procéderiez-vous si vous pouviez lire n'importe quel fichier, mais pas plus?À moins que l'administrateur ne fasse plus d'erreurs, votre seul pari est de déchiffrer le mot de passe dans / etc / shadow et d'espérer que SSH avec authentification par mot de passe ou similaire sera même disponible au public.C'est pourquoi il est important de choisir un mot de passe sécurisé, de limiter la quantité de services proposés par votre hôte et de désactiver l'authentification par mot de passe.
Si l'accès en lecture à `/ etc / shadow` signifiait" game over ", il n'y aurait aucune raison de ne stocker que des mots de passe hachés en premier lieu.
@HagenvonEitzen: Et même si, si j'avais en quelque sorte des autorisations en tant qu'utilisateur sql, j'essaierais d'abord (au cas où mes intuitions causent des dommages) `SELECT * FROM pw;` et cela de même.mais cela ne me donne pas du tout accès à `/ etc / shadow`.
Cinq réponses:
#1
+56
Anders
2016-08-23 19:40:25 UTC
view on stackexchange narkive permalink

Il existe plusieurs façons:

  • Injection SQL
  • Fuite de sauvegardes
  • Des employés mécontents qui les fuient
  • Quelconque une sorte de violation du serveur qui permet l'exécution de code.

Comme vous pouvez le voir, cela peut se produire de très nombreuses façons - comme phihag le mentionne dans les commentaires, plus que la moitié du top 10 OWASP pourrait conduire à des fuites de hachages - ils ne peuvent donc pas être facilement compilés dans un message.

Cela ne signifie pas qu'il est inévitable que les pirates informatiques obtiennent le hashes, mais vous devez toujours utiliser un bon algorithme de hachage pour vous protéger et protéger vos utilisateurs au cas où. Puisqu'une sauvegarde peut être perdue ou votre serveur piraté sans que vous ne vous en rendiez compte, avoir des mots de passe correctement hachés devrait être la seule chose qui vous permette de dormir la nuit. Cette stratégie est connue sous le nom de "défense en profondeur", ou simplement "planifier le pire".

Je ne veux pas dire que ce n'est pas important, il semble juste qu'il y ait parfois cette attitude fataliste à ce sujet.Je trouve beaucoup d'informations sur le craquage des mots de passe, mais pas tellement sur la façon d'éviter les fuites de hachages.
@JimmyJames La raison pour laquelle vous ne trouvez aucune information spécifique sur la prévention des fuites de mots de passe est que pratiquement * chaque * vulnérabilité côté serveur le permet.Parmi les [10 principales classes de vulnérabilité de l'OWASP] (https://www.owasp.org/index.php/Top_10_2013-Top_10), les classes 1, 2, 4, 5, 6 et 9 peuvent divulguer des hachages de mots de passe.En d'autres termes, plus de * la moitié de ** tous les ** efforts de sécurité * contre la divulgation de hachage de mot de passe d'une manière ou d'une autre.
Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/44500/discussion-on-answer-by-anders-how-does-an-attacker-get-access-to-hashed-passwor).
#2
+29
Mark Buffalo
2016-08-23 19:39:37 UTC
view on stackexchange narkive permalink

Il existe de nombreuses méthodes. En voici quelques-unes auxquelles je peux penser du haut de ma tête. Maintenant, je me trompe peut-être un peu avec la syntaxe car je n'ai pas pris la peine de la tester pour le moment, mais en général, ce sont des choses que vous feriez pour obtenir ces données.

Notez que , avec les exploits ci-dessous, je ne fournis pas nécessairement des exemples qui volent des hachages (à l'exception de SQLi), mais des exemples de la façon dont les exploits peuvent fonctionner. L'attaquant utiliserait les exploits ci-dessous pour compromettre davantage un système.

  1. Injection SQL

    Exemple:
    a OU 1 = 1 '; exec sp_msforeachtable "SELECT * FROM?"; -

    Vous pouvez également utiliser sp_msforeachdb , comme ceci:

    a ' ; exec sp_msforeachdb 'USE?; exec sp_msforeachTable "SELECT * FROM!", "!"'; -

    Le - est là pour commenter des parties de l'instruction SQL qui peut interférer avec votre injection. Ce ne sont que des exemples très basiques. Cela dépend vraiment du format de la requête.

  2. Injection du système d'exploitation . ; cat / etc / passwd; rm -rf / *
  3. Injection LDAP . * , (cn = *) (| (password = *))
  4. Référence d'objet directe non sécurisée menant à Local / Vulnérabilité d'inclusion de fichiers distants .

    / etc / passwd% 00 (note: les mots de passe, bien sûr, ne sont pas stockés ici; trouver des noms d'utilisateur valides lorsque les gens réutilisent des mots de passe est la clé ici, ou utiliser les noms d'utilisateur pour aider à l'élévation des privilèges)

    % 00 est un "terminateur nul" utilisé pour éviter que quoi que ce soit après lui, vous n'essayez donc pas d'inclure quelque chose qui ne le fait pas existent, par exemple: /etc/passwd.txt . Cela peut également être \ 000 , \ x00 , \ z , \ u0000 , \ 0 ou \ 00 selon la langue que vous utilisez.

  5. Piratage d'un développeur / utilisateur ayant accès aux bases de données.
  6. Exploiter le serveur de base de données ou le serveur Web par d'autres moyens.
Donc, en un mot, une ou plusieurs vulnérabilités sont utilisées pour accéder indirectement.OK semble évident maintenant que vous le mettez comme ça.
Plutôt.Tous sont de toute façon relativement faciles à exploiter.
Les systèmes modernes n'auront pas de mots de passe dans / etc / passwd, ils sont dans / etc / shadow.
@MikeP Vous avez raison.C'est juste un exemple.
pourquoi craquer un mot de passe serait-il une préoccupation majeure?S'ils ont accès à la base de données, ils n'ont sûrement pas besoin d'un mot de passe pour accéder à d'autres informations précieuses - ils pourraient simplement les consulter et seraient probablement en texte brut
Je ne suis pas sûr de vous suivre.Le mot de passe ne sera pas stocké en texte brut s'il est bien fait, même si tout le reste est faux.C'est une préoccupation majeure car les gens réutilisent les mots de passe, et cela peut leur permettre d'accéder à d'autres sites Web en utilisant le même combo nom d'utilisateur / mot de passe.
@binnyb, obtenir l'adresse e-mail et le mot de passe d'un utilisateur ne compromet pas seulement le système unique.En raison de la réutilisation des mots de passe, cela peut compromettre de nombreux systèmes.Pour plus d'informations: http://krebsonsecurity.com/2013/06/the-value-of-a-hacked-email-account/
@MikeP J'aurais dû clarifier: `/ etc / passwd` vous permet de trouver des noms d'utilisateur, qui peuvent ensuite être utilisés pour vous connecter ou augmenter les privilèges.C'est une petite partie du processus, mais fondamentale.Lorsque les utilisateurs réutilisent des mots de passe sur plusieurs systèmes, il se peut que vous deviez simplement trouver un nom d'utilisateur valide si vous avez des mots de passe valides.LFI / RFI peut également être utilisé pour obtenir l'exécution de code, ce qui pourrait fournir des informations d'identification de base de données, des références AWS, etc.
#3
+9
MikeP
2016-08-23 22:29:10 UTC
view on stackexchange narkive permalink

Un ajout à Mark Buffalo:
7. Attaque Man-in-the-Middle. Regarder le trafic non chiffré peut souvent révéler un hachage de mot de passe. Dans un scénario de pass-the-hash, les systèmes feront confiance au hachage et au mot de passe et laisseront un attaquant copier simplement le hachage sans le casser.

Quelle connexion interceptez-vous ici?
OP ne demande que les cas où l'attaquant a accès à de nombreux hachages.
@Bergi Cette réponse est également pertinente.
@Bergi, OP n'indique pas "lots".Cependant, si quelqu'un a accès à un moyen d'attaquer MitM, alors il peut en obtenir "beaucoup".
Oui, si vous pouvez écouter le trafic non chiffré entre la base de données et le serveur d'application qui pourrait révéler des hachages, c'est ce que je voulais que vous clarifiiez.Mais je pense qu'un scénario pass-the-hash où vous pouvez contrôler les hachages en étant un mitm n'est pas pertinent pour la question.
#4
+6
Cort Ammon
2016-08-24 02:45:42 UTC
view on stackexchange narkive permalink

Le seul ordinateur vraiment sécurisé est celui qui est isolé d'Internet, éteint, débranché, enterré dans un bunker à 100 pieds sous terre, avec des gardes armés à la seule entrée. Même dans ce cas, je le vérifierais de temps en temps.

Le hachage des mots de passe fait partie de ce que l'on appelle la «sécurité en profondeur». Vous avez raison de dire que, dans un monde idéal, vous ne commettriez aucune erreur qui permettrait aux attaquants d'accéder à ces données, donc en théorie, cela n'aurait pas d'importance s'il s'agissait de mots de passe en clair ou de hachages. Dans un monde réel, des intrusions se produisent et il est extrêmement difficile de prévoir comment et où elles se produiront. L'idée derrière la sécurité en profondeur est de faire en sorte qu'en théorie, même si un attaquant compromet votre système d'une manière ou d'une autre, vous avez déployé des efforts pour atténuer les dégâts.

Dans le monde réel, il y a un besoin naturel d'accéder régulièrement aux hachages. Chaque fois qu'un utilisateur se connecte, vous devez pouvoir y accéder. En conséquence, ils sont presque toujours accessibles à n'importe quelle application qui effectue l'authentification. Si quelqu'un compromet votre application, il pourra peut-être lire des données qu'il n'était pas censé pouvoir lire.

Les façons dont ces attaques se produisent sont infinies. Vous pouvez avoir des attaques par injection SQL si vous n'avez pas réussi à nettoyer vos entrées. Vous pourriez avoir un dépassement de tampon, donnant à l'attaquant la possibilité d'exécuter son propre code. Vous pourriez avoir une erreur d'autorisations, rendant accidentellement un fichier lisible par des personnes alors que vous n'auriez pas dû. L'attaquant peut mettre la main sur l'une de vos bandes de sauvegarde en raison d'une mauvaise gestion de votre service de sauvegarde!

Toutes ces attaques permettent à un attaquant de prendre pied sur votre ordinateur, mais elles n'entraînent pas toujours une rupture complète. Vous avez peut-être chrooté votre serveur SQL, de sorte que le processus du serveur SQL ne peut littéralement pas voir le reste de l'ordinateur. Cependant, dans de telles situations, les informations de connexion dont les utilisateurs ont besoin doivent être à la portée du serveur SQL ou sans valeur. Ainsi, les informations de connexion sont généralement compromises avant que d'autres compromis plus néfastes ne se produisent.

En hachant les mots de passe, vous diminuez leur valeur. Un hachage n'est pas utile à des fins de connexion. Ils doivent avoir le mot de passe haché à cette valeur. Ils peuvent ou non être en mesure de payer le coût de la rupture du hachage. Dans le meilleur de tous les mondes, vous n’avez jamais eu à vous soucier de cela en premier lieu, mais si vous souscrivez à l’approche de sécurité en profondeur, vous vous assurez que même une intrusion réussie ne compromet pas toutes vos données.

Vous salerez également le hachage, de sorte que 2 mêmes mots de passe ne se retrouvent pas avec le même hachage.De cette façon, les pirates ne peuvent pas simplement créer une énorme base de données de hachage pour les passords.
"Je m'en occuperais de temps en temps" - et c'est probablement votre chute.Quelles que soient les procédures que vous mettez en place pour vous laisser vérifier, vous avez la possibilité de foirer quelque chose et de permettre à un attaquant d'entrer.
@SteveJessop Certes, le meilleur moyen de sécuriser un ordinateur a toujours été de le faire passer dans une déchiqueteuse à bois, puis de mettre le feu aux restes =)
@CortAmmon Bien que je ne sois pas en désaccord avec le fait que la paranoïa est importante dans la sécurisation des systèmes, je pense que ce raisonnement est souvent utilisé à tort comme une excuse pour ne pas essayer.Je perçois une illusion populaire selon laquelle pénétrer dans un système est comme entrer dans un coffre-fort.Avec suffisamment de temps, d'efforts et d'équipement, vous pouvez vous y introduire. La réalité est que la plupart des vulnérabilités sont intégrées aux systèmes en raison de la paresse et de l'ignorance.Lorsque les gens échouent en écrivant du code vulnérable ou en n'utilisant pas les bonnes pratiques, nous entendons souvent parler de «l'impossibilité» de sécuriser les systèmes.
@JimmyJames J'ai également vu l'effet inverse.J'ai vu des gens qui croient que, puisqu'ils ont fait tout ce qu'ils peuvent pour sécuriser un système, et qu'ils croient qu'un système peut réellement être sécurisé, ces deux hypothèses réunies «prouvent» que leur système est sécurisé.Ensuite, ils deviennent paresseux et n'utilisent pas la sécurité en profondeur.Ce n'est que lorsque vous admettez que votre système n'est pas sécurisé que la sécurité en profondeur a du sens.J'ai également assisté à une marche incessante vers une utilisation "parfaitement sécurisée" du tableau de bord contre les rochers.Je trouve que ces deux cas sont aussi problématiques que celui que vous évoquez.
@CortAmmon Bons points.Si je pouvais inventer une phrase autour de cela, je lui ferais quelque chose comme "supposer que vous avez des vulnérabilités et s'efforcer continuellement de les éliminer toutes".
@JimmyJames J'aime ce phrasé.Cela me rappelle le fameux phrasé «Les plans sont inutiles, mais la planification est indispensable».
Un ordinateur non alimenté peut avoir une bonne confidentialité, mais l'intégrité et la disponibilité peuvent faire un peu défaut ...
#5
+2
rackandboneman
2016-08-24 14:53:13 UTC
view on stackexchange narkive permalink

Certaines installations un * x / linux à l'ancienne en réseau utiliseront toujours le service NIS / YP pour l'authentification gérée de manière centralisée. NIS publie efficacement les mots de passe hachés sur le réseau pour chaque poste de travail pour authentifier les utilisateurs.

Et, jadis, les mots de passe salés étaient conservés dans un fichier lisible par le monde entier `/ etc / password`.
Ce qui est toujours une option disponible au moment de l'installation avec certaines distributions Linux modernes.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...