CVE-2020-10136～IP-in-IPに脆弱性…
久しぶりに個人的なツボにはまる脆弱性が…
CVE-2020-10136の脆弱性概要
詳しくは以下のJVNの記事を見てください。
要は「IP over IPを実現する規格の1つで、悪用される脆弱性があるからね」というもの。
この脆弱性を悪用すると、何ができるのか？
脆弱なIP-in-IPを使えるところを経由して、好きなところにIPパケットを送りつけることができます。いわば「IPパケットプロキシ」のような感じです。
IP-in-IPは、以下のRFCに記述されています。
TCPコネクションが必要など、戻りパケットが必須な攻撃を仕掛けるためには、少しアタマを使う必要がありますし、DDoSのように「大量にあちこちからパケットを送りつける用途」には若干効率が落ちる可能性はありますが*1、単にパケット送りつけられればいいという話であれば、これは非常に有用な脆弱性になります。
対策のサマリ
該当するJVN（http://jvn.jp/ta/JVNTA90492923/index.html）にも記述はありますので、そちらをご覧いただきたいですが、個人的にはそれも含めて以下の3つのいずれかになる、と考えています。
以下、上記のような結論に至った経緯を説明します。
IP-in-IPの通常利用と悪用のイメージ
以下に、通常の利用イメージ（あくまでイメージｗ）を示します。
普通ならば、Normal Userが、IP-in-IPサービスを経由して、任意の（Normal Userが通信したい）ホストにIPパケットを送りつけます。
詳細は省略しますが、通常はNormal Userとの間で、IP-in-IPを利用したトンネルを開設していると考えられるので、戻ってきたIPパケットは、宛先IPアドレスがNormal Userのものであれば、またIP-in-IPを使ってNormal Userに送り届けられます。
ところが、通常のIP-in-IPの規格を見ると、以下のようなことも可能そうです…。
そして、今回の脆弱性は、どうもこういうことが出来てしまう、というように読めます。
ポイントは、Normal UserもAttacker（攻撃者）も、フォーマットが正しいパケットさえ送っていれば、カプセル化を解除の上IP-in-IP serviceを提供するコンピュータ上での処理が走る、ということです。
攻撃者が送りつけたいIP packet2とIP packet3は、送信元IPアドレスに何が入ってるかわからないですが、IPパケットを送りつけるだけで成立する攻撃を仕掛けたいのであれば、これだけで事足ります。
JVNで挙げられている対策～送信元を限定した遮断は「役に立たない」
今回、該当するJVN（http://jvn.jp/ta/JVNTA90492923/index.html）には、以下の4つの対策が記述されています。
- アップデートする
- IP-in-IP を無効化する
- PoC を確認する
- 侵入検知システムでフィルタリングする
この中で、1のアップデートについてはよくわからない*2ですが、2についてはすべてのIP-in-IPを遮断・無効にする対策であり、使わずにすむのであれば、それが一番いいと思っています。
なお、よく言われる「送信元を限定する」対策は、今回の場合は役に立ちません。理由は後述します。
3は確認のための手段なので、有用といえば有用ですが、それで何かの対策になるか？は怪しいです。3を実施して、影響あるとなったら1,2,4のいずれかを実施する、というのが正しいでしょう。
4は「検知する」だけであり、これだけで遮断はできません。
送信元限定が対策にならない理由～IPはステートレス＆IP-in-IPは認証レス
送信元限定が対策にならない理由は2つ。
- IPプロトコルはステートレスである
- IP-in-IPに認証の仕組みがない
IPプロトコルがステートレスであり、かつIP-in-IPそのものには認証のしくみがないため、別の認証手段が必要となります。実際、RFC2003（RFC 2003 - IP Encapsulation within IP）でも、Authentication Header（RFC 1826 - IP Authentication Header）について言及されています。
じゃあ対策は？～IPsecを使うこと。でもこの時点で、IP-in-IPいらなくね？
ここまで読んでくれた人はもう理解したと思いますが、安全にIP-in-IPを使うためには、IP-in-IPパケットの送信元が正当であることを確認出来る必要があります。今、IPパケット単位でこのようなことを実現できるポピュラーな技術はIPsecです。実際、前述のAuthentication Header（RFC 1826 - IP Authentication Header）も、IPsecを実現する1つの形態です（パケット認証のみを行うモード）。今はだいたいESPだけで暗号化＋認証いけてしまうのですが、AHのような認証だけ行うというのも今回の場合は有効である、ということです。
もっとも、ここまでやっておいて、IP-in-IP + AHとするくらいならば、IPsecトンネルモード使えばいいんじゃないか？と思うのはオレだけではないはずです。
むすび～IP-in-IPを使うならばベンダの修正を適用 or AHを併用する or 他の選択肢を採用できないか？を考えよう
今回の脆弱性は、いろいろとステートレスの意味を考えさせられるものでした。
とりあえず「不正なIP-in-IP通信を検知できる」というところでしのいで（問題は、しのいだところで不正なパケット送付を防止できるわけではないこと）、ベンダ製装置を使用しているのであれば、修正を適用する、もしくはIPsec AHを使う、もしくは別の手段に乗り換えるかというくらいしかないです。
テレワーク関係で「即座に」留意しなきゃいけないこと
さんざん書くだけ書いて、すっかり忘れてたｗ
テレワーク関係で「即座に」留意しなきゃいけないことその1～リモート操作ツールのファイル共有機能
例えばWindowsのリモートデスクトップを使う場合、ローカルのドライブをRDP経由でアクセスさせることが可能です。
また、クライアントとサーバの間でファイルをコピペすることも可能です。
ポリシーで禁止することは可能だけど、忘れないでね。
当然、TeamViewerやVNCなどでもファイル転送は可能になるケースはありますし、いわゆるリモート操作系ツールではファイル転送の機能は結構な高確率で実装されているので、ファイルの持ち出しとか點せたくない場合には注意。
テレワーク関係で「即座に」留意しなきゃいけないことその2～オンライン会議サービスのファイル共有機能
これも上記と似ている課題。
契約した側でオフにしたり、会議開催側が無効にしたりとできるみたいだけど、このあたりも留意して使う必要があります。
ファイル持ち出しは、DRM等のツールを使うことで、ある程度はリスク緩和可能
DRM（デジタル著作権管理）のためのシステムを活用することで、ある程度はファイル持ち出しに対抗することが可能。
でも、対応可能なファイル形式に限界があったり、本当に必要があって持ち出す時に（DRM解除しないで）使えないなどという話もあるので、運用が少し難しいかも。
あと、導入にあたり、例えばActive Directoryが必要だったりというケースもあるので、このあたりのものの導入は計画的に。
PPAPは役に立たない
PPAPは、「Passwordつきzip暗号化ファイルを送ります. Passwordを送ります. Aん号化（暗号化
ということで、PPAPは即座に捨てることをお勧めします*1。
おまけ：PPAPがなぜもてはやされている()のか＆その害悪っぷり
諸説ありますが、ISMSの審査観点にこのような手法を取ってデータを保護しているか？という説が個人的には最有力だと考えています。
あと、たまたま「ISMS」「メール」「暗号化」の3つのキーワードで検索をかけたところ、見つかったページの1つに以下のような文章がありました。
様々な企業が「メール添付ファイルのZIPパスワード化」を行っており、そして様々な人が、その方法について議論しています。確かに、技術的な側面から見れば、ZIPパスワード化は無意味かもしれません。
しかし「ヒューマンエラーをなくす」という観点から見れば、1つの立派な情報セキュリティ対策といえます。
ここについては、大いに異を唱えたく。
- 「無意味かもしれません」ではなく「無意味」です
- 「ヒューマンエラーをなくす」という観点から見れば、1つの立派な情報セキュリティ対策といえます→控えめにいっても「いえません」
この論を唱えている会社の製品を見たところ、以下の処理を行うシステムを販売しているように見えました。
- メールに添付されたファイルを抽出し、パスワード付きZIPで保護する
- 元の添付ファイルは削除し、かわりにパスワード付きZIPを添付する
- 元メール内で指定された送信先に、パスワード付きZIPで保護されたファイルを添付したメールを送信する
- 元メール内で指定された送信先に、パスワードを記述したメールを送信する
おそらく、ヒューマンエラーと言ってるのは、「暗号化し忘れを防ぐ」ということだと思うのですが、機能的には送信先の指定誤りには対応できません*2。
そもそもPPAPが無意味である＆その根拠を示している人がいるにもかかわらず（リンク先の記事は比較的最近ですが、主張自体は前から存在します）、無意味とされた手法を金科玉条のごとく遵守する、ということ自体が滑稽である、と考えます。
本質的に暗号化には、機密性を担保する役割があります。暗号化を施すことで、以下の2つの効果を期待できます。
- 途中経路での覗き見に対抗する
- 誤った送信先（閲覧権限のない相手）に機密情報を添付したメールを送ってしまった場合であっても、内容の閲覧はできないようにする
PPAP自動化を行った場合、1も2も達成できないどころか、「システム入れたから大丈夫」という謎の安心感から、いわゆる機密情報誤送信系のインシデントの発覚が遅れる懸念があります。なにせ、暗号化、暗号ファイル添付したメール送信、パスワード送信の一連の操作を自動化してくれてるので、送信先を誤った時には、そのまま暗号化ZIPとパスワードが誤った送信先に送られます。
これならば、アクセスリストをきちんと設定したオンラインストレージの上にファイルを置いておくほうが、はるかにマシです。
また、筆者は、上記以外にも「害になるであろうケース」を発見しています。
- 添付ファイルの暗号化が「広義でのメール改ざん」になるため、PGP等の署名検証が失敗する
- 署名データそのものが暗号化される懸念がある
PGPで再署名したくても、秘密鍵は送信者の手元にあるのが普通であり、変なシステムに預けるとか危険極まりなくてやりたくありませんし、できません。
その他、筆者はまだ経験したことはありませんが、最悪「PGP等で暗号化されたデータがさらに暗号化ZIPに含められる」という、冗談のようなことが発生することも想定されます。
冗談のようですが本当に起こった（もしくは起こりうる）害悪を前にして、これをして「セキュアである」という方は、ぜひその根拠を教えて下さい。もしくはもっとシンプルに「PGPよりもPPAPのほうが安全である、という根拠を示せる人がいたら、ぜひ私に教えて下さい」。
書いていて、PPAPが想像以上にダメなことを再確認してしまって、頭が痛い…
テレワークはいいかもしれないが、導入を決めるまでが結構大変かも…（制度、技術、セキュリティをどう考える？）
書いたら長くなった…けど、何らかの議論のネタなりになればということで、とりあえず放流する。
「テレワーク」というと、なかなか魅惑なパワーワードだが、ちょっとアタマを巡らせると、かなり大変であることがわかる。
大変といっても、実は文章の読み替えをやったり考え方を柔軟にしたりということをできれば、あんまりハードルにならないのかもしれないが、考えないといけないことをとりあえずざっと書いてみた。
とりあえず、一つの思考実験的に書いたものなので、考え違いや抜け漏れあるかもしれないが、そこはご容赦を。
1. 制度面の課題
テレワークというと、オフィスにいなくても仕事が出来る、とポジティブに考える人が多いが、会社の就業規則などの面を考慮すると、結構な難事が出てくる懸念がある。
とはいえ、（最初に結論を書いてしまうが）何のための業務で、どんな成果を期待するのか？が明らかになれば、下記の話は（本質的には）問題にならないことが多い。むしろ問題にする人がいるとしたら、「既存ルールの整合性をどのように取るのか」ということを考えなければいけない人であろうと考える。
1.1. 就業場所に関する規則
こんなこと書くと、「また昭和かよ」と言われそうだが、別に平成の早いうちでもこういう話はいくらでも出てきていたので、昭和だの平成だの令和だのというようにくくらないでほしい。
基本、テレワークのような就業場所にとらわれない働き方を前提に出来るのは、最低限3つの前提を満たす必要がある、と考えてほしい。
- 特定の就業場所に行かなくても遂行可能な業務であること
- 就業規則等で、特定の場所以外での業務遂行を認めていること
- 顧客との契約上、特定の場所以外での業務遂行を認められていること
個々の業務特性を考慮すると、さらに条件は細分化されるが、とりあえずざっくり上記3つについては、「最低限」押さえておかないといけない、と私とかは考える。
1.2. テレワークに係る費用負担
テレワークは、インターネットのような安価かつリーズナブルな通信帯域を「誰もが」利用しうる状況になって、はじめて可能になった就労形態とも言えるが、そこにかかる費用を（たとえ少額とはいえ）労働者の持ち出しにしてよいのか？という議論が出てくる懸念はある。そこは、光熱費なども同じことが言える。
1.3. 労働時間の算定に関する課題
「8:30～17:00勤務」とか、固定的な労働時間帯を設定し、そこは業務専念すべし、という話になってくると、結構ややこしい。そもそも「その労働時間帯は適正であるか？」とか、「何を根拠にそう決まっているか」という話も出てくる。
1.4. 勤怠管理および評価に関する規則
これは、労働者当人というよりは、管理者が「どう評価すればいいのか」という話に帰着する。
労働時間については、「一定時間、適切に手を動かしていれば必ず成果が出る」という思想に基づいたものであると考えられるため、そういう考え方がフィットしないような業務であれば、そもそも勤怠管理という考え方をあらためる必要があると考える。
「プロセスもきっちり評価する」という話であっても、「そのプロセスをどう遂行しているのか」がわかればよい話であり、それを時間だけで評価すると、どうしても評価結果が歪む可能性がある。
1.5. まとめ～制度ありきでテレワークを難しくするのではなく、何のためにどういう制度を敷くか？を考えよう
会社における制度は、会社がその社会的使命を果たすために、構成員に求める行動を明文化したものである。
管理のため云々という話はあるだろうが、じゃあその管理は何のためか？というのを考えていくと、最終的にはその会社が何のために業務を行っているのか？に行き着くはず。
個人事業主や構成員の数が少ない会社の場合は、こういう制度をがらっと変えて周知、というのももしかしたら難しくないのかもしれないし、場合によっては明文化も（法令が求めるもの以外は）なされなくてもうまくいくのかもしれない。しかし、構成員（社員）が多くなればなるほど、こういう制度をきちんと決定の上で周知・遵守を促さないと、だいたいの場合はうまく動かない。
しかし、そのために（業務によってはできるはずの）テレワークをしない／させないというのは、非常に残念な結果を招く。
技術的課題はあるものの、可能であれば制度面をきっちり整備して、可能な業務ではテレワークを（ある程度）認める、というように舵を切るのもアリなはずだ。
2. 技術的課題
制度的な課題をクリアしても、次は技術的な課題がある。
オンプレミスを主体とした社内システムや業務システムを持っている会社の場合、テレワークを実施することで、インターネットの出入り口に設置・稼働している機器の負荷が逼迫する可能性がある。
2.1 何がテレワークを阻害するのか？
特に昨今、DaaS（Desktop as a Service）をパブリッククラウドではなくオンプレで（社内ネットワークに）構成している場合には、そのような社内ネットワークを構成している機器の負荷は、設計時のものを超える懸念がある。
- (1) RDPによる画面転送に起因したトラフィック
ここは、当然だが会社からのアウトバウンドが増える。 - 音声系トラフィック
ここは、何を使うかによって、トラフィックの増え方が変わる。 - 動画系トラフィック
ここも、何を使うかによって、トラフィックの増え方が変わる。
1はしょうがないとしても、2,3は問題になりうる。
個人的には、以下の2つの条件が同時に満たされてしまった時に、問題は顕在化しうる、と考える。
- オンライン会議系の外部サービス（例：WebEx、Zoom、Microsoft Teams）をオンプレDaaSもしくは社内に設置したPCで使う
- 社内で構成したオンプレDaaSもしくはPCをRDP経由で「社外から」使う
この2つが場合は、音声系や動画系の情報が、HTTPS経由でDaaSなど社内に入ってきたあとに、RDPトラフィックに乗って社外（利用者のところ）に出ていく。
発生する通信は、社内から普通に利用する時の倍程度（インバウンドとアウトバウンド）の想定。音声だけならばまだしも、資料の画像や動画などが乗ってくると、かなりクる。
あと、オンライン会議を多くの人が使うようになると、今度はアウトバウンドのTCPセッションの数が問題になりうる。普通にStatelessなWebアクセスが大半だったりする分には全然OKで、通常のようにF2Fで打ち合わせを行うなどであればいいのだが、オンライン会議がマジョリティになると、今度はTCPセッションが膨大になる。
このあたり、何の考慮もしていなかったりすると、利用者数が万単位になった瞬間に詰む。まぁ、普通は万単位の利用者がいる場合には、Proxyなどはロードバランサ使って適度に振り分けるはずだが、オンライン会議は基本数十分とか1時間とかセッション張りっぱなしというのもザラである。
トラフィック量（帯域）の話以外だと、テレワークの場合は、プロトコルの限界や、トラフィックをさばく機器の性能問題は、多分トラフィック量よりも先に限界が見えてくる、と思う。
2.2 本質的な技術的課題：会社の環境がすべてのボトルネックになる
他の要因もあるのかもしれないが、何をするにも一旦会社の中に収容され、会社の外に出ていく。管理はしやすいかもしれないが、管理のしやすさと引き換えに、多くのユーザにとって利用しづらい環境（業務アプリケーションを満足に利用できないなど）を実現してしまう。
2.3. とりあえずの解決策の案：せめてオンライン会議くらいは会社を経由させるな
オンライン会議のサービスは、（当然だが）外部のサービスであることが大半だ。
だったら、家から直接使ってもいいのではないか？と考える。
それが出来ない場合は、会社の設備を増強するしかないわけだが、それにも限界がある上に、直接外部のサービスを使ったほうが効率はよい。
もちろん、持ち出し出来ない資料（でも投影は可）を、会議で使うこともあるだろう。この場合は、会議運営を行うホストのみが社内システムに入る形にし、参加者は直接オンライン会議サービスに接続させる、というのでよいのではないか。あとはホストの権限で、ファイルを見せることはできても共有出来ないようなしくみを使う（例えば、ファイル共有機能を無効にする）ことで、ある程度の対処は可能だ。投影内容を写真に取られたらどうする？的な話はあるだろうけど、テレワークを実施させる以上、常につきまとうリスクだ。
完全には難しい場合には、オンライン会議系のトラフィックは、別のNWから外に出す、というのもあるかもしれないが、NW構成が面倒になるだけな気もするので、オススメは最初から会社を経由させない、というもの。
3. テレワークに係るセキュリティ
あまりセキュリティの話はしたくないのだがｗ、オレ自身にそういう属性がついてしまっているので、とりあえずざっと書いておく。
3.1 ソリューションありきで考えない
昨今、「これ使えばテレワークバッチリ！」と煽っているソリューションやツールが多いが（個人的には、Tea○Vie○er使えばバッチリ！と言ってるところがあって、こけそうになったｗ）、ソリューションやツールはあくまで「業務を補助する道具」である。
もちろん、ないよりはあったほうがいいが、そのソリューションを導入したら何が出来て何ができないか、何は制御できるか？という話を、後述する3.2のところでリスクを考える時に、細かく見ていく必要がある。
自分とこに必要なものが何か？をきちんと押さえておくことが重要である。それこそ「監査できること」なども、要件に含めておく必要があるが、これは別にテレワークに限った話でもないか。
3.2 自分のところにとっての「テレワークを認めることによるリスク」を考えよう
テレワークを認めることによって、どのようなリスクが発生するのか？を認識しよう。
1,2で「いけるね」となっても、ここがダメだとそもそもテレワーク難しいね、になってしまう。
3.3 リスクに応じた情報の機密性、完全性、可用性の確保を考える
ある程度リスクを考えることができれば、あとはそのリスクに応じて対処を行うことを考えよう。
- 仕事場以外で仕事をするからといって、情報をお気軽に持ち出されては非常に困る。
- 仕事場以外で会議（オンライン会議）をする時に、大丈夫なしくみがあるか
3.4 リスクが現実になってしまった時の対応プランを考えよう
これは別に、あらためて考えるというよりは、既存のプランがきちんと発動するかどうか？を確認する話と考えてもらえればよい。
何か起こってしまった時に、事象を追跡できるようにする、という話もこの中に含まれる。
裏を返すと、テレワークに必要なツールは、ユーザの行動を（後追いであっても）追跡できるものが望ましい、ということになる。
4. まとめ～テレワークを実施したいのであれば、制度と技術とセキュリティの3面から！
少し長くなったが、最終的に述べたいのは以下の5つ。
- テレワークを出来る土壌があるならば、テレワークを認めてもよいのではないか
- テレワークを認めてもよいのであれば、認める根拠を制度化すべき
- テレワークを実施するにあたっての技術的な課題を考慮のこと
- セキュリティ関連の話は、リスクもあわせて考慮のこと
- 最終的にテレワークを認めるかどうか？は、上記1～4を勘案の上、総合的に判断すること
とはいえ、テレワークやらなくても考えないといけないことも「かなりあるはず」なので、備えをきっちり出来ているところであれば、見た目ほどの作業は発生しない…と思いたい。
…結構長くなったな…。
「Zoom」のその後
IPAから続報が出ていたので、ちょっと見てみました。
www.ipa.go.jpそこには、「どうやったら警告が出てくるのか？」の解説がありました。
なんだ、インストールした後に「買う」とすると、あの警告が出てくるのね。ということで、またまた検証してみました。いろいろと釈然としないのもあるので、とりあえずスッキリするために。
なお、同じことやってマシン壊れたとか調子悪くなったとか言われても、こちらで責任取れないので、試すときは自己責任で。
まずは「Zoom」を起動して「Purchase」を選ぶ
これは、上記のIPAのページでも紹介しているものですが、とりあえず「Zoom」を起動して出てくる画面から「Purchase」を選びます。
一番上を選ぶと、「警告画面」が出てくるはず…なので、確かに警告画面は出てきたのですが、ウチでは違うものが出てきました。
これ、使用しているセキュリティソフトウエアの警告画面です。
この検証自体は、VMware上にインストールしたWindowsで実施しているのですが、VMware - ホストOS - インターネット と出て行く前に、セキュリティソフトウエアが通信を見て、ヤバいURLにアクセスしようとしたら「ここ危険だからとりあえず止めてます」という画面を見せるようになっている、というわけです。
「Zoom」でPurchase押した後は、どんな通信が走っているのか？
簡単に言うと、Webブラウザを起動して、特定のURLにアクセスしようとしています。
見たところ、「Zoom」を開発・販売している会社のWebサイトの"/buy.html"というページにアクセスしようとしているのですが、見たところ、その会社のWebサイトはすでに存在せず、そのかわりに別のサイトにリダイレクトされます。
/buy.htmlにアクセスした際のレスポンスが、「302 Found」なのですが、Webブラウザは、レスポンスに含まれるLocationヘッダで示されたURLにさらにアクセスに行きます。
これ以降、ずっとHTTPSアクセスなので、その中で何が起こっているのか？までは推し量れないのですが、アクセスする中でセキュリティソフトウエアが「危険」とみなしているサイトにアクセスしようとしたため、セキュリティソフトウエアからの「警告メッセージ」が表示された、というのが私のところで起こったことです。
今回「Purchaseボタンを押しちゃった時の対処」＝「ウィンドウを消す」は正しい
今回、不幸にしてさまざまな脅しメッセージを表示されちゃった人もいらっしゃると思いますが、落ち着いてみれば「ブラウザの画面に警告入れたり派手な表示にしたりして、恐怖を煽っている」だけです。
なので、その時になんかのソフトウエアをインストールしたとかなければ、新しく表示されたおどろおどろしいWebブラウザのウィンドウを「ウィンドウの右上にあるバツ印のボタン」をクリックして消せば、さっぱり消えます。
仮に何かプログラムの実行を促されても、決してやっちゃいけません。それは最初に「Zoom」をインストールした時と同じかそれ以上に危険な行為です。
これはZoomだけどZoomじゃない！（意味不明）
みんな大好き＆私も大好きなZoomですが、最近偽物が増えてるという噂を聞きます。
で、我らがにゃん☆たく先生も検証されている。
ただ、にゃん☆たく先生の検証範囲は、「これは僕が使いたいリモート会議のZoomじゃない！」という結論で終わっているように見えるので、じゃあそのZoomはどのZoomじゃい？というのを確認してみました。
なお、本稿では以降、、いわゆるリモート会議サービス「じゃない」Zoomを「Zoom」と称します。
まずはかの「Zoom」をインストール
「Zoom」をどうやってインストールしたか？はおいときます。同じことやって「PCが壊れたどうしてくれる」と因縁つけられても嫌なんで。
普通にインストーラをダウンロードして実行することで、普通にインストールされたわけですが、なるほど。インストール直後に以下のような画面が。
なお、最初にスクリーンキャプチャを取りそこねたんで、「（イメージ）」と書かれてます。上の図は、インストールされた「Zoom」を（わざわざ指定して）起動した図です。Run 3 out of 20 と書かれてるんで、「20回のうち3回起動した」ということで、あと17回起動できます。
「Zoom」の開発元Webサイトにアクセスする（失敗）
次にやったのは、Dachshund Softwareという会社のWebサイトを探してアクセスすることですが、これは見事に失敗しました。理由はよくわからね。
「Zoom」のヘルプを見る
実行ファイルがあるんだから、ヘルプくらいねえのか？と探したら、ありました。
一緒にインストールされていたので、見たところ、以下のような画面が。まっとうです。
ちっこくてわからないかもしれませんが、上記は「What is Zoom?」の部分です。
書かれていることは、「Zoomはソフトウエアの起動、再起動、スタンバイ、復帰を高速化する」ということで、「リモート会議には全く役に立たない機能」ということがわかりました。
さっきのうっとおしい画面は「試用中画面」ということで、金払うかどうするか？を問い合わせるだけのものだった、ということで。
「Zoom」の消し方
普通にアンインストールすれば消えるようにみえます。
上記で「Zoom 1.3.1」を選択し、上の「アンインストールと変更」を押して、アンインストールすれば消えます。
名前がかぶった「Zoom」とZoom（あーまぎらわし）
不幸にして名前がかぶった、機能違いの「Zoom」ですが、インストール時のサポートプラットフォームに以下のような一文が（赤字・協調は筆者による）。
Zoom is fully compatible with Windows 95/98/98SE/Me/NT/2000/XP.
ということで、「Zoom」は、リモート会議のZoomよりも、だいぶ古いであろうことが推し量れます（騙りでなければですが）。
むすび～ソフトウエアを使う時は正規サイトから＆名前だけでなく機能も吟味しましょう
今回検証した結果、「Zoom」は同じ名前でも、機能が異なるソフトウエアというオチでした。しかしこれは、Zoomのサービスをきちんと指定して（今回の場合はリモート会議）検索なりすれば、だいぶリスクは下げられるのではないか？と感じています。
リモート会議のZoomは、自分とこのサービスを紹介するページとかも作っていますし、そもそもZoomを使って開催される会議に参加するだけならば、ソフトウエアをインストールしなくてもいけます。
会議に参加する側は、多分「検索→ダウンロード→インストール」とか複雑な手順を踏まなくても、「https://zoom.us」ではじまるURLをクリックすれば参加はできます*1。
どうしてもZoomクライアントをインストールしなきゃ、という人は、会議の主催をする人か、Zoomの機能をフルに使いたい人じゃないかと思いますが、そういう人は慌てずに、ちゃんとZoomのサービスサイトにログインして、そこからいろいろと探すのが良いかと思います。
もっとも、Zoom会議の招待メールを模したものが来てる気もするので（私のところには来てませんが）、見に覚えのない会議招待は、招待元に確認するなりスルーするなりしてもいいかなと思います。もしあなたがその会議に必須のメンバなのであれば、別の手段で確認が来ます。
Happy Remote Conference!
*1: これはこれで危ういのですが
Windows ExplorerはInternet Explorerとは違う（キリ）
またも新たな脆弱性…。
「Type 1 Font Parsing Remote Code Execution Vulnerability」ですか…
この脆弱性は、 Adobe Type Manager Libraryに存在しており、悪意ある細工がなされたファイルが置かれたフォルダをExplorerで開くと、コードが実行される「かも」という剣呑な代物。なぜ「かも」としているのか？については後述する。
- ADV200006 | Type 1 Font Parsing Remote Code Execution Vulnerability
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200006 （こちらは英語版）
https://portal.msrc.microsoft.com/ja-jp/security-guidance/advisory/ADV200006 （こちらは日本語版（2020年3月25日 03:02追記））
なぜこれが「Remote Code Execution」なのか？
「Remote Code Execution」となってはいるが、この脆弱性を悪用しても、リモートから攻撃者が自由に攻撃対象をつっつけるわけではない。
何らかのファイルをメールでもWebでもいいから攻撃対象に細工したファイルを保存なりダウンロードさせ、当該ファイルを含むフォルダをWindows Explorerで開かせると攻撃が成立する。
このため攻撃者は、以下の3つの段階を経る必要がある。
- 攻撃用ファイルを作成する
- 攻撃対象がダウンロードし、ファイルの内容を確認したくなるような場所に配置する
- 攻撃対象がWindows Explorerで、当該ファイルの所在を確認するように仕向ける（コマンドプロンプトでdirコマンドなどで確認というのはダメｗ）
ということで、この脆弱性が使えるようになるためには、必ず「Windows Explorer」が介在する必要がある。
なんか多くの人が使うファイルを（別途）改ざんして、この脆弱性を利用するようなものに仕立て上げ、ダウンロードさせるということができれば、とりあえず成立するようなものなので、そういう観点に立てば「リモートからコードが実行可能である」と言えるのだろう。
「Windows Explorer」 is not 「Internet Explorer」(!)
上記のアドバイザリを見てると、Mitigationのところに「Windows Explorer」と出てくるが、Windows Explorerは「Internet Explorerとは別物」である*1。
Windows Explorerとは、Windowsのシェルの1つである。そう。フォルダアイコンをダブルクリックすると起動するアレである。
そんな勘違いをするドジは自分だけだと信じたいが、そういうわけにもいかないのと、仮に自分がまた間違えそうになった時のために、これを一応残しておく*2。
「Type 1 Font Parsing Remote Code Execution Vulnerability」を軽減するための具体的な方法
脆弱性の話を書いて恐怖を煽るのは本意ではないが、2020年3月24日深夜の時点でまだ脆弱性修正がリリースされていないので、軽減策を書いておこう。
上記のリンクは、これを書いている時点で英語版しかなく、しかも「英語版Windows」での対処方法しか書かれていないので（当然）、日本語Windowsでどうすりゃいいの？という読み替えがちょっと面倒。
なので、以下でざざっと書いてみる。
やることは「プレビュー」を無効にし、攻撃者が脆弱性を突く余地をなくすこと
Windowsでファイルのプレビュー*3をしようとすると、脆弱なライブラリを使い、結果コード実行に至る、というのがどうも本質のようなので、プレビューをなくすために何をすればいいのか？というにが「Workaround」に記述されている。
Windows Server 2016, Windows 10, and Windows Server 2019でのWorkaroundで記述されているのは、以下のこと。Windows 8.1とかでは用語が違うので、また確認してから追記してみることにする。
- Windows Explorerを起動し、「表示」タブを選択する
- 「プレビュー ウィンドウ」と「詳細ウィンドウ」のどちらも選択されない状態にする（clearする）
- オプションをクリックし、「フォルダと検索のオプションを変更」を選択する
- 「表示」タブを選択する
- 「詳細設定」中の「常にアイコンを表示し、縮小版は表示しない」をチェックし、有効にする
- Windows Explorerのすべてのインスタンスを閉じて、変更を有効にする
具体的にやる方法は、以下のような感じ。
手元の環境で、Windows 10の場合はこうやるんだな、というのを確認した。
とりあえず、（Windows 10とかで）やることはこんな感じなので、何かの参考になれば幸いである。
Window 8.1とWindows 7の場合（これ以降は、2020年3月25日03:32にまとめて追記）
もともとのアドバイザリは、Windows 8.1のWorkaroundとWindows 7のWorkaroundをまとめているが、Windows 8.1は書かれている方法ではWorkaround適用を行えない。「プレビューウィンドウ」と「詳細ウィンドウ」の無効化をする方法が、Windows 8.1の場合はWindow 10の場合と近いので、留意のこと。
具体的には、以下のような感じ。
Windows 7は以下のような感じになっている。
こちらは、Windows Explorerを起動後、「整理」→「レイアウト」と進めばOKだが、そもそもEOLなので、とっとと退役させることをおすすめする*4。
他の対策は？～WebDAVクライアントを無効にする、ATMFD.dllをリネームする、etc...
他にも対策はあるが、これは何をどう突っ込んでいいのかという感じ。
- WebDAVクライアントを無効にする
これは、WebClientサービスを無効にする、ということと同義。
でも、プレビューとかさせなければ済むので、フォルダオプションでプレビューウィンドウとか詳細ウィンドウを表示させなければいいようにも見える。
それ以前に、WebDAVクライアントを使う場合には、相応の理由があるはずなので、業務影響を考慮して無効化する必要がある。使わなきゃならないけど脆弱性は緩和したい場合は、フォルダオプションを変更すればいいはずだけど、もし万全を期してというのであれば、無効化した上で代替策を提示しよう。
その際には、以下のリンクが参考になる。
- ATMFD.dllをリネームする
これは、脆弱なAdobe Type Manager Libraryの実体であるATMFD.dllをリネームして、脆弱なライブラリを使わないようにする対策である。
ある意味本質的（？）とも言えるけど、削除してもいいんじゃないか？とも思うのは気のせいだろうか…。 - レジストリ編集し、ATMFD.dllを無効にする（Windows 8.1以前で有効らしい）
有効とあるが、「次のサブキーに移動し」と書かれているにもかかわらず、移動先のサブキーがないので、（試すならば）サブキー作成の上、値を書き込む必要がある。
Windows 8.1の場合のレジストリ（サブキーがない）
Outlookのプレビューには影響するのか？～回答：影響しません
一つだけ気になったけど、影響なしとのことだったので。
Outlookのプレビューは、また別の仕組みを使っているという認識なので、これはまぁ正しいということで。
まとめ～今回の件も、アドバイザリを適切に読み解けば、「何がヤバくて」「どうすればいいか」という正しい恐れ方と当座の対策は見えてくるので落ち着こう
いろいろ書いたが、個人的に思うのは「Remote Code Execution」と書かれているからといって大騒ぎしても下手を打つだけなので、適切に対処したいのであれば、アドバイザリはちゃんと読もう。
Windows ServerとSMB ServerとWindows ClientとSMB Clientと（あーまぎらわし！）
月刊マイクロソフトで修正されたCVE2020-0796のWorkaroundに関連した情報が、油断するとわからなくなる書き方になっている*1ので、覚書。
記事自体は後述するが、別にこの記事が悪いというわけではなく、用語自体をきちんと押さえておかないと、一気に混乱する恐れがある、というだけ。
SMBv3 ServerとSMB Client
SMBv3 Serverと書かれているが、別にこれはWindows Serverでしか稼働していないというわけではない。Windows 10などのClient系Windows OSでも普通に動作している「Server」サービスに実装されているのが、SMBv3 Serverだ。
同じようにSMB Clientも、Windows Clientでしか稼働していないというわけではない。「Workstation」サービスに実装されているのがSMB Clientである。
- ADV200005 | Microsoft Guidance for Disabling SMBv3 Compression
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200005
SMBv3 ServerとSMB Clientという用語が出てきたら、Windows ServerとWindows Clientの両方が影響する、と思って情報を読み解こう。
CVE-2020-0796のあぶねえところ
CVE-2020-0796のあぶねえところは、リモートコード実行につながるという1点であり、「とっとと修正あてろ」というところなのだけど、これを放っておくとそのうち感染を拡大していくWannaCryのようなのが出てくるかも、というのが嫌なところ。それも、SMBv3（のうち、SMB 3.1.1）という（これまた）Windows使ってりゃ避けられないプロトコル（ただし、実装しているのは一部のWindows）の実装にあるのだから、さらに嫌。ただ、新しい機能であるSMBv3 Compressionの実装で出てる脆弱性なので、影響範囲はわりかし限定的。Windows Server, version 1903 (Server Core installation) 、Windows Server, version 1909 (Server Core installation) 、Windows 10 Version 1903（32bit, x64, ARM）、Windows 10 Version 1909（32bit, x64, ARM）だけ*2
これをうまく悪用されると、勝手に拡大感染して、感染先で好き放題やって、さらに感染を広げるというめちゃくちゃ嫌なものの悪夢が再現する、というのが最低のシナリオである。
Workaroundはレジストリ編集（ただしSMBv3 Serverのみ）
修正ファイルを適用出来ない人に対しては、レジスト編集を行うことで適用可能なWorkaroundがあるが、これはSMBv3 Serverのみである。SMB Clientにはこの方法は使えない*3。
で、先述のとおり、SMBv3 ServerとSMB Clientという用語は、Windows ServerとかClient系Windows OSとかいうのを区別するものではなく、単純にWindows上の機能を区分するものでしかないので、Workaroundを適用する人は、Windows ServerであろうとClient系Windows OSであろうと該当するものには適用しておこう。
SMB ClientはWorkaroundないけど大丈夫なのか？
大丈夫とは言えないけど、対策されていないSMBv3 Serverほどにはリスクは高くない、という感じ。
脆弱性の説明を読むとわかるけど、脆弱なSMB Clientを落とすには、悪意あるSMBv3 Serverを用意して誘い込む（接続させる）必要があるため、まず手間がかかる。
SMBv3 Serverの場合は、口が空いてれば悪意あるパケットをぶちこまれる懸念があるので、Workaroundを適用するか脆弱性修正を行うか、という話になってくる。
参考情報
- ADV200005 | Microsoft Guidance for Disabling SMBv3 Compression
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/adv200005 - CVE-2020-0796 | Windows SMBv3 Client/Server Remote Code Execution Vulnerability
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796
- SMBv3 における脆弱性について
https://www.jpcert.or.jp/newsflash/2020031102.html
