This post is also available in: English (英語)
概要
先日、脆弱性CVE-2020-17049 (別名: Bronze Bit)をMicrosoftが公開しました。Key Distribution Center (KDC)がサービスチケットを処理し委任が許可されているかを検証する過程で発生する脆弱性です。「NetSPI Blog CVE-2020-17049: Kerberos Bronze Bit Attack」で解説されているように、この攻撃ではKerberosサービスチケットを改ざんすることで、機密アカウントや「Protected Users」グループのメンバーを含む任意のユーザーを装った認証をターゲットに対して行えます。
Microsoftはこの脆弱性の更新プログラムを公開しており、今後のWindows Updateで段階的に展開される見込みです。 Microsoftは2021年5月11日とそれ以降でのみ本修正の強制を目指しています。一方で、更新プログラムが存在しても、すぐにはサーバーに適用できない組織が少なくありません。特に、組織インフラに不可欠なActive Directory Domain Controllerサーバーへの適用には時間がかかるでしょう。
本記事では脆弱性の詳細と、Cortex XDRを利用した攻撃の監視と検出についてご説明します。
Kerberos委任
Kerberos委任の一般的な使用例は、Webサーバーでデータベースサーバーからユーザーのデータを取得する場合です。データベースサーバーは、ユーザーデータへのアクセス権をユーザーにのみ付与できます。この場合、Webサーバーはユーザーを偽装する必要があります。この偽装をKerberos委任と言います。
Kerberos委任の方式は3種類知られています:
制約なし委任: ユーザーが、制約なし委任を許可されているサービスに対して認証を行う場合、KDCがチケット発行サービス(TGS)にユーザーのチケット認証チケット(TGT)を追加し、サービスがTGTを抽出できるようにします。サービスアカウントはこのTGTを使用してユーザーの代理でTGSチケットを取得します。この場合、Protected Usersグループに含まれていないユーザーや、「アカウントは機密性が高く、委任できません」に設定されていないユーザーは、このタイプの委任を保持するサービスアカウントになりすますことができ、サービスアカウントは任意のリソースに対するTGSを取得できます。
制約なし委任は重大なセキュリティリスクを招きます。なぜなら、サービスへの認証を行った各ユーザーのTGTをメモリに保持するためです。攻撃者がこの種のサービスアカウントを侵害すれば、ユーザーのTGTを抽出してドメイン上の任意のリソースに対する認証を行えます。
制約付き委任: セキュリティを強化し、委任サービスがアクセス可能なリソースを厳格に制御するため、Microsoftは制約付き委任を導入しました。この情報はActive Directoryの属性「msDS-AllowedToDelegateTo」に含まれます。さらに、メモリ上へのユーザーのTGTの保持を避けるため、MicrosoftはKerberosの拡張機能を実装しました。この拡張機能はS4U (Service for User)と呼ばれ、S4U2SelfとS4U2Proxyから構成されます。S4U2Selfを利用すると、サービスが自分自身へのチケットをユーザーの代理で要求できます。このチケットでは転送可能ビットがONになります。その後、別のサービスの認証を行う場合は拡張機能S4U2Proxyを利用します。この拡張機能を利用すると、「msDS-AllowedToDelegateTo」で指定されたサービスへのチケットをユーザーの代理でTGSに要求できます。
リソースに基づく制約付き委任: 3つ目の委任方式は上の2つとは異なり、代理を務めるサービスではなくリソース側でセキュリティ制御を定義します。このアクセス制御情報は属性「msDS-AllowedToActOnBehalfOfOtherIdentity」で確認できます。
今回確認された脆弱性
上述の通り、委任を許可されるユーザーはProtected Usersグループに含まれず、機密アカウントに指定されていないユーザーだけです。これらのユーザーについては、TGS要求で転送可能ビットがONになっていても、転送可能ビットがOFFのチケットをKDCが返します。CVE-2020-17049はKerberosの設計上の欠陥から生じた脆弱性です。ユーザーの権限は特権属性証明書(PAC)で検証しますが、KDCオプションフラグの改ざんを判定する整合性チェックのしくみがありません。KDCオプションフラグを保護しているのはサービスチケットのパスワードハッシュだけです。そのため攻撃者はサービスハッシュを侵害すれば、チケットを復号して転送可能ビットを反転させ再暗号化することが可能です。
振る舞いをもとに活動を監視
Kerberosトランザクションの冒頭は標準的な内容で、TGS応答も暗号化されているため、監視できるのは転送可能ビット反転後の活動だけです。それでも、Cortex XDRにはCortex XDRエージェント、弊社NGFW、Active Directoryから取得したデータを相関付ける機能があるため、非常にきめ細かい監視が可能です。攻撃者はチケットを改ざんして転送可能ビットを反転させる必要があるため、Kerberosセッションはlsass.exeではなく攻撃者のプロセスから始まります。
![図2: Cortex XDRの Network Connections タブ。ACTION_TYPEが[Authentication(認証)]の接続が1つ表示されている。](https://www.paloaltonetworks.com/blog/wp-content/uploads/2021/03/word-image-48.png)
以下のハンティングクエリを使用して該当するプロセスを検索できます:
|
1 |
dataset = xdr_data|filter event_type = STORY and os_actor_process_image_name != "lsass.exe" and os_actor_process_os_pid != 4 and arraystring(action_app_id_transitions, ",") contains "kerberos"| fields os_actor_process_image_path, os_actor_process_image_command_line, action_remote_ip, dst_action_external_hostname, action_app_id_transitions|dedup os_actor_process_image_path, os_actor_process_image_command_line, action_remote_ip, dst_action_external_hostname, action_app_id_transitions |
次に、ネットワーク上で伝送されるKerberosデータを見ると、転送可能フラグと制約付き委任フラグに注目することで、S4U2Proxy要求を発見できます。
この場合、KerberosのフラグとActive Directoryのデータを取得できるので、当該ユーザーが委任不可の機密ユーザーかどうかや、Protected Usersグループに含まれるかどうかを確認できます。
2番目のシナリオでは、リソースに基づく制約付き委任の回避を攻撃者が試みる場合があります。攻撃者は委任が許可されていないマシンしか利用できないためです。
このシナリオでは、攻撃者が既知のパスワードを用いてマシンアカウントを作成し、標的サービスの信頼済みプリンシパルに追加します。この際、新規作成したマシンアカウントのTGTを要求し、アカウントを委任サービスとして利用します。このケースについては、Cortexエージェントと弊社NGFWの相関付け機能を利用することで、TGTのマシンアカウントが実際のコンピュータ名と異なることを検出できます。
最後に、攻撃者は要求元ユーザーのTGSをKerberosキャッシュに受け取り、完全な動作を実現します。Kerberosチケットキャッシュ改ざんの事例では、悪意あるプロセスは「LsaCallAuthenticationPackage」という名称で「KerbSubmitTicketMessage」という名前のフラグ メッセージ タイプを伴います。「LsaCallAuthenticationPackage」はRPCベースの関数であり、lsass.exe上でRPCサーバーハンドラをトリガーします。この関数は「AuthenticationPackage」パラメータと「ProtocolSubmitBuffer」パラメータに基づいて多様なリクエストを処理し、各リクエストを適切なハンドラにルーティングします。
この活動に関しては、Cortex XDRに搭載されたRPC追跡機能によってシステム上に生成された関連イベントを追跡し、RPCオペレーションの要求元プロセスを特定できます。また、サーバーに送信されたフラグ メッセージ タイプを監視することでチケットインジェクションを検出できます。このフラグ メッセージ タイプは「ProtocolSubmitBuffer」パラメータの一部であり、lsass.exeが「NtReadVirtuaMemory」関数を呼び出してインジェクタプロセスから読み取ります。
Cortex XDRはRPC関数のコンテキストとインジェクタからコピーしたフラグ メッセージ タイプを相関付けることが可能です。この高度な相関付け機能を利用することで、この攻撃とKerberosチケットインジェクションをエージェントがブロックできます。
Cortex XDRのアラート
この活動に対してCortex XDRは複数のアラートを発します。まずは、静的分析です。WildFireとBehavioral Threat Protectionにより、この手口を実行するMimikatzなどのツールにアラートを発報します。
攻撃の後段では、非標準プロセスに含まれる一般的でないKerberos実装と、一般的でないソースによるマシンアカウントの利用をAnalytics BIOCによってアラートします。
これらの検出技術に続いて、Bronze Bit脆弱性そのものに特化したCortex XDR Analytics BIOCをトリガーします。
最後に、攻撃者がパス ザ チケット(PTT)攻撃を実行して新しい資格情報を悪用した場合は、PTT活動に対するBehavioral Threat ProtectionをCortex XDRがトリガーします。
| ソース | 説明 |
| XDR Analytics BIOC | 非標準プロセスからのKerberosトラフィック |
| XDR Analytics BIOC | 侵害を受けた可能性があるマシンアカウント |
| XDR Analytics BIOC | Bronze Bitエクスプロイト |
| XDRエージェント | 振る舞いベースの脅威を検出
(Kerberosチケットのインジェクション) |
| XDRエージェント | 疑わしい実行ファイルを検出 |
| XDRエージェント | 振る舞いベースの脅威を検出 |
| XDRエージェント | WildFireマルウェア |
結論
CVE-2020-17049脆弱性の原因は、Kerberosの転送可能フラグのちょっとした改ざんです。しかし、Kerberosの応答は暗号化されているため、全ユーザーのシークレットを保護しなければ改ざんは検出できません。Cortex XDRであれば、複数のデータソースを相関付けて様々な攻撃ステップで悪意ある活動を検出する能力を活用することで、この振る舞いを検出できます。
Unit 42によるBronze Bit脅威の概要はこちら。