Cisco Japan Blog

Firepower を使って BlueKeep などの暗号化された RDP 攻撃を防御する

1 min read



 

Microsoft  は、先日、リモート デスクトップ プロトコル (RDP)サービスにおいて認証前にリモートでコードが実行される脆弱性に対して修正をリリースしました。5 月の月例パッチpopup_icon において CVE-2019-0708 として特定されているとおり、この脆弱性は、「ワーマブル」である、つまりこの脆弱性をエクスプロイトする攻撃がマシンからマシンへと容易に拡散する危険があるという理由から、研究者やメディアの注目を大いに集めています。この脆弱性については、「Beers with Talos」ポッドキャストのエピソード 54popup_icon?で詳しく説明されています。

Cisco Talos では、RDP が実際にどの程度脆弱なのかを判断するため、即時にリバースエンジニアリング作業を開始しました。そして脆弱な状況を確認してすぐに、カバレッジを準備してリリースpopup_iconしました。SNORTR の?SID 50137popup_iconは、CVE-2019-0708 のエクスプロイトと、この脆弱性を悪用するためのスキャンの試みを適切にブロックします。

このルールは、「MS_T120」仮想チャネルの使用を試みる RDP 接続をすべてブロックすることにより、CVE-2019-0708 のエクスプロイトを防止します。RDP プロトコルでは、さまざまな種類のデータ(クリップボード、音声など)の転送に使用される仮想チャネルが定義されています。こうしたチャネルはクライアントが指定するものですが、MS_T120 チャネルは、それとは別に Microsoft が Windows RDP システムに作成するものです。クライアントが MS_T120 チャネルを作成することは想定されていません。未認証の攻撃者は、細工したデータをリモートからこの内部チャネルに送信することで CVE-2019-0708 をエクスプロイトできます。

クライアントがどの仮想チャネルをサポートするかは RDP サーバ側には認識されていないため、クライアントは、必要なチャネルのリストを RDP セッションの開始時の接続開始パケットに含めます。

クライアント –> 接続要求 –> サーバ
クライアント <– 接続確認 <– サーバ
— 場合により、トランスポートを TLS に切り替え —
クライアント –> MCS 接続開始–> サーバ
クライアント <– MCS 接続応答 <– サーバ

RDP 接続要求では、クライアントが TLS 対応であると指定することができます。この指定があると、ほとんどのケースのサーバは接続確認パケット以降の接続を TLS に切り替えます。このため、暗号化されているケースでは、Cisco Firepowerpopup_iconは RDP に TLS 復号化が設定されている場合のみ仮想チャンネル リストをスキャンすることになります。

前述の Snort ルールは BlueKeep に対する防御として有効に機能しますが、それでも、暗号化された攻撃は、ユーザに気付かれず検出されないまま実行される可能性が残されています。Firepower デバイスで RDP に TLS 復号化を設定していなければ、CVE-2019-0708 のエクスプロイトにより、急速に拡散する危険のあるマルウェアを送り込まれる可能性があります。

以下に、Cisco Firepower で RDP 復号化を設定する方法を説明します。この説明が該当するのは、Windows Server 2008 インスタンスのみです (新しいバージョンの Windows Server は BlueKeep の影響を受けません)。また、Windows 7 では、レジストリにカスタムの RDP 証明書を設定することしかできません。Windows 7 で自己署名の RDP 証明書と秘密キーをエクスポートすることは可能ですが、自動生成された証明書の秘密キーはエクスポート不可となっているため、エクスポートには mimikatz ツールの使用が必要になります。このような問題を考慮した結果、今回の説明は Windows Server 2008 のみを対象とすることにしました。

* 注:以下の手順では、SSL 復号化をサポートするインライン Firepower デバイスが必要になります。詳細については、シスコ次世代侵入防御システム(NGIPS– Ciscopopup_icon を参照してください。

RDP 復号化の設定手順

  1. RDP サーバが使用する証明書を確認する
    Windows Server 2008 では、RDP の TLS 証明書は [リモートデスクトップセッションホストの構成] で設定されています。[リモートデスクトップセッションホストの構成] を開き、RDP 接続をダブルクリックして、RDP サーバが使用する証明書をメモします。これが後で必要になります。

  1. RDP 証明書と秘密キーをエクスポートする
    mmc.exe を開き、[ファイル] -> [スナップインの追加と削除] を選択します。

左側で [証明書] を選択し、[追加] をクリックします。

[コンピューターアカウント] をクリックし、[次へ] をクリックします。その後、[完了] をクリックします。
最後に、[OK] をクリックすると証明書スナップインが追加されます。

左側でローカル コンピューターの証明書を選択した後、右側で、RDP サーバが使用する証明書(前のステップの [リモートデスクトップセッションホストの構成] に設定されていた証明書)を探します。

その証明書を右クリックし、[すべてのタスク] から [エクスポート] をクリックします。

 

証明書のエクスポートウィザードで、[はい、秘密キーをエクスポートします] をクリックし、[次へ] をクリックします。

 

[Personal Information Exchange] が選択されていることを確認し、[次へ] をクリックします。

 

PFX ファイルを暗号化するため、インポート パスワードを入力します。このパスワードを忘れないようにしてください。後で必要になります。”Next” をクリックしてください。

PFX ファイルのファイル名を入力し、[次へ] をクリックします。
最後に、[完了] をクリックします。

これで、RDP 証明書と秘密キーが正常にエクスポートされました。
次に、それらを Firepower アプライアンスで使うための準備を行います。

3. Firepower 用に RDP 証明書と秘密キーを準備する
この手順では、OpenSSL ツールと、手順 2
でエクスポートした PFX ファイル(この例では dc1.pfx)が必要になります。
PFX ファイルから RDP 証明書を抽出します。

$ openssl pkcs12 -in dc1.pfx -clcerts -nokeys -out cert.pem
Enter Import Password:

上記のコマンドでは、インポート パスワードの入力を求められます。これは、ステップ 2 で設定したパスワードです。
PFX ファイルから RDP 秘密キーを抽出します。

$ openssl pkcs12 -in dc1.pfx -nocerts -out key.pem
Enter Import Password:
Enter PEM pass phrase:
Verifying – Enter PEM pass phrase:

上記のコマンドでは、同じインポート パスワードの入力と、PEM パスフレーズの設定を求められます。この秘密キーのパスフレーズを覚えておいてください。これは、RDP 証明書を Firepower に追加するときに必要になります。

4. RDP キーを Firepower にインポートする
この時点で、RDP 証明書「cert.pem」と、暗号化された RDP 秘密キー「key.pem」が手元にあるはずです。

[オブジェクト(Objects)] -> [オブジェクト管理(Object Management)] に移動します。

右上にある [内部証明書の追加(Add Internal Cert)] を選択します。

証明書の名前(サーバ名など)を指定し、[証明書データ(Certificate Data)] セクションで cert.pem のデータを貼り付けるか、cert.pemファイルを指定します。[キー(Key)] セクションでも、key.pem について同じ操作を行います。[暗号化] のボックスをクリックし、ステップ 3 の PEM パスフレーズを入力します。

これで、RDP 証明書と秘密キーが正常にインポートされました。次に、復号化用の SSL ポリシーを作成します。

5. SSL ポリシーを作成する

[ポリシー] -> [SSL] に移動します。

[新しいポリシー(New Policy)] を選択します。

ポリシー名と説明を入力し、デフォルトのアクションに [復号しない(Do not decrypt)] を選択します。

 

ポリシー エディタが表示されたら、[ルールの追加](右上)を選択します。
ルールの名前を指定し、アクションに [復号(既知のキー)] を選択します。[使用(with)] フィールドをクリックし、前のステップ 4 でインポートした証明書を選択します。
必要に応じて、送信元と送信先のネットワークを選択するか、[すべて(any)] のままにします。

[ポート] タブをクリックし、[選択された送信先ポート] で TCP ポート 3389(値は環境によって異なる場合があります)を入力し、[追加] をクリックします。

 

[ログ(Logging)] タブで、必要に応じて接続の終了時のログ記録を有効にします。
[追加] をクリックし、次に [保存] をクリックしてルールを保存します。
SSL に関する詳細な資料については、こちらpopup_iconを参照してください。

6. BlueKeep に対する侵入防御ルールを有効にする

 

[ポリシー] -> [アクセス制御] -> [侵入防御] に移動します。
侵入ポリシーを編集します。
Snort ID 50137「OS-WINDOWS Microsoft Windows RDP MS_T120 channel bind attempt」のフィルターを設定します。
チェックボックスをクリックして、[ルール状態] -> [ドロップしてイベントを生成(Drop and Generate Events)] を選択します。

 

[ポリシー情報] をクリックして、変更を確定します。

7. アクセス制御ポリシーを構成する
[ポリシー] -> [アクセス制御] に移動し、該当のアクセス制御ポリシーを編集します。

 

[詳細設定] タブで、[SSLポリシー設定] を編集します。

ステップ 5 で作成した SSL ポリシーを選択し、[OK] をクリックします。

「詳細設定」タブの [ネットワーク分析ポリシーと侵入ポリシー(Network Analysis and Intrusion Policies)] セクションで、[アクセス制御ルールが決定される前に使用される侵入ポリシー(Intrusion Policy used before Access Control rule is determined)] の下に侵入防御ポリシーが選択されていることを確認します。

 

アクセス制御ポリシーの [ルール] タブで、[すべて(any)] に対する許可ルールに適切な侵入ポリシーが設定されていることを確認します。

必要に応じて、デフォルトのアクションでも侵入防御ポリシーを有効にします。

変更を保存し、反映します。
RDP 接続をして機能を検証します。

暗号化されたエクスプロイトの検証

まず、パッチが適用されていない(つまり、保護されていない)Windows 7 システムでエクスプロイトが試みられるとどのようなことが起こるのかを見てみましょう。

 

ご覧のように、エクスプロイトが開始されると、予想どおりシステムのサービスが妨害されます。次に、このブログで説明したように RDP に対して SSL 復号化を有効にし、Firepower の検出機能を活用する場合のプロセスを検証します。

今度は、攻撃が暗号化されているにもかかわらず、サービス妨害は発生せず、システムは影響を受けていません。以下の画面キャプチャは、SID 50137 により、Firepower において BlueKeep の暗号化されたエクスプロイトが警告され、切断されたことを示しています。

 

 

まとめ

ここ数年の間に、各種 Windows サービスの関連サービスに影響を及ぼして大いに注目を浴びた脆弱性がいくつかありました。影響を受けたサービスの中には、もちろんすべてではありませんが、インターネットに公開されるべきではないものも含まれています。外部に公開される部分を減らすために一層の対策を講じることが必要であり、RDP や SMB などのサービスが明らかに必要な場合以外は公開されないことを確実にしなければなりません。しかし、そうした対策を講じたとしても、パッチの適用が不要になるわけではありません。この脆弱性も、情報セキュリティの基本的な中核概念の 1 つとしてなぜパッチの適用が重要視されているのかを示す一例となっています。このような重大な脆弱性はある程度の時間が経つと必ず出現してきます。企業は、さまざまな方法での対応を考え準備をしておく必要があります。パッチの適用には時間がかかります。また、検出や防御の機能の適切な導入には、さまざまな困難が伴うこともあります。今回の脆弱性の事例では、可視性を高めるために、より徹底した防御として SSL 復号化が必要でした。

暗号化は、インターネットに深く浸透し、多くのアプリケーションが活用するようになってきています。このため、同じような種類の手口は増えてくるでしょう。攻撃者はどんな種類の検出でも回避しようと常にその手段を探しています。暗号化の使用は、一部の検出技術には回避の手段として非常に有効に働きます。こうした状況の中、Cisco Talos は攻撃者の動きに常に目を光らせ、攻撃に対抗すべく、より優れた新しい方法の開発に努めています。

 

本稿は 2019年5月31日に Talos Grouppopup_icon のブログに投稿された「Using Firepower to defend against encrypted RDP attacks like BlueKeeppopup_icon」の抄訳です。

コメントを書く