Account Takeover

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Outorisasie kwessie

Die e-pos van ’n rekening moet probeer verander word, en die bevestigingsproses moet ondersoek word. As dit swak bevind word, moet die e-pos verander word na dié van die beoogde slagoffer en dan bevestig word.

Unicode Normaliseringskwessie

  1. Die rekening van die beoogde slagoffer victim@gmail.com
  2. ’n Rekening moet geskep word met behulp van Unicode
    byvoorbeeld: vićtim@gmail.com

Soos verduidelik in this talk, kan die vorige aanval ook uitgevoer word deur derdeparty identity providers te misbruik:

  • Skep ’n rekening by die derdeparty identity provider met ’n e-pos soortgelyk aan die slagoffer deur ’n Unicode-karakter te gebruik (vićtim@company.com).
  • Die derdeparty-provider behoort nie die e-pos te verifieer nie
  • As die identity provider die e-pos verifieer, kan jy dalk die domein-gedeelte aanval soos: victim@ćompany.com en daardie domein registreer en hoop dat die identity provider die ascii-weergawe van die domein genereer terwyl die slagoffer-platform die domeinnaam normaliseer.
  • Meld aan via hierdie identity provider by die slagoffer-platform wat die Unicode-karakter behoort te normaliseer en jou toegang tot die slagoffer se rekening toelaat.

Vir verdere besonderhede, raadpleeg die dokument oor Unicode-normalisering:

Unicode Normalization

Herverbruik van Reset Token

As die teikenstelsel toelaat dat die reset link opnieuw gebruik kan word, behoort pogings aangewend te word om meer reset links te vind met gereedskap soos gau, wayback, of scan.io.

Pre Account Takeover

  1. Die slagoffer se e-pos moet gebruik word om op die platform aan te meld, en ’n wagwoord moet gestel word (daar behoort ’n poging aangewend te word om dit te bevestig, alhoewel die gebrek aan toegang tot die slagoffer se e-posse dit moontlik onmoontlik maak).
  2. Wag totdat die slagoffer via OAuth registreer en die rekening bevestig.
  3. Daar word gehoop dat die gewone registrasie bevestig sal word, wat toegang tot die slagoffer se rekening sal gee.

CORS-misconfigurasie na Account Takeover

As die bladsy CORS-miskonfigurasies bevat, kan jy dalk sensitiewe inligting van die gebruiker steel om sy rekening te oor te neem of hom te laat verander van auth-inligting met dieselfde doel:

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

As die bladsy kwesbaar is vir CSRF, kan jy dalk die gebruiker sy wagwoord wysig, e-pos of authentisering sodat jy daarna toegang kan kry:

CSRF (Cross Site Request Forgery)

XSS to Account Takeover

As jy ’n XSS in die toepassing vind, kan jy dalk cookies, local storage, of inligting van die webblad steel wat jou in staat kan stel om die rekening oor te neem:

XSS (Cross Site Scripting)

Same Origin + Cookies

As jy ’n beperkte XSS of ’n subdomain takeover vind, kan jy met die cookies speel (byvoorbeeld deur dit te fixate) om te probeer om die slagoffer se rekening te kompromitteer:

Cookies Hacking

Aanval op die wagwoordherstel-meganisme

Reset/Forgotten Password Bypass

Sekuriteitsvraag-herstellings wat op kliënt-gelewerde gebruikersname vertrou

As ’n “update security questions” vloei ’n username parameter aanvaar alhoewel die aanroeper reeds geverifieer is, kan jy enige rekening se hersteldata oorskryf (insluitend admins) omdat die backend gewoonlik UPDATE ... WHERE user_name = ? met jou onbetroubare waarde uitvoer. Die patroon is:

  1. Meld aan met ’n weggooigebruiker en vang die sessie-cookie op.
  2. Dien die slagoffer se gebruikersnaam en nuwe antwoorde in via die reset-formulier.
  3. Verifieer onmiddellik deur die security-question login-endpoint met die antwoorde wat jy so pas ingespuit het om die slagoffer se voorregte te erf.
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

Alles wat deur die slagoffer se $_SESSION-konteks (admin dashboards, gevaarlike stream-wrapper-funksies, ens.) geblokkeer is, is nou blootgestel sonder om die werklike antwoorde aan te raak.

Geënumeerde gebruikersname kan dan geteiken word via die overwrite-tegniek hierbo of hergebruik word teen bykomstige dienste (FTP/SSH password spraying).

Response Manipulation

As die authentication response tot ’n eenvoudige boolean gereduseer kan word, probeer om false na true te verander en kyk of jy toegang kry.

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. Die Host header word gewysig nadat ’n password reset request geïnisieer is.
  2. Die X-Forwarded-For proxy-header word verander na attacker.com.
  3. Die Host, Referrer, en Origin headers word gelyktydig na attacker.com verander.
  4. Nadat ’n password reset geïnisieer is en gekies is om die e-pos weer te stuur, word al drie van die bogenoemde metodes gebruik.

Response Manipulation

  1. Code Manipulation: Die statuskode word na 200 OK verander.
  2. Code and Body Manipulation:
  • Die statuskode word na 200 OK verander.
  • Die response body word gewysig na {"success":true} of ’n leë objek {}.

Hierdie manipulasie-tegnieke is doeltreffend in scenario’s waar JSON gebruik word vir data-oordrag en -ontvangs.

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.
With the new login, although different cookies might be generated the old ones became to work again.

References

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks