IISチルド脆弱性の修正

9

IISサーバーの1つ（IIS 7.5、Server 2008 R2）は、チルドショートファイル名の開示の問題に対して明らかに「脆弱」です。

しかし、実際に問題を解決するのに苦労しています。これまでのところ、

8.3ファイル名を無効にし、Webサーバーを停止し、サイトディレクトリを再作成して、サービスを再開しました
チルダのフィルタールールをURLに追加しました。

ここに画像の説明を入力してください

チルドANYWHEREのフィルタールールを追加しました。

ここに画像の説明を入力してください

IISRESET 数回
web.config関連するフィルタールールが追加されていることを確認

..しかし、それでも、サイトにテストに合格させることができません。

java -jar ~/temp/IIS-ShortName-Scanner-master/IIS_shortname_scanner.jar http://www.example.com

[...SNIP...]

Testing request method: "TRACE" with magic part: "/webresource.axd" ...
Testing request method: "DEBUG" with magic part: "" ...
Testing request method: "OPTIONS" with magic part: "" ...
Testing request method: "GET" with magic part: "" ...
Reliable request method was found = GET
Reliable magic part was found = 
144 requests have been sent to the server:

<<< The target website is vulnerable! >>>

これを解決するには、他に何が必要ですか？

編集：ここにあるDIR /x何の8.3形式を示していないように見えます。

ここに画像の説明を入力してください

これがサイトのアプリプールです（サーバー上の他のすべてのサイトは同じです）。

ここに画像の説明を入力してください

EDIT2：8.3ファイル名が残っていないことの確認：

ここに画像の説明を入力してください

security iis

— ケンド
ソース

ディレクトリに8.3形式の名前があるかどうかをダブルチェックする簡単な方法は、ですdir /x。サイトには、自動生成された8.3名がまだ含まれているディレクトリへのシンボリックリンクがある場合があります。

— ブライアン

私が恐れている8.3ファイル名の兆候はありません:(

— KenD

.NET 4.0のインストール（これはこの脆弱性の影響を受けません）は、この問題の他の一般的な回避策です。もう試しましたか？

— HopelessN00b 2015

.Net 4がインストールされ、サーバー上のすべてのアプリケーションプールが使用するように設定されている.NET Framework v4.0.30319-上記の編集のスクリーンショットを参照してください。

— KenD 2015

4

ワオ。おそらくここでストローをつかんでいますが、使用している脆弱性スキャナーは信頼できるものですか？別のツールを試すか、手動で攻撃を実行してみてください。

— HopelessN00b 2015

6

既存の短いファイル名をスキャンしてみてくださいfsutil：

fsutil 8dot3name scan /s /v E:\inetpub\wwwroot

そして、それらが見つかった場合はそれらを取り除きます。

fsutil 8dot3name strip /s /v E:\inetpub\wwwroot

また、空のマジックパーツ（magic part: ""）が含まれるログを確認すると、POCのバグである可能性があります。config.xmlのこの行は、後にコンマが余分にあるように見えます/webresource.axd。

<entry> key="magicFinalPartList">
 <![CDATA[\a.aspx,\a.asp,/a.aspx,/a.asp,/a.shtml,/a.asmx‌,/a.ashx,/a.config,/a.php,/a.jpg,/webresource.axd,,/a.xxx]]>
</entry>

私は開発者に尋ねました。それについてツイッター経由で、彼は答えた：

拡張機能が不要なまれなケース。しかし、最近、それが原因となった問題はさらに増えました！今すぐ削除します。

Configファイルから削除しました。これは2番目の苦情でしたので、今回の変更に適した時期でした。

だから、あなたは今安全だと思います:)

— ビートクラッカー
ソース

変更はありません。元の投稿の「

— EDIT2

1

マジックパーツが空のログ（magic part: ""）を見ると、POCのバグである可能性があります。このラインconfig.xmlの ルックス、それは後に余分なコンマを持っているよう/webresource.axd：

<entry key="magicFinalPartList"><![CDATA[\a.aspx,\a.asp,/a.aspx,/a.asp,/a.shtml,/a.asmx,/a.ashx,/a.config,/a.php,/a.jpg,/webresource.axd,,/a.xxx]]></entry>

— beatcracker

それは非常に興味深いですが、改訂を振り返ってみると、その "ダブルコンマ"はしばらくの間コードに含まれています。これを削除すると、テストは明らかなエラーなしで実行されるようになります...

— KenD

ハ、あなたは安全です、アップデートを見てください！

— ビートクラッカー2015年

すべてが機能し、私たちはずっと安全でした:)あなたの助けをありがとう、開発者に連絡してください！

— KenD 2015

1

また、「注：NtfsDisable8dot3NameCreationレジストリエントリへの変更は、変更後に作成されるファイル、フォルダ、およびプロファイルにのみ影響します。既存のファイルは影響を受けません。」

注：8.3ファイル名の作成を無効にすると、Windowsでのファイルパフォーマンスは向上しますが、一部のアプリケーション（16ビット、32ビット、または64ビット）は、長いファイル名を持つファイルやディレクトリを見つけられない場合があります。

— アルバートリオハス
ソース

0

残念ながら、これに本当に対処する唯一の方法は、ウィンドウのバージョンによっては、迷惑な一連の旋回であり、8.3の名前を生成する機能を無効にします。

Windowsのバージョン：

すべてのNTFSパーティションで8.3形式の名前の作成を無効にするには、管理者特権のコマンドプロンプトでfsutil.exe behavior set disable8dot3 1と入力し、Enterキーを押します。

出典：http : //support.microsoft.com/kb/121007

— デイブ・ホーランド
ソース

あなたがリンクした記事は、8.3ファイル名の作成を無効にする方法を述べていますが、なぜそれが問題を解決するのかではありません。

— マイケルハンプトン

私はすでに8.3ファイル名を無効にしておりdir /x、サイトのディレクトリに短いファイル名が表示されていません

— KenD

ケン、これはあなたが以前使っていた方法でしたか？

— デイブオランダ

うん。レジストリ設定への参照も見ましたが、fsutilコマンドはそのキーを設定するだけのようです。

— KenD 2015

0

スクリプトがどのように機能し、ネットワークがどのように設定されているかは正確ではありませんが、IISサーバーの前にあるもの（たとえそれが仮想マシンの単なる仮想デバイスであっても）を介してフィルタリングするのはどうですか？つまり、その特定の問題に関連するトラフィックを明確にドロップするルールを使用してIPSをセットアップしますか？

— dtbnguyen
ソース