要約
- Flame の偽造証明書は、Microsoft のルート秘密鍵を奪わずに Microsoft ルートへ連鎖した。Terminal Server ライセンス基盤の予測可能な発行項目と MD5 選択プレフィックス衝突により、CA が正規証明書へ与えた署名が、現代の Windows でコード署名を妨げる critical 拡張を除いた別証明書でも検証できた。
- 復旧は一枚の証明書の失効では終わらなかった。Microsoft は新旧のライセンス CA 階層全体を不信頼化し、後継を通常の Windows クライアントが信頼しない独立ルートへ移し、コード署名を廃止し、ライセンス専用 EKU を付与し、更新経路と不信頼リスト配布を同時に強化した。
正しい署名が不十分な問いに答えた
2012年6月、Flame の一部ファイルは署名されていなかったのではない。Windows が Microsoft のルートまで辿れる署名を持っていた。
署名検証は、ある鍵がこのダイジェストへ署名し、その鍵がローカルに受理された証明書経路に属するかを答える。しかし、Remote Desktop のライセンスを処理する階層が、Windows Update を名乗る権限まで持つべきかは別の問いである。
Microsoft Security Advisory 2718704は、Microsoft の認証局から派生した無許可証明書が実際の攻撃で使われていると公表した。調査先は Terminal Server Licensing Service だった。企業の Remote Desktop 利用を認証するサービスが古い署名アルゴリズムを使い、コード署名能力を持つ証明書を発行していた。
問題は単に「MD5 が残っていた」ことではない。狭いライセンス業務が、幅広い判断に使われるルートへ到達できた。企業内で同じ所有者に属することが、異なる用途を技術的に委任する理由として扱われていた。
ルート信頼は一枚の万能許可証ではない。発行方針、Key Usage、Extended Key Usage、critical 拡張、アプリケーション規則、クライアントの不信頼状態を組み合わせて、はじめて一つの能力になる。ライセンス経路が更新パッケージを認可できるなら、証明書グラフは組織上の近さを越権へ変換している。
予測可能な発行が署名オラクルになった
ライセンス証明書の登録には Microsoft 内部 PKI へのアクセスが不要だった。署名はmd5RSAで、有効期間は既知、シリアル番号も高い確率で予測できた。選択プレフィックス衝突に必要な条件が発行手順の中に並んでいた。
攻撃者は、発行済み証明書を後から自由に書き換えたわけではない。二つの異なる前半を用意する。一方はライセンスサービスが署名する正常な証明書、もう一方は攻撃者が使いたい証明書である。計算した後半を付け、完成した二つの MD5 値を一致させる。CA は正常な方のダイジェストへ署名するが、その署名はもう一方でも成立する。
ライブの CA は秘密鍵演算を提供した。予測可能な日付と番号は、発行前の計算を可能にした。MD5 は異なる意味を一つのダイジェストへ畳み込んだ。広く信頼されたルートは、結果に実用的な価値を与えた。
通常の資産台帳では、アルゴリズム、テンプレート、登録窓口、ルートストアが別項目になる。Flame が示したのは、それらの積を監査する必要性である。低重要度に見える旧ライセンス機能でも、出力が受理境界を越えるなら高価値の署名者になる。
衝突耐性のあるアルゴリズム、予測できない発行項目、通常クライアントから切り離されたルート、実際に強制される用途制限のどれか一つでもあれば、攻撃経路は変わった。
衝突は秘密鍵の回収ではない
CWI の暗号研究者 Marc Stevens は、Flame が当時未公表だった選択プレフィックス衝突の変種を使ったと分析した。2009年に公開された方法の単純な再利用ではなかったが、先行研究は既に、正規の X.509 証明書と攻撃者の rogue CA 証明書が同じ MD5 値を持ち得ることを実証していた。
ここを曖昧にすると対策を誤る。資料は Microsoft のルート鍵や中間鍵が抽出されたとは述べていない。正規 CA は保護された鍵で通常どおり署名した。攻撃者が壊したのは、署名が一つのメッセージだけを選ぶという前提だった。
一方、「鍵が盗まれていないから軽い」とも言えない。鍵保管は署名系の一境界にすぎない。CA が攻撃者の影響を受ける構造へ衝突に弱いダイジェストで署名すれば、鍵を装置から出さずに権限だけを外へ運べる。
RFC 6151は2011年、デジタル署名のように衝突耐性が必要な用途で MD5 は受容できないと明記した。同時に HMAC-MD5 とは性質が異なると説明する。したがって「MD5 を発見した」という警告だけでは足りない。誰がメッセージを形作り、どの性質を期待し、衝突後のオブジェクトがどの権限を継承するかを問うべきだ。
証明書署名は、発行者の意思を一つの審査済み内容へ結び付ける。その内容が二つの異なる能力へ分岐できるなら、秘密鍵が安全でも意思の一意性は失われる。
critical 拡張がクライアント側の拒否を担った
Flame の証明書には、ライセンス証明書で想定される CRL Distribution Point、Authority Information Access、critical な Microsoft Hydra 拡張が見当たらなかった。解析では、古い Issuer Unique Identifier 領域の中に拡張らしい構造も見つかった。決定的なのは、通常の Hydra 制約が検証経路で効かなかったことだ。
X.509 の critical は重要度の形容詞ではない。理解できない critical 拡張を含む証明書を拒否せよ、という依存実装への命令である。RFC 5280はその失敗閉鎖を規定し、Key Usage と Extended Key Usage が同時に存在する場合の用途の交差も示す。
Windows Vista 以降は、Hydra に関係する拒否を実行した。通常のライセンス証明書のままでは Flame のコード署名目的に使えない。Microsoft によれば、攻撃者は critical 制約を含まない別証明書を作りながら、CA が署名した MD5 値を維持するために衝突を必要とした。Vista 以前では衝突なしでも攻撃可能だった。この差は Windows 世代固有であり、すべての X.509 ライブラリへ一般化できない。
テンプレートに拡張が書かれているだけでは制御にならない。署名対象の内側にあるか、critical が必要な箇所で指定されているか、重要クライアントが同じように処理するか、発行変種で省略できないかを検証する必要がある。Flame は規則を無視させたのではなく、規則のないオブジェクトを提示した。
証明書だけでは標的へ届かない
Microsoft は、Windows Update を偽装するには無許可証明書に加えて中間者の位置が必要だったと説明した。署名済みの攻撃パッケージを Automatic Update へ渡さなければならない。中央 Windows Update サーバーの侵害としては記録されていない。
証明書構築は見かけの出所を受理可能にした。ネットワーク位置は正規応答を攻撃者の応答へ置換した。更新エージェントの規則は、Microsoft 配下の署名を更新権限として扱うかを決めた。攻撃は一つの万能権限ではなく、三つの限定権限の組み合わせだった。
配信できなければ証明書は使われない。署名を拒否されれば中間者だけでは足りない。製品、バージョン、チャネル、明示された署名階層まで結び付ける追加規則があれば、別用途の企業証明書はなお拒否できる。
Microsoft が Windows Update、WSUS、関連管理基盤を強化した理由はここにある。必要なのは署名かネットワークかという二択ではない。チャネル専用鍵、正しい証明書用途、対象製品メタデータ、置換を防ぐ配信条件を同時に確認することだ。
「信頼しない」を各端末へ届ける
対応は観測された一枚に限定されなかった。2718704は三つのライセンス中間 CA を Untrusted Certificate Store へ移し、Microsoft の技術説明は過去と現在の Terminal Server ライセンス階層全体を無効にしたと述べる。未知の同系統証明書や模倣攻撃を残さないための広い措置だった。
ただし、不信頼化の発表は証明書のビットを変えない。新しい状態が各クライアントへ届き、チェーン検証時に拒否されて初めて権限が終わる。2012年6月には Windows Vista と Windows 7向けに Disallowed Certificate Trust List の自動更新も導入され、毎日新しい不信頼情報を確認できるようになった。それ以前は不信頼ストアへの移動に個別更新が必要だった。
信頼の俊敏性には撤去方向がある。新しいルートを追加する速さだけでなく、危険な能力をどこまで、何時間で、どの証拠を伴って停止できるかが重要だ。不信頼リストは負の制御面であり、通常の更新経路が疑われるときにも安全に届かなければならない。
Lu Heng の running-code 論は、事件の証拠ではなく明示した分析枠としてこの境界を説明する。制度上の決定は実装が実行して初めて現実になる。Microsoft が公表し、プラットフォームが配り、クライアントが最後の拒否を行う。
後継構造は鍵だけでなく能力を変えた
新しい Terminal Server ライセンス階層は Microsoft Root Authority へ連鎖しなくなった。通常の Windows クライアントが信頼しない独立ルートを使い、コード署名証明書の発行をやめ、コード署名に使えないライセンス専用 EKU を導入した。
アルゴリズム変更は署名の一意性を守る。独立ルートは再発時の影響半径を狭める。コード署名廃止は不要な能力を除く。EKU は業務目的を機械が強制する条件へ変える。旧階層の不信頼は残存経路を閉じる。更新チャネル強化は、企業内の任意署名が更新権限を暗黙に継承するのを防ぐ。
単なる証明書ローテーションなら、同じ権限グラフを新鍵で再生しかねない。完全な修復は、旧階層が何を決定できたか、正規業務に何が必要か、どの依存側が受理を終えるべきかを分解する。
正規業務にも分離費用が発生した
既存の Terminal Server CAL は無効にならなかった。しかし新しいライセンスサーバーを設置・再認証したり、新しい CAL パックを導入したりする管理者は、Product Activation Clearinghouse 側の証明書変更に伴ってサーバーを再認証する必要があった。
これは最小権限の現実的な費用である。古い業務を楽にするため権限を共有し続けると、悪用後の緊急分離を最悪の時点で行うことになる。事前台帳には、再認証対象、孤立ネットワーク、不信頼情報の配布経路、WSUS、旧クライアント、業務復旧手順が必要だ。
正規機能の継続と過剰権限の継続は同じではない。CAL を保ち、新証明書で管理を再開しながら、ライセンスサービスの一般コード署名権だけを戻さない設計は可能だった。
証拠の限界
一次資料は実際の悪用、ライセンス経路、衝突機構、Windows 世代差と対策を裏付けるが、被害台数の完全な集計や Flame 運用者の検証可能な帰属を示さない。
衝突は秘密鍵回収でも、任意の既存証明書の事後編集でもない。影響可能で予測可能なライブ発行を前提に準備した。Windows Update 偽装にはさらに中間者配信が必要だった。
後継階層は2012年に SHA-1 を使用した。その後の SHA-1 廃止は別の時間軸であり、今回の MD5 利用と同一視できない。RFC は一般的な技術文脈、Lu Heng の記述は開示した分析枠である。
確実な結論は限定的だが強い。証明書チェーンは実行可能な能力グラフであり、安全性は CA が署名できる範囲、オブジェクトの用途、アプリケーションの解釈、ローカルのルート選択、不信頼を配って実行する速度に依存する。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加