Wie man unsichere Webanwendung hackt

In diesem Artikel möchte ich demonstrieren, wie einfach es ist, vertrauliche Informationen von einer Webanwendung zu erhalten, die… nun, schenkt der Sicherheit nicht zu viel Aufmerksamkeit. Ich werde mit einer Beispiel-Java-Anwendung arbeiten, die ich zu Demonstrationszwecken in Spring Boot erstellt habe. Die durchgeführten Angriffe sind jedoch für jede andere Programmiersprache oder jedes andere Framework gültig. Einige Schwachstellen und Sicherheitsprobleme, die demonstriert werden, umfassen:

• SQL Injection
• Sensitive data exposure
• Unzureichende Protokollierung
• Defekte Authentifizierung

Das Setup

Wir werden mit einer fiktiven Webanwendung arbeiten, mit der Sie sich als Benutzer anmelden können, der Teil einer Gruppe ist. Je nach Benutzerrolle kann er entweder grundlegende oder vertrauliche Daten anzeigen. In diesem Fall sehen Sie eine Liste der Mitarbeiter in einem Unternehmen, deren Status usw.

Sie können die Quellen zu dieser Anwendung in meinem Github finden: https://github.com/rapasoft/hackme.

Angriff #1: Mann im mittleren Angriff

Stellen Sie sich vor, Sie sitzen in einem Restaurant und möchten etwas in der obigen Anwendung überprüfen. Sie stellen eine Verbindung zum WLAN des Restaurants her, öffnen die Anmeldeseite, geben Anmeldeinformationen ein und erhalten die gewünschten Informationen (z. B. die Liste bestimmter Mitarbeiter). Was Sie jetzt vielleicht nicht wissen, ist, dass Ihre Anmeldeinformationen kompromittiert wurden. Lassen Sie uns die Anmeldeseite genau untersuchen:

Diese Anwendung verwendet kein SSL/TLS (z.B. keine https:// Verbindung). Dies bedeutet, dass alle gesendeten Informationen von jedem, der Zugriff auf die Kommunikation zwischen Client und Server hat, als Klartext angezeigt werden können.

Das ist genau das, was im sogenannten Man-in-the-Middle-Angriff passiert. Genauer gesagt, In diesem Fall wurde ARP-Spoofing verwendet, um das gesamte Netzwerk zu vergiften, so dass der Angreifer über alles Bescheid weiß und an allen Paketen schnüffeln kann. Ich werde nicht ins Detail gehen, wie ARP-Spoofing funktioniert, sondern es in diesem Video demonstrieren:

Möglicherweise müssen Sie dieses Youtube-Video in einem neuen Fenster und im Vollbildmodus öffnen, um weitere Details anzuzeigen

Was Sie oben sehen können, ist, dass ich Ettercap gestartet habe, eine umfassende Suite für MITM-Angriffe, und ARP-Spoofing in meinem lokalen Netzwerk durchgeführt habe. Wenn der Benutzer (ich über das iPad) die Anmeldeinformationen eingibt, sind sie in der Zwischenzeit sowohl in Ettercap als auch in Wireshark (Tool zur Analyse des Netzwerkverkehrs) sichtbar.

Angriff #2: SQL Injection

Wir setzen unsere Rolle als Angreifer dieser Anwendung fort und haben jetzt die Anmeldeinformationen für den Benutzer hgraves mit dem Kennwort P4SSW0RD. Sie können sehen, dass diese Anwendung nicht nur kein TLS verwendet, sondern auch eine sehr schwache Kennwortrichtlinie, mit der Benutzer wirklich schreckliche Kennwörter auswählen können.

Wir melden uns mit den obigen Anmeldeinformationen an und sehen ein Eingabefeld mit der Option, nach einer Personenliste zu suchen. Wenn Sie Search drücken, erhalten Sie die vollständige Liste der Personen. Wenn wir zum Beispiel „Fra“ eingeben, erhalten wir gefilterte Ergebnisse basierend auf der Suche. Was ist, wenn wir dort einen illegalen Charakter setzen? Es ist offensichtlich, dass hinter dieser Anwendung eine Datenbank steckt, also probieren wir das Zeichen ' aus:

Dies ist nicht nur fehlgeschlagen, sondern wir können auch sehen, dass die POST -Anforderung mit einer sehr spezifischen Fehlermeldung fehlgeschlagen ist, die die Struktur der gesamten SQL-Anweisung offenlegt. Wir können sehen, dass WHERE P.NAME LIKE '%'%' am Ende verwendet wird.

Erfahrener Hacker braucht nicht mehr. Das Anpassen der Suchzeichenfolge kann nach wenigen Versuchen zu folgenden Ergebnissen führen:

Die Injektion hat in diesem Fall eine union to select-Anweisung erstellt, die Benutzernamen und Kennwörter zusammen mit ihrer Rolle abruft. Nicht nur das war erfolgreich, wir haben es geschafft, es in der ursprünglichen Client-Anwendung anzuzeigen.

Wir haben jetzt Anmeldeinformationen aller Benutzer und ihrer Rollen (angezeigt durch die Ganzzahl in der Spalte „Alter“). Wenn hframe die Rolle 1 hat, muss rgraves daher der wichtigere Benutzer mit der Rolle 3 sein.

Angriff #3: Angriff auf schwach gehashte Passwörter

Wir haben beim ersten Angriff erfahren, dass für diese Anwendung wahrscheinlich keine Kennwortrichtlinie festgelegt ist. Dies würde uns hoffen lassen, dass rgraves auch der Sicherheit nicht zu viel Aufmerksamkeit schenkt.

Der einfachste Weg, einen Hash eines Passworts zu knacken, der einen unzureichenden Hashing-Algorithmus verwendet (wie in diesem Fall MD5), besteht darin, einen Wörterbuch- oder Rainbow Table-Angriff durchzuführen. Es gibt viele Möglichkeiten, aber am einfachsten ist es, Internetdienste zu verwenden, die bereits über eine große Datenbank mit Passwort-zu-Hash-Kombinationen verfügen:

Der erste ist hframe, der zweite ist rgraves. smorgan scheint stärkere Passwörter zu verwenden als andere, da es nicht im Wörterbuch enthalten ist.

Sie können sehen, dass das Passwort für rgraves Schwertfisch ist, was bedeutet, dass er nicht weiß, wie wichtig es ist, ein Nicht-Wörterbuch-Passwort zu wählen;). Nichts hindert uns nun daran, uns als Benutzer anzumelden und den Abschnitt „Admin“ und vertrauliche Informationen zu entdecken:

Lies das nicht, wenn du Deutscher bist 🙂

Wie kann ich das beheben?

Man könnte sagen, dass all dies leicht verhindert werden könnte. Man könnte sagen, dass dies Anfängerfehler waren. Nun, das mag wahr sein, aber was auch wahr ist, ist, dass das Open Web Application Security Project Injection als Nummer 1 der Sicherheitslücken in Webanwendungen auflistet (und das seit mehreren Jahren).

Wenn Sie sich also gefragt haben, wie Sie all dies verhindern können, lassen Sie uns zusammenfassen:

• Verwenden Sie immer SSL / TLS, wenn Sie etwas an den Server senden. Es müssen keine Anmeldeinformationen sein, es wird derzeit allgemein als gute Praxis angesehen. Auch wenn Sie überhaupt keine Eingaben auf Ihrer Seite haben! Am einfachsten ist es, Zertifikate über Dienste wie Let’s Encrypt bereitzustellen.
• Denken Sie daran, dass selbstsignierte Zertifikate das Problem der Datenexposition verringern können, aber nicht verhindern, dass MITM-Angreifer die gesamte Site mit seinem eigenen selbstsignierten Zertifikat fälschen.
• Beim Umgang mit SQL-Abfragen immer Escape-Parameter vom Client erhalten. Der einfachste Weg, dies zu tun, besteht darin, die Funktionen Ihres Frameworks zu verwenden, z. B. im Frühjahr können Sie NamedParameterJdbcTemplate verwenden, was auch für die Lesbarkeit gut ist.
• Sei paranoid. Validieren Sie alle Benutzereingaben. Auch in der Java / Spring-Welt können Sie Validierungsregeln mit der JSR-380 Bean-Validierungsimplementierung wie Hibernate Validator hinzufügen und Parameter kommentieren, z. B. @Pattern(regexp = "*") String name würde die Eingabe von ' verhindern.
• Protokollieren Sie alle Versuche, ungültige Eingaben in die Anwendung zu übergeben. Darüber hinaus stellen Sie dem Client im Fehlerfall keine implementierungsspezifischen Informationen zur Verfügung.
• Verbessern Sie Ihre Authentifizierung.
  • Verwenden Sie nach Möglichkeit mindestens eine 2-Faktor-Authentifizierung.
  • Implementieren Sie keine benutzerdefinierten Kennwortspeicher- oder Verschlüsselungsalgorithmen. Es ist extrem schwierig, es alleine zu machen, und Sie werden definitiv scheitern. Es gibt bewährte Lösungen wie BCrypt.
• Lesen und Lesezeichen OWASP TOP 10. Beginnen Sie dort und gehen Sie dann die Liste der Best Practices durch.