MS14-068で普通のユーザーが管理者になれた理由 ── KerberosのPACと署名検証

一般社員の佐藤さんは会社のアカウントでログオンできます。でも、管理者専用の共有フォルダーは開けません。本人だと分かったことと、管理者として扱ってよいことは別だからです。

MS14-068で崩れたのは、後者を判断するための情報の信頼性でした。

1. 概要

MS14-068は、一般のドメインユーザーが偽った権限情報をWindowsのKDCに受け入れさせ、ドメイン管理者権限へ昇格できる問題を修正したセキュリティ情報です。 脆弱性の番号はCVE-2014-6324。KDCは、ドメインコントローラー上でKerberosのチケットを発行する機能です。¹

表は当時のMicrosoftの告知に基づきます。日本のJPCERT/CCの注意喚起は翌19日です。以下では佐藤さん、認証を担当するDC、ファイルサーバーを例に、所属情報が権限へ変わる流れを追います。²³

2. 対象

当時の対象OSにはWindows Server 2003、2008、2008 R2、2012、2012 R2が含まれます。特に問題になるのはドメインコントローラー（DC）として動く機械です。各エディションとサービスパックは、MS14-068の対象製品表で確認できます。⁴

有効なドメイン資格情報を持ち、対象のKDCへ要求を送れることが攻撃の前提です。管理者の資格情報は要りませんが、匿名の外部利用者や、PCのローカルアカウントだけで攻撃できるわけではありません。⁵

flowchart TB
    accTitle: 一般ユーザーからドメインの権限発行機能へ届く
    accDescr: 一般のドメイン資格情報を持つ利用者がKDCへ要求を送り、その結果がドメイン内のサービス利用へ影響します。
    U["一般ドメインユーザー"] -->|"チケットを要求"| K["DC上のKDC"]
    K -->|"権限情報を含むチケット"| S["ドメイン内のサービス"]

図1: 入口は一般ユーザーでも、判断する相手はドメインの認証基盤です。⁶

当時確認された攻撃は2008 R2以前の経路を狙っていました。ただしMicrosoftは2012以降にも、悪用が難しい関連経路があると説明しています。「手元の検証コードが失敗したから2012は対象外」とは判断できません。一方、DCではないWindowsへの更新は多層防御のためで、この問題への直接の脆弱性とは区別されています。⁷

3. 詳細

チケットは、名前だけを運んでいるわけではない

佐藤さんがファイルサーバーへ接続する場合、まずKDCからTGTを受け取ります。TGTは、その後サービス用のチケットを求めるために使うチケットです。ファイルサーバーへ渡すのは、そのサーバー向けに発行されたサービスチケットになります。⁸

このチケットには、PAC（Privilege Attribute Certificate）という認可用のデータも入ります。そこには「誰か」だけでなく、「どのセキュリティグループに属するか」などが記録されます。プロキシ設定のPACファイルとは別物です。⁹

実際のPACでは、KERB_VALIDATION_INFOのUserIdやGroupIdsなどが、その情報を保持します。人間向けの表にすると、例えば次のような違いです。これは構造を説明するための要約で、実際のPACのバイト列ではありません。¹⁰

Windowsは、受け取ったPACの情報を利用者のログオントークンへ反映します。トークンはユーザーやグループのSID、特権などを持つ、アクセス判断のためのオブジェクトです。サーバーが「管理者グループに許可する」と設定していれば、トークンにどのグループが入ったかが、開けるかどうかを変えます。¹¹

flowchart TB
    accTitle: PACのグループ情報がアクセス判断へ使われる
    accDescr: サービスチケットのPACからログオントークンへ利用者とグループの情報が反映され、サーバーのアクセス許可と照合されます。
    P["チケット内のPAC"] --> T["利用者のログオントークン"]
    T --> G["グループなどの情報"]
    G --> A["対象のアクセス許可と照合"]

図2: チケットとトークンは同じものではありません。運ばれた情報がサーバー側の判断に使われます。¹²¹¹

所属欄を勝手に変えられないよう、鍵で保証する

利用者が自分で「管理者」と書けるだけなら、この仕組みは成立しません。そこでPACには署名を付け、内容が正当に作られたものかを検証します。PACの仕様で使う署名は、公開鍵の証明書ではなく、秘密の共有鍵を使ったチェックサム、つまり鍵付きの検査値です。¹³

この区別が今回の核心です。普通のハッシュ値なら、元データを知る人は自分でも計算できます。所属欄を書き換えた後、新しいハッシュ値も計算し直せば、データと検査値のつじつまは合います。それだけでは、権限ある発行者が作った証拠になりません。

鍵付きのメッセージ認証コード（MAC）は、内容に加えて共有する秘密鍵を使います。正しい検査値を作るには、内容だけでなく鍵が必要です。利用者が持つ自分のログオン資格情報と、KDCがPACを保証するための鍵は、役割が違います。¹⁴¹³

flowchart TB
    accTitle: 内容だけで計算できる値と秘密鍵が必要な値
    accDescr: 普通のハッシュは内容だけで再計算できますが、MACの生成には内容に加えて秘密鍵が必要です。
    D["内容"] --> H["ハッシュ値"]
    M["内容と秘密鍵"] --> C["MAC"]

図3: 改ざん後の内容と検査値が一致していても、秘密を持つ発行者が作ったとは限りません。¹⁴

検証器が、鍵の要らない方式も受け入れた

MS14-068では、このPACの署名検証に欠陥がありました。KDCは、攻撃者の作ったPACを正しいものとして扱い、そこに記載された高い権限を受け入れてしまいます。⁶

どんな検査値が問題だったかは、Rapid7が公開している検証コードからも確かめられます。MS14-068用の実装はPACのチェックサム種別にRSA_MD5を指定しています。その型のchecksum実装は、引数の鍵を使わず、データから通常のMD5値を返します。名前にRSAとあっても、この処理でRSA署名を作っているわけではありません。¹⁵¹⁶

つまり、攻撃者が「自分は管理者グループの一員だ」というPACを作り、それに自分で計算した検査値を付けることができました。本来なら鍵を知らない相手には作れない保証を要求すべき場所で、鍵なしでも作れる値を受け入れたのです。MD5の衝突を見つけたり、管理者のパスワードを解読したりする話ではありません。¹⁵¹⁶¹⁴

flowchart TB
    accTitle: 自分で作った権限情報がKDCの検証を通ってしまう
    accDescr: 攻撃者は偽のグループ情報と鍵なしで作れる検査値を用意でき、脆弱なKDCがそのPACを受け入れてしまいます。
    F["偽のグループ情報"] --> C["攻撃者が検査値も計算"]
    C --> V["脆弱なKDCのPAC検証"]
    V --> A["正当な情報として受け入れる"]

図4: 問題は計算の不一致ではなく、その方式を権限の証明として認めたことです。⁶¹⁶

暗号文を直すのではなく、KDCに受け入れさせる

ここで「TGTは暗号化されているのに、中の所属欄をどう変えるのか」という疑問が残ります。単に手持ちのTGTをテキスト編集する、という説明では不正確です。

公開された検証では、チケットの要求に偽のPACを含め、脆弱なKDCに処理させる経路を使います。Rapid7の実装説明も、TGS要求中のPAC検証を利用して、偽のPACを含むTGTを取得するものとしています。チケット全体の暗号化を破る代わりに、発行側が攻撃者の権限情報を信じてしまう点を利用します。¹⁷

その結果、佐藤さんは本人の資格情報を出発点にしながら、管理者グループを主張する情報で扱われ得ます。最初からADのグループ登録を変更する権限があったのではなく、PACを通じた権限の主張が通ってしまったのです。⁶

4. 影響

直接の結果は、一般ユーザーからドメイン管理者への権限昇格です。そこから、ドメインコントローラーを含むドメイン内のコンピューターの侵害へ進めます。単なる一台のアプリの権限判定ミスではありません。¹⁸

佐藤さんのPCで管理者パスワードを当てたわけでも、ファイルサーバーの暗号を破ったわけでもありません。サーバーが信頼している認証基盤に、偽の権限情報を承認させたため、被害が他の機械へ及びます。実際のアクセスは各資源の許可にも依存しますが、ドメイン管理権限まで得られることが問題の重大さです。¹¹¹⁸

flowchart TB
    accTitle: 一般ユーザーの侵害から認証基盤の侵害へ広がる
    accDescr: 一般のドメイン資格情報からPACの偽造が受け入れられ、ドメイン管理権限を得ると、DCや他のドメイン資源へ被害が広がり得ます。
    U["一般ドメイン資格情報"] --> P["偽のPACが受理される"]
    P --> D["ドメイン管理権限"]
    D --> R["DC・ドメイン資源の侵害"]

図5: 認証基盤の判断を共有する複数の機械が、同じ偽の情報を信用することになります。¹⁸

Microsoftは公開時点で限定的な標的型攻撃を把握していました。後に公開された検証コードだけから、当時すべての攻撃が同じ経路・同じ対象で行われたとは判断できません。²

5. 対策

すべてのDCで検証の欠陥を塞ぐ

2014年の修正はKB3011780です。Microsoftは、WindowsのKerberosで署名を検証する動作を修正したと説明しています。KDCが受け取ったPACを正しく検証することが対策の中心で、当時のセキュリティ情報に回避策は示されていません。¹⁹

更新の優先順位も、2008 R2以前のDC、2012以降のDC、その他のWindowsの順でした。よく使うDCだけ直して終わりにせず、認証を担うDCを把握して対応します。²⁰

これは2014年の更新の解説です。現在の環境を点検する際に、古いKBの番号が一覧にあるかだけを合否判定にせず、対象OS・役割・修正を含む更新状態を管理情報で確認する必要があります。古い攻撃コードが動かないことも、修正済みの証明にはなりません。

検知の手がかりと、分からないこと

Microsoftの当時の案内では、更新前の既知攻撃に、ログのSecurity IDとAccount Nameの不一致という手がかりがありました。ただし、その検知を回避する方法もあると明記されています。²¹

更新後のWindows Server 2008 R2以降では、監査が有効ならイベント4769の失敗コード0xfが調査の手がかりになります。別のまれな原因でも記録され得るため、1件だけで攻撃を断定しません。記録がない場合も、監査設定や保存期間を確認せずに「攻撃はなかった」とは言えません。²²

更新と侵害からの復旧は別の作業

既に管理権限を得た攻撃者は、別の侵入経路を残せます。パッチを適用しても、作られたアカウントや変更された設定まで元へ戻るわけではありません。Microsoftの2014年の説明も、ドメイン侵害後の高い確度での復旧には再構築が必要になるほどの問題だと警告しています。²³

flowchart TB
    accTitle: 脆弱性の修正と既に行われた変更の調査は別
    accDescr: 更新でPAC検証の欠陥を修正する作業と、侵害時に残されたアカウントや設定を調査して復旧する作業を分けます。
    P["修正更新を適用"] --> F["検証の欠陥を塞ぐ"]
    I["既存の侵害を調査"] --> R["残された変更から復旧"]

図6: 更新済みという事実だけでは、侵害前の状態へ戻った証拠にはなりません。²³

6. 教訓

この問題を「Kerberosの暗号が弱かった」とだけ覚えると、直すべき場所を取り違えます。鍵が必要な証明を要求する場面で、鍵なしでも作れる検査値を受け入れた。暗号ライブラリが計算できる方式と、その用途で許可してよい方式を分ける必要がありました。

自作の認可処理でも、入力の形式と検査値が合うだけでは足りません。誰がその値を作れるのか。その人に権限情報を決めさせてよいのか。 この二つを検証側で決める必要があります。一般社員として認証済みの相手にも、自分の所属を自由に宣言させてよいわけではありません。

本稿は公開資料と公開検証実装の読み取りによる解説です。未修正Windowsへの攻撃、チケットの生成・注入、実環境での再現は行っていません。佐藤さんとサーバーの構成は説明用です。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全6件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

関連記事

• Zerologonの認証突破とNetlogon
• PrintNightmareのドライバー導入とSYSTEM権限

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

MS14-068とCVE-2014-6324は何が違いますか？

MS14-068は2014年11月18日に公開されたMicrosoftのセキュリティ情報の番号で、CVE-2014-6324はそこで扱われたKerberosの脆弱性の識別子です。更新プログラムはKB3011780として案内されました。

攻撃にはドメイン管理者のパスワードが必要でしたか？

必要ありませんでした。一般の有効なドメイン資格情報が前提で、管理者の秘密を破る代わりに、偽ったPACをKDCに受け入れさせます。匿名の外部利用者やローカルアカウントだけで成立する、という意味ではありません。

PACには何が入っていますか？

Kerberosチケットで運ばれる認可用のデータで、ユーザーや所属グループの識別情報などを含みます。Windowsはその情報をログオントークンへ反映し、アクセス判断に使います。プロキシ設定のPACファイルとは別物です。

暗号化されたチケットを書き換える攻撃ですか？

単に既存のTGTの暗号文を編集する説明では不正確です。公開された検証では、チケット要求に含めた偽のPACの検証を通す経路が使われました。PACの署名検証とチケット全体の暗号化は、別の保護です。

更新後にイベント4769の0xfがなければ安全ですか？

その判断はできません。Microsoftの当時の案内には対象OS・更新・監査設定の条件があり、修正前の検知にも限界がありました。また0xfは別の理由でも記録され得ます。記録の有無だけで侵害を断定したり否定したりせず、更新状況と他の証拠を確認します。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。