私たちのIISサーバー(IIS 7.5、Server 2008 R2))の1つは、明らかに チルダショートファイル名の開示 問題に対して「脆弱」です。
しかし、実際に問題を解決するのに苦労しています。これまでのところ、
8.3ファイル名を無効にし、Webサーバーを停止し、サイトディレクトリを再作成して、サービスを再開しました
URLにチルドのフィルター規則を追加しました:
IISRESET
数回
web.config
には関連するフィルタールールが追加されています
..しかし、それでも、サイトに test を渡すことができません。
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! >>>
これを解決するには、他に何が必要ですか?
EDIT:ここにDIR /x
8.3ファイル名が表示されないようです:
これがサイトのアプリプールです(サーバー上の他のすべてのサイトは同じです)。
EDIT2:8.3ファイル名が残っていないことの確認:
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>
私は開発者に尋ねました。それについてツイッター経由で、彼は答えた:
だから、あなたは今安全だと思います:)
また、「注:NtfsDisable8dot3NameCreationレジストリエントリへの変更は、変更後に作成されるファイル、フォルダ、およびプロファイルにのみ影響します。既存のファイルには影響しません。」
注:8.3ファイル名の作成を無効にすると、Windowsでのファイルパフォーマンスは向上しますが、一部のアプリケーション(16ビット、32ビット、または64ビット)は、長いファイル名を持つファイルやディレクトリを見つけられない場合があります。
残念ながら、これに本当に対処する唯一の方法は、ウィンドウのバージョンによっては、迷惑な一連の旋回であり、8.3の名前を生成する機能を無効にします。
Windowsのバージョン:
すべてのNTFSパーティションで8.3形式の名前の作成を無効にするには、管理者特権のコマンドプロンプトで「fsutil.exe behavior set disable8dot3 1」と入力し、Enterキーを押します。
スクリプトがどのように動作し、ネットワークがどのように設定されているかは正確にはわかりませんが、IISサーバーの前にあるものを介してフィルタリングします(仮想マシン内の単なる仮想デバイスであっても)。つまり、IPSで、特定の問題に関連するトラフィックを明確にドロップするルールを設定しますか?