Shikata Ga Nai

Private? There is no such things.

Full Account Take Over by very simple trick.を訳してみた

Hello there, ('ω')ノ

 

非常に単純なトリックによる完全なアカウントの乗っ取りを。

 

脆弱性:

 アカウントの乗っ取り

 アクセス制御の破綻

 

記事:

 https://medium.com/@xerox0x1/full-account-take-over-by-very-simple-trick-b4025a53047c

 

今回は、最初に Access Control のバグを探し始め。

それで、すぐにすべてのユーザの役割を再確認して。

リクエスト、レスポンスの操作、検索エンジンの隠されたエンドポイントへの。

ドーキング、ウェイバック マシン、alien vaultなど。

 

https://otx.alienvault.com/

 

残念ながら、すべてのユーザ ロールは安全に処理され。

そのような場合に他に何もすることはありませんでしたが。

気が付くまで、プラットフォームで新しいユーザを作成する要求があり。

こんな感じで。

 

 

マークされた値を分解してみると。


1.「platform」: このユーザに割り当てるプラットフォーム。

 「platform ID = account ID」

2.「uzrole」: そのユーザに割り当てられる役割。

 悪意のあるハッカーは、ユーザにプラットフォームへのフル アクセスを。

 許可するユーザ ロールを選択したと考えて。

3.「allowedplatforms」: これが最も危険なプラットフォームで。 


この JSON には、必要な数のプラットフォーム ID を追加でき。

 

 

allowedplatforms」セクションにいくつかのプラットフォームを追加し。

リクエストを転送し。

ほぼすべてのリクエストを同じ基準でチェックしたため。

うまくいかないことは間違いありませんでしたが、驚いたことにうまくいって。

200OKで、以下の返事が返ってきて。

 

 

応答の「allowedplatfroms」を詳しく見ると。

 

• リクエストの早い段階で ID を割り当てたプラットフォームを確認し。

 ページを更新すると、作成したユーザがこれらのプラットフォームに。

 アカウントの完全な権限で割り当てられていることがわかり。

• すべてが正しいことを確認するために、このユーザでいくつかの。

 プラットフォームにログインしましたが、彼女は完全な権限で。

 ログインしていて。

 そこから、管理者の削除、変更、アカウント全体の削除など、何でもできて。

 

脆弱性は重複していましたが、そこから何かを思いついて。

 

結論:

• アクセス制御は常に優先され。

• 常に最も単純なことを試して。

 通常、脆弱性はあまりにも明白で、よく掘り下げる必要があるだけで。

 

Best regards, (^^ゞ