Shikata Ga Nai

Private? There is no such things.

When not to rely on Automated Toolsを訳してみた

Hello there, ('ω')ノ

 

自動化ツールに頼るべきではない場合を。

 

脆弱性:

 プロトタイプ汚染

記事:

 https://medium.com/@rodriguezjorgex/when-not-to-rely-on-automated-tools-429b331e0613

 

自動化ツールを使用してプロトタイプ汚染を発見した方法

今回は手動でハンティングするのが好きですが、chaos ツールを使用して

サブドメインのリストを取得する以外は、通常はあまり偵察をせず。

そこで、次のコマンドを使用してカオスから始めて。

 

 chaos -d REDACTED > subdomains.txt

 

結果を確認した後、Burp Suiteを開いて内蔵ブラウザを実行し。

プロトタイプ汚染でドムインベーダーを有効にすることにして。

 

プロトタイプ汚染が有効になった DOM Invader

 

DOM Invader を有効にして、いくつかのサブドメインに移動すると、

DOM Invader がヒットし続け。

しかし、開発者ツールの [DOM Invader] タブを確認するたびに、

[エクスプロイト] または [ガジェットのスキャン] オプションが表示されず。

 

DOM Invader タブにガジェットが表示されない



ついにプロトタイプ汚染を発見

約 1 時間手動でサブドメイン間を移動した後、最終的に [DOM Invader] タブに

ヒットし、[ガジェットのスキャン] オプションが表示され。

 

「ガジェットのスキャン」を表示する「DOM Invader」タブ

 

[ガジェットのスキャン] をクリックすると、DOM Invader は使用する次の

ペイロードを見つ。

 

https://redacted.com/#__proto__[div][2]=%3Cimg+src+onerror%3Dalert%28document.domain%29%3E

 

URL に移動した後、アラート XSS を確認し、レポートの作成を開始して。


プロトタイプの汚染:自動化なし

レポートを提出すると、かなり早く優先順位が付けられ。

しかし、さらに印象的だったのは、24 時間以内にパッチ検証リクエストを

受け取ったことで。

 

クライアントはそんなに早くコードを修正したのか?

馴染みのない方のために説明すると、Synack では、レポートを送信すると、

クライアントは問題を修正した後にパッチの検証をリクエストでき。

パッチの検証を受け入れ、再び DOM Invader を有効にして

サブドメインに移動して。

 

そして再び、DOM Invader は、プロトタイプ汚染の脆弱性があるため、

ガジェットをスキャンするように指示し。

もう一度ガジェットをスキャンしましたが、驚いたことに、

DOM Invader はガジェットを見つけられず。


これで完了?

プロトタイプの汚染がまだある場合、クライアントは何を修正したのか??

調べてみると、クライアントはシンク、つまり XSS を反映していたコードの

部分を修正したようで。

しなければならなかったのは、追加のシンクを見つけることだけで。

しかし、DOM Invader はそれを見つけることができず。

では、別のシンクがあったのか?

 

前日、プロトタイプ汚染についてハッシュタグ #HackTheBox Academy を

勉強していましたが、ホワイトボックス攻撃モジュールで

クライアント側のプロトタイプ汚染に関する特別なトピックが

あったことが分かり。

このモジュールでは、DOM Invader が機能しないインスタンスもあり、

ガジェットを手動で見つける必要があり。

ガジェットを見つけるための Github リポジトリを提供して。

 

https://github.com/BlackFan/client-side-prototype-pollution/tree/master/gadgets

 

HackTheBox Academy モジュールで学んだのと同じテクニックを使用し、

クライアントの Web アプリケーションで使用できるガジェットを探し。

2つの異なるガジェットをテストした結果、正しいガジェットが見つかって。

 

https://redacted.com/#__proto__[preventDefault]=x&__proto__[handleObj]=x&__proto__[delegateTarget]=<img/src/onerror%3dalert(document.domain)>

 

アラートが再び表示され、問題が解決していないことをクライアントに通知し、

シンクだけでなく根本原因を確実に解決することに戻って。


結論

もし自動化ツールだけに頼っていたら、クライアントはパッチ適用後に

Web アプリケーションが安全であると信じたままになっていたはずで。

しかし、綿密な作業を行い、手動で調査を行うことで、

1つの脆弱性を悪用する追加の方法を見つけることができて。

 

最新情報を入手し、学習し続けることも良いことで。

HackTheBox アカデミーは素晴らしいリソースで。

自分の技術を向上させたいバグハンターに強くお勧めして。

 

Best regards, (^^ゞ