本記事は英文記事をベースに実機検証なしで書き上げたものであり、内容が誤っている可能性があります。本記事を参考にしたことで問題が発生しても責任は取りませんのでご了承ください。
ドメインユーザーのID/Passwordだけでドメインコントローラーを乗っ取れる、衝撃の脆弱性が発見されました。
- 原文
- 日本語の解説記事
脆弱性の内容
今回の”PrivExchange”は、Exchange Serverの複数の脆弱性/設定を組み合わせて動作するものです。
1.EWSの”PushSubscription”を利用して、Exchange Serverに認証行為を開始させる
最初にExchange ServerのEWSを利用します。EWSの”PushSubscription”機能を利用すれば、Exchangeに対して任意のURLに対して認証を行わせることが可能です。この例では、Exchange Serverに命令して、攻撃者のPCに対してExchange Server権限で認証を試行させます。
※ EWSを利用するため、ExchangeユーザーのID/Passwordを利用します。
で、元記事の”Performing the attack without any credentials altogether”にあるのですが、ネットワークパケットをコントロールできる立場なら、ユーザーのID/Passwordを知らなくても、同一セグメントの一般ユーザーの認証パケットをExchange Serverに投げることで同じことが出来ます。
2.NTLM認証にハッシュが付与されていないため、中間者攻撃を行うことが可能である。
これはExchange Serverではなく、昔からWindows Server自体に存在する脆弱性となります。以下、2004年(15年前)の記事。
1.でExchangeに対して攻撃者のPCに認証を行わせるように仕向け、その認証をDomain Contorollerに転送することで、中間者攻撃が成立します。これにより、攻撃者のPC = Exchange Serverのコンピューターアカウントに成りすますことができます。
で、ここが記事を読んでもいまいちわからないのですが、おそらくDomain Controllerが受け付けられる認証方式ならなんでもいいようです。具体的には、ExchangeユーザーのID/Passwordを使って認証を成功させるパターンの場合、HTTPプロトコル経由でNTLM認証(マン・イン・ザ・ミドル)攻撃を行います。ネットワークパケットをコントロールするパターンの場合、SMBプロトコルを使って同じことをやります。
どちらも、マン・イン・ザ・ミドル攻撃を完了した後、Domain ControllerのLDAP認証に中継します。
3.Exchange Serverのコンピューターアカウントに、過剰な権限が割り振られている
脆弱性、というよりは仕様上の欠点ですが、Exchange Server(のコンピューターアカウント)はActiveDirectoryに対して非常に強い権限を持っていまづ。これにより、1と2の方法でExchange Serverのコンピューターアカウントを乗っ取り、Domain Controllerに対して認証を成功させることで、ActiveDirectoryに対して自由に操作が出来てしまう状況です。
アタック方法
Githubで公開されている簡単なスクリプトを利用すればいけそうです。
GitHub – dirkjanm/PrivExchange: Exchange your privileges for Domain Admin privs by abusing Exchange
影響をうける環境
この脆弱性を利用してADを乗っ取るには
- Exchange ユーザーのID/Passwordを知っている事
- Exchange Serverに対してEWSアクセスできるネットワーク環境にいること
- ActiveDirectoryに対してNTLMアクセス可能なネットワーク環境にいること
が必要です。また、
- NTLMv1が有効であること
が条件のように思われます(元記事の”The technical bits – relaying to LDAP and signing”によると、NTLMv2ならMICと呼ばれるハッシュ値を改ざんできず、マン・イン・ザ・ミドル攻撃が失敗する)
悪意のある社外ユーザーに攻撃されるか?
- Exchange ユーザーのID/Passwordを知っている事
- 通常は知りえないが、漏洩したID/Passwordを知られている可能性があるので、危険性あり
- Exchange Serverに対してEWSアクセスできるネットワーク環境にいること
- 外部からのEWSアクセスを許可している場合があるので、その場合は危険
- ActiveDirectoryに対してNTLMアクセス可能なネットワーク環境にいること
- ADを外部に公開しているケースは少ないと思われる。攻撃者がADに接続できなければセーフ。
ADにアクセスさえできなければ、ADを乗っ取られる可能性はないです。それでもExchange Serverへの攻撃は通ってしまいますが…。あるいは、EWSを外部公開していないとかだと安心です。
悪意ある社内ユーザーに攻撃されるか
一般的な社内ユーザーは上記条件を満たしているので、簡単に攻撃が出来ます。
対処法(案)とそれによる影響
マイクロソフト社から正式な修正パッチが出るまでは、解説記事で触れられている方法で対応するしかなさそうです。しかしながら、一部対応はマイクロソフト社非推奨の内容であり。実行にはリスクが伴うものもあります。
対処法1. EWSの機能を制限
EWSにさえアクセスできない/使えないならこの攻撃は成立しないので、EWSを無効化、あるいは以下のコマンドで、EWSのpushsubscriptionsを無効化することができます。
New-ThrottlingPolicy -Name NoEWSSubscription -ThrottlingPolicyScope Organization -EwsMaxSubscriptions 0 Restart-WebAppPool -Name MSExchangeServicesAppPool
本対処方法はマイクロソフトが推奨するものではなく、EWSの動作に必要な機能まで無効化される可能性があります。
対処法2. LDAP Channel bindingの有効化、SMB署名の有効化
LDAP Channel bindingの有効化またはSMB署名の有効化を行うと、それぞれのプロトコルで改竄が出来なくなるようです。
SMBを防いでもEWSに対してHTTPアクセスし、NTMLへのマン・イン・ザ・ミドル攻撃をすればLDAP認証までたどり着けるので、根本解決はLDAP Channel bindingかと思われます。
対処法3. Exchange Serverのコンピューターアカウントから、過剰に付与されている権限をはく奪
Githubに公開されているツールを利用して、Exchange Serverのコンピューターアカウントから、過剰に付与されている権限をはく奪することができます。
使い方は以下記事の中盤を参照
Import-Module ServerManager Add-WindowsFeature RSAT-AD-PowerShell Import-Module ActiveDirectory .\Fix-DomainObjectDACL.ps1
で、現状の危険な権限を列挙し
.\Fix-DomainObjectDACL.ps1 -Fix
で修正を行えます。
本対処方法はマイクロソフトが推奨するものではなく、Exchange Serverの動作に必要な権限まではく奪する可能性があります。
対処法4. NTLMv1プロトコルの無効化
元記事を読む限り”NTLMv1プロトコルの無効化すれば解決じゃね?”と思うのですが、元記事の解決策には書いておらず、NTLMv1の無効化が正しいかどうか不明です。
マイクロソフト社の動き
2019/1/31では公式声明はないですが、MSとつながりの深い海外のエンジニアいわく、マイクロソフトが解決のために動いているとのことですが、公式ソースは出ていません。
Serious Exchange Server vulnerability reported
But, before going any further – Microsoft is actively working to resolve the issue as quickly as possible, so expect to hear more from the Exchange team in the coming days.
