「Multiple Organization Full account Take-over via privilege escalation」からIDORを学ぶ

ソース:

medium.com

脆弱性:IDOR

 

訳:

組織の Web アプリケーションに重大度の高いセキュリティ上の欠陥があるため、攻撃者は、採用担当者、管理者、さらには CEO/CTO などの高い特権を持つユーザーを含むユーザー アカウントを乗っ取ることができ。
この欠陥により、ユーザーの機密データが漏洩し、機密情報への不正アクセスが許可され、重大なビジネス上および技術上のリスクが引き起こされ。
この脆弱性は、Web アプリケーションの不適切なアクセス制御メカニズムと不適切な入力検証によって発生し。
攻撃者はこの欠陥を悪用して、未承認のエンドポイントに移動し、制限されたリソースにアクセスし、ユーザーの役割を操作して、同じ組織および別の組織ユーザーの高い特権を持つアカウントを乗っ取り。

 

重大度 :

CVSS スコア: 8.9

CVSS マトリックス: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

影響を受けるリソース

影響を受ける URL:

· https://redeacted.herokuapp.com/employer/637f69c02527bb#######

· https://redeacted herokuapp.com/recruiters

· https://redeacted.herokuapp.com/employer/search

· https://redeacted.herokuapp.com/employerRep/search

 

影響を受けるパラメータ:

· 雇用主ID

ビジネス リスク: この脆弱性に関連するビジネスリスクは重大

· ユーザー プロフィール、雇用詳細、財務記録などの機密データの損失

· データ違反による潜在的な法的および規制上の影響

· ユーザーの信頼やブランド価値の喪失につながる風評被害

· 訴訟費用、罰金、業務中断による経済的損失

技術的リスク: 技術的リスクには次のものが含まれ

· データ侵害や改ざんにつながる不正アクセス

· ユーザーの役割と権限の不正な変更

· 重要なシステム コンポーネントと管理機能の公開

· 事業運営やサービスに支障をきたす可能性があり

 

再現手順

1) 候補者の詳細を使用してログインし、Web アプリケーションにアクセスし。

 

図:1

 

2)  URL から一意の英数字のユーザー ID を特定します。

 

図:2

 

3) 次に、上記のページを更新し、BurpSuiteで以下のリクエストをインターセプトし、そのリクエストをBurpSuiteのリピータータブに送信し。

 

図:3

 

4) 権限のないユーザー ID を使用して /employer エンドポイントにアクセスしようとすると、404 エラーが発生します。

 

図:4

 

5) リクエストメソッドを POST に変更しようとすると、403 エラーが発生します。リクエストは有効ですが、十分な権限がないことがわかります。

 

図:5

 

6) ParamMiner を使用して隠しヘッダーとパラメーターについて 分かりました。 隠しヘッダー「 X-Original-URL employeeId 」パラメータリクエストをファジングすると、特定のリクエストに存在する。

 

7) X-Original-URL メイン URLから取得した値 「/employer/search」と「 employeeId パラメータ値「 637f69562527bb2840XXXXX」を持つヘッダーを追加し(図3 )。

Header-> X-Original-URL: /employer/search

Body-> {“employerId”:”637f69562527bb2840XXXXX”}

 

リクエストを送信すると、現在存在するすべてのユーザーが表示され。

 

図:6

8) 上記のリクエストにより、候補者と採用担当者を含む現在の組織ユーザーのメタデータを確認でき。

9) 次に、同じ組織の別のユーザーのアカウントを引き継ぎ。
候補ユーザーの「ユーザー詳細」編集機能を使用し。
これは、電子メールフィールドのクライアント側でのみ制限が実装されるクライアント検証バイパスに対して脆弱。

 

図:7

 

10) [適用] をクリックした後、 「ユーザーの詳細 」編集リクエストをインターセプトし、プロファイル セクションから burp スイートの。

 

図:8

 

11) 同じ組織の別のユーザーのアカウントを引き継ぐには、ユーザー ID を前のステップで取得した採用担当者の ID に置き換え、電子メールの値を攻撃者の電子メールに置き換え。

 

図:9 これが元のリクエストです

 

図:9.1 これは、通常のユーザーの雇用主 ID をリクルーター ID に変更し、メールに攻撃者の電子メールを含める更新されたリクエスト。これにより、パスワードのリセット中に攻撃者の電子メールでリセット トークンが取得されるようになり

 

12) パスワードのリセット機能を使用して、以下の手順でリクルーター アカウントを正常にリセットしました。 

 

図:10

 

図:10.1

 

図:10.2 - 攻撃者のメールボックスでリクルーター アカウントのパスワード リセット トークンを正常に受信しました

 

13) リクルーターアカウントを引き継ぐので、リクルーターアカウントでログインし。
Recruiter アカウントでは、採用担当者の承認セクションから取得した CTO/CEO のメールを検索する「 searchByEmail 」と「 SearchByName 機能についてしり。

 

図:11

 

14) 再度、パスワードのリセット機能を使用して、CEO/CTO アカウントの引き継ぎに成功しました。 (ステップ 12 に従って、任意のアカウントのパスワードをリセットし)

15) 管理者パネルでは、キャンペーンの管理、ジョブクレジット、キャンペーン分析、ユーザーの管理機能を実行でき。

 

図:12

 

16) 「ユーザーの管理」タブに移動すると、組織に存在するすべての高い権限を持つ操作ユーザーを確認できます。 

 

図:13

 

17) 電子メールによる検索機能を使用して、組織が現在のアプリケーションを通じて面接プロセスを管理している候補者、採用担当者、人事、営業、または CEO/CTO の電子メールを検索し。 EmployerId を取得でき。
これは、別の組織候補ユーザーからその特定の組織に対して管理者アカウント乗っ取り攻撃を実行するのに十分で。

マインド マップ: アプリケーション データ フローと攻撃シナリオの高度な理解を強化し。

 

図:14

 

ほなほな。