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

Authorization Issue

Daar moet probeer word om die e-pos van ’n rekening te verander, en die bevestigingsproses moet ondersoek word. As dit as swak bevind word, moet die e-pos na daardie van die beoogde slagoffer verander en dan bevestig word.

Unicode Normalization Issue

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

Soos verduidelik in this talk, die vorige aanval kan ook gedoen word deur derdeparty identiteitsverskaffers te misbruik:

  • Skep ’n rekening by die derdeparty-identiteitsverskaffer met ’n soortgelyke e-pos as die slagoffer deur ’n Unicode-karakter te gebruik (vićtim@company.com).
  • Die derdepartyverskaffer moet nie die e-pos verifieer nie.
  • As die identiteitsverskaffer die e-pos wel verifieer, kan jy dalk die domeindeel aanval, bv.: victim@ćompany.com en die domein registreer en hoop dat die identiteitsverskaffer die ASCII-weergawe van die domein genereer terwyl die slagofferplatform die domeinnaam normaliseer.
  • Meld aan via hierdie identiteitsverskaffer op die slagofferplatform wat die Unicode-karakter behoort te normaliseer en jou toegang tot die slagofferrekening sal gee.

Vir verdere besonderhede, verwys na die dokument oor Unicode Normalization:

Unicode Normalization

Reusing Reset Token

As die teikenstelsel toelaat dat die reset link hergebruik word, moet pogings aangewend word om meer reset links te vind met behulp van gereedskap soos gau, wayback, of scan.io.

Pre Account Takeover

  1. Die slagoffer se e-pos moet gebruik word om by die platform aan te meld, en ’n wagwoord moet ingestel word (daar moet gepoog word om dit te bevestig, alhoewel gebrek aan toegang tot die slagoffer se e-posse dit onmoontlik kan maak).
  2. Wag totdat die slagoffer via OAuth registreer en die rekening bevestig.
  3. Dit word gehoop dat die normale registrasie bevestig sal word, wat toegang tot die slagoffer se rekening sal gee.

CORS Misconfiguration to Account Takeover

As die bladsy CORS misconfigurations bevat, mag jy in staat wees om gevoelige inligting van die gebruiker te steel om sy rekening oor te neem of hom te laat verander van auth-inligting vir dieselfde doel:

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

As die bladsy kwesbaar is vir CSRF kan jy die gebruiker laat sy wagwoord, e-pos of verifikasie wysig 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 in staat wees om cookies, local storage, of inligting van die webblad te steel wat jou in staat kan stel om die rekening oor te neem:

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

As jy ’n beperkte XSS of ’n subdomain takeover vind, kan jy met die cookies speel (byvoorbeeld deur dit te fixateer) om die slagofferrekening te kompromitteer:

Cookies Hacking

Attacking Password Reset Mechanism

Reset/Forgotten Password Bypass

Security-question resets that trust client-supplied usernames

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

  1. Meld aan met ’n weggooigebruiker en vang die sessiecookie op.
  2. Stuur die slagoffer se gebruikersnaam plus nuwe antwoorde via die reset-formulier in.
  3. Verifieer onmiddellik via die veiligheidsvraag-aanmeld-endpoint met die antwoorde wat jy 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 beveilig is (admin dashboards, dangerous stream-wrapper features, ens.) is nou blootgestel sonder om die werklike antwoorde aan te raak.

Gelysde gebruikersname kan dan geteiken word via die overwrite technique hierbo of hergebruik word teen bykomstige dienste (FTP/SSH password spraying).

Response Manipulation

As die authentiseringsrespons gereduseer kan word tot ’n eenvoudige boolean, probeer net 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 ná die inisiasie van ’n password reset request.
  2. Die X-Forwarded-For proxy header word verander na attacker.com.
  3. Die Host, Referrer, en Origin headers word terselfdertyd verander na attacker.com.
  4. Na die inisiasie van ’n password reset en dan die keuse om die e-pos weer te stuur, word al drie die bogenoemde metodes gebruik.

Response Manipulation

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

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

Change email of current session

Van this report:

  • Aanvaller versoek om sy e-pos na ’n nuwe een te verander
  • Aanvaller ontvang ’n skakel om die e-posverandering te bevestig
  • Aanvaller stuur die skakel aan die slagoffer sodat hy daarop klik
  • Die slagoffer se e-pos word verander na die een wat deur die aanvaller aangedui is
  • Die aanval kan die wagwoord herstel en die rekening oorneem

This also happened in this report.

Bypass email verification for Account Takeover

  • Aanvaller meld aan met attacker@test.com en verifieer die e-pos tydens inskrywing.
  • Aanvaller verander die geverifieerde e-pos na victim@test.com (geen sekondêre verifikasie by e-posverandering nie)
  • Nou laat die webwerf victim@test.com toe om aan te meld en ons het die e-posverifikasie van die slagoffer omseil.

Old Cookies

Soos verduidelik in this post, was dit moontlik om in te teken op ’n rekening, die cookies as ’n geverifieerde gebruiker te stoor, uit te teken, en dan weer in te teken.
Met die nuwe aanmelding, alhoewel verskillende cookies moontlik gegenereer is, het die oues weer begin werk.

Trusted device cookies + batch API leakage

Langlewendige device-identifiseerders wat recovery beheer, kan gesteel word wanneer ’n batch API jou toelaat om onleesbare subresponses na skryfbare sinks te kopieer.

  • Identify a trusted-device cookie (SameSite=None, long-lived) used to relax recovery checks.
  • Find a first-party endpoint that returns that device ID in JSON (e.g., an OAuth code exchange returning machine_id) but is not readable cross-origin.
  • Use a batch/chained API that allows referencing earlier subresponses ({result=name:$.path}) and writing them to an attacker-visible sink (page post, upload-by-URL, etc.). Example with Facebook Graph API:
POST https://graph.facebook.com/
batch=[
{"method":"post","omit_response_on_success":0,"relative_url":"/oauth/access_token?client_id=APP_ID%26redirect_uri=REDIRECT_URI","body":"code=SINGLE_USE_CODE","name":"leaker"},
{"method":"post","relative_url":"PAGE_ID/posts","body":"message={result=leaker:$.machine_id}"}
]
access_token=PAGE_ACCESS_TOKEN&method=post
  • Laai die batch-URL in ’n versteekte <iframe> sodat die slagoffer die trusted-device cookie stuur; die JSON-path verwysing kopieer die machine_id na die attacker-controlled post, selfs al is die OAuth-respons onleesbaar vir die bladsy.
  • Replay: stel die gesteelde device cookie in ’n nuwe sessie. Recovery beskou die browser nou as trusted, en openbaar dikwels swakker “no email/phone” flows (bv. geoutomatiseerde dokumentoplaai) om ’n attacker email by te voeg sonder die wagwoord of 2FA.

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