はじめに

このエントリでは、DEVCORE に所属するオレンジ・ツァイ氏の CODE BLUE 2022 での講演「キャッシュで踊ろう-Microsoft IIS ハッシュテーブルへの攻撃」の中から、 Microsoft Internet Information Services (Microsoft IIS) に認証を迂回される問題 (CVE-2022-30209 ) を取り上げて解説いたします。解説にあたり、同氏の CODE BLUE 2022 での 講演 や スライド だけでなく、同氏のブログ記事 も参考にしています。(Microsoft IIS の UriCache モジュールの処理にサービスを妨害される問題 (CVE-2022-22025 ) は 前回の記事 で扱っておりますので、そちらもぜひご参照ください。)

以下は、継続的脆弱性管理ツール SIDfm VM での当該脆弱性情報の画面を表示したものです。

前提となる用語

ハッシュ関数やハッシュテーブルについて

ハッシュ関数やハッシュテーブルについては 前回の記事 で説明しておりますので、できればそちらをご参照ください。

LKRHash について

LKRHash は、1997年に Per-Åke Larson 氏、Murali Krishnan 氏、および George V. Reilly 氏によって開発されたハッシュテーブルの実装です。 こちらの論文 では「LKRHash は、キャッシュに重度に依存する現代のプロセッサで高速に動作するとともにハイレベルな並行操作を可能にするように設計された、ハッシュテーブルの実装です。線形ハッシュをベースにしており、テーブルは少数の要素から数百万まで拡大 (あるいは縮小) でき、検索、挿入、および削除に予想される時間は常に一定です。」と説明されています。

ツァイ氏は LKRHash によるハッシュテーブルの実装の特徴として「キーの抽出、ハッシュ値の算出、キーの比較といったテーブル関連の関数をアプリケーションが定義できる」点を挙げ、「この種の拡張性が脆弱性マイニングのための多くの機会を作り出している」と主張しています。(講演資料 p.23)

Microsoft IIS に認証を迂回される問題 (CVE-2022-30209 ) について

一般的に、認証は重い処理です。Microsoft IIS は、パフォーマンスの改善のため、BASIC 認証などのパスワードをもとにした認証やクライアント証明書に使用するトークンをデフォルトでキャッシュします。このキャッシュには LKRHash テーブルが使用されています。

ここで、キャッシュされたトークンによる認証処理の流れを考えてみます。まず、あるユーザが認証を試行し、ログオンに成功したとします。ログオンの結果はハッシュテーブルのレコードとしてキャッシュされます。レコードのキーのハッシュ値は、LKRHash テーブルの pfnCalcKeyHash 関数によって「ユーザ名」と「パスワード」から計算されます。同じユーザから再度認証の試行があった場合、「ユーザ名」と「パスワード」は同じもののため、キャッシュのレコードにヒットします。キャッシュのヒットをもって同じユーザと判断することは、できません。ハッシュの特性として、異なる入力から同じハッシュ値を計算することがあるからです。Microsoft IIS では「認証の試行の際に入力された内容」と「キャッシュでヒットしたレコードの内容」を比較することで、本当にそのユーザであるかどうかの確認を行っています。

pfnEqualKeys 関数は、このような目的のために使用されるものですが、ツァイ氏は、この関数が認証方法とユーザ名のみを比較し、パスワードを比較していないことを発見しました。これは、認証方法とユーザ名が一致し、ハッシュ値が衝突するような入力であれば、たとえパスワードが誤りであったとしても認証が成功することを意味します。(講演資料 p.77)

悪用のための工夫

しかしながら、この脆弱性の悪用は困難です。まず、悪用にはハッシュ値の衝突が必要となりますが、攻撃者は衝突を起こすことができる入力値をあらかじめ知っているわけではありません。そのため、オンラインで全てのパターンを試すことになります。次に、悪用には既知のユーザがログオンに成功し、トークンがキャッシュされていないければなりません。使用されていないキャッシュは Cache Scavenger によって15分で削除されるので、悪用可能な時間枠はトークンがキャッシュされている間、つまり通常は15分未満となります。

ツァイ氏は、悪用を阻むこのような条件を軽減あるいは回避できる方法を発見しました。これらを順を追って説明いたします。

衝突確率の向上

キーのハッシュ値は32ビット整数のため、衝突を起こさせるには最高で約42億回の試行を要します。ツァイ氏は、ハッシュ値をよりランダムにするために擬似乱数生成法の一つである線形合同法 (LCGs) が使用されていることに着目しました。32ビット整数のキー空間では線形合同法によるランダム化は1対1の対応にならないため、事前の計算によって不要なパスワードを除いた辞書を用意することで、成功確率を少なくとも13%向上できた、とツァイ氏は述べています。(講演資料 の p.83 および p.84)

ユーザインタラクション無しでの悪用

Connect as 機能とは、Web サイトへアクセスするための資格情報を指定できる Microsoft IIS のオプションです。ツァイ氏によれば、Web ホスティングなどでよく使われているとされており、IIS が新たなプロセスを生成する際に指定したユーザで自動的にログオンするとされています。ツァイ氏はこの機能を利用することで、ユーザインタラクション無しに認証の試行が可能であると説明しています。(講演資料 p.85)

Cache Scavenger によるキャッシュ削除の迂回

前述のように、Cache Scavenger は使用されていないキャッシュを15分で削除します。もし、あるアクセスが資格情報を使用しており、各アクセスの時間間隔が15分未満であれば、トークンは永続的にキャッシュされることになります。

Microsoft Exchange Server のアクティブモニタリングサービスは、デフォルトで有効なサービスであり、全てのサービスのヘルスチェックを実行します。ツァイ氏は Outlook Web Access や ActiveSync へのチェックが「資格情報あり」で「10分毎」に行われることを発見しました。(講演資料 p.90 〜 p.93)

このように、一見悪用の難しいと思われる脆弱性でも工夫を積み重ねることである程度の実用性を得てしまうことが分かるかと思います。

対策

修正プログラム

Microsoft IIS に認証を迂回される問題 (CVE-2022-30209 ) は、ツァイ氏によって発見された他の 2 件の脆弱性と共に、2022年7月のセキュリティ更新プログラムで修正されています。

更新履歴

• 2023年02月01日

  • 新規公開

参照

1. Orange Tsai, "Let's Dance in the Cache - Destabilizing Hash Table on Microsoft IIS!," Orange Blog, Aug 18, 2022.
2. Orange Tsai, "[CB22]Let's Dance in the Cache - Destabilizing Hash Table on Microsoft IIS!," CODE BLUE, Jan. 01, 2023
3. Orange Tsai, "[cb22] Lets Dance in the Cache Destabilizing Hash Table on Microsoft IIS by Orange Tsai," SlideShare, Jan. 01, 2023
4. Orange Tsai, "Let's Dance in the Cache: Destabilizing Hash Table on Microsoft IIS," Black Hat, Aug, 2022.
5. "Windows IIS Server の特権の昇格の脆弱性 | CVE-2022-30209," Microsoft Security Update Guide, Jul 12, 2022.