Windows の RDP named pipe 問題：この脆弱に２回目の CVE-2022-24533 が採番された理由

Details of Twice-Patched Windows RDP Vulnerability Disclosed

2022/06/17 SecurityWeek — 今週に、アイデンティティ・セキュリティ企業である CyberArk の研究者たちが、Microsoft が２回にわたってパッチをリリースせざるを得なかった、Windows の RDP named pipe の脆弱性に関する技術情報を公開した。この脆弱性 CVE-2022-21893 は、2022年1月の Patch Tuesday で対処されたが、修正内容の分析により、新たな攻撃ベクターに対するパッチが漏れていることが判明した。2022年4月の Patch Tuesday で Microsoft は、この脆弱性を CVE-2022-24533 として解決している。

CyberArk は CVE-2022-21893 について、Windows Remote Desktop Services の脆弱性であり、RDP 経由でマシンにアクセスした非特権ユーザーが、接続している他のユーザーのクライアント・マシンのファイル・システムに、アクセスできる可能性があると説明している。



この問題により、攻撃に成功した脅威アクターは、クリップボードの内容／転送されたファイル／スマートカード PIN などの、他の接続ユーザーが所有するデータの閲覧／変更が可能になる。また、対象となるマシンにログオンしている、他のユーザーになりすまし、USB デバイスやハードディスクなどの、リダイレクトされた被害者のデバイスにアクセスすることも可能となる。

CyberArk は、「この問題により、データ・プライバシー侵害／横方向への移動／権限の昇格などにつながる可能性がある」と指摘している。研究者たちによると、この脆弱性は、Remote Desktop Services における named pipe の不適切な許可に起因し、その結果として、通常の権限を持つユーザーが、他の接続セッションの RDP 仮想チャンネルを引き継ぐケースが生じるとのことだ。CyberArk は、「この named pipe は、システム上の全ユーザーが同じ名前で、追加の named pipe サーバー・インスタンスを作成できるようデザインされていた」と説明している。

最初のパッチでは、pipe のパーミッションを変更することで、標準的なユーザーが named pipe サーバーを作成できないように修正された。しかし、ユーザーが後続のインスタンスに対する権限を設定できる場合において、最初の pipe サーバーの作成に関連するリスクに対処していなかったらしい。

CyberArk は、「同じ名前で複数の pipe インスタンスを作成する場合、CreateNamedPipe() の最初の呼び出しに渡されたセキュリティ記述子が、すべてのインスタンスで使用されてしまう。したがって、それ以降の呼び出しにおいて、それぞれのセキュリティ記述子を渡すことが可能であっても、それらは無視されてしまう。そのため、攻撃者が最初の pipe インスタンスを作成した場合に、その他のインスタンスのパーミッションの制御が可能になってしまう」とは指摘している。

2022年4月の Patch Tuesday 以降は、新しい pipe 用に新しい GUID が生成され、攻撃者が次の pipe 名を予測するのを防ぐようになった。したがって、 pipe サーバーは新たな一意の名前で作成される。 さらに Microsoft は、カレントのプロセス ID と、 named pipe サーバーのプロセス ID を照合するための、追加のコントロールを導入した。

CyberArk は、「それにより、仮に攻撃者が何らかの方法で GUID を予測できたとしても、異なるプロセス ID を持つことになるため、攻撃が成立しないことを保証する追加制御となる。この場合、 pipe サーバーとクライアントは同じプロセスで作成されるため ( pipe クライアントのハンドルは後で呼び出し元のプロセスに返される)、このチェックは容易に実行できる。今回の変更により、この脆弱性におけるリスクは十分に対処された」と指摘している。

お隣のキュレーション・チームに聞いたところ、脆弱性 CVE-2022-21893 は 1月12日に、CVE-2022-24533 は 4月13日に、それぞれ Patch Tuesday の一部としてレポートしているとのことでした。このところ、PrintNightmare と ProtocolNightmare に苦しめられてきた Microsoft ですが、カレントのプロセス ID と、named pipe サーバーのプロセス ID を照合するという、抜本的な対策を講じたようです。