サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト フェロー 関原 弘樹
「雨の歌」で連想するアーティストは？ という問いに「ブラームス…ともう一人は一般人に
GitHub
の認知度を飛躍的に向上させた超有名歌手」なんて答えると歳がばれてしまいそうですが、速報によれば関東地方も先週末に梅雨入り“したよう”です。
本コラム執筆中も雨が降り続いていますが
5
月末には真夏日が連続していたので、湿度が高いとはいえこの涼しさはそんなに悪くないと感じます。
さて、今回も
Windows
リモートデスクトップサービス（以下RDP）に関連するお話です。
前回の私のエントリー「
【エバンジェリスト・ボイス】脆弱性対応とポリシー
/
デザイン
」では
RDP
に関する脆弱性
CVE-2019-0708
について取り上げました。
■
DDoS
再び！？
その後「
BlueKeep
」と名付けられた
CVE-2019-0708
はご存じのように先月のパッチで修正されていますが、まだまだ修正されていないままインターネット上に放置されているシステムは多いようです。ある専門機関の調査では
5
月末の時点で
100
万台弱存在しているとの報告が出ています。
外部リンク：
依然として
100
万台弱の
Windows
システムに「
BlueKeep
」の脆弱性
本当にこれだけのシステムがコントロールされれば
3
年前に猛威を振るった「
MIRAI
」のような大規模
DDoS
の再来も十分考えられます。今後、十分な警戒が必要でしょう。
■新たな脆弱性
CVE-2019-9510
RDPについてはさらに今月上旬、新たにCVE-2019-9510 という脆弱性が発見されています。
外部リンク：
Microsoft Windows
リモートデスクトップのネットワークレベル認証に
Windows
ロックスクリーンをバイパスされる問題
これは①～③の条件が成立した場合に、
RDP
で通信しているシステムがスクリーンロックされていても解除されてしまい、再認証なしでデスクトップにアクセス可能になるというものです。
①
Windows 10 1803
もしくは
Windows Server 2019
およびそれ以降のシステムで
RDP
を
NLA
（
Network Level Authentication
）と共に使用中
② RDP で通信先のシステムの画面がロック状態になっている。
③ RDP クライアント～通信先システム間の RDP セッションが IP ネットワークの問題で一度中断され、その後復旧する
形としては
RDP
セッション経由ですでに認証済のリモートシステムの再認証がバイパスされ、ロック解除後の状態でデスクトップにアクセス可能となるものですが、攻撃を開始するためには悪意のある者が
RDP
クライアントの動作するデスクトップ画面に直接アクセスする必要があります。
そもそも、そのデスクトップ画面にアクセス可能ということはすでに何らかのユーザー認証を受けており、同一のデスクトップ画面にアクセスする限り権限の変更はないはずですので、現在のセキュリティのセオリーである
ユーザーアカウントの共有がなく、操作端末（RDPクライアント）のクリアスクリーンが保たれていれば、さほどリスクが高いとはいえない
でしょう。
■念のため確認
JPCERT/CCのサイトに記載の通り、CVSS v3でスコアが4.3と危険度はさほど高くないCVE-2019-9510ですが念のためちょっと確認してみましょう。
VMの
Windows10
に
RDP
接続します。
画面をロックして、
この状態のままネットワーク接続から
ネットワークアダプタを無効化（これはケーブル抜去や中継 NW の切断でも同様のはずです）。
RDPセッションが中断され、このような画面になります。
その後は、おもむろにネットワークアダプタを有効化！
RDPセッションの復旧後、確かにロックが外れていますね…成功です！！
Win10や Server 2019 の検証はほぼ RDP 経由で実施しており、ありがちなシチュエーションなのに今まで気づきませんでした。
RDPでセッションの中断が発生した時はすぐに切断して新しいセッションを張っていたからかもしれません。なお、同様の内容を Win10 1709 で検証してみると（こちらの環境では）ロックは解除されていませんでした。
検証環境がすぐに用意できないので確認はしていませんが
MFA
（
Multi-Factor Authentication/
多要素認証）もバイパスされるようです。
■
CVE-2019-9510
への
Microsoft
の対応
ちなみに以下のリンクのように
Microsoft
はこの
CVE-2019-9510
について脆弱性とみなしていません。
CVE番号が与えられるような脆弱性について必ずしもベンダがそれを認め
Fix
するとは限らないということは覚えておいて損はないかもしれません。
外部リンク：
日本マイクロソフト株式会社からの情報
--
「詳細な調査を行った結果、本動作は、マイクロソフトが定義する Windows のセキュリティ修正要件 (https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria) を満たさない動作であると判断しました。
本動作は、 Windows Server 2019 のネットワーク レベル認証 (NLA) の動作です。 NLA は接続を許可するために、接続の早い段階でユーザーの資格情報を必要とします。
同じ資格情報は、ユーザーをセッションにログインするためにも利用されます。
接続が許可される限り、クライアントは資格情報をキャッシュし、自動接続をするための再接続処理に利用されます。」
--
日本マイクロソフト株式会社の言い分は本件単独であれば（他の脆弱性と組み合わさらなければ）というコンテキストでは一応納得はいきます。
ただ、それぞれの環境での運用方針も関係する場合があることと、
MFA
のバイパスはユーザーにとってかなり予想外といえるので、
MFA
に依存して
端末やユーザーアカウントを共用している環境や、物理アクセスへの制限が弱い環境では十分な注意が必要
と考えられます。また、前回同様
リモートからの送信元アクセス制限は検討すべき
でしょう。
■
RDP
のセキュリティレベル
前回の私のコラム
をご覧いただいた方は
Windows
の
RDP
のセキュリティレベルには
Windows XP
（と
Server 2003
）までのクラシックな
RDP
を使用したレベルと、
Vista
（と
Server 2008
）以降の
NLA
を使用するレベルがあることをすでにご理解いただいているかと思います。
# XPでも
SP3
であればレジストリの変更で
NLA
を使用することは一応可能です。
本コラムの後半はこのクラシック
RDP
と
NLA
のプロトコルの違いをパケットキャプチャで確認してみます。
★クラシック
RDP
現在サポート中の
Windows OS
ではすべて
NLA
をサポートしていますので今ではまず使われません。ここでは「
gpedit.msc
」から強制的にクラシック
RDP
を使用するように設定して確認しました。
赤枠内ですぐ RST された 1266/TCP-3389/TCP のセッションと続く 1267/TCP-3389/TCP にセッションが確認できます。 TCP の 3 ウェイハンドシェイクは確認できますが、上位プロトコルの詳細はこれだけではよくわかりませんね。暗号アルゴリズムについては 4 年ほど前に調査した時は RC4 の 56 か 128bit を使用していたと記憶しています。
TCPストリームを追跡してみるとバイナリデータが並び、テキストデータでは「 rdpdr 」、「 rdpsnd 」、「 RSA1 」という単語が確認できます。赤いマスクの部分は RDP クライアントが動いているコンピュータの名前です。
★
NLA
を使用した
RDP
赤枠のパケットナンバー
1127
以降の「
Client Hello
」「
Server Hello
～」から「
Client Key Exchange
～」「
Change Cipher Spec
」のシーケンスを見ると
3389/TCP
で
TLS1.2
が動作していることがはっきりわかります。
#ちなみに新しめの RDP バージョンでは回線が絶好調になってくると 3389/UDP も使用してきます
そして青枠の「
Server Hello
」のメッセージからはネゴシエーションでサーバ側がオファーしたサイファースイート「
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
」が読み取れます。
ご覧いただいたように
NLA
のセキュリティは
TLS
に依存しています。
これは今回の事象にどのように関係するのでしょうか？？
■クラシック
RDP
での動作
ついでといっては何ですが、念のためいくつかクラシック
RDP
での動作も確認してみました。
Win7 SP1 ⇒ Win7SP1 ロック外れず
Win10 1804 ⇒ Win7SP1 ロック外れず
Win7 SP1 ⇒ WinS2k8R12 ロック外れず
Win7 SP1 ⇒Win10 1709 ロック外れず
#この組み合わせのWin10側はロープアップパッチ未適用
Win7 SP1 ⇒Win10 1804 ロックが外れた！
Win10 1804 ⇒Win10 1804 ロックが外れた！
Win7 SP1 ⇒WinS2k19 ロックが外れた！
よくわからなくなってきました！
この結果が正しいとすれば、今回の脆弱性は
NLA
の動作や仕様に起因するものではなく、対象の
OS
で資格情報のキャッシュ方法か再利用の方法に何らかの変更があったことが起因するようにもみえます。
つまりマイクロソフトがアナウンスしている「 NLA は～」という部分は本質ではない可能性があるということです。
[
参考]Win10 1804 クラシックRDPでのセッション中断
やはりロックは外れます。
RDPの仕様詳細は下のリンクで確認できるようですが、残念ながら今回はここまでです。
#シーケンス図等も収録されていますのでご興味のある方は是非ご確認ください
外部リンク：
[MS-RDPBCGR]: Remote Desktop Protocol: Basic Connectivity and Graphics Remoting
■雨の歌
今後、働き方改革がますます推進されると、雨の日には自宅で好きな曲を聴きながらセキュアにリモートアクセスして業務をするのが当たり前になりそうですね。
さて、どの曲にしましょうか？
ではまた、次回のエントリーでお会いしましょう。
Hiroki Sekihara, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
※「■念のため確認」の次の行に記載のCVE番号（CVE-2019-9510）に誤記がありました。現在は修正済です。
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
