Skip to content

1. SF Authentication

Allgemein¶

Authentication ist ein Prozess der User bzw. Clients identifiziert und ggf. unterschiedliche Rechte auf Webseiten verteilt, weil Webseiten in erster Linie erstmal öffentlich für das ganze Internet ist. Deswegen sind robuste Authentication-Mechanismen essenziell für Web-Security.

Es gibt 3 verschiedene Haupttypen - Etwas was man weiĂź z. B: Passwort - Etwas was man hat z. B: SchlĂĽssel - Etwas was man ist z. B: FingerabdrĂĽcke, Gesichtserkennung oder Verhaltensweisen

Authentication: Prozess um von jemandem die Identität zu bestätigen Authorization: Welche Art von Rechte hat der User

Wie entstehen vulnerabilities beim authentifizieren¶

  • Zu Schwache Mechanismen und nicht gegen Brute-Force gesichert
  • Schlechte Implementierung sodass der Hacker das einfach bypassen kann (Broken Authentication)

Brute-Force¶

Verschiedene Passwort/Username Kombinationen durch Trial und Error mit einem Algorithmus durchlaufen lassen.

gezielteres Brute-Force¶

Bei einem gezielterem Brute-Force werden gewisse Passwortlisten genommen oder wahrscheinlichere Kombinationen verwendet.

Außerdem muss man auf diverse Dinge achten die ggf. Auskunft über zB: korrekte Usernamen geben durch: - Status Code: Während einer Brute-Force attacke ist es wichtig immer die selbe Fehlermeldung zu liefern also ob Username nun richtig oder falsch ist sonst kann ein unterschiedlicher Status-Code Auskunft darüber liefern ob der Username in der Datenbank auftaucht oder nicht. - Error messages: Manchmal könnten auch Error Messages unterschiedliche Ausgaben liefern zB: "Username ist falsch" oder "Username und Passwort sind falsch" oder "Passwort ist falsch" - Response Time: Je nachdem ob ein Username korrekt ist braucht das System länger weil es nach dem zugehörigen Passwort sucht was eine längere response-time bedeuten könnte wodurch sich auch erahnen lässt ob ein Username richtig oder falsch ist

🖥️🧪Lab: Username enumeration via different responses¶

  1. Suche nach POST /login request.username_enumeration_burp1.png
  2. An Intruder senden, Passwortliste einfĂĽgen und start Attackusername_enumeration_burp2.png
  3. Length unterschiedlich -> Username vermutlich korrektusername_enumeration_burp3.png
  4. Dann das gleiche mit Passwort und dem gefundenen Usernamen wiederholen. -> Statuscode 302username_enumeration_burp4.png

🖥️🧪Lab: Username enumeration via subtly different responses¶

Ziel:
Analyse der Login-Funktion, um Unterschiede bei falschen und korrekten Eingaben zu erkennen und anschlieĂźend einen erfolgreichen Brute-Force Angriff durchzufĂĽhren.

Vorgehen:

  1. Erste Tests im Intruder:

    • Alle Responses hatten Status Code 200.
    • Die Response Length war zwar unterschiedlich, der Unterschied entstand jedoch nur durch ein eingebundenes Analytics-Script → kein valider Indikator.

  2. Vergleich der Fehlermeldungen:

    • Verschiedene Keywords getestet (Grep Match).
    • Mit komplett falschen Usernamen (asd7127371231b2n178z) Response im Repeater ĂĽberprĂĽft.
    • Unterschied entdeckt:
      • UngĂĽltiger Username → Fehlermeldung: “Invalid username and password.”
      • GĂĽltiger Username, falsches Passwort → Fehlermeldung fast gleich, aber ohne Punkt am Ende.
    • Damit konnte ein valider Benutzername identifiziert werden.

  3. Brute Force Passwort-Test:

    • Den ermittelten gĂĽltigen Benutzernamen mit einer Passwortliste im Intruder getestet.
    • Nach Auswertung der Responses → Login erfolgreich → Zugang erhalten.

Ergebnis:
Die Login-Funktion ist anfällig für Username Enumeration (durch subtile Unterschiede in den Fehlermeldungen) und erlaubt anschließend einen erfolgreichen Brute-Force Angriff auf das Passwort.

🖥️🧪 LAB: Authentication – Username Enumeration & IP-Blocker Bypass¶

Ziel:
Analyse der Login-Funktion hinsichtlich Brute-Force-Absicherung, Username Enumeration und möglichen Bypass-Mechanismen.

  1. Erste Beobachtungen

    • Bei einem korrekten Benutzernamen und einem absichtlich langen Passwort dauert die Antwort des Servers signifikant länger.
    • Bei einem falschen Benutzernamen erfolgt die Antwort dagegen sehr schnell.
      → Dadurch lässt sich eine Username Enumeration über Response Time durchführen.

  2. IP-Blocker

    • Nach ca. 3 fehlgeschlagenen Login-Versuchen wurde die Client-IP blockiert.
    • Durch Tests festgestellt: Ein einfacher X-Forwarded-For-Header reicht aus, um die Sperre zu umgehen.
    • Das System vertraut offenbar den ĂĽbergebenen Headern und wertet diese fĂĽr die IP-Erkennung aus.

  3. Vorgehen mit Burp Intruder

    1. Payload Setup:

      • Benutzername: Liste mit potentiellen Usernamen.
      • Passwort: Konstant ein langes Passwort, um Response Time-Unterschiede deutlicher zu machen.
      • X-Forwarded-For: Als zweiter Payload-Parameter → IP-Adresse dynamisch hochzählen (z. B. 1.1.1.§1§).

    2. Angriff:

      • Intruder-Attacke gestartet mit 2 Positionen:

        • Benutzername → arbeitet die Liste durch.
        • X-Forwarded-For → erhöht bei jedem Versuch die letzte IP-Ziffer.

      • Ergebnis:

        • Der korrekte Benutzername konnte eindeutig identifiziert werden, da die Response Time deutlich höher war als bei allen anderen Requests.

  4. Passwort Brute Force:

    • Danach denselben Ansatz mit dem bekannten, validen Benutzernamen.
    • Passwortliste abgearbeitet, X-Forwarded-For weiter rotiert, um Sperre zu umgehen.
    • Ergebnis: Login erfolgreich.

  5. Ergebnis

    • Die Anwendung ist anfällig fĂĽr:
      1. Username Enumeration via Response Time.
      2. Brute Force trotz IP-Blocker, da X-Forwarded-For manipuliert werden kann.

Ziel:
Analyse der Login-Schutzmechanismen, insbesondere der IP-Blockierung bei fehlerhaften Versuchen und deren mögliche Umgehung.

Lab: Broken brute-force protection, IP block¶

  1. Erste Beobachtungen

    • Die Login-Funktion blockiert eine IP-Adresse nach 3 fehlgeschlagenen Versuchen.
    • Anders als in der Variante mit X-Forwarded-For konnten wir diesmal feststellen:
      Ein erfolgreicher Login (z. B. mit einem bekannten gĂĽltigen Account) setzt die IP-Blockliste zurĂĽck.
    • Damit ist es möglich, den Brute-Force-Schutz durch periodische „Reset-Logins“ auszuhebeln.

  2. Vorgehen

    1. Analyse mit Burp Repeater:

      • Mehrfach falsche Passwörter gesendet → Blockierung nach 3 Versuchen bestätigt.
      • Danach mit gĂĽltigem Account („wiener:peter“) eingeloggt → Blockierung sofort aufgehoben.

    2. Strategie fĂĽr Brute Force:

      • Wir haben eine Passwortliste fĂĽr den Zieluser „carlos“ vorbereitet.
      • In regelmäßigen Abständen nach jeweils 3 Versuchen wurde ein zusätzlicher Login mit „wiener:peter“ eingestreut, um die Blockierung zurĂĽckzusetzen.
      • Dadurch konnten die Brute-Force-Versuche ohne Unterbrechung fortgesetzt werden.

    3. Umsetzung:

      • Zwei Payload-Sets im Intruder:
        • Benutzername: Hauptsächlich „carlos“, alle 3 Versuche ergänzt durch „wiener“.
        • Passwort: Aus Passwortliste, alle 3 Versuche ergänzt durch „peter“.
      • Ergebnis: Der IP-Blocker griff nicht mehr, da jede Blockade durch den gĂĽltigen Login sofort zurĂĽckgesetzt wurde.
      • Der korrekte Benutzername und anschlieĂźend das Passwort konnten so gefunden werden.

  3. Ergebnis

    • Die Anwendung ist anfällig fĂĽr Brute Force trotz IP-Blocker, weil ein erfolgreicher Login die Blockliste sofort löscht.
    • Der Schutzmechanismus ist dadurch wirkungslos, sobald Angreifer Zugang zu irgendeinem gĂĽltigen Account haben.

Account Locking¶

Grundidee:
Webseiten sperren Accounts nach einer bestimmten Anzahl fehlgeschlagener Login-Versuche, um Brute-Force-Angriffe zu erschweren.

Vorteile - SchĂĽtzt bedingt vor Brute-Force-Angriffen auf ein bestimmtes Konto, da dieses nach wenigen Fehlversuchen gesperrt wird.

Schwächen / Umgehungsmöglichkeiten 1. Username Enumeration - Wenn der Server bei gesperrten Accounts andere Fehlermeldungen zurückgibt, können Angreifer dadurch gültige Usernamen erkennen.

  1. Brute Force gegen viele Accounts

    • Schutz greift nur bei Angriffen auf ein einzelnes Konto.
    • Angreifer können mehrere Accounts parallel angreifen, solange sie das Limit pro Account nicht ĂĽberschreiten.
    • Beispiel:
      • Max. 3 Versuche erlaubt → Angreifer probiert pro User 3 Standard-Passwörter.
      • Es reicht, wenn ein User tatsächlich eines dieser Passwörter nutzt → Account kompromittiert.

  2. Credential Stuffing

    • Bei Credential Stuffing werden echte, gestohlene Zugangsdaten (aus Leaks) massenhaft ausprobiert.
    • Da pro Account nur ein Login-Versuch nötig ist, greift Account Locking hier nicht.
    • Besonders gefährlich, weil viele Nutzer ihre Passwörter auf mehreren Webseiten wiederverwenden → Angreifer können so gleich mehrere Accounts ĂĽbernehmen.

User Rate Limiting¶

Ansatz:
Eine weitere Möglichkeit, Brute-Force-Angriffe zu verhindern, ist Rate Limiting pro Benutzer/IP. - Wenn zu viele Login-Versuche in kurzer Zeit von derselben IP ausgehen, wird diese IP blockiert. - Die Entsperrung kann erfolgen: - automatisch nach einer bestimmten Zeit, - manuell durch einen Administrator, - manuell durch den Benutzer (z. B. per CAPTCHA).

Vorteil gegenüber Account Locking: - Weniger anfällig für Username Enumeration und DoS-Angriffe.

Schwächen: - Angreifer können ihre scheinbare IP manipulieren (z. B. per Proxy oder Header-Manipulation), um die Sperre zu umgehen. - In manchen Fällen lässt sich die Sperre auch aushebeln, indem mehrere Passwortversuche in einer einzigen HTTP-Anfrage kombiniert werden.

Schwachstellen bei Multi-Faktor-Authentifizierung (MFA)¶

Viele Websites nutzen noch reine Single-Factor Authentifizierung (Passwort). Immer häufiger wird aber Zwei-Faktor-Authentifizierung (2FA) eingesetzt, bei der Nutzer etwas wissen (Passwort) und etwas besitzen (z. B. Code vom Gerät).

Vorteile von 2FA¶

  • Angreifer können evtl. ein Passwort stehlen.
  • Gleichzeitig an den zweiten Faktor zu kommen, ist deutlich schwerer.
  • Darum ist 2FA grundsätzlich sicherer als reines Passwort-Login.

Probleme & Schwachstellen¶

  1. Schlechte Implementierung

    • 2FA ist nur so sicher wie die Umsetzung.
    • Fehler können dazu fĂĽhren, dass man 2FA umgehen oder ganz ĂĽberspringen kann.

  2. Gleicher Faktor doppelt geprĂĽft

    • E-Mail-basierte 2FA gilt nicht als echte Zwei-Faktor-Authentifizierung.
    • Der Nutzer gibt Passwort ein und erhält Code per Mail → beide hängen vom Wissen des E-Mail-Passworts ab.
    • Ergebnis: Es wird nicht wirklich ein zweiter Faktor geprĂĽft.

  3. Token-Methoden

    • Sicherer: Dedizierte Geräte (RSA-Token, Keypads) oder Apps wie Google Authenticator → Code wird lokal auf dem Gerät generiert.
    • Unsicherer: SMS-Codes → können abgefangen werden (z. B. durch Angriffe auf das Mobilfunknetz).
      • Risiko: SIM-Swapping → Angreifer ĂĽbernimmt Rufnummer, erhält alle SMS inklusive 2FA-Codes.

  4. Bypass-Szenarien

    • Manche Websites setzen 2FA technisch falsch um:
      • Zuerst Passwort-Eingabe, danach Code-Eingabe auf separater Seite.
      • Nach Passwort-Eingabe gilt der Nutzer bereits als „eingeloggt“.
      • Angreifer kann direkt auf geschĂĽtzte Seiten zugreifen, ohne jemals den Code einzugeben.

Lab: 2FA simple bypass¶

Oft wird eine 2FA abgefragt, aber letztlich gar nicht gegengecheckt. D. h wenn man sich einloggt mit dem Passwort kann es sein, dass ein einfaches droppen vom 2. Login den Zugang ermöglicht. So wie in der Lab Aufgabe

Lab: 2FA broken logic¶

Nachträglicher Bericht.

Man muss aufpassen, dass man nicht den 2FA brute-forcen kann. -> User ausloggen bei zu vielen fehlschlägen mit 2FA -> in der praxis aber oft sinnlos weil ein advancter Hacker auch diesen Prozess automatisieren kann mit Burp Makros