面白さと実刑判決を呼ぶ IIS サーバー偵察

 (mll.sh)
2 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • IIS のデフォルト画面は行き止まりではなく、バグバウンティ偵察の出発点であり、Shodan・Google dork・レスポンスヘッダーを使って露出したサーバーや隠れた vhost を絞り込める
  • HTTP/1.0 リクエスト、HTTPAPI 2.0 404、SSL 証明書、Host ヘッダーのブルートフォースは、内部 IP・Exchange ホスト名・仮想ホストを見つける初期の手がかりになる
  • IIS の DOS 8.3 ベースの tilde shortname enumeration は、ディレクトリリスティングが無効でも短いファイル名・ディレクトリ名を露出させ得る。GitHub 検索・BigQuery・LLM・crunch で完全な名前候補を推定する
  • IIS/.NET 特化のファジングでは、web.config、trace.axd、elmah.axd、appsettings.*.json、.aspx/.ashx/.asmx/.config のような 高価値パスと拡張子を先に狙う
  • web.config の露出、cookieless session のパス正規化、reverse proxy path confusion、NTFS alternate data stream、アップロード拡張子回避、HPP は、設定ミスやレガシー挙動が攻撃面につながり得ることを示している

IIS サーバーを見つけ出す偵察方法

  • IIS 対象は検索エンジンやインターネット資産検索サービスでまず発見できる
  • Shodan クエリは、対象ドメインの SSL 証明書、組織名、http.title:"IIS" の組み合わせで IIS サーバーを絞り込む方法
    • 対象例には staging サーバー、忘れられた管理パネル、インターネットに露出した内部ツールが含まれる
    • Shodan のほか、fofa、censys、netlas、odin も異なるインターネットインデックスを提供する
  • Google dorking は、IIS の痕跡がインデックスされたページを探すのに使われる
    • aspnet_client フォルダーと _vti_bin は IIS のシグナルとして扱われる
    • ext:aspx は ASP.NET ページを見つけ、その背後に IIS があることを示唆する
    • site:*.target.com、site:*.*.target.com 形式のワイルドカード検索は、基本的なサブドメイン列挙で見落とした多段サブドメインを見つけるのに使われる
  • レスポンスヘッダーは IIS 識別の最も簡単な手がかり
    • Server: Microsoft-IIS/10.0
    • X-Powered-By: ASP.NET
    • 大規模確認では httpx や nuclei で IIS 対象リストを作れる

IIS 確認後に得られる初期の手がかり

  • 一部の IIS 構成、特に Exchange または OWA フロントは HTTP/1.0 リクエストに内部情報を露出することがある
  • Location ヘッダーに https://192.168.5.237/owa/ のような 内部 IP が入る場合がある
  • X-FEServer ヘッダーは Exchange サーバーの内部ホスト名を明かすことがある
  • こうした情報は後続段階で利用可能な 情報漏えい につながる

自動化と隠れた仮想ホスト探し

  • IIS 対象リストを確保した後、nuclei を microsoft、windows、asp、aspx、iis、azure、config、exposure などのタグで実行すると反復作業を減らせる
  • HTTPAPI 2.0 404 は、本当に何もないことを意味しない場合がある
    • IIS インスタンスが特定の 仮想ホストにバインドされており、リクエストの Host ヘッダーが一致しないため 404 になることがある
  • 隠れた vhost を見つける方法は 2 つある
    • SSL 証明書の subject または SAN フィールドから必要なホスト名を探す
    • 証明書が役立たなければ、ffuf と Host ヘッダー用 wordlist で vhost をブルートフォースする
  • 正しいホスト名を見つけると、通常の 404 ではなく実際のアプリケーションが応答することがある

IIS tilde shortname enumeration

  • IIS は古い DOS の 8.3 ファイル名規則に由来する挙動のため、特殊なリクエストでファイルやディレクトリの短縮名を列挙できることがある
  • ディレクトリリスティングが無効でも、WEB~1.CON、GLOBAL~1.ASA、SITEBA~1.ZIP、ADMIN~1 のような断片が露出することがある
  • shortscan は IIS shortname 列挙ツールとして使われる
  • burp’s IIS Tilde Enumeration Scanner も代替として活用できる
  • 短縮名を完全なファイル名に戻す方法はいくつかある
    • LLM: shortname の断片を含む可能性のあるファイル名候補を生成する
    • GitHub code search: ~1 の前の最初の 6 文字と拡張子を基準に実際のファイル名を検索する
    • GSNW: shortname の断片を受け取り、GitHub code search で一致するファイル名を収集する
    • GitHub-IIS-Shortname-Generator: 類似の方法で単語リストを生成する
    • shortnameguesser: scanner 出力から複数ソースを問い合わせ、ターゲット用 wordlist を作る
  • BigQuery 方式は、Google BigQuery の公開 GitHub データセットで shortname パターンに一致するファイルパスを探す
  • LLM、GitHub、BigQuery が失敗したら、crunch で残りの文字列組み合わせの wordlist を作り、ffuf で試す
    • ハイフン、アンダースコア、URL エンコードされた空白、区切りなしなどのファイル名バリエーションもあわせて確認する
    • Windows はファイル名の空白を許可し、IIS もそれを配信できる

IIS/.NET 特化ファジング

  • 一般的な wordlist だけでは、IIS/.NET エコシステム固有のファイルやエンドポイントを見落とすことがある
  • 優先的に確認すべき 高価値対象 には次が含まれる
    • /web.config, /web.config.bak, /web.config.old, /web.config.txt
    • /global.asax
    • /trace.axd
    • /elmah.axd
    • /connectionstrings.config
    • /appsettings.json, /appsettings.Development.json, /appsettings.Staging.json, /appsettings.Production.json, /appsettings.Local.json
    • /secrets.json
    • /WS_FTP.LOG
    • /_vti_pvt/service.cnf
  • trace.axd は ASP.NET の trace viewer で、有効ならヘッダー・Cookie・時には認証情報を含むリクエスト/レスポンスログが露出することがある
  • elmah.axd は、開発者が無効化し忘れた デバッグエンドポイントとして残り、エラーログを表示することがある
  • IIS 特化の拡張子ファジング対象には .asp, .aspx, .ashx, .asmx, .wsdl, .wadl, .config, .xml, .zip, .txt, .dll, .json が含まれる
  • 活用しやすい wordlist は次のとおり
    • secLists IIS.txt: 基本的な IIS パス、一般的なハンドラー、レガシーファイルを含む
    • orwa’s iis.txt: 実際のバグバウンティプログラムで使われた IIS リストとして紹介されている
    • orwa’s aspx.txt: .aspx エンドポイント中心のリスト
    • wfuzz iis.txt: 既知の脆弱な IIS パスに焦点を当てた小さなリスト
    • dirbuster-ng iis.txt: IIS 特化の弱点を狙ったコンパクトなリスト
    • Assetnote wordlists: 実際のクロールデータから自動生成され毎月更新される。ASP と ASPX のリストが推奨される
    • OneListForAll: onelistforallshort.txt は対象を絞った実行に、完全版は長時間実行に使われる
  • IIS は 大文字小文字を区別しないため、mixed-case の wordlist は重複リクエストを生むことがある
    • lower-case のリストを使うか、tr '[:upper:]' '[:lower:]' | sort -u で正規化する方法が使われる

web.config とコード露出

  • web.config を path traversal、誤って露出したバックアップファイル、shortname ベースの発見で読めると、IIS 対象では影響が大きくなり得る
  • IIS の web.config には、ViewState の署名と暗号化に使われる machine keys が入っていることがある
  • machine keys があれば、悪意あるシリアライズ済み ViewState payload を偽造し、デシリアライズによる リモートコード実行 につながる可能性がある
  • ysoserial.net は、key があるとき payload 生成を支援するツール
  • ファイルダウンロードやファイル読み取りパラメータがあれば、../../web.config や URL エンコード変種を試す流れにつながる
  • ASP.NET のレガシーな cookieless session 機能は (S(X)) 形式のセッショントークンを URL パスに入れられる
    • IIS がそのセグメントをパス正規化中に除去し、/bin ディレクトリアクセス制限を回避できることがある
    • Newtonsoft.Json.dll 自体は標準ライブラリで、アプリケーション秘密情報を含まない場合がある
    • 実際のアプリケーション DLL を取得できれば、dotPeek や dnSpy でデコンパイルし、ハードコードされた認証情報、API キー、内部エンドポイントロジック、カスタム認証実装を確認できる

パス正規化、NTFS、アップロード、WAF 回避

  • IIS が reverse proxy の背後にある、または reverse proxy として動作する場合、パス正規化の差異がアクセス制御回避につながることがある
    • proxy はエンコードされたパスを別リソースとして転送する一方、IIS は %2f を / にデコードし、traversal を解釈して保護パスを提供してしまうことがある
  • IIS 7.5 および類似バージョンでは、NTFS の alternate data streams と index allocation の挙動により basic authentication を回避できる可能性がある
    • 認証モジュールは保護パスとして認識しなくても、ファイルシステムは実ディレクトリとして解釈できることがある
  • ファイルアップロード機能では、.aspx、.asp が遮断されても、IIS がデフォルトで HTML として配信する拡張子を通じて stored XSS が可能な場合がある
    • HTML レンダリング拡張子の例: .cer, .hxt, .htm
    • XML ベース XSS ベクター拡張子の例: .dtd, .mno, .vml, .xsl, .xht, .svg, .xml, .xsd, .xsf, .svgz, .xslt, .wsdl, .xhtml
  • IIS にはファイル名末尾のドットを削除する挙動があり、shell.aspx.、shell.aspx..、shell.aspx... のようなアップロードフィルター回避が可能なことがある
  • server-side includes 対象として .stm, .shtm, .shtml 拡張子が挙げられている
  • WAF が payload をブロックするとき、HTTP Parameter Pollution により重複パラメータへ payload を分割して入れられることがある
    • IIS と ASP.NET は通常、重複パラメータ値をカンマで連結するため、WAF の背後で payload が再構成され得る

IIS バグバウンティで残る教訓と資料

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker News のコメント

  • すべてのハニーポットの前に IIS のランディングページを置くのは、まさにブラックハットを引き寄せるため
    連中が自分の尻尾を追いかけて何時間も無駄にしたと思うと、この上なく愉快

    • そこで止めずに、本物のIIS サーバーを前段に置いて、ハニーポットをマトリョーシカみたいに何重にも重ね、どこまで入ってくるか見ると面白そう
    • 既存組織の IP 帯域でハニーポットを動かしているのでなければ、結局来るのはボットトラフィックだけ
      上位のブラックハットは大きな標的を狙い、下位は Shodan で見つけた簡単な獲物か、自分たちが見つけたアプリケーションのゼロデイに集中する
    • ノイズは本当に過小評価されているセキュリティ層
    • Plex と Nintendo Switch のポートを開けたら、狂ったようにスキャンが飛んできた
      ポートスキャナーを出し抜く方法があるなら、もっと知りたい
    • aspnet_client/admin.php みたいな URL を作って、WebObjects ヘッダーを返すようにしておくのも良い趣味になりそう

  • 「IIS が古い DOS の 8.3 ファイル名規則を受け継いだレガシー動作を持っている」というのは、IIS のドキュメントルートがデフォルトで C:\Inetpub である点と相まって、基盤 OS の動作が露出するという意味なのか気になる
    Windows 10/11 では 8.3 ファイル名は C ドライブでデフォルト有効だが、他のドライブではデフォルト無効
    PS> (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').DisplayVersion → 24H2
    fsutil 8dot3name query C: は 8dot3 name creation is ENABLED、fsutil 8dot3name query U: は DISABLED と表示される

    • 脇道だけど、Windows アップデートが「保護の強化」という曖昧な理由で、サーバーではないすべての PC に**c:\inetpub**を作っていた件を思い出した
      https://www.pcworld.com/article/2684062/why-is-windows-11-la...
    • この内容の元の研究はここ: https://soroush.me/downloadable/microsoft_iis_tilde_characte...
    • Windows 10 のマシンでは DisplayVersion コマンドに応答がなく、古いバージョン、たとえばLTSCでは以下のように ReleaseId を使う必要があるようだ
      (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').ReleaseId → 1809

  • 文章の文体がかなり独特

    • 何度も Claude が書いたのかと思った

  • うわ、これは昔を強く思い出す
    かつては IIS スキャナーが多すぎて、サーバーログが実質使い物にならないレベルだった
    ../ を URL エンコードするだけで済むディレクトリトラバーサル脆弱性があり、数か月にわたってインターネット全体を焼き尽くしていた

    • そういうトラバーサルの試みは、今でも PHP/WordPress のスクリプトキディ攻撃と並んで本当によく見かける

  • まだIISを使っているところなんてあるのか?

    • ある。Windows Server と IIS を使えばドメイン参加済みのマシンになり、通常は HOST/MACHINE.DOMAIN 形式の SPN がある
      Windows サービスと IIS App Pool Identity は (g)MSA や仮想アカウント(NT Service*)でログオンするので、30/60/90 日ごとのパスワード更新を手で扱わなくても、管理されたKerberos環境がきちんと動く
      MS SQL Server に Kerberos でログインし、別の Web アプリの OAuth2 フローにも Kerberos でログインするといったことが、すべて自然に機能する
      標準の Windows シェルから WinRM も特に設定なしで使えるし、技術的には 2FA も回避できるが、実際そういう仕組みで動いている
      Linux でも可能かといえば可能だが、きちんと設定される可能性は勤務環境次第で、これまでの経験では高くなかった
    • 企業の IT 部門では今でもものすごく多く使っている
    • Windows Server で IIS を回し続けている人たちとはよく話す
      古いアプリが本当に多く、その中にはかなり重要なものも多い
    • 一部の銀行はいまだに IIS を使っている
      イントラネットを運用するだけの規模の大企業なら、どこかしら、あるいは全面的にIISが動いている
      AD との統合が優れていて、とても複雑な作業も馬鹿げているほど簡単になる
      世界が AWS に移って利用は減っているが、それも結局また一社の独占製品(Amazon)に縛られることで、同じくらい愚かだ。今回はハードウェアすら所有しないという違いがあるだけ
      公共部門の IT は IIS を好む。自治体の税金や不動産の Web サイトを見ると、.aspx スクリプトが大量にある可能性が高い
      ヨーロッパの公共部門 Web アプリでも見たことがあり、SQL Server バックエンドを持つカスタム .NET アプリケーションが地方自治体全体を動かしていることが多い
      アジア、特に中国と台湾は IIS を好み、いろいろなもののホスティングに使っているように見えた
      世界の大勢は確かに移ったが、都市や重要な組織を動かすレガシーコードが IIS 上に大量に残っていて、今後も変わらないだろう
      それが悪いと思うなら、いまだに Web 上で AS/400、Lotus Notes、Novell GroupWise を動かしているところもある
    • そうだね。それで、よく分かっていない立場から聞くけど、今は何を使うべきなんだ?
      小さな会社が企業向け .NET Framework のコードを書いていて、Windows 一色で、顧客はクラウドを受け入れず、SOAP が依然主流で、唯一の IT 担当者は 2010 年以降に何が起きたか気にする余裕すらない、という状況を考えればいい
      全面書き直しは現実的に不可能で、セキュリティ上の利点は得たいが、設定を深く掘る余力もなく、Kubernetes みたいな複雑なものに賭けることもできない

  • nginx についてもこういう分析記事を読みたい

  • デスクトップブラウザ全体で見るなら、デザインは本当によくできていて、内容も素晴らしい

    • 皮肉なのか分からないけど、自分のデスクトップブラウザではサイドバーが本文パネルに重なって、テキストの上にテキストが載っている
      それでも、それ以外のプレゼンテーションは気に入っている
    • 「素晴らしい」というのは、2000 年代初頭のスクリプトキディレベルの内容にしては少し甘い評価
      筆者は、文明が大した理由もなく互いに意地悪をしない人々にどれだけ依存しているか、まだ学ぶ必要がありそう

  • 左側のサイドバーが本文テキストと重なっているのはどういうことなんだろう