Frage:
Wie erhält ein Angreifer Zugriff auf gehashte Passwörter?
JimmyJames
2016-08-23 19:30:08 UTC
view on stackexchange narkive permalink

Die Art und Weise, wie wir Passwörter hashen, und die Stärke des Passworts sind wichtig, denn wenn jemand Zugriff auf die gehashten Passwörter erhält, ist es möglich, viele, viele Passwörter in überraschend kurzer Zeit auszuprobieren und alles zu knacken, was schwach ist.

Die Frage, die ich habe, ist, wie der Angreifer überhaupt Zugriff auf die gehashten Passwörter erhält. Wenn sie zum Beispiel Zugriff auf die Datei / etc / shadow haben, ist das Spiel dann nicht schon vorbei? Sind es einfach schlechte Berechtigungseinstellungen? Backups? Andere Fehler? Ist es so, dass, sobald ein System kompromittiert ist, das Passwort von dort verwendet wird, um zu versuchen, in andere Systeme zu gelangen?

Ich denke, meine Anfrage läuft letztendlich auf die Implikation hinaus, die ich durch das Lesen über dieses Thema bekomme, dass es unvermeidlich ist dass der Angreifer Zugriff auf die Hashes erhält. Wie passiert das in der Praxis?

Sie werden auch feststellen, dass meistens nicht Betriebssystemkennwörter (`/ etc / shadow`) durchgesickert sind, sondern Kennwörter für eine webbasierte App / einen webbasierten Dienst.Diese werden normalerweise in einer Datenbank gespeichert und sind daher anfällig für Datenbankverletzungen.
Einige Protokolle (z. B. NTLM, WPA2-PSK) senden Kennwort-Hashes über das Netzwerk
@paj28 in Bezug auf NTLM ist dies dasselbe, was [pass-the-hash] ermöglicht (https://dfir-blog.com/2015/11/08/protecting-windows-networks-defeating-pass-the-hash /) richtig?
Es ist * nicht * unvermeidlich, aber das spielt keine Rolle.Gutes Sicherheitsdesign * setzt * voraus, dass jede andere Verteidigung gefallen ist, und zielt darauf ab, Wege zu finden, um die geschützte Ressource weiterhin zu retten.Warum möchten wir, dass Hashing-Algorithmen resistent gegen Angriffe sind?Denn * unter der Annahme * ist dieser Algorithmus der letzte Mann, der zur Verteidigung der geschützten Ressource steht.
Eine wichtige Sache, an die Sie sich erinnern sollten: Auch wenn viele der Probleme, die Kennwort-Hashes aufdecken, für den gehackten Server "Spielende" bedeuten können, liegt der Wert nicht unbedingt dort.Der Server, der gehackt wurde, ist für den Hacker möglicherweise nahezu wertlos. Wenn diese Hashes jedoch geknackt werden können (oder wenn es sich um Klartext usw. handelt), bedeutet die Wiederverwendung von Kennwörtern, dass der Hacker möglicherweise Zugriff auf E-Mail-Konten, Bankkonten usw. hat.
@EricLippert Ihr Punkt ist klar, aber ich möchte nur klarstellen, dass ich die Notwendigkeit eines starken Hash nicht in Frage stelle.Ich versuche nur, die Mechanik solcher Angriffe besser zu verstehen, da die meiste Literatur zu diesem Thema damit zu beginnen scheint, die Hashes in der Hand zu haben.Die Antworten sind hilfreich, wenn ich zu artikulieren versuche, warum Passwörter problematisch sind.
Normalerweise nicht.* Wenn sie es irgendwie tun *, dann kann dich die Hashing-Stärke immer noch retten.
@JimmyJames - Es ist definitiv verwandt, obwohl es zwei verschiedene Probleme gibt: 1) Im Netzwerk übertragene Hashs sind anfällig für Sniffing und Brute Focing. 2) Auf Live-Systemen erfasste Hashes können direkt verwendet werden, ohne dass das Passwort brutal erzwungen werden muss
Zum Vergleich denke ich, dass das MySQL-Anmeldesystem (ohne SSL) anfällig für 1 ist, aber nicht für 2.
Der Zugriff auf / etc / shadow ist möglicherweise noch nicht beendet.Möglicherweise können Sie eine Sicherheitsanfälligkeit bezüglich der Offenlegung von Dateien auf einem Webserver ausnutzen, der als Root ausgeführt wird (was nicht der Fall sein sollte, aber trotzdem).Wie würden Sie vorgehen, wenn Sie eine Datei lesen können, aber nicht mehr?Sofern der Administrator nicht mehr Fehler gemacht hat, besteht Ihre einzige Wette darin, das Passwort in / etc / shadow zu knacken und zu hoffen, dass SSH mit Passwortauthentifizierung oder ähnlichem überhaupt für die Öffentlichkeit verfügbar ist.Aus diesem Grund ist es wichtig, ein sicheres Kennwort zu wählen, die Anzahl der von Ihrem Host angebotenen Dienste zu begrenzen und die kennwortbasierte Authentifizierung zu deaktivieren.
Wenn der Lesezugriff auf "/ etc / shadow" "Spiel vorbei" bedeutet, gibt es keinen Grund, nur gehashte Passwörter darin zu speichern.
@HagenvonEitzen: Und selbst wenn ich als SQL-Benutzer irgendwie Berechtigungen hätte, würde ich zuerst versuchen (falls meine Intuitionen Schaden anrichten) `SELECT * FROM pw;` und so weiter.aber das gibt mir überhaupt keinen Zugang zu "/ etc / shadow".
Fünf antworten:
#1
+56
Anders
2016-08-23 19:40:25 UTC
view on stackexchange narkive permalink

Es gibt verschiedene Möglichkeiten:

  • SQL-Injection
  • Durchgesickerte Backups
  • Verärgerte Mitarbeiter, die sie verlieren
  • Beliebige Art von Verletzung des Servers, die die Ausführung von Code ermöglicht.

Wie Sie sehen, gibt es viele, viele Möglichkeiten, wie dies geschehen könnte - wie phihag in Kommentaren erwähnt, mehr mehr als die Hälfte der OWASP Top 10 könnte zu durchgesickerten Hashes führen - daher können sie nicht einfach in einem Beitrag tabellarisch aufgeführt werden.

Dies bedeutet nicht, dass es unvermeidlich ist, dass Hacker die bekommen Hashes, aber Sie sollten trotzdem einen guten Hashing-Algorithmus verwenden, um sich und Ihre Benutzer für alle Fälle zu schützen. Da ein Backup verloren gehen oder Ihr Server gehackt werden kann, ohne dass Sie es jemals bemerken, sollten Sie nur dann richtig gehashte Passwörter verwenden, um nachts schlafen zu können. Diese Strategie wird als "Tiefenverteidigung" oder einfach als "Plan für das Schlimmste" bezeichnet.

Ich will nicht vorschlagen, nicht wichtig zu sein, es scheint nur manchmal so, als ob es diese fatalistische Einstellung gibt.Ich finde viele Informationen über das Knacken von Passwörtern, aber nicht so viele darüber, wie man verhindert, dass die Hashes auslaufen.
@JimmyJames Der Grund, warum Sie keine spezifischen Informationen zum Verhindern des Verlusts von Passwörtern finden, ist, dass praktisch * jede * serverseitige Sicherheitsanfälligkeit dies zulässt.Von den [OWASP Top 10-Schwachstellenklassen] (https://www.owasp.org/index.php/Top_10_2013-Top_10) können die Klassen 1, 2, 4, 5, 6 und 9 Kennwort-Hashes verlieren.Mit anderen Worten, mehr als die Hälfte aller Sicherheitsanstrengungen wirkt der Offenlegung von Passwort-Hashs auf die eine oder andere Weise entgegen.
Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (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

Es gibt viele Methoden. Hier sind einige, die mir auf den ersten Blick einfallen. Jetzt bin ich vielleicht ein bisschen falsch mit der Syntax, da ich mich momentan nicht darum gekümmert habe, sie zu testen, aber im Allgemeinen sind dies Dinge, die Sie tun würden, um diese Daten zu erhalten.

Beachten Sie dies Mit den folgenden Exploits stelle ich nicht unbedingt Beispiele bereit, die Hashes stehlen (mit Ausnahme von SQLi), sondern Beispiele dafür, wie die Exploits funktionieren können. Der Angreifer würde die folgenden Exploits verwenden, um ein System weiter zu gefährden.

  1. SQL-Injection

    Beispiel:
    a ODER 1 = 1 '; exec sp_msforeachtable "SELECT * FROM?"; -

    Sie können auch sp_msforeachdb verwenden, wie folgt:

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

    Der - dient zum Auskommentieren von Teilen von die SQL-Anweisung, die Ihre Injektion beeinträchtigen kann. Dies sind nur sehr grundlegende Beispiele. Es hängt wirklich vom Format der Abfrage ab.

  2. OS-Injektion . ; cat / etc / passwd; rm -rf / *
  3. LDAP-Injektion . * , (cn = *) (| (password = *))
  4. Unsichere direkte Objektreferenz, die zu Local / führt Sicherheitsanfälligkeit bezüglich Remote File Inclusion .

    / etc / passwd% 00 (Hinweis: Passwörter werden hier natürlich nicht gespeichert. Das Auffinden gültiger Benutzernamen, wenn Benutzer Passwörter wiederverwenden, ist hier der Schlüssel oder die Verwendung der Benutzernamen

    % 00 ist ein "Null-Terminator", der verwendet wird, um zu verhindern, dass etwas danach kommt. Sie versuchen also nicht, etwas einzuschließen, das dies nicht tut existieren, zB: /etc/passwd.txt . Dies kann auch \ 000 , \ x00 , \ z , \ u0000 , \ 0 oder \ 00 , abhängig von der verwendeten Sprache.

  5. Hacken eines Entwicklers / Benutzers mit Zugriff auf die Datenbanken.
  6. Ausnutzen des Datenbankservers oder Webservers auf andere Weise.
Kurz gesagt, eine oder mehrere Sicherheitslücken werden verwendet, um indirekt Zugriff zu erhalten.OK, irgendwie offensichtlich, jetzt wo du es so formulierst.
Ja schon.Alle sind sowieso relativ einfach auszunutzen.
Moderne Systeme haben keine Passwörter in / etc / passwd, sondern in / etc / shadow.
@MikeP Sie sind richtig.Dies ist nur ein Beispiel.
Warum sollte das Knacken eines Passworts ein Hauptanliegen sein?Wenn sie Zugriff auf die Datenbank haben, benötigen sie sicherlich kein Kennwort, um auf andere wertvolle Informationen zuzugreifen. Sie können diese einfach anzeigen und sind wahrscheinlich im Klartext
Ich bin mir nicht sicher, ob ich dir folge.Das Passwort wird nicht im Klartext gespeichert, wenn es richtig gemacht wird, auch wenn alles andere falsch ist.Dies ist ein großes Problem, da Benutzer Kennwörter wiederverwenden und möglicherweise mit derselben Kombination aus Benutzername und Kennwort auf andere Websites zugreifen können.
Das Abrufen der E-Mail-Adresse und des Kennworts eines Benutzers durch @binnyb, gefährdet nicht nur das eine System.Aufgrund der Wiederverwendung von Passwörtern können viele Systeme gefährdet werden.Für weitere Informationen: http://krebsonsecurity.com/2013/06/the-value-of-a-hacked-email-account/
@MikeP Ich hätte klarstellen sollen: Mit `/ etc / passwd` können Sie Benutzernamen finden, mit denen Sie sich anmelden oder Berechtigungen eskalieren können.Es ist ein kleiner Teil des Prozesses, aber ein grundlegender.Wenn Benutzer Kennwörter auf mehreren Systemen wiederverwenden, müssen Sie möglicherweise nur einen gültigen Benutzernamen finden, wenn Sie über gültige Kennwörter verfügen.LFI / RFI kann auch verwendet werden, um die Codeausführung zu erreichen, die DB-Anmeldeinformationen, AWS-Creds usw. bereitstellen kann.
#3
+9
MikeP
2016-08-23 22:29:10 UTC
view on stackexchange narkive permalink

Eine Ergänzung zu Mark Buffalo:
7. Man-in-the-Middle-Angriff. Wenn Sie unverschlüsselten Datenverkehr beobachten, wird häufig ein Kennwort-Hash angezeigt. In einem Pass-the-Hash-Szenario vertrauen Systeme dem Hash und dem Kennwort und lassen einen Angreifer den Hash einfach kopieren, ohne ihn zu knacken.

Welche Verbindung fangen Sie hier ab?
OP fragt nur nach Fällen, in denen der Angreifer Zugriff auf viele Hashes erhält.
@Bergi Diese Antwort ist ebenfalls relevant.
@Bergi, OP gibt keine "Lose" an.Wenn jedoch jemand Zugriff auf eine Art des MitM-Angriffs hat, kann er "viele" erhalten.
Ja, wenn Sie den unverschlüsselten Datenverkehr zwischen der Datenbank und dem Anwendungsserver abhören können, der möglicherweise einige Hashes aufzeigt, sollten Sie dies klarstellen.Aber ich denke, ein Pass-the-Hash-Szenario, in dem Sie die Hashes als Mitm kontrollieren können, ist für die Frage nicht relevant.
#4
+6
Cort Ammon
2016-08-24 02:45:42 UTC
view on stackexchange narkive permalink

Der einzige wirklich sichere Computer ist ein Computer, der vom Internet isoliert, ausgeschaltet, ausgesteckt, in einem 100 Fuß unter der Erde gelegenen Bunker mit bewaffneten Wachen am einzigen Eingang begraben ist. Selbst dann überprüfe ich es von Zeit zu Zeit.

Das Hashing der Passwörter ist Teil der sogenannten "Sicherheit in der Tiefe". Sie haben Recht, dass Sie in einer idealen Welt keine Fehler machen würden, die Angreifern Zugriff auf diese Daten gewähren würden. Theoretisch wäre es also egal, ob es sich um Klartextkennwörter oder Hashes handelt. In einer realen Welt treten Eingriffe auf, und es ist bemerkenswert schwer vorherzusagen, wie und wo sie auftreten werden. Die Idee hinter der eingehenden Sicherheit besteht darin, sie so zu gestalten, dass Sie theoretisch, selbst wenn ein Angreifer Ihr System auf irgendeine Weise kompromittiert, Anstrengungen unternommen haben, um den Schaden zu mindern.

In der realen Welt gibt es solche ein natürliches Bedürfnis, regelmäßig auf Hashes zuzugreifen. Jedes Mal, wenn sich ein Benutzer anmeldet, müssen Sie darauf zugreifen können. Dementsprechend sind sie fast immer für jede Anwendung zugänglich, die die Authentifizierung durchführt. Wenn jemand Ihre Anwendung kompromittiert, kann er möglicherweise Daten lesen, die er eigentlich nicht lesen sollte.

Die Art und Weise, wie diese Angriffe auftreten, ist endlos. Sie können SQL-Injection-Angriffe ausführen, wenn Sie Ihre Eingaben nicht bereinigen konnten. Sie könnten einen Pufferüberlauf haben, der dem Angreifer die Möglichkeit gibt, seinen eigenen Code auszuführen. Möglicherweise liegt ein Berechtigungsfehler vor, der dazu führt, dass eine Datei versehentlich von Personen gelesen werden kann, wenn dies nicht der Fall sein sollte. Der Angreifer kann aufgrund eines Missbrauchs durch Ihren Sicherungsdienst eines Ihrer Sicherungsbänder in die Hände bekommen!

Alle diese Angriffe geben einem Angreifer Halt auf Ihrem Computer, führen jedoch nicht immer zu einer vollständigen Unterbrechung. Möglicherweise haben Sie Ihren SQL Server chrooted, sodass der SQL Server-Prozess buchstäblich nicht den gesamten Rest des Computers sehen kann. In solchen Situationen müssen die Anmeldeinformationen, die Benutzer benötigen, in Reichweite des SQL-Servers sein oder keinen Wert haben. Daher werden Anmeldeinformationen in der Regel kompromittiert, bevor andere schändlichere Kompromisse auftreten.

Durch Hashing der Kennwörter verringern Sie deren Wert. Ein Hash ist für Anmeldezwecke nicht nützlich. Sie müssen das Passwort haben, das auf diesen Wert hasht. Sie können sich die Kosten für das Brechen des Hash leisten oder auch nicht. In der besten aller Welten mussten Sie sich darüber überhaupt keine Gedanken machen. Wenn Sie sich jedoch für den Sicherheitsansatz anmelden, stellen Sie sicher, dass selbst ein erfolgreicher Eingriff nicht alle Ihre Daten gefährdet. P. >

Sie werden auch den Hash salzen, damit 2 gleiche Passwörter nicht den gleichen Hash erhalten.Auf diese Weise können Hacker nicht einfach eine riesige Datenbank mit Hashs für Passwörter erstellen.
"Ich würde ab und zu nachsehen" - und das ist wahrscheinlich Ihr Untergang.Unabhängig davon, welche Verfahren Sie eingerichtet haben, um sich selbst zu überprüfen, haben Sie die Möglichkeit, etwas zu vermasseln und einen Angreifer hereinzulassen.
@SteveJessop Richtig, der beste Weg, einen Computer zu sichern, bestand immer darin, ihn durch einen Holzhacker zu führen und dann die Überreste in Brand zu setzen =)
@CortAmmon Obwohl ich nicht damit einverstanden bin, dass Ihre Paranoia für die Sicherung von Systemen wichtig ist, denke ich, dass diese Argumentation oft als Entschuldigung dafür missbraucht wird, es nicht zu versuchen.Ich nehme eine populäre Täuschung wahr, dass das Einbrechen in ein System wie das Einbrechen in einen Safe ist.Wenn Sie genügend Zeit, Mühe und Ausrüstung haben, können Sie einbrechen. Die Realität ist, dass die meisten Schwachstellen aufgrund von Faulheit und Unwissenheit in Systeme eingebaut sind.Wenn Menschen versagen, indem sie anfälligen Code schreiben oder keine bewährten Methoden anwenden, hören wir oft von der „Unmöglichkeit“, Systeme zu sichern.
@JimmyJames Ich habe tatsächlich auch den gegenteiligen Effekt gesehen.Ich habe Leute gesehen, die glauben, dass diese beiden Annahmen zusammen "beweisen", dass ihr System sicher ist, da sie alles getan haben, um ein System zu sichern, und sie glauben, dass ein System tatsächlich sicher sein kann.Dann werden sie faul und verwenden die Sicherheit nicht in der Tiefe.Nur wenn Sie zugeben, dass Ihr System unsicher ist, ist eine umfassende Sicherheit sinnvoll.Ich habe auch einen unerbittlichen Marsch in Richtung "perfekt sicherer" Dash-Usability gegen die Felsen gesehen.Ich finde, dass beide Fälle genauso problematisch sind wie der, den Sie ansprechen.
@CortAmmon Gute Punkte.Wenn ich einen Satz dazu prägen könnte, würde ich ihn so etwas wie "Angenommen, Sie haben Schwachstellen und bemühen uns ständig, alle zu beseitigen".
@JimmyJames Ich mag diese Formulierung.Es erinnert mich an die berühmte Formulierung "Pläne sind nutzlos, aber Planung ist unverzichtbar."
Ein Computer ohne Stromversorgung hat möglicherweise eine gute Vertraulichkeit, aber Integrität und Verfügbarkeit können etwas fehlen ...
#5
+2
rackandboneman
2016-08-24 14:53:13 UTC
view on stackexchange narkive permalink

Einige vernetzte Un * x / Linux-Installationen der alten Schule verwenden weiterhin den NIS / YP-Dienst für die zentral verwaltete Authentifizierung. NIS veröffentlicht effektiv die gehashten Kennwörter im Netzwerk für jede Workstation, um Benutzer zu authentifizieren.

Und in früheren Tagen wurden die gesalzenen Passwörter in einem weltweit lesbaren "/ etc / password" aufbewahrt.
Dies ist bei einigen modernen Linux-Distributionen zur Installationszeit immer noch eine Option.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...