Hello there, ('ω')ノ
何百万ものサーバ管理にアクセスする方法を。
脆弱性：
特権の昇格
一括割り当て
記事：
ツール：
BurpSuite
下記が、OWASPジュースショップで。
OWASP Juice Shopの「Improper Input Validation」に。
「管理者権限を持つユーザとして登録する」という説明のあるタスクがあって。
これがどのように機能するかは、登録時にあって。
タスクを完了するには、「role」という名前と「admin」の値を持つパラメータを。
推測して渡す必要があって。
このタスクを完了すると。
「これを実際のシナリオに実際に適用できるか」と思ったものの。
答えは、「No」で。
序章：
プログラムには、サインアップ／ログインが必要なサブドメインがあるので。
すぐにアカウントを作成して。
アカウント登録中は、すべてが正常で。
簡単にするためにデモンストレーションの目的で。
下記が、リクエストとすると。
POST /register HTTP/1.1
Host: www.redacted.com
Content-Type: application/json
{“email”: “user@tld.xyz”, “password”: “password123”}
上記のリクエストは、ホームページへの302リダイレクトを返して。
疑わしいことは何もないと思うので、サイトの探索を続けると。
サイトを探索する際に、「My Account」機能を確認して。
そこにCSRFとIDORの脆弱性があることを期待したものの、何もなくて。
userIDに結合されている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, (^^ゞ
