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-Adresse eines Accounts zu ändern, und der Bestätigungsprozess muss geprüft werden. Wenn dieser als schwach eingestuft wird, sollte die E-Mail auf die des beabsichtigten Opfers geändert und anschließend bestätigt werden.

Unicode-Normalisierungsproblem

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

As explained in this talk, the previous attack could also be done abusing third party identity providers:

  • Erstelle ein Konto beim Drittanbieter-Identity-Provider mit einer dem Opfer ähnlichen E-Mail, indem du ein Unicode-Zeichen verwendest (vićtim@company.com).
  • Der Drittanbieter sollte die E-Mail nicht verifizieren.
  • Wenn der Identity Provider die E-Mail verifiziert, kannst du möglicherweise den Domain-Teil angreifen, z. B.: victim@ćompany.com, diese Domain registrieren und darauf hoffen, dass der Identity Provider die ASCII-Version der Domain erzeugt, während die Zielplattform den Domainnamen normalisiert.
  • Melde dich über diesen Identity Provider in der Zielplattform an, die das Unicode-Zeichen normalisieren sollte und dir Zugriff auf das Opferkonto gewährt.

Für weitere Details siehe das Dokument zur Unicode-Normalisierung:

Unicode Normalization

Reset-Token wiederverwenden

Erlaubt das Zielsystem das erneute Verwenden des Reset-Links, sollten Anstrengungen unternommen 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 zur Registrierung auf der Plattform verwendet werden, und ein Passwort sollte gesetzt werden (es sollte versucht werden, dieses zu bestätigen, auch wenn fehlender Zugriff auf die E-Mails des Opfers das unmöglich machen kann).
  2. Man sollte warten, bis das Opfer sich via OAuth anmeldet und das Konto bestätigt.
  3. Hoffentlich wird die reguläre Registrierung bestätigt, sodass Zugriff auf das Opferkonto möglich ist.

CORS-Fehlkonfiguration für Account Takeover

Wenn die Seite CORS-Fehlkonfigurationen aufweist, 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 dasselbe zu erreichen:

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

Wenn die Seite für CSRF verwundbar ist, könntest du den Nutzer dazu bringen, sein Passwort, seine E-Mail oder die 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, local storage oder Informationen von der Webseite stehlen, die dir ermöglichen könnten, das Konto zu übernehmen:

XSS (Cross Site Scripting)

  • Attribute-only reflected payloads on login pages can hook document.onkeypress, exfiltrate keystrokes through new Image().src, and steal credentials without submitting the form. See Attribute-only login XSS behind WAFs for a practical workflow.

Same Origin + Cookies

Wenn du eine eingeschränkte XSS oder eine Subdomain-Übernahme findest, kannst du mit Cookies spielen (zum Beispiel durch Fixation), um zu versuchen, das Opferkonto zu kompromittieren:

Cookies Hacking

Angriff auf den Password-Reset-Mechanismus

Reset/Forgotten Password Bypass

Zurücksetzen von 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 beliebiger Konten (inklusive Admins) überschreiben, da das Backend typischerweise UPDATE ... WHERE user_name = ? mit deinem nicht vertrauenswürdigen Wert ausführt. Das Vorgehen ist:

  1. Melde dich mit einem Wegwerfbenutzer an und fange das Session-Cookie ab.
  2. Sende den Benutzernamen des Opfers plus neue Antworten über das Reset-Formular.
  3. Authentifiziere dich sofort über den Login-Endpunkt für Sicherheitsfragen mit den eben injizierten Antworten, um die Rechte 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, dangerous stream-wrapper features, etc.) is now exposed without touching the real answers.

Enumerated usernames can then be targeted via the overwrite technique above or reused against ancillary services (FTP/SSH password spraying).

Response Manipulation

If the authentication response could be reduced to a simple boolean just try to change false to true and see if you get any access.

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. Der Host-Header wird nach dem Einleiten einer password reset-Anfrage verändert.
  2. Der X-Forwarded-For Proxy-Header wird auf attacker.com geändert.
  3. Die Host-, Referrer- und Origin-Header werden gleichzeitig auf attacker.com geändert.
  4. Nach dem Einleiten einer password reset-Anfrage und dem erneuten Versenden der Mail werden alle drei der 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 zu {"success":true} oder zu einem leeren Objekt {} geändert.

These manipulation techniques are effective in scenarios where JSON is utilized for data transmission and receipt.

Change email of current session

From this report:

  • Attacker requests to change his email with a new one
  • Attacker receives a link to confirm the change of the email
  • Attacker send the victim the link so he clicks it
  • The victims email is changed to the one indicated by the attacker
  • The attack can recover the password and take over the account

This also happened in this report.

Bypass email verification for Account Takeover

  • Attacker logins with attacker@test.com and verifies email upon signup.
  • Attacker changes verified email to victim@test.com (no secondary verification on email change)
  • Now the website allows victim@test.com to login and we have bypassed email verification of victim user.

Old Cookies

As explained in this post, it was possible to login into an account, save the cookies as an authenticated user, logout, and then login again.
Mit dem neuen Login, obwohl möglicherweise andere Cookies generiert wurden, funktionierten die alten 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