Account Takeover

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Autorisierungsproblem

Es sollte versucht werden, die E-Mail eines Accounts zu ändern, und der Bestätigungsprozess muss untersucht werden. Wenn er als schwach befunden wird, sollte die E-Mail auf die des vorgesehenen Opfers geändert und dann bestätigt werden.

Unicode-Normalisierungsproblem

  1. Das Konto des vorgesehenen Opfers victim@gmail.com
  2. Es sollte ein Konto mit Unicode erstellt werden
    zum Beispiel: vićtim@gmail.com

Wie in diesem Talk erklärt, könnte der vorherige Angriff auch durch Missbrauch von Third-Party-Identity-Providern durchgeführt werden:

  • Erstelle ein Konto beim Third-Party-Identity-Provider mit einer dem Opfer ähnlichen E-Mail unter Verwendung eines Unicode-Zeichens (vićtim@company.com).
  • Der Third-Party-Provider sollte die E-Mail nicht verifizieren.
  • Wenn der Identity-Provider die E-Mail verifiziert, kannst du vielleicht den Domain-Teil angreifen, z. B. victim@ćompany.com, diese Domain registrieren und darauf hoffen, dass der Identity-Provider die ASCII-Version der Domain generiert, während die Zielplattform den Domainnamen normalisiert.
  • Logge dich über diesen Identity-Provider bei der Zielplattform ein, die das Unicode-Zeichen normalisieren sollte und dir Zugang zum Konto des Opfers ermöglicht.

Für weitere Details siehe das Dokument zu Unicode Normalization:

Unicode Normalization

Wiederverwendung von Reset-Token

Wenn das Zielsystem den Reset-Link zur Wiederverwendung zulässt, sollte versucht werden, weitere Reset-Links zu finden, z. B. mit Tools wie gau, wayback oder scan.io.

Pre Account Takeover

  1. Die E-Mail des Opfers sollte verwendet werden, um sich auf der Plattform zu registrieren, und ein Passwort sollte gesetzt werden (es sollte versucht werden, es zu bestätigen, auch wenn der fehlende Zugang zu den E-Mails des Opfers das unmöglich machen kann).
  2. Man sollte warten, bis das Opfer sich via OAuth anmeldet und den Account bestätigt.
  3. Hoffentlich wird die reguläre Registrierung bestätigt, wodurch Zugriff auf das Konto des Opfers möglich wird.

CORS-Misconfiguration zum Account Takeover

Wenn die Seite CORS-Fehlkonfigurationen enthält, könntest du in der Lage sein, sensible Informationen vom Nutzer zu stehlen, um sein Konto zu übernehmen oder ihn dazu zu bringen, Auth-Informationen zu ändern, um denselben Zweck zu erreichen:

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

Wenn die Seite für CSRF verwundbar ist, könntest du den Benutzer dazu bringen, sein Passwort, seine E-Mail oder seine Authentifizierung zu ändern, sodass du anschließend darauf zugreifen kannst:

CSRF (Cross Site Request Forgery)

XSS to Account Takeover

Wenn du eine XSS in der Anwendung findest, könntest du Cookies, localStorage oder Informationen von der Webseite stehlen, die es dir ermöglichen könnten, das Konto zu übernehmen:

XSS (Cross Site Scripting)

Same Origin + Cookies

Wenn du eine eingeschränkte XSS oder eine Subdomain-Übernahme findest, könntest du mit den Cookies spielen (z. B. Fixierung), um zu versuchen, das Konto des Opfers zu kompromittieren:

Cookies Hacking

Attacking Password Reset Mechanism

Reset/Forgotten Password Bypass

Zurücksetzen per Sicherheitsfragen, die client-seitig gelieferte Benutzernamen vertrauen

Wenn ein “update security questions”-Flow einen username-Parameter annimmt, obwohl der Aufrufer bereits authentifiziert ist, kannst du die Recovery-Daten jedes Accounts (einschließlich Admins) überschreiben, weil das Backend typischerweise UPDATE ... WHERE user_name = ? mit deinem nicht vertrauenswürdigen Wert ausführt. Das Vorgehen ist:

  1. Melde dich mit einem Wegwerf-User an und capture das Session-Cookie.
  2. Sende den Benutzernamen des Opfers plus neue Antworten über das Reset-Formular.
  3. Authentifiziere dich sofort über den Security-Question-Login-Endpunkt mit den Antworten, die du gerade injiziert hast, um die Privilegien des Opfers zu übernehmen.
POST /reset.php HTTP/1.1
Host: file.era.htb
Cookie: PHPSESSID=<low-priv>
Content-Type: application/x-www-form-urlencoded

username=admin_ef01cab31aa&new_answer1=A&new_answer2=B&new_answer3=C

Anything gated by the victim’s $_SESSION context (Admin-Dashboards, gefährliche stream-wrapper-Funktionen, etc.) ist nun zugänglich, ohne die echten Antworten zu verändern.

Aufgelistete Benutzernamen können dann über die oben erwähnte overwrite technique angegriffen oder gegen Nebendienste (FTP/SSH password spraying) wiederverwendet werden.

Response Manipulation

Wenn die Authentifizierungsantwort auf ein einfaches boolean reduziert werden kann, versuche einfach, false in true zu ändern und zu sehen, ob du Zugriff erhältst.

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. Der Host-Header wird nach dem Einleiten einer Passwort-Zurücksetzen-Anfrage modifiziert.
  2. Der X-Forwarded-For Proxy-Header wird auf attacker.com gesetzt.
  3. Die Host-, Referrer- und Origin-Header werden gleichzeitig auf attacker.com geändert.
  4. Nach Einleitung eines Passwort-Zurücksetzens und anschließendem Erneut-Versenden der Mail werden alle drei der oben genannten Methoden angewendet.

Response Manipulation

  1. Code Manipulation: Der Statuscode wird auf 200 OK geändert.
  2. Code and Body Manipulation:
  • Der Statuscode wird auf 200 OK geändert.
  • Der Response-Body wird auf {"success":true} oder ein leeres Objekt {} geändert.

Diese Manipulationstechniken sind wirksam in Szenarien, in denen JSON für die Datenübertragung und -empfang verwendet wird.

Email der aktuellen Session ändern

From this report:

  • Der Angreifer fordert an, seine E-Mail auf eine neue zu ändern
  • Der Angreifer erhält einen Link zur Bestätigung der E-Mail-Änderung
  • Der Angreifer schickt dem Opfer den Link, sodass dieses darauf klickt
  • Die E-Mail des Opfers wird auf die vom Angreifer angegebene E-Mail geändert
  • Der Angreifer kann das Passwort wiederherstellen und das Konto übernehmen

Dies geschah auch in this report.

Bypass email verification for Account Takeover

  • Der Angreifer loggt sich mit attacker@test.com ein und verifiziert die E-Mail bei der Registrierung.
  • Der Angreifer ändert die verifizierte E-Mail zu victim@test.com (keine sekundäre Verifizierung bei E-Mail-Änderung)
  • Nun erlaubt die Webseite victim@test.com sich einzuloggen und wir haben die E-Mail-Verifizierung des Opfer-Users umgangen.

Old Cookies

Wie in diesem Beitrag erklärt, war es möglich, sich in ein Konto einzuloggen, die Cookies als authentifizierter Benutzer zu speichern, sich auszuloggen und dann erneut einzuloggen.
Bei dem neuen Login wurden zwar möglicherweise andere Cookies generiert, aber die alten funktionierten wieder.

References

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks