【Windows系】脆弱性レポート(CVE-2020-1472)Netlogonの特権昇格の脆弱性の対応まとめ
初投稿(3人目)です。
仕事で調査した脆弱性について、少し面白かったのと報告書作るのに少し苦労したため、ナレッジ共有も兼ねて投稿します。
※できるだけ、現在本脆弱性の対応に追われている人が読みやすいように書くつもりですが、、、
1.はじめに
題名にもあるようにMicrosoftから「CVE-2020-1472」のレポートで発表されました、「Netlogonの特級昇格の脆弱性」についてお話しようと思います。
本脆弱性がMicrosoftから発表されたのは2020年の8月で、すでに1年半も経っている脆弱性になります。
詳しい内容は上記リンクの公式レポートを確認してください。
本脆弱性を一言でまとめると、「ドメインコントローラ(DC)に対して、認証に使う通信(Netlogon)を悪用すると特級昇格できちゃう脆弱性があるよ」ってことらしい。
(うーん、雰囲気はわかる)
長々書いても仕方ないので、筆者の場合の結論(対応方法)について記載していきます。
2.結論(筆者の場合)
※あくまでも筆者の場合です、鵜呑みにして対応はしないでください。。。
影響の出るシステムについて
まずはこちらから洗い出していきます。
■Active Directory(Windows Server)
こちら、もちろんActive Directoryを扱う環境は脆弱性の対象です。
(きっとここに流れ着いた、人たちもWindows管理者でしょう。。。)
■Samba(Linux)
こちらも認証系を行っているものになりますので、脆弱性の対象になります。
とりわけ、Active Directory と併用してLinux系のシステムを管理しているような環境だと対応範囲が広くなります。
大きく分けると、この2つです。(他にもあったらごめんなさい…)
対応方法~Active Directory(Windows Server)~
こちら、まず保守しているWindows Serverがサポート期間内のものか確認をお願いいたします。
(サポート切れてる環境を保守している人なんていないと思いますが・・・)
サポートされていましたか？
では、次にSambaを用いた環境でないことを必ず確認してください。
Sambaが環境にないこと確認できましたか？
では、累積更新プログラムを当ててください。
以上です。
！？
そうなんです、こちらサポート期間内のWindows Serverであれば2021年2月以降の累積更新プログラムを当てれば対応は終了になります。
今回の脆弱性はWindows環境だけに限った話なのであれば楽勝です。
問題はSamba(Linux)等のMicrosoft製品以外のDCを利用している場合です。
(Sambaを使われている皆様おまたせしました。かつ、今回はSambaに絞ってお話します。)
Sambaを利用されている(恐れがある方も)方はまず、2020年の8月11日から2021年1月12日までに配信された累積更新プログラムを内容を確認の上でActive Directoryを保有するWindows Serverに当ててください。
その上で適用後から出力されるイベントログを監視してください。
次のイベントIDについては、対応が必要になります。
イベント ID 5829
これは、脆弱な通信を利用してDCに接続しているコンピュータを検知した際に表示されるイベントIDです。
こちらが今回対応が必要になるイベントIDになりますので、必ず確認をお願いいたします。
その他のイベントIDについても出典のURLに記載がありますので、もっと詳細に切り分けを行う方は御覧ください。
上記イベントIDで対応が必要なコンピュータの切り分けを実施してください。
これの対応に伴い、MicrosoftからもイベントIDの確認に役立つツールを公表しています。(以下リンク参照)
次は、Sambaの構成内容を確認して対応を行いましょう。
対応方法~Samba(Linux)~
では、Sambaの対応になります。
むしろこっちがメインでしょう。
Microsoftも脆弱性の報告が上がってから約半年間は脆弱性の穴をわざと開けていたのはSamba等のActive Directory 以外のDCの対応を行ってもらうためです。
※「3.脆弱性の原因と対応年歴」の箇所で、Microsoftの対応年歴も確認します。
確認項目は以下です！
Sambaのversionを確認する
Sambaのverが4.8以上の場合
Sambaの構成ファイルであるsmb.confを確認
confに「server schannel = no」または「server schannel = auto」と記載された設定が存在しないこと
Sambaのverが4.8未満の場合
Sambaの構成ファイルであるsmb.confを確認
confの[global] セクションに「server schannel = yes」と記載された設定が存在すること
以上が、(私が行った)対応になります。
ちなみに、RHEL7以上ですと、デフォルトでSambaのver4.8以上が入っているらしいので特別な対応は不要になります。
3.脆弱性の原因と対応年歴
脆弱性の原因
さて、対応方法などを確認していろいろ疑問に思ったことがあったかもしれませんが、今からその部分を解消していければと思います。
まず、脆弱性の原因ですが、こちらも簡単にまとめると以下のになります。
全て0の平文を入力として与えると、一定の確率で平文と全く同じ全て0の暗号文が生成されるという事態が生じてしまう脆弱性である。
上記、脆弱性の特徴からNetLogonの通信時にゼロ埋めされた暗号文の生成を実施できることから「ZeroLogon」といった名称がつけられました。
細かいNetLogonの仕様についてもアウトプットの一環として記載しようと思ったのですが、思いの他ややこしい(のと、間違った情報をお伝えしかねない)ので、詳しい内容が知りたい方は上記出典でも使わせていただいたレポートをご確認ください。
上記のような脆弱性に対応するべく、MicrosoftはSecure RPCを利用した通信が「強制」される更新を2021年2月の累積更新プログラムから追加したため、対応が必要になりました。
では、Microsoftはどういった対応をとったのか簡単にご説明いたします。
脆弱性の対応年歴
Microsoftは、まず公表した2020年8月のタイミングでまず累積更新プログラムに以下のような更新を加えて配信いたしました。
フェーズ1(2020年8月より)
「安全な RPC (Secure RPC)」の既定での利用:
ドメインコントローラが、Netlogon セキュア チャネル接続で「安全な RPC (Secure RPC)」を既定で利用するようになり、「安全な RPC (Secure RPC)」を利用できるドメイン端末間では「安全な RPC (Secure RPC)」を利用します。
（こちらはあくまでSecure RPCが利用できなくてもDC間通信ができる状態のままです。）新しいイベントログ:
DC でアカウントが拒否された場合や強制モードで拒否される可能性がある場合に、DC は新しいイベントのログを記録します。
(こちらは簡単に2.結論(筆者の場合)でも書かせていただきました)
続いて、2021年2月のフェーズ2で以下のような更新を累積更新プログラムに追加いたしました。
フェーズ2(2021年2月より)
「安全な RPC (Secure RPC)」の強制:
ドメインコントローラにて、Netlogon セキュア チャネル接続で「安全な RPC (Secure RPC)」の利用が強制されます。「安全な RPC (Secure RPC)」を利用できない「非準拠デバイス」は、ドメインコントローラと接続できません (ただし「ドメイン コントローラー:脆弱な Netlogon セキュア チャネル接続を許可する」グループポリシーで指定したデバイスは接続を許可されます)。イベントログ機能の更新:
ID 5829 を記録する機能は削除されます。すべての脆弱な接続が拒否されるため、システム イベント ログに ID 5827 と 5828 のみが表示されるようになります。
こういった流れでMicrosoftは更新プログラムを修正していき、本脆弱性の対応を行ったそうです。
こちらのMicrosoftの対応について書くにあたって参考にしたサイトは以下になります。
なんとなく本脆弱性について理解できたでしょうか？
4.感想
最後、感想になります。
「なんだ、今更そんな話してるのか」って方もいたかもしれません。
私のように今更この問題に取り組んだ人間からすると「先人の方々よ、結局どういった対処をしたのだね？」といった記事がやはり多かったです。
(仕事で本件の報告書を書くことはあっても、インターネット上にこういった形で対応レポートを公開することはないですもんね。。。)
加えて、対応方法を見て感じたと思います、「なんだ、複雑な対応いらないじゃん」と
複雑な対応がいらないからこそ、報告書作成の時に労力に見合わない裏どりをした上で、対処不要の理由を列挙しなくてはならず、累積更新プログラム適用の承認を取るのに少し苦労しました。
今回のことで思ったことは、Windowsの管理を行っている者としてはMicrosoftの脆弱性レポートくらいは少し目を通しておいてもいいかな〜と思いました。
(あと、累積更新プログラムの適用頻度をもう少し早めていくようにお客様に打診するべきとも。。。)
Windowsはもはや社会インフラになり、多くの企業でも採用されていますし、Microsoftから公式ドキュメントも多く出ているのに、「結局対応方法が不明瞭。」みたいなことが多いので、今後は共有できる範囲で備忘録としてこちらでアウトプットできればと考えています。
では、、、
(来週はITに関係ない週報にしたいな〜。)