IIS サーバーのペネトレーションテストと列挙手法

Microsoft Internet Information Services（IIS）サーバーは設定ミスが多く、セキュリティ研究者やバグバウンティハンターにとって広範な攻撃対象となります。主なポイントは、デフォルトの IIS スプラッシュページが内部 IP の漏洩、ショートネーム列挙、重要な構成ファイルの露出といった深刻な脆弱性を隠していることが多く、これらはリモートコード実行（RCE）につながり得るということです。

大規模に IIS ターゲットを特定する方法

IIS サーバーは受動的リコンと能動的フィンガープリントを組み合わせて特定し、テスト対象リストを作成できます。

受動的ディスカバリ

  • Shodan クエリ: ssl:"target.com" http.title:"IIS" や org:"target" http.title:"IIS" といったクエリを使ってステージングサーバーや忘れられた管理パネルを見つけます。
  • Google Dorking: site:target.com inurl:aspnet_client や site:target.com ext:aspx | ext:ashx | ext:asmx など、IIS 固有の指標で検索します。スタックされたワイルドカード（例: site:*.*.target.com）を使用すると、ネストされたサブドメインや開発用マシンが明らかになることがあります。

能動的フィンガープリント

  • レスポンスヘッダー: nc や openssl での生リクエストにより、Server: Microsoft-IIS/10.0 や X-Powered-By: ASP.NET ヘッダーが判明することが多いです。
  • 自動スキャン: httpx などのツールで大量にフィンガープリントできます。例: httpx -l targets.txt -td | grep IIS。

初期情報収集

IIS サーバーが特定できたら、特定のリクエストで内部インフラ情報が漏洩することがあります。

内部 IP の漏洩

Microsoft Exchange や OWA のフロントエンドとして構成された IIS 環境に対し HTTP/1.0 リクエストを送ると、Location ヘッダーに内部 IP アドレスが返されることがあります。さらに X-FEServer ヘッダーでサーバーの内部ホスト名が明らかになることもあります。

HTTPAPI 2.0 404 エラーの扱い方

HTTPAPI 2.0 404 エラーはサーバーは稼働しているが、特定の Host ヘッダーが必要であることを示します。回避手順は次の通りです。

  1. SSL 証明書の Subject または Subject Alternative Name（SAN）フィールドから正しいホスト名を確認する。
  2. ffuf と Host ヘッダー用ワードリストを使ってバーチャルホストをブルートフォースする。

高度な列挙: IIS チルダ（~）ショートネーム

IIS はレガシーな DOS 8.3 ファイル名規則を保持しており、ディレクトリ一覧が無効化されていてもファイルやディレクトリのショートネームを列挙できます。

ショートネームの発見

shortscan や Burp Suite の IIS チルダ列挙スキャナなどのツールで、WEB~1.CON（web.config）や SITEBA~1.ZIP（バックアップファイル）といったショートネームの断片を特定できます。

ショートネームから完全ファイル名への解決

ショートネームは最初の 6 文字しか提供しないため、完全なファイル名は推測または外部データで解決する必要があります。

  • LLM: 大規模言語モデルにショートネームのスニペットから考えられる完全単語のリストを生成させる。
  • GitHub Dorking: GitHub のコード検索（例: path:/.ds_st）で実際のファイル名を探す。
  • BigQuery: Google BigQuery の公開 GitHub データセットをクエリし、ショートネーム正規表現に合致するパスを抽出する（例: REGEXP_CONTAINS(path, r'(?i)(\/siteba[a-z0-9]+\.zip|^siteba[a-z0-9]+\.zip)')）。
  • ブルートフォース: crunch で残りの文字列組み合わせを生成し、ffuf でファジング。ハイフン、アンダースコア、URL エンコードされたスペース（%20）などの区切り文字も試す。

高価値ターゲットのファジング

一般的なワードリストは IIS には効果が薄いです。ファジングは .NET 固有のファイルや拡張子に焦点を当てるべきです。

重要なパスと拡張子

高価値ターゲット例:

  • 設定ファイル: /web.config, /web.config.bak, /appsettings.json, /connectionstrings.config
  • デバッグエンドポイント: /trace.axd（ASP.NET トレースビューア）や /elmah.axd（エラーログビューア）。これらはリクエスト/レスポンスログや認証情報を漏洩させる可能性があります。
  • 拡張子: .asp, .aspx, .ashx, .asmx, .config, .json, .xml, .zip, .bak, .txt

推奨ワードリスト

有効なワードリスト例: SecLists の IIS.txt、Orwa の iis.txt と aspx.txt、Assetnote が自動生成した ASP/ASPX リスト。

エクスプロイトとバイパス手法

web.config RCE チェーン

web.config へのアクセスは重要な発見です。このファイルには ViewState の署名・暗号化に使用されるマシンキーが含まれることが多く、取得できれば ysoserial.net を使って悪意あるシリアライズ済み ViewState ペイロードを作成し、リモートコード実行（RCE）を実現できます。

クッキーなしセッションによる DLL 暴露

ASP.NET のクッキーなしセッション構文 (S(X)) を悪用すると、ディレクトリ制限を回避して /bin フォルダにアクセスできます。例: GET /(S(X))/b/(S(X))in/WebApplication1.dll は /bin/WebApplication1.dll に解決され、攻撃者はコンパイル済み DLL を取得し、dnSpy や JetBrains dotPeek で逆コンパイルできます。

パス・認証バイパス

  • リバースプロキシパス混乱: %2f（URL エンコードされたスラッシュ）を使用してプロキシのアクセス制御を回避（例: /anything/..%2fadmin/）。
  • NTFS メタデータハック: IIS 7.5 の基本認証を回避するために NTFS の代替データストリームをリクエスト（例: /admin::$INDEX_ALLOCATION/admin.php）。
  • ファイルアップロードバイパス: .aspx フィルタを回避するために末尾にドットを付加（例: shell.aspx.）。IIS はファイル提供前にドットを除去します。

HTTP パラメータ汚染（HPP）による WAF バイパス

IIS と ASP.NET は重複パラメータの値をカンマで連結します。この特性を利用してペイロードを複数パラメータに分割でき、WAF の検知を回避しつつバックエンドで再構築されます（例: ?param=<svg/&param=onload=alert(1)>）。

まとめ

このガイドは Microsoft Internet Information Services（IIS）サーバーに対する高度な偵察とエクスプロイト手法を詳述しています。特にショートネーム列挙、設定ファイルの露出、WAF バイパスに焦点を当てています。

Sources