Windows Updateは“Microsoftが想定している最大の更新間隔の期間内”に更新







Windows Updateは適切な更新サイクルで――CredSSP脆弱性対策について



本連載では「Windows Update」のトラブルや回避方法をよく取り上げていますが、今回は更新をしばらく怠ったときの副作用の話です。それをよく示す事例が、2018年5月の定例更新後に発生する可能性があります。更新サイクルを調整している個人や企業は、今後、近いうちに影響を受けるかもしれません。実は“Microsoftが想定している最大の更新間隔の期間内”に更新されていれば、影響を受けることはありません。

[山市良，テクニカルライター]


“初物”にはやっぱりリスクが伴う

　前回 は「Windows 10 April 2018 Update（バージョン1803、ビルド17134.1）」のリリースに合わせ、特別版をお送りしました。自分に都合の良いタイミングで、自分主導でアップグレードすること、そしてまだWindows 10 バージョン1803にアップグレードしていない（Windows Updateで検出されない）場合は、まず情報収集することが大事であることをお伝えしました。


　新バージョンのリリース直後は隠れた不具合が多数含まれている可能性があり、いち早く飛びつく場合は“失敗のリスク”をある程度覚悟しておかなければなりません。何の問題もなく成功し、快適なWindows 10生活を送れる人もいれば、失敗の連続に時間と労力をとられる人もいます。特に、万が一に備えたフルバックアップは大事なことです。


　Windows 10 バージョン1803は、正式リリースから約1週間というところで、「Intel SSD 600p」シリーズまたは「Intel SSD Pro 6000p」シリーズを搭載したデバイス（PC）をWindows 10 バージョン1803にアップグレードしようとすると、“再起動時またはシステム停止後にUEFI（Unified Extensible Firmware Interface）設定画面に入る動作が繰り返される”という重大な問題が報告されています。


　筆者はこの問題を、2018年5月8日（米国時間）リリースのWindows 10 バージョン1803の累積更新プログラム「KB4103721」のサポート情報「Known issues in this update（この更新プログラムの既知の問題）」として、5月10日になって追記されたことで知りました。本稿執筆時点（2018年5月11日）では、Windows Updateによる対象デバイスへの機能更新の配布は停止されています。問題が発生したPCは、Windows 10 バージョン1709以前に戻し、問題が修正されるのを待つ以外にないようです。


Windows Update


　“Windows 10はSSDじゃないと、とても使い物にならない”（Windows Updateに時間がかかるなど）という意見を目にしたことがありますが、その人のPCは大丈夫だったのか少し気になりました。また、一部の環境では（Intel SSDとは関係なく）、Windows 10 バージョン1803向けに初めて提供された累積的な品質更新プログラムの影響で、PCが起動できなくなる問題がユーザーフォーラムなどで報告されています。まだWindows 10 バージョン1803にアップグレードしていない場合は、もうしばらく様子を見た方が無難かもしれません。


　また、アップグレードして今のところ問題がなくても、しばらくして不具合に気付くことがあるかもしれません。Windows 10 バージョン1709以前のバックアップ（システムイメージ）がある場合は、しばらく保持しておくことをお勧めします。安定しているようだからと、Windows 10 バージョン1803のバックアップで上書きしてしまうと後悔することになるかもしれません。例えば、32bit（x86）版のWindows 10 バージョン1803には不具合があり、システムイメージの作成が「RPCサーバーを利用できません。（0x800706BA）」で失敗することを確認しています。

3月から開始され、5月に完了した、CredSSPの脆弱性対策

　リリース直後にインストールすることのリスクは、Windows 10の新バージョン（ビルド）へのアップグレードである「機能更新プログラム」だけでなく、毎月の第二火曜日（日本ではその翌日の水曜日）やその間に提供される「品質更新プログラム」にもいえることです。Windows 10 Pro以上のエディションであれば、「Windows Update for Business（WUfB）」や企業の「Windows Server Update Services（WSUS）」を利用して更新のタイミングを調整できるので、リスクをある程度軽減できます。残念ながら、Windows 10 Homeエディションにはそのための機能はありません。


　更新のタイミングを調整できるといっても、いつまでも更新しない状態を続けるのは、セキュリティ問題を放置することになるので避けるべきです。Windows Update for Businessには「更新の一時停止」という機能がありますが、この機能を使って更新をストップできる時間幅は「最大35日間」です。Microsoftはおそらく、この35日間を最大の更新間隔と想定しており、この想定に基づいて動いているはずです（更新プログラム自身の不具合の改修や段階的な仕様変更など）。


　この想定に基づいて考えるとしっくりくる事例が、2018年3月に公開された以下のセキュリティアドバイザリで説明されている「CredSSP（Credential Security Support Provider）プロトコルの脆弱（ぜいじゃく）性問題」への対策でした。CredSSPを使用するものの1つに、リモートデスクトップ接続の「ネットワークレベル認証（NLA）」があります。

　この脆弱性は、悪用される可能性は低く、サービス拒否（Denial of Service：DoS）攻撃の対象になるものではありませんが、現在サポート対象のWindows全て（Windows 7、Windows 8.1、Windows 8.1 RT、Windows Server 2008以降のWindows Server）が影響を受けるものです。どのような脆弱性なのか気になる方は、上記のセキュリティアドバイザリで確認してください。


　この脆弱性を緩和する対策は、2018年3月の定例更新の累積的な品質更新プログラム（Windows 10／Windows Server 2016以降の「累積更新プログラム」、Windows 8.1／Windows Server 2012 R2以前の「セキュリティマンスリー品質ロールアップ」）として初めて提供されました。


　しかし、新しいポリシーとして追加された「Encryption Oracle Remediation」（5月の累積的な品質更新プログラム以降は「暗号化オラクルの修復」）というポリシーを構成しない限り、CredSSPの挙動が変化することもなければ、脆弱性が緩和されることもありませんでした。この対策は、4月の累積的な品質更新プログラムにも、累積的なので当然のことながら含まれます。なお、「暗号化オラクルの修復／Encryption Oracle Remediation」という名称は、CVE-2018-0886の脆弱性に由来するものだとは思いますが、詳しいところは分かりません。


　しかしながら、「暗号化オラクルの修復（Encryption Oracle Remediation）」ポリシーが未構成の場合の既定が、3月、4月の更新の時点では「脆弱（Vulnerable）」だったものが、5月の更新で「緩和（Mitigated）」に変更されました。クライアント側が5月以降の更新で最新になってからは、サーバ（Windows Serverではなく、接続先という意味）側が3月以降に更新されていれば、CredSSPの脆弱性が自動的に緩和されるようになりました。一方で、5月以降、リモートデスクトップ接続が見たこともないエラーメッセージを表示して失敗するという現象に遭遇する可能性も出てきました

　CredSSPの脆弱性への対応措置は、3月の更新から段階的に行われたものであり、Microsoftが想定している更新間隔（最大35日）内に更新されていれば、接続に失敗するという影響を受けることはありません。この変更については、3月に公開されたサポート情報「KB4093492」で予告されていました。また、5月初めには、日本マイクロソフトのサポートチームからも詳細な説明が公開されました。しかし、サポート情報や公式ブログによる発信だけでは周知されるのは難しかったでしょう。

　以下の表1にリモートデスクトップ接続について、CredSSPの脆弱性への対応措置が与える影響をまとめました。3月または4月の更新、5月の更新の適用状況と、「暗号化オラクルの修復」ポリシーの構成（または未構成のときの既定値）の組み合わせにおける、接続の可否および脆弱性の状態を示しています。


　3月の更新以降、「暗号化オラクルの修復」ポリシーを構成することで、表1が示すように、CredSSPの脆弱性に対してさまざまなセキュリティ強化策を講じることができるようになりました。

　しかし、表1で注目してほしいのは“ポリシーが未構成時の既定値の影響”です。4月の更新以前は明示的にポリシーを構成しない限り、何の影響もありませんでした（脆弱性は解決されていない状態）。5月の更新により、ポリシーが未構成時の既定値が「緩和（Mitigated）」に変更されたことで、クライアントとサーバの両方が最新状態に更新されていれば脆弱性の影響を受けることなく、安全に接続するようになります（表1の緑の枠で囲んだところ）。一方、サーバ側に3月以降の更新が適用されていない場合は、脆弱性を回避するために接続がブロックされるようになります（表1の赤の枠で囲んだところ）。この部分が前出の≪画面1＞のエラーになったところです。


早急に以前の接続環境を回復するには

　CredSSPの脆弱性対策は、3月から段階的に行われてきたわけですが、予告を知らずに突然、接続エラーに遭遇すると驚くかもしれません。特に、サーバ機はなかなか止められないものです。Microsoftが想定している期間（最大35日）を超えたサイクルで更新を管理し、データセンター内のサーバへの管理アクセスをリモートデスクトップ接続に依存している企業も多いでしょう。接続エラーを回避する方法は、次の【A】～【D】の4つのいずれかになります。CredSSPの脆弱性を放置しないためには、できるだけ速やかに【A】の対策を講じるべきですが、それまでの間は【B】～【D】のいずれかで一時的に接続可能にできます。

・【A】サーバ側に3月以降の累積的な品質更新プログラムを適用します。

・【B】「ローカルグループポリシーエディター」（Gpedit.msc）を使用してクライアント側の以下の「暗号化オラクルの修復」ポリシーを有効にして、保護レベルを「脆弱」に設定します（画面2）。つまり、3月または4月時点のポリシー未構成に戻します。

  • コンピューターの構成\管理用テンプレート\システム\資格情報の委任\暗号化オラクルの修復
  • 【C】上記のポリシー設定と同等のレジストリ設定を行います。コマンドプロンプトを管理者として開き、以下のコマンドラインを実行します。PCの再起動は必要ありません。CredSSPの脆弱性対策は、ポリシーをサポートしないHomeエディションでも行われています。Homeエディションの場合は、この方法でポリシーと同等の設定が可能です。

REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /v AllowEncryptionOracle /t REG_DWORD /d 2 /f


　また、レジストリ設定は、次のコマンドラインで削除することができます。

REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP" /f


  • 【D】リモートデスクトップ接続のサーバ側で、ネットワークレベル認証（NLA）を求めないように構成します（画面3）。次に説明しますが、これは別の脆弱性のリスクを高めることに注意してください。


ネットワークレベル認証なしはDoS攻撃のリスクあり

　CredSSPは、リモートデスクトップ接続のネットワークレベル認証で利用されるため、CredSSPの脆弱性対策の目に見える影響はリモートデスクトップ接続が主なものになります。しかし、CredSSPは、「WinRM（Windowsリモート管理）」や「PowerShell Remoting」「Hyper-Vマネージャー」などの管理ツールでも使用される場合があります。今回の対策がこれらにどう影響するのか明確になっていませんが、リモートデスクトップ接続の接続エラーで判断できるかもしれません。

　ネットワークレベル認証は、Windows XP Service Pack（SP）3からリモートデスクトップ接続のセキュリティ強化のために導入されました。ネットワークレベル認証を使用しない以前の接続では、まずリモートデスクトップ接続のセッションを確立し、その後、そのセッション内で認証を行います。

　一方、ネットワークレベル認証は、資格情報をまず送信し、認証された時点で初めてセッションを確立します。そのため、ネットワークレベル認証は、悪意のあるユーザーが接続先のサーバをスプーフィングするMan-in-the-Middle攻撃や、認証のためのセッション確立とUIの表示を悪用したサービス拒否（DoS）攻撃から保護する防御層になります。

　例えるなら、ネットワークレベル認証は建物のエントランスにオートロックシステムのようなものです。ネットワークレベル認証を要求しないということは、誰でも玄関先までやってきて、ドアを蹴り上げて脅したり、ピッキングやバールでドアをこじ開けたりする機会を与えてしまうことになります


　前述したように、CVE-2018-0886のCredSSPの脆弱性は、DoS攻撃の対象になるものではありませんが、CredSSPの脆弱性対策の影響を一時的に回避するためにネットワークレベル認証を不要にすること（前述の【D】の対応）は、DoS攻撃のリスクを増加させることになる点に十分に注意してください。