サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト フェロー 関原 弘樹
この週末、ニュースサイトを見ていたら「改正道路運送車両法成立」というニュースが目に入ってきました。
外部サイト：
乗りものニュース「自動運転車に安全基準＝改正道路運送車両法成立へ」
自動運転車の運行を安全に実施するために必要な、車両に対する技術的な要件に関する法の整備が大きな目的のようです。
記事によれば
2020
年までには緊急時以外は自動運転が可能である「レベル
3
」を高速道路上に対象に実現を目指し、一部エリアでは完全自動の「レベル
4
」も可能にしたいということで、現状を考えるとずいぶん急いでいるなという印象を受けました。
出典：
国土交通省
さて、先週は定例の「 Windows Update 」で修正パッチが配布される週でもありました。
今月のパッチにはリモートデスクトップサービス（以下 RDP ）を経由して悪意のあるコードを実施させることが可能な脆弱性 「CVE-2019-0708」 ※1 の修正が含まれています。
※
1
外部サイト：
マイクロソフト「CVE-2019-0708
のユーザー向けガイダンス | リモート デスクトップ サービスのリモートでコードが実行される脆弱性」
本脆弱性は２年前に大急行した「 WannaCry 」のようなマルウェア – ユーザーのクリックにより発動するだけでなく、ネットワークを介してワーム ※2 のように広がる – に悪用される可能性があるということで、すでにサポートが終了している Windows XP や Server 2003 にもパッチが提供されるという異例の対応になりました。
※2 外部サイト： マカフィー公式ブログ「ワームとは？ウイルスとの違い｜特徴・感染経路・被害例・対策を解説」
■ CVE-2019-0708 RDP の脆弱性
まずは脆弱性が突かれる条件等から
該当
OS
は以下です。
RDP
ということでサーバ系が気になりますが2k12以降は対象外です。
- Windows Server 2008 R2 SP1
- Windows Server 2008 SP2(x86/x64)
- Windows Server 2003 SP2(x86/x64)
- Windows 7 SP1(x86/x64/Embedded 含む)
- Windows Vista(x86/x64)
- Windows XP SP3 x86
- Windows XP Professional x64 Edition SP2
- Windows XP Embedded SP3 x86
また、攻撃成立の条件は以下と発表されています。
1)RDP が有効
2)CVE-2019-0708パッチが未適用
3)サーバ側でRDP時にネットワーク レベル認証 (NLA) を強制していない
Server 2008だと最新の
Windows Server OS
と違い
RDP
を有効にした場合
NLA (ネットワーク レベル認証)有効がデフォルトではなかった
と記憶しています。
今回のこの脆弱性については本コラム執筆中の
5/21
時点では悪用の事実は確認されていないようですが、リスク管理の観点から、対象となるシステムに対し速やかにパッチの適用をする必要があります。
実際にどのような攻撃方法なのか、や検証コードについてはまだ公表されておりませんので、これ以上の情報については続報を待つ必要があります。
■ワークアラウンドまたは緩和策
さて、今回はパッチが提供されているので適用することが最善の対策となりますが、パッチを適用したくても検証に必要な時間が確保できなかったり、その他の理由ですぐにはできない状況もあったりするでしょう。
そのような状況下でとるべきワークアラウンド（回避策）や緩和策ですが、今回はどのようなものがあるか見ていきましょう。
①サービス無効化
RDPを無効化します。まさにワークアラウンドですね
。
そもそも
RDP
はデフォルトでは無効です。必要だから有効化していのですが…
各サーバや端末の設定を確認し、有効化しているものについて
RDP
がどうしても必要か再度精査し、不要であれば無効化します。
Windows Server 2008R2の場合
②アクセス制限
緩和策です。
RDPにアクセスできる端末を信頼できるもののみに制限することにより脆弱性の悪用リスクを低減します。
RDPは
IP
ネットワーク上で動作します。サーバの重要度によって
IP
サブネットを細かく分離している場合はゲートウェイ（ルータ、
L3SW
等）のインターフェイス上の「
ACL
（アクセスコントロールリスト）」で、そうでない場合は「
Windows
ファイアウォール」でサーバにアクセス可能な送信元
IP
アドレスを制限しましょう。
アクセス可能な送信元 IP アドレスを持つ端末を厳重に管理することにより、社内に侵入され CVE-2019-0708 による攻撃の足場を築かれた場合でも重要なサーバや端末を乗っ取られるまでの時間を稼ぐことが可能です。
設定例
ゲートウェイインターフェイス上の
ACL
（
Cisco
系）の場合
例）
172.31.0.5
の
Windows
サーバに
RDP
アクセスが可能な端末を
IP
アドレス
10.255.255.10
～
11
の（現行
Windows
系のエフェメラルポートを使う）端末のみに制限する。
Windows ファイアウォールの場合
例）ドメインプロファイルで
Windows
ファイアウォールを構成する
Server 2008
に
RDP
アクセスが可能な端末を
IP
アドレス
10.100.100.10
～
11
の端末のみに制限する。
③ NLA の有効化
RDPの構成で ネットワーク レベル認証 (NLA) ※3 を有効にしてあれば攻撃者がサーバにアクセス可能なユーザー名 / パスワードを把握していない限り CVE-2019-0708 の脆弱性を利用した攻撃を開始できないということなので緩和策となります。
Windows Server 2008R2の場合
※
3
NLA (ネットワーク レベル認証)
Windows Vista, Server 2008以降で利用可能なRDPの認証機能。
これ以前のRDPではクライアントの接続要求時に直接デスクトップのログインプロセスまで進み、ログイン画面を表示していた。NLAはデスクトップのログインプロセスへの悪意のある攻撃を防ぐため、サーバがユーザーとのセッションを確立する前にユーザーの資格情報を提示するよう接続元に強制する仕組み。
NLAを構成すると旧世代のクライアントでは接続ができず、仕様の変更で一時的に対応するクライアントからでも接続が不能になる事象があったため、NLAに対応するサーバでも有効にされていない可能性がある。
NLAの有効化に関しては他に以下のような方法もあります。
1) ポリシーで設定
[コンピューターの構成 ] - [ 管理用テンプレート ] - [Windows コンポーネント ] - [ リモート デスクトップ サービス ] - [ リモート デスクトップ セッション ホスト ] - [ セキュリティ ]
"リモート接続にネットワークレベル認証を使用したユーザー認証を必要とする " を " 有効 " に
2) レジストリで設定
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
⇒ REG_DWORD: UserAuthentication
⇒ Value: 1
出典： マイクロソフト「 CVE-2019-0708 (Remote Desktop Service の脆弱性 ) について」
■システムのデザイン
前項では CVE-2019-0708 を例に挙げ、ワークアラウンドや緩和策を含めた脆弱性への対応とその考え方を確認しました。本項では一般的な考え方を取り上げます。
前項のように脆弱性への対応が必要になった時に、現場の担当者が独断で判断し実行しようとすると、例えば「パッチ適用」では「運用も関連するのでどのような手順で実施するのが正しいのかわからない！」という問題が出てくるかもしれません。
また、「アクセス制限」では「設定すべきパラメータがわからない、決まらない！」「セキュリティの観点から本当に正しく効果的に設定できているのかわからない！」という問題が出てくるのではないでしょうか。
これは当然のことで。まずデバイスレベルでセキュリティの設定を正しく行うためにはその上流にある概念、対象となるシステムのデザインを正しく理解しておく必要があります。
システムがどのようにデザインされているかを理解すれば
・新しいパッチはどのように配布・適用するのが最も安全で効率的か
・ RDP を接続可能にするクライアントはどのセグメントに配置されているのか
・そのクライアントの OS は何か
・クライアントにはどのようなセキュリティ対策を施しておけばいいのか
・制限用の ACL はどの場所に設定するのか
など・・・
ということが自ずと決まってきます。
■セキュリティポリシー
また、システムのデザインがセキュリティ対策を容易に・無理のない形で実施できるようになっているかどうかはデザインのさらに上流である要求事項やポリシーとの一貫性にかかっています。
基本方針ともいえるビジネス上の要求事項をセキュリティポリシー、運用ポリシーが正確に取り込んでいれば、それらのポリシーがシステムをデザインするうえでの重要な指針であり、制約事項となります。
ポリシーからデザインまでが一貫しており、システムがセキュアに設定・運用されていれば、脆弱性が発見された時にあわててワークアラウンドを検討する必要はありません。
パッチを安全に適用するプロセスは確立されているし、不必要な管理アクセスはすでに無効になっていることでしょう。
■おわりに
ゴールデンウィーク前の 4 月から今日まで悲惨な交通事故のニュースが連日メディアで報道され続けています。
安全性 = セーフティの歴史はセキュリティより長いといわれていますが、セーフティでも、いやセーフティだからこそ十分に機能させるためにはポリシーとそこから導き出されるデザインが重要なカギを握っているということは論を待たないことでしょう。
車両レベル安全のための機能を定義して安全を担保しようとする取り組みも、もちろん必要ですが、インフラを含めたシステムのデザインが機能しなければ機能は十分に効果を発揮できないでしょう。
インフラという意味にはコントロールを司る各種標識やセンサーだけでなく、もっと根本的な部分 - 人と車のアイソレーション – という課題も含まれます。
そもそも、それ以前のポリシーの問題、例えば責任の所在。 - これは事故時の刑事、民事の判決や保険の支払いに大きく影響してきます - 政府筋ではレベル 4 以降をシステムの責任と規定したいようですが、ではシステムとは何？どのようにステークホルダのコンセンサスを得る？維持管理については？
政府主導であっても簡単ではないと感じています。また、これは各国家で必ずしも同一になるとは限らないというのもポイントです。
他にも危険回避時のアルゴリズム – どのように被害を最小化するか。そもそも被害の最小化とは何か等 – について定義し、明確な回答を持つ方は存在しないのではないでしょうか。
その点が考慮されていないロードマップだとしたら、急いで導入しても画餅になってしまうのではないのか？と感じるのが正直なところです。
ではまた、次回のエントリーでお会いしましょう。
Hiroki Sekihara, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
