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コマンドなどで確認というのはダメw)
ということで、この脆弱性が使えるようになるためには、必ず「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以前で有効らしい)
有効とあるが、「次のサブキーに移動し」と書かれているにもかかわらず、移動先のサブキーがないので、(試すならば)サブキー作成の上、値を書き込む必要がある。
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
テレワークが止まらないので(何)、オンライン会議システムを3つくらい立て続けに使ってみた
私の勤務先もご多分にもれず、原則テレワーク状態に。
そんな中、この短期間に3種類のオンライン会議システムを使うことになったので、個人的な所管ではあるけど書き留めてみようかなと思う。
- Zoom
今やオンライン会議サービスの代表的な選択肢になっている感のあるモノ。
無償で使えるのは40分まで。あとは契約しているサービス内容によって、時間とか付加サービスの内容が変わる風。
遅延も少ないし、共有画面もきれい。これ使ってから、オンライン会議のイメージがガラッとかわった感。 - Microsoft Teams
Microsoftが提供するコミュニケーション基盤。
Business Chatの分野では比較的新参という印象を受ける。
これもまた、オンライン会議の機能を持っており、会議へのinviteはOutlook(筆者が仕事で使ってるのは、Outlook 2016)からボタン一発で行えるのが便利(プラグイン使えば、他のものでもできるのかもしれないけど、TeamsもOutlookもMSの製品であることを考えると、最初からこの機能が使えるOutlookを利用していれば、超便利)。
画面共有はきれいだけど、音声通話は少しラグが生じるところが残念。 - WebEx
Ciscoが提供するオンライン会議サービス。
このサービス領域では、結構老舗の部類に入る。
ネットワーク屋さんが開発・提供しているサービスだけあって、音声の遅延は小さい。でも(理由はわからんけど)画面共有はあまりきれいではない。
Zoom、Microsoft Teams、WebExのいずれも有償プランはあるけど、無償でもある程度は利用可能*1。これはありがたい。
いずれのサービスも、プランの選択次第で電話経由でも会議に参加できるようになるが、気をつけないと会議参加用の電話番号がアメリカのものになったりするので注意w。
個人的に一番推したいのは、やっぱZoom。
好きに使えばいいという話はあるけど、紹介した3つのサービスの中で、専業でやってるのはZoomだけなんだよね(いずれどこかに買われるのではないか?とも思ってるけど、今のところは専業)。Microsoft TeamsもWebExもいいサービスではあるんだけど、手軽さという点ではZoomが頭一つ抜けている*2。試す敷居も低く、インタフェースも洗練されており、直感的に使用可能。
このところ、世の中いろいろと暗い方向の話が多いけど、こういう時だからこそポジティブに動けるところはそう動いていこう、と思うのでした。まる。
VBAマクロについての覚書
VBAでネットワーク使う時に、いろいろと制約事項が出て来やしないか?というので調べてた。
結論は以下のとおり
- HTTPリクエスト系は、VBAマクロで普通に書ける
- WinSockを用いたネットワークアプリケーションは、どこでも動くものを書くのは困難(MSWINSCK.OCXが必要だが、このOCXファイルはVB6ランタイムに含まれるらしく、Windows 10で使うのはちと勇気がいる(というか普通には入っていない))。
いろいろと凶悪なBotが出てくる中で、マクロで完結させられるかどうか?の調査をしていたのだけど、とりあえず素の状態でVBAでネットワークを、というのは難しいという結論になりました。
ファイルレスマルウエアは「ファイルは作らない」が、何も作らないわけではない
標的型攻撃に「ファイルレスマルウエア」が使われるようになって久しいが、標的型攻撃を仕掛けるモチベーション(きっかけ/やる気の源)は一体何か?を考えてみよう。
- 仕掛ける相手の持ってる情報が欲しい
- できれば長い期間、情報を継続的に獲得したい
- でも、仕掛ける相手に侵入するのは結構手間
となると、何らかの方法で(だいたいはHTTP/HTTPS経由)情報を持ち出す手段を攻撃を仕掛ける相手に仕込みたいとなる。
ファイルレスマルウエアは、単純にファイルをスキャンするツールではみつからない。
しかし、単にメモリ上にしか存在しないマルウエアは、永続性の観点で不安定である。「再起動したら消える」脆弱な存在だ。
それでは、永続化するためにはどうしたらいいのだろうか。Windows上でファイルレスマルウエアを永続化するのは、(わりかし)容易かなと思う。以下、例えばこんな方法がある、ちうのを挙げていく。
- サービスに登録したPowershell等のワンライナースクリプト
- タスクスケジューラに登録したPowershell等のワンライナースクリプト
別にPowershellに恨みがあるわけではないがw、Powershell上のワンライナースクリプトを用いて外部からプログラムを取得し、それを実行するというのはありうるし、ワンライナーでも結構なことを行える。
さらに、外部に情報を持ち出すときにも(本当にファイルレスならば)一時ファイルを作成せず、「ファイルを読む→HTTPリクエストに読んだ内容を乗せる」という処理を繰り返すし、RATっぽいものも動かして、外部からの制御を受け付けるようC&Cサーバに接続を行わせることも可能だ(今だったらこっちか?)。
ということで、「ファイルを作らない」だけで、痕跡はあちこちに残るため、その痕跡を逃さないために、例えばEDRであったり(端末セントリックだが、ログは集中管理されるのが普通なので、後述するSIEMとも絡んでくる可能性あり)、SIEMであったり(各種ログセントリック)というツールを導入・運用していくという話になってくる。
攻撃者の立場に立って考えると、「永続化」という話は重要なポイントなので、永続化のための手法を押さえておくと、攻撃された痕跡を見つけるのに役立つかもしれない。
ファイルレスマルウエアは「確かに」ファイルは作らない
「本当に」痕跡が残らないと、そもそもどこからも何も検知できないが、実際には検知できているし、そのためのソリューションもある。
じゃあ、どこで検知しているのか?というのを少し考えてみよう。
フォレンジック関係ツールの検証やってみた(少しだけ)
思うところあって、TSURUGI Linuxを使ってみた
TSURUGI Linuxは、デジタルフォレンジック向けのLinuxディストリビューション。
デジタルフォレンジックに使えるLinuxディストリビューションには、例えばKali LinuxやSANS SIFT Workstationなどがあるが、今回あえてTSURUGI Linuxを使ってみたのには理由がある。
- わりかし新しいディストリビューションである
- Acquire向けの機能に絞ったISOイメージを配布している
- 起動するだけであれば、誤ってHDDイメージを壊すことがない
新しいのはまぁいいとして、なぜ2,3が重要なのか?を以下に述べる。
まずは2から。実際にフォレンジックをやったことある人ならば経験ある人もいるかもだけど、HDDイメージを取得する時に、普通に配布されているLinuxディストリビューションではうまくいかない(そもそもブートすらしない)ことがある。
ブートすらしない理由は、経験的にはIA32の拡張機能であるPAE(物理アドレス拡張)が関係していることが多い。PAEをサポートしないCPUでは、PAEを有効にしたカーネルでブートさせられないため、いろいろと小細工が必要になってくるが、TSURUGI LinuxのAcquire用イメージは、PAEなしCPUだろうとCylixだろうとTransmetaだろうと(ブート時のメッセージを読む限りは)サポートしており、わりかし安心して動かせる(速度は遅いがw)。
環境によってはGUIがうまく動かない(画面がうまく出ない)ことがあるが、この場合であってもCtrl + Alt + F1を押下することで、CUIログイン画面が出る。実はThinkPad X31でGUIがうまく動かなかったのだが、Ctrl + Alt + F1を押下し、ユーザ名root、パスワードなしでログインできた。
そして3。TSURUGI Linuxは、起動した段階では(少なくとも)ブートデバイス以外のHDDやSSDは、接続形態を問わず書き込み禁止状態になっている。あとでUSB HDDを追加しても、追加したHDDはかたっぱしから書き込み禁止状態になる。この状態であれば、起動しても(所定のコマンドを知らない限りは)書き込みをできるようにならない。
TSURUGI Linuxでブート後HDDを書き込み可能にするためには?
blockdevコマンドを用いる。
wrtblkコマンドをはじめとして、複数のそれ向けコマンドがあるが、これらのコマンドはシェルスクリプトであり、中でblockdevコマンドを実行している。
詳しくはblockdevコマンドのヘルプをみてもらいたいが、少なくとも書き込み禁止状態を解除するだけならば、blockdev --setrw <書き込み禁止を解除したいデバイスファイル名> とすることで、書込み禁止状態を解除できる。
ファイルシステム作成時とマウント時のblockdev --setrw の範囲の違い
ファイルシステムを作成する時には、作成するデバイス(パーティション)に対応するデバイスファイルのみをblockdev --setrwすればいいが、マウントしたりという時には、そのパーティションが含まれるHDDを指すデバイスファイルもblockdev --setrw しておかないといけない。そうでないとマウント時にread onlyモードにされる。
商用ツールだと、EnCase ImagerやFTK ImagerがTSURUGI Acquireに近いが、多分TSURUGI Acquireのほうが使い勝手がよい
フォレンジックをやる人の中には、イメージ取得にEnCase ImagerやFTK Imagerを使う人も多いと思う。
しかし、EnCase Imagerは入手方法がわからず(私は30分格闘してあきらめた)、FTK ImagerはWindows版は64bit版しか配布されていない。ところが、TSURUGI Acquireの中にはなんとFTK ImagerのLinux 32bitコマンドライン版が含まれている。FTK Imager のLinux 32bit コマンドライン版はなかなかステキな機能がある。個人的には以下の2つがツボった。
- デバイスファイルやraw形式のファイルを入力に指定可能
- e01形式(EnCase形式)で出力可能
もうこれだけでも使う価値がある。
64bitカーネルが動かない/64bit Windowsでないなどの理由でFTK ImagerやEnCase Imagerが使えない場合でも、マシンを落としてOKならば、TSURUGI Acquireを使ってイメージを取得することが可能だ。
TSURUGI Linuxの弱点:とりあえずドキュメント類に乏しいw
まだ出たばかりなのでしょうがないといえばしょうがないのだけど、まだドキュメント類はそんなにない(というかほとんどないw)。まずは自分でいろいろ使ってみて、情報量を増やすのはアリかなと思った。