リフレクトファイルダウンロード（RFD）攻撃に関する質問

Question

私はこの記事とセキュリティ研究者Oren Hafifによるホワイトペーパーを読みます。

RFDは、他の多くのWeb攻撃と同様に、悪意のあるリンクを被害者に送信することから始まります。ただし、他の攻撃とは異なり、RFDはブラウザコンテキストの外部で終了します。

ユーザーは、信頼できるWebサイトへの悪意のあるリンクをたどります。

実行可能ファイルがダウンロードされ、ユーザーのマシンに保存されます。すべてのセキュリティインジケータは、ファイルが信頼できるWebサイトで「ホストされている」ことを示しています。

ユーザーは、コンピューターを完全に制御するシェルコマンドを含むファイルを実行します。

悪意のあるURLの例は次のようになります。

https://www.google.com/s;/ChromeSetup.bat;/ChromeSetup.bat?gs_ri=psy-ab&q=%22%7c%7c%74....

これは最近のShellshockのバグに似ていますが、攻撃がサーバーではなくクライアントに向けられる点が異なります。私の質問は：

GoogleはサーバーのChromeSetup.batディレクトリの下に/s;ファイルをホストしていますか？
どのOSが脆弱ですか？この攻撃はWindows OSの特定のバージョンに固有ですか？
Webサイトでユーザーが<img>タグのsrc属性に悪意のあるURLを配置することを許可している場合、クライアントはどのようにしてクライアントを保護できますか？

NSSec · Accepted Answer

GoogleはChromeSetup.batをホストしていません。この攻撃の要件は、あまり一般的ではないContent-Typeと、できれば誤って構成されたContent-Dispositionヘッダー（つまり、「filename」属性がない）のエンドポイントがWebサイトに必要であるということです。これらの2つのヘッダーにより、ブラウザーは応答をレンダリングするのではなく、ファイルとしてダウンロードします。

URLで、エンドポイントが '/ s'であることを指定すると、コンテンツタイプがapplication/jsonのオートコンプリート候補がJSONとして提供されます。 IEの古いバージョンは、コンテンツタイプのみに基づいてダウンロードを促します。新しいバージョンとChromeは、この攻撃が機能するために不完全なcontent-dispositionヘッダーを必要とします。

別の要件は、このエンドポイントがクエリ文字列からのユーザー入力を反映する必要があることです（postまたはcookieデータも明らかに機能しますが、攻撃者にとってはそれほど効果的ではありません）。これにより、ダウンロードされるファイルの悪意のあるコンテンツが提供されます。

指定したURLでは、これはquerystringパラメータの値になります。

ダウンロード用にファイル名が提供されていないため、ブラウザはファイル名を1つ選択しようとします。 GoogleのWebサイトでは、urlパラメーター（; /ChromeSetup.bat;部分）を介して緩いURLを許可していたため、ブラウザーはそのクリーンアップバージョン（つまりChromeSetup.bat）をユーザーに提示するファイル名として選択しました。 Webアプリケーションはこの入力を無視しますが、ブラウザはそれを使用します。

どのOSのどのブラウザーもこのように応答する可能性があります。 Chromeは、偽造されたファイル名で応答をダウンロードします。これはOSXでも機能します。

Windowsには、ファイル名に「セットアップ」が発生したときにユーザーに適切に警告しないという弱点があります。また、クリックすると、.batファイルが直接実行されます。攻撃者はハッシュバン表記の完全なシェルスクリプトを提供できない可能性が高いため、OSXおよびLinuxはこのファイルを実行しません。それでも、実行可能ビットが設定されていないため、直接実行されません。

ユーザーはダウンロードをアクティブ化/承諾する必要があるため、Wonでドライブするだけではすぐに「感染」することはありません。クライアント（ブラウザ）は、実行可能ファイルを実行するだけでなく、適切な警告を提供する必要があります。ユーザーはランダムな.batファイルを実行するよりもよく知っているはずですが、それがこの攻撃の強みです。「ファイル」はGoogle.comから提供されるので、安全でしょうか。ここで最も重要なパーティは脆弱なWebサイトです。このWebサイトでは、ユーザーがカスタムパスを提供できないようにし、適切なヘッダーを提供してこれを防止し、ユーザー入力の反映を再検討する必要があります。