2019.09.02

Black Hat USA2019　SMB・NTLM解説編

イベント

Black Hat USA2019およびDEFCON27に参加してきました。Black HatやDEFCONの説明はこちらをご覧ください。筆者は業務でTLPT支援やペネトレーションテストを担当しているため、業務に関連するセッションを中心に聴講しました。その中で、興味深いセッションがあったのでご紹介したいと思います。

Marina Simakov氏、Yaron Zinar氏によるFinding a Needle in an Encrypted Haystack: Leveraging Cryptographic Abilities to Detect the Most Prevalent Attacks on Active Directoryでは、NTLM Relay(中間者攻撃)の既知の手法(CVE-2015-0005)および新しい手法(CVE-2019-1019)などについて紹介されていました。NTLM認証については以前のブログで触れておりますが、改めてご紹介したいと思います。NTLMに関しては以下のドキュメントを参考に記載します。

NT LAN Manager (NTLM) Authentication Protocol

Netlogon Remote Protocol

では、NTLM認証が具体的にどのように利用されているのかクライアントがファイルサーバへSMBでアクセスした際のやりとりを例にご紹介したいと思います。SMBはServer Message Blockの略で、ファイル共有などで利用されているプロトコルです。SMBは複数のバージョン(SMBv1、SMBv2、SMBv3)とありますが、本ブログでは以下のドキュメントを参考に記載します。

Server Message Block (SMB) Protocol Versions 2 and 3

SMBはよく利用されているプロトコルの1つだと思います。ただ、どのような通信が行われているのかあまり分からないなという方向けにご紹介したいところですが、上記仕様は455ページあり、筆者もすべてを把握できていません。今回のブログではカンファレンスの中で触れられていたSMB Relayに関連する箇所のみとなりますが、簡単にご紹介したいと思います。SMBはメッセージ(SMB2 NEGOTIATEやSMB2 SESSION_SETUPなど)によりパケットのボディや動作を制御します。それぞれのメッセージにはRequestとResponseが存在します。

アクション	メッセージ
プロトコル開始	SMB2 NEGOTIATE
認証	SMB2 SESSION_SETUP, SMB2 LOGOFF
シェアアクセス	SMB2 TREE_CONNECT, SMB2 TREE_DISCONNECT
ファイルアクセス	SMB2 CREATE, SMB2 CLOSE, SMB2 READ, SMB2 WRITE, SMB2 LOCK, SMB2 IOCTL, SMB2 QUERY_INFO, SMB2 SET_INFO, SMB2 FLUSH, SMB2 CANCEL
ディレクトリアクセス	SMB2 QUERY_DIRECTORY, SMB2 CHANGE_NOTIFY
ボリュームアクセス	SMB2 QUERY_INFO, SMB2 SET_INFO
OpLoCkによるキャッシュ制御	SMB2 OPLOCK_BREAK
エコー	SMB2 ECHO

クライアントがサーバの共有フォルダへアクセスする場合、以下のやりとりが行われます。

SMB2 NEGOTIATE
クライアントがサーバに対して利用バージョンなどを通知します。
SMB2 SESSION_SETUP
新規またはすでに存在しているSMB2プロトコルのコネクションで新しい認証されたセッションをリクエストします。以前のブログでもご紹介しておりますが、NTLMv2認証の場合、クライアントからサーバへサポートしているNTLMのオプションなどの情報をNTLM_NEGOTIATEとして送付します(SMB2 SESSION_SETUP Request1)。その後、サーバからServer Challengeを含む情報をクライアントへNTLM_CHALLENGE_MESSAGEとして送付します(SMB2 SESSION_SETUP Response1)。クライアントはサーバから送付されたServer Challengeおよびクライアントで生成したClient Challenge、パスワードのNTLM Hashなどから算出された結果をNTLM_AUTHENTICATEとして送付します(SMB2 SESSION_SETUP Request2)。サーバでも同様の手法で算出し、一致するか確認することで認証を行います。認証の結果をSMB2 SESSION_SETUP Response2で送付します。後述しますが、ドメイン内のリソースへのアクセス時、サーバでは認証情報は保持していないため、ドメインコントローラへNetlogon Remote Protocolを用いた問い合わせが発生します。
SMB2 TREE_CONNECT
クライアントがサーバの特定の共有にアクセスする際に送信されます。

NTLM認証は、SMB2 SESSION_SETUPで利用され、認証が成功した場合に後続の処理が実行できるようになります。では、セッションの話に戻りますが、SMBやNTLMにおいて中間者攻撃を行おうとした場合どうなるのでしょうか。SMBでは、SMB署名(SMB Signing)という中間者攻撃を防ぐための仕組みがあります。メッセージ長やメッセージをSigning keyで署名することで実際の送信者とパケット内の送信者の違いから中間者攻撃や改ざんを検知することができます。Signing keyは、送信者のパスワードを基に生成されます。SMBのバージョンによっても署名に用いられる方法は異なっており、3.Xではメッセージに対してAES-128-CMACを用いて16byteのhashを算出します。2.1または2.0.2では、HMAC-SHA256を用いて32byteのhashを算出し前半の16byteを用います。

では、SMB署名が有効な場合と無効な場合で、中間者攻撃(SMB Relay)がどのようになるのか試してみたいと思います。構成は以下となっています。

SMB署名が無効な場合、下記(攻撃者で実行しているツールの出力結果)の通り中間者攻撃が成功します。

[*] Servers started, waiting for connections
[*] SMBD: Received connection from 192.168.11.132, attacking target 192.168.11.167
[*] Authenticating against 192.168.11.167 as SCAN\Administrator SUCCEED
[*] Administrator::SCAN:7ee******************************************c2b1:01010*****************************************************************************************100390032002e003100360038002e00310031002e00310033003500000000000000000000000000
[*] Sending status code STATUS_SUCCESS after authentication to 192.168.11.132
[*] Requesting shares on 192.168.11.167.....
[*] Found writable share ADMIN$
～省略～

SMB署名が有効な場合、下記(攻撃者で実行しているツールの出力結果)の通り中間者攻撃が失敗します。

[*] Servers started, waiting for connections
[*] SMBD: Received connection from 192.168.11.132, attacking target 192.168.11.167
[-] Signature is REQUIRED on the other end, attack will not work
[*] Authenticating against 192.168.11.167 as SCAN\Administrator SUCCEED
[*] Administrator::SCAN:3eb******************************************4cb:01010*****************************************************************************************100390032002e003100360038002e00310031002e00310033003500000000000000000000000000
[*] Sending status code STATUS_SUCCESS after authentication to 192.168.11.132
[*] Requesting shares on 192.168.11.167.....
[-] Error requesting shares on 192.168.11.167, aborting.....
[-] Error performing the installation, cleaning up: SMB SessionError: STATUS_ACCESS_DENIED({Access Denied} A process has requested access to an object but has not been granted those access rights.)

SMB署名の設定は、クライアントおよびサーバで有効な場合に利用するパターンと常に利用するパターンの2通りあります。後者の場合、特定の製品によってSMB署名に対応していない場合、アクセスできなくなる可能性があります。SMB署名を常に利用する設定にする場合は、ご利用の製品ベンダーの対応状況についてもご確認いただく必要があります。また、SMB署名を有効にすることでスループットにも影響が出てしまう可能性があります(https://docs.microsoft.com/ja-jp/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always)。

次にNTLM Relayについて見ていきたいと思います。カンファレンスでは既知の手法としてCVE-2015-0005が取り上げられていました。CVE-2015-0005は、NETLOGONサービスでドメインコントローラはターゲットサーバを検証しないため、攻撃者がセキュア通信のエンドポイントにあたるコンピュータ名を詐称することでNTLMの中間者攻撃が可能となる脆弱性です。CVE-2015-0005は、MS15-027で修正されています。

NETLOGONサービスは、クライアントがあるドメインに参加するファイルサーバなどへアクセスした場合に、当該サーバからドメインコントローラに対する認証をつかさどるサービスで、サーバとドメインコントローラ間の通信はサーバのコンピュータアカウントのパスワードで暗号化されています。クライアントからの認証要求に対して、サーバがドメインコントローラへ問い合わせを行い、その認証結果が暗号化された通信を介して、サーバへ通知されます。この認証方式はパススルー認証と呼ばれています。

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/70697480-f285-4836-9ca7-7bb52f18c6af より引用

パススルー認証が成功した場合、ドメインコントローラはUserSessionKey(https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/5e550938-91d4-459f-b67d-75d70009e3f3におけるSessionBaseKey)をサーバに返します。UserSessionKeyは、SMB署名を行うための秘密鍵の生成にも利用されます。CVE-2015-0005では、攻撃者がサーバのコンピュータアカウントのパスワードを事前に取得し、何らかの方法でクライアントが攻撃者サーバへアクセスさせることで、ドメインコントローラは、認証要求してきたコンピュータ名の検証を行わないため、中間者攻撃が可能となります。SMB署名の生成に利用されるUserSessionKeyを攻撃者に取得されてしまうため、SMB Relayで記載したSMB署名は対策にならず、MS15-027を適用する必要があります。

では、新たに発見された脆弱性について解説したいと思います。CVE-2015-0005では、認証を要求したコンピュータ名の検証ができていないことに起因しましたが、今回の発表で紹介されたCVE-2019-1019は、NTLM_AUTHENTICATEで本来送信すべきコンピュータ名のデータそのものを送信せず欠損させることでコンピュータ名の検証が行われず中間者攻撃が可能となります。ただ、NTLM_AUTHENTICATEにはMIC(Message Integrity Check：メッセージの整合性チェック)があり、NTLM_NEGOTIATE、NTLM_CHALLENGE_MESSAGE、NTLM_AUTHENTICATEの整合性をチェックするためのデータがセットされています。このMICはUserSessionKeyおよび事前の中間者攻撃で取得したNTLM_NEGOTIATE、NTLM_CHALLENGE_MESSAGE、NTLM_AUTHENTICATEから算出することが可能であるため、整合性のチェックもbypass可能となります。CVE-2019-1019の対策は、各OSに必要となるセキュリティパッチを適用する必要があります(https://portal.msrc.microsoft.com/ja-jp/security-guidance/advisory/CVE-2019-1019)。

上述の通り、MICは整合性をチェックするために利用されるデータですが、改ざん検知にも利用されており、カンファレンスではMICの整合性チェックのbypass方法についても紹介されていました。手法は、CVE-2019-1019と同様でMIC自体を送信しないことです。その結果、整合性のチェックや改ざんの検知をbypassすることが可能です。また、MICを送付するかどうかは、クライアントがセットするフラグ(MsvAvFlags)で制御されています。デフォルトで送付する(セットされる値は0x00000002)ようになっていますが、サーバはフラグが送付するようになっていたとしてもMICが送付されなかった場合の検証が行われていません。対策ですが、セキュリティパッチが提供されており、各OSに必要なものを適用する必要があります(https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1040)。

SMBやNTLM、Netlogonなど普段どういった通信が発生しているかあまり意識されることも少ないかと思いますが、とても複雑かつ緻密な通信が行われていることがお伝え出来たのではないかと思います。筆者も今回のカンファレンスを通じて、プロトコルに対する知識を勉強する機会となり、非常に有用であったと感じています。今回ご紹介できなかった他のカンファレンスなどについては、機会があれば別のタイミングで改めてご紹介したいと思います。では、今回アメリカに滞在中、テキーラを飲めなかったので、飲みに行ってきます、テキーラを。