SPN通信 2022年5月26日

修正されたDNSHostName偽装による権限昇格問題


みなさん、こんにちは。 SPNの塩月です。

今回お話する「DNSHostName偽装による権限昇格問題」[1]は今月のWindows更新プログラムによって修正された脆弱性の一つ(CVE-2022-26923)[2]で、Active Directory(AD)環境下においてコンピュータアカウントの不正なデジタル証明書を発行させることにより標準ユーザがドメイン管理者権限を奪うことができるというものです。

ドメイン内にAD証明書サービス(AD CS)が存在している環境ではAD CSからユーザアカウントやコンピュータアカウントの証明書を発行してもらい、その証明書を利用してドメインコントローラへ当該ユーザやコンピュータを認証するということが行われます。その際に通常、ユーザアカウントの場合にはuserPrincipalName属性(ユーザのメールアドレス)が、コンピュータアカウントの場合にはdNSHostName属性(コンピュータのFQDN)が、それぞれ証明書の発行先の情報として使用され、ドメインコントローラに対する認証時にはその発行先情報に基づいてアカウントがマッピングされます。

例えば「HOGE」というコンピュータがドメイン「lab.local」にあったとしましょう。このコンピュータのアカウント名(sAMAccountName属性)は「HOGE$」で、dNSHostName属性には「HOGE.lab.local」という名前が登録されており、発行された証明書の名称は「HOGE.lab.local」となります。証明書による認証時にはこの名前のホスト名部分の最後に「$」を付け、その名前をsAMAccountName属性に持つコンピュータアカウントつまり「HOGE$」として認証が行われます。

このようにコンピュータアカウントのdNSHostName属性は証明書によるコンピュータの認証において重要な役割を果たしますが、一方でdNSHostName属性は、そのコンピュータをドメインへ追加したユーザであれば一定の条件下で他の値に変更することができ、しかもそれが他のコンピュータと重複していても構わないという問題がありました。一般的な攻撃シナリオは次の通りです。

攻撃者はまず標準ユーザ権限で架空のコンピュータアカウント「HOGE」をドメイン内に作成し、そのアカウントのdNSHostName属性の内容をドメインコントローラのFQDN(例えばDC01.lab.local)に変更します。ちなみにコンピュータアカウントの作成は標準ユーザでも10台までなら可能です(デフォルト設定)。次にアカウント作成時に設定したパスワードを用いてそのコンピュータHOGEの証明書をAD CSへ要求します。AD CSは要求に応じてHOGEの証明書を発行しますが、dNSHostName属性がDC01.lab.localになっているので、証明書の発行先名称はDC01.lab.localになり、その証明書で認証するとDC01$すなわちドメインコントローラのコンピュータアカウントでログオンできてしまうわけです。

  コンピュータHOGEを作成        ・・・ dNSHostName → HOGE.lab.local
    ↓
  dNSHostNameをDC01のものに変更 ・・・ dNSHostName → DC01.lab.local
    ↓
  HOGEの証明書を取得            ・・・ 証明書の発行先 → DC01.lab.local
    ↓
  この証明書で認証              ・・・ コンピュータアカウントDC01$でログオン

本脆弱性を利用した攻撃は比較的容易に行うことができ、攻撃用のPythonツール[3]も公開されているため危険性は極めて高いと言えるでしょう。マイクロソフトは5月の更新プログラムでこの脆弱性および関連する別の脆弱性(CVE-2022-26931)[4]の修正を行い、dNSHostName属性の変更に制約を加えると共に、AD CSが発行する証明書の中にアカウントのSIDを挿入することで認証時に証明書とアカウントとのマッピングのチェックが厳密に行えるように改善しました。ただしデフォルトで一年間は証明書の互換性のために互換モードでの運用となり、マッピングチェックで問題が検出されたとしてもイベントログに記録して認証自体は通過させてしまいます。詳細については参考資料[5]をご覧ください。

実は今回の脆弱性は今年1月のSPN通信で取り上げた「SAMAccountName偽装による権限昇格問題」とよく似ており、いずれもアカウントと他の認証データ(前回の場合はTGT、今回は証明書)とのマッピングに問題があったため発生したものでした。脆弱性の報告者も今回の脆弱性についてはSAMAccountName偽装の攻撃手法からインスパイアされたと述べています。ADあるいはAD CSの長い歴史の中でこのようなシンプルな脆弱性が今まで見逃されてきたことはびっくりですが、他に同様の脆弱性がまだ潜んでいる可能性も否定できません。今後しばらくはAD認証関連の脆弱性から目が離せないですね。

それではみなさん、またお会いしましょう。

[1] Certifried: Active Directory Domain Privilege Escalation (CVE-2022-26923)
[2] CVE-2022-26923 - Active Directory Domain Services Elevation of Privilege Vulnerability
[3] Certipy
[4] CVE-2022-26931 - Windows Kerberos Elevation of Privilege Vulnerability
[5] KB5014754 - Certificate-based authentication changes on Windows domain controllers
[6] Detecting DnsHostName Spoofing with Microsoft Defender for Identity

合同会社セキュリティ・プロフェッショナルズ・ネットワーク
代表社員 塩月誠人