QUIC のシャットダウン：SMB over QUIC を実行している Windows サーバーの DoS 脆弱性
エグゼクティブサマリー
Akamai のリサーチャーである Ben Barnea が Microsoft Windows Server 2022 の重大な脆弱性を発見しました。この脆弱性は、 CVE-2023-24898 に指定され、ベーススコアは 7.5 です。
この脆弱性は、srvnet.sys ドライバーのバッファ割り当てのチェックが欠落していることに起因しています。
この脆弱性により、Windows Server 2022 マシンに対するリモートサービス妨害（DoS）攻撃が発生する可能性があります。この脆弱性は、不正な攻撃者によってインターネット経由でトリガーされる可能性があります。
脆弱性があるのは、比較的新しい機能である SMB over QUIC を使用するサーバーのみです。この機能を有効にするためには、サーバーが Windows Server 2022 Azure Edition である必要があります。
これらの脆弱性は、「責任ある開示」に従って Microsoft に報告され、 2023 年 5 月の Patch Tuesdayで修正されました。
Akamai は Insight クエリーを提供し、 Akamai Guardicore Segmentation ユーザーがネットワーク内の脆弱である可能性のあるサーバーを検知できるようにしています。
はじめに
QUIC は、Google が設計した比較的新しいトランスポート層プロトコルであり、いくつかの実装があります。QUIC は、レイテンシーやパケット損失など、一般的なインターネットの問題を克服しながら、接続の信頼性を高め、セキュリティを確保することを目的としています。QUIC は UDP で伝送されます。
Microsoft の QUIC の実装は MsQuicと呼ばれています。Windows にも QUIC が組み込まれ、SMB プロトコルのトランスポート層（ SMB over QUICという機能）として使用されているほか、IIS の HTTP/3 でも使用されています。SMB over QUIC は Windows Server 2022 Azure Editionでのみ使用できますが、HTTP/3 は Windows Server 2022 で実行されるすべての IIS 展開で使用できます。
このブログ記事で取り上げる脆弱性は、SMB のトランスポート層である srvnet.sysを実行するドライバーに存在します。
脆弱性
接続の状態を維持するために、QUIC は接続識別子を使用します。接続識別子は、クライアントとサーバー間の接続を一意に識別します。クライアントは複数の同時接続を作成できます。QUIC 接続も多重化されます。つまり、クライアントとサーバーは、同じ接続を介して同時に複数のストリームでデータを交換できます。
SMB over QUIC のコードは srvnet.sysに実装されています。サーバーがストリーム上で新しいデータを受信すると、関数 SrvNetQuicServerReceiveEvent が呼び出されます。この関数の目的は、クライアントから送信された完全な SMB メッセージを読み取ることです。これが正常に実行されると、メッセージが SMB メッセージのリストに転送され、処理が続行されます。
SMB メッセージを読み取るために、コードは最初に SMB メッセージサイズの読み取りを試みます。このサイズは 4 バイトの整数で表されます。正常に実行された場合、サイズが割り当ての 最大許容サイズ より大きくないことがチェックされます。チェックを通過すると、コードはこのサイズのバッファを割り当て、パケットの残りのバイトを新しく割り当てられたバッファに読み込もうとします。SMB メッセージ全体の読み取りが完了すると、新しい SMB メッセージが受信されたことが SMB レイヤーに示されます。
SMB メッセージの構造を図 1 に示します。
図 1：srvnet.sys 内の SMB メッセージ構造
この脆弱性は、SMB メッセージサイズの受信バイト数が 4 バイト未満の場合に発生します （図 2）。この場合、コードは受信した X バイトを保存し、 PendingMessageSize を 4 マイナス X に設定します（X は メッセージサイズの受信バイト数です）。次にパケットを受信すると、SMB メッセージサイズに必要な残りの 4 - X バイトが読み取られます。
図 2：悪性パケットのメッセージサイズは 4 バイト未満
メッセージサイズの読み取りが完了すると、コードは最大許容サイズと比較した メッセージサイズの検証を実行せずに、SMB メッセージを即座に割り当てます 。そのため、SMB メッセージのサイズを 1 つではなく 2 つのパケットで送信することで、攻撃者は最大許容サイズの検証を回避し、極めて大きな割り当てを要求できます。
悪用
このバグを DoS 脆弱性に変換するためには、上述の問題をトリガーするパケットを継続的に送信する必要があります。
ただし、最大許容サイズを回避することはできますが、次の 2 つの制限があります。
1. SrvNetAllocateBuffer の割り当てのハードリミットは 16 MB です。
2.許可される同時未認証接続の数は、サーバー上の使用可能な RAM に応じて制限されます。この制限により、悪用は最大 32 GB の RAM を搭載したサーバーに制限されます（この制限を回避する方法については次のセクションで説明します）。
この脆弱性を悪用するためには、最初に複数の接続を作成し、サーバーが 16 MB を割り当てるように、1 度に 2 つのパケットを送信することを試みます。これを繰り返し実行すると、メモリーが枯渇します。この脆弱性はドライバーに存在し、カーネルモードで実行されるため、 システム全体が不安定になり、応答しなくなります。
この攻撃は最適化されているか？
この攻撃では、多数のパケットを送信する必要があります。しかし、QUIC の機能を悪用することで、必要なパケット数を減らすことができると考えられます。
QUIC は 1 つの接続で複数のストリームを許可しますが、 initial_max_streams_bidi プロパティを介してこの数を制限することもできます。SMB over QUIC は、1 つの接続の同時ストリーム数を 1 つに制限します。
複数の 同時 ストリームを使用してこの攻撃を強化することはできませんが、別の方法でこの脆弱性の悪用を試みることはできます。複数の同時ストリームを作成する代わりに、複数のフレームを持つ 1 つの QUIC パケットを作成して、次のシーケンスが 連続して 繰り返し発生するようにします。
1.ストリームを作成する
2. 2 つの DATA フレームを送信して、16 MB の割り当てをトリガーする
3.ストリームを閉じる
こうすることで、未認証接続の制限を回避することもできます。これは、読者への挑戦として残しておきます。
検知と緩和
Akamai Guardicore Segmentation ユーザーは、次の簡単な Insight クエリーを実行することにより、稼働中の SMB over QUIC サーバーを見つけることができます。
select * from registry where
path="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableSMBQUIC" and data=1
Windows Server マシンにパッチを適用することをお勧めします。この脆弱性に対する他の緩和策や回避策は存在しません。適用しない場合は、SMB over QUIC 機能をオフにするしかありません。
まとめ
QUIC は比較的新しいネットワークプロトコルであり、確実にパフォーマンスを向上させ、レイテンシーを軽減します。このプロトコルはすでに 2 つの極めて有名なプロトコルに組み込まれていることは明らかです。それは、IIS（HTTP/3 の場合）と SMB です。
Akamai は QUIC が Windows の新しい魅力的なアタックサーフェスになると考えており、一般的にもそのように見なされています。ここで取り上げた問題以外に、別の脆弱性（ CVE-2023-23392）が存在し、HTTP/3 で修正されました。
他のリサーチャーにも、MsQuic を使用するさまざまなコンポーネントや MsQuic 自体を調査していただきたいと思います。
