Internet Infrastructure Review（IIR）Vol.32
2016年8月29日発行

Volatility Frameworkとは

この図を見れば分かるとおり、デフォルトではWindowsのプロファイルしか同梱されていません。LinuxやMac OS Xのメモリイメージを解析する場合は、VolatilityのGitHubページ（※49）からプロファイルをダウンロードする必要があります。しかし、すべてのOSバージョンに対応したプロファイルが提供されているわけではありません。また、Linuxでは、Kernelのバージョンアップも多く行われますので、同じOSバージョンでもLinux Kernelのバージョンが異なるという状況も考えられます。

このような場合、使用しているシステムに合わせたプロファイルを自身で生成する必要があります。本稿では自身でLinux Kernel用のVolatilityプロファイルを生成する際の手順を解説します。

プロファイル生成の準備

解析対象システムのバージョンの確認

プロファイル生成マシンの準備

Volatilityプロファイルを生成するためのマシンを用意します（解析対象システムへの変更を最小限にするため、別途マシンを用意してください）。このとき、OSバージョンとLinux Kernelバージョンは上記で確認したものと同じバージョンのものを用意することが望ましいです。なお、プロファイルを生成するマシンはバーチャルマシンでも問題ありません。

Volatilityのダウンロード

Volatilityの実行とプロファイルの生成に必要なライブラリをインストールします（図-16）。一部、gitを使用していますが、Linuxディストリビューションによっては、これらのライブラリのパッケージが用意されている場合もあると思いますので、適宜、インストールを行ってください。
次に、Volatilityをダウンロードします（図-17）。Volatilityはシステムにインストールしなくても実行することができるため、今回はこのまま使用します。Volatilityをダウンロードしたディレクトリ内で「$ python ./vol.py --info」と実行して、エラーが発生しないことを確認してください。

Linux Kernel開発環境インストール

プロファイル生成

「volatility/tools/linux」ディレクトリ内で、makeコマンドを実行します。問題がなければ、同じディレクトリに「module.dwarf」というファイルができているはずです。次に、「volatility/volatility/plugins/overlays/linux/」ディレクトリに、module.dwarfとSystem.mapファイルをまとめたZIPファイルを作成します（図-19）。

拡大する

図-19 プロファイル生成

このZIPファイルがVolatilityのプロファイルとなります。プロファイルに命名規則はありませんが、最低限OSバージョンが分かるようなプロファイル名が望ましいでしょう。より細かく管理するのであれば、Linux Kernelバージョンもプロファイル名に含めてください。
生成したプロファイルがVolatilityに認識されているかどうかは、図-20のようなコマンドで確認することができます。

拡大する

図-20 プロファイル確認

異なるバージョンのプロファイルを生成する場合

ここまで説明した手順で、現在動作しているLinux KernelのVolatilityプロファイルは生成できるようになりました。しかし、同じOSバージョンでも異なるバージョンのLinux KernelやカスタマイズされたLinux Kernelのプロファイルを生成する場合は、作業手順を少し変える必要があります。

Linux Kernelのバージョンが異なる場合

「Linux Kernel開発環境インストール」のステップの代わりに、図-21のように適当なディレクトリにプロファイルを生成したいLinux Kernelのパッケージを展開します。

拡大する

図-21 異なるバージョンのLinux Kernelを展開

カスタマイズされたLinux Kernelの場合

特定の機器や用途向けにLinux Kernelがカスタマイズされている場合、Linuxディストリビューションが配布しているパッケージをそのまま利用することはできません。このような場合、以下のいずれかの対応を行い、Linux Kernelのソースコードを用意します。

1. カスタマイズされたLinux Kernelのソースコードやパッチが手に入る場合、それを利用する。
2. ソースコードやパッチが手に入らない場合、解析対象システムが利用しているLinux Kernelに可能な限り近いバージョンのLinux Kernelソースコードを用意する。また、解析対象システムのカーネルコンフィグを利用して、可能な限り似通ったコンフィグを行う（※50）。

このように解析対象システムで動作しているLinux Kernelに近い状態のソースコードが必要になりますが、これ以外の作業はこれまで解説した手順と変わりません。

なお、Mac OS X用のプロファイルは本稿の冒頭で書いたように、VolatilityのGitHubページからダウンロードすることができますが、新バージョンのリリース直後など、タイミングによっては最新版用のプロファイルをダウンロードすることができない場合があります。生成手順はLinux Kernelとおおよそ同じ（※51）ですので、自分でOS X用プロファイルを生成することを検討してみてはいかがでしょうか。

EMET

EMET（Enhanced Mitigation Experience Toolkit）は脆弱性の悪用を緩和するためのツールで、マイクロソフトが配布しています（※53）。Windowsのセキュリティ機能を最大限有効化すると共に、既知の攻撃手法への緩和策が実装されています。EMETはドメイン配下のクライアントに一斉インストールし、ポリシーを強制することも可能です（※54）。本稿執筆時点での最新版は5.5であり、それを元にEMETを単一ホストで利用する場合の説明します。インストール後、スタートメニューからEMET GUIを起動すると、EMETの管理ツールが起動します。

これで基本的な設定は終了です。以降は管理画面からAppsをクリックし、環境に応じて個別のアプリケーションを追加したり、テスト中や利用中に不具合が出たアプリケーションについて、干渉している機能を個別に外すなどの対処を行いながら、運用をしていきます。

UACの厳格化

UAC（ユーザアカウント制御）はVista以降導入された機能で、管理者権限アカウントであっても通常は特権を無効化しておきます。OSにとって重要な変更が実行中のプログラムによって行われようとした場合に、ユーザに対してその変更は自身が行ったものであるか確認を求めることで、悪意のある変更を検出する機能です。

UACには大きく分けて4段階の設定値が存在し、Vistaではデフォルトで最高値である「常に通知する」が設定されていました。しかし、XPを単体で利用していたユーザはそのほとんどが常時管理者権限を使用しており、Vistaに乗り換えた際、頻繁にUACのポップアップが出現したため、多くのユーザがこの機能を批判しました。そのため、Windows7以降のデフォルトはそれよりも一段低い「アプリがコンピュータに変更を加えようとする場合のみ通知する」に変更になっています。しかし、これにはいくつか欠陥があり、UACを回避してユーザの同意なしに管理者権限に自動昇格してしまう攻撃が実際の事案でも確認されています（※55）。このような脆弱性を避けるため、UACを常に通知する、に変更して運用した方がよいでしょう（※56）。

1. コントロールパネルから、ユーザーアカウント、ユーザアカウントとたどります。
2. ユーザアカウント制御設定の変更をクリックすると、図-25が表示されます。
3. Windows 7以降は上から2番目が設定されているので、スライドを一番上に引き上げ、OKを押します（図-26）。

これで自動昇格が起こらず、常にポップアップが出現し、管理者ユーザが異常に気づきやすくなります。

WSHの無効化

WSH（Windows Script Host）はホスト上でVBScriptやJScriptを実行するための機能です。前号のIIR Vol.31「1.4.1 各種のランサムウェアとその対策」でも記載したとおり、TeslaCryptやLockyではJScript（.js）がメールに添付された事例が確認されています。また、過去にはショートカットファイル（.lnk）内にVBScript（.vbs）を埋め込んだものをメールで送信する手口も確認されています。このような攻撃を防ぐために、レジストリエディターを使用して以下のキーに値を追加し、この機能を無効化します。

• キー
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings
• 値の名前
  Enabled
• 値のデータ（DWORD値）
  0

無効化すると、.jsや.vbsをダブルクリックしたり、cscript.exeを実行した場合、警告が出ることが確認できます（図-27）。

拡大する

図-27 WSHが無効化されたことの確認

rundll32.exe、regsvr32.exeの通信の禁止

rundll32.exe、regsvr32.exeはVBScript（.vbs）やJScript（.js）ファイルをリモートのホストからhttpなどを経由して取得し、実行する機能があります。これは攻撃者に使われうる機能であるため、禁止すべきです。ただし、rundll32.exeやregsvr32.exeは通常のWindowsの処理中にも使われているため、実行そのものを禁止することはできません。そこで、セキュリティが強化されたWindowsファイアウォールの送信の規則など、パーソナルファイアウォールの機能を用いて、これらの実行ファイルが外部と通信するのをブロックします。64bit環境の場合、SysWOW64側にも実行ファイルが存在するため、同様にブロックします。

拡大する

また、C:\Windows\WinSxS以下のフォルダ内にもこれらの実行ファイルが存在する可能性があるため、それも禁止する必要があります。

PowerShellの禁止

PowerShellはWindowsの管理やWindows APIを呼び出したりできるなど、非常に強力なWindowsのスクリプティング言語です。デフォルトではファイル化されたスクリプトが実行できないようになっていますが、この制限は簡単に回避できてしまいます。また、ショートカットや外部に存在するスクリプトをHTTP経由で直接実行することができるなど、実際の攻撃に利用されていることが確認されているため、一般ユーザが実行できないようにAppLockerやソフトウェアの制限のポリシーなどで、次のパス以下を全体的に制限すると良いでしょう。

拡大する

また、C:\Windows\WinSxS以下のフォルダ内にもpowershell.exeやpowershell_ise.exeが存在する可能性があるため、それも禁止する必要があります。

HTAの禁止

HTA（.hta）はHTMLで記述されたアプリケーションであり、HTML、VBScriptやJScriptを用いてコードを記述することが可能です。例えば最近ではLockyを使う攻撃者が.htaファイルを添付したメールを送信し、それをユーザに開かせることで感染を試みた事例が存在します。それ以外にも、少なくとも2007年からマルウェアが悪意のあるHTAを利用した事例が存在します（※57）。これに対処するために、mshta.exeをAppLockerやソフトウェアの制限のポリシーなどで制限すると良いでしょう。C:\Windows\WinSxS以下のフォルダ内にも存在する可能性があるため、それも禁止する必要があります。グループポリシーエディターで.htaの関連付けを外す手法も限定的な解決策の1つですが、厳密に言えば、mshta.exeをショートカット経由で呼び出された場合に回避されてしまうため、完全な解決策ではありません。

Webブラウザのプラグインを自動実行させない（Click to Play）

Google ChromeやFirefoxにはClick to Playと呼ばれる、ユーザが明示的に許可した場合のみWebブラウザプラグインの実行を許可する設定を行うことができます（※58）。これにより、Flashなどが自動的に実行されなくなり、これらの脆弱性を悪用してマルウェアに感染させる攻撃（ドライブバイダウンロード）を緩和することができます。

Google Chrome

1. Google Chromeのメニューから、設定をクリックします（図-28）。
2. ページの一番下にある、詳細設定を開く、をクリックします。
3. プライバシーのコンテンツの設定をクリックします。
4. プラグインのプラグインコンテンツをいつ実行するかを選択する、をクリックします。
5. 完了ボタンをクリックすれば、Click to Playが有効になります（図-29）

Firefox

1. URLバーにabout:configと入力します。その際に、警告が出ますが、細心の注意を払って使用する、をクリックします（図-30）。
2. plugins.click_to_playの値をtrueにすることで、Click to Playが有効になります（図-31）。

マッシュアップコンテンツを制限する

Firefoxのアドオンには、NoScript Security Suite（※59）やRequestPolicy Continued（※60）のような、スクリプトの実行を許可するサイトを限定したり、URLバーに入力したドメインとは異なるドメインへのアクセスを制限するプラグインが存在します。これらを利用することで、普段閲覧しているWebページが改ざんされていても外部サイトにはリダイレクトされないため、悪意のあるWebサイトに誘導されにくくなり、結果としてマルウェア感染を緩和することが可能です。

ストアアプリの禁止

Windows 8以降では、ストアアプリが利用できますが、ユーザが自由にアプリをインストールできてしまうため、ストア内にマルウェアなどが混入していた場合に誤ってインストールしてしまう可能性があります。また、デフォルトでもゲームなどが含まれており、ビジネス環境においては好ましくありません。そこで、ストアアプリの利用を一律禁止します。

1. 管理者権限でローカルグループポリシーエディターを起動してください。これはgpedit.mscを実行することで起動することが可能です。
2. メニュー左側のツリーからコンピューターの構成、管理用テンプレート、Windowsコンポーネント、ストア、とたどります（図-32）。
3. 以下の項目を有効に切り替えます（図-32）。
   －ストアアプリケーションをオフにする
   －Windowsストアからすべてのアプリを無効にする（この項目はWindows 10以降のみ）
4. ポリシーを強制したいホストを再起動するか、管理者権限でコマンドプロンプトを開き、gpupdate/forceコマンドを実行すると、ソフトウェアの制限のポリシーが有効になります。

拡大する

図-32 ストアアプリの設定画面

無効にした後にストアにアクセスすると、アプリにアクセスできなくなっているのが分かります（図-33）。また、AppLockerでもアプリを制御することができます。

拡大する

図-33 ストアアプリ - 拒否されたときに表示される画面

各対策と侵入経路の効果

各侵入経路ごとの各対策の有効性を以下の表-1にまとめました。

拡大する

表-1 各対策とそれぞれの侵入経路の効果

攻撃成立の可能性

上記対策を行うことで多くのマルウェア感染を止められますが、以下のような条件下では攻撃を防ぐことはできません。

• 任意のコード実行の脆弱性を突くExploitによる攻撃が成立
• 権限昇格の脆弱性を用いてSYSTEM権限など、高い権限でマルウェア実行
  もしくは、マルウェアをメモリ上のみに展開し、実行

ただし、EMETを回避した上で未知の脆弱性（0-day）を成立させるなど、条件としては非常に厳しいものであり、ほとんどの攻撃は成立しないと考えています（※61）。

副作用

AppLockerやソフトウェアの制限のポリシーを利用した場合、通常のGoogle Chromeは動かなくなります。これはChromeが一般ユーザのユーザディレクトリにインストールされるためです。この代替案として、スタンドアローンインストーラを利用することで、Program Files以下にインストールすることができます。ただし、この状態でもGoogle Chromeのアップデート用プログラムはユーザのtempディレクトリ上に実行ファイルを展開して実行しようとするため、正常にアップデートが行われなくなってしまいます。これを回避するために、このアップデータが持つ証明書を許可ルールとして登録しておくと良いでしょう（※62）。

WSHを無効化した場合、ログオンスクリプトなどにVBScriptを用いているとこれらの実行ができなくなります。PCの管理にPowerShellを用いていた場合はPowerShellの実行が禁止されると影響が出ます。

メールで文書をやりとりする場合、ファイルを暗号化する際に自己展開形式にして送信する文化が日本には根強く残っていますが、アプリケーションホワイトリスティングを導入した場合、ユーザが保存できる領域に存在する実行ファイルを例外なく拒否することになるため、受信者は添付ファイルの中身をチェックすることができなくなります。しかし、例えば一昨年に標的型攻撃で頻繁に使われたEMDIVIも自己展開形式を使用していましたが、攻撃者が送信元の組織と同一のアーカイバや暗号化ツールを入手し、自己展開形式でファイルを作成してメールを送信した場合、無害な添付ファイルと攻撃の区別がつきません。添付ファイルの暗号化を行いたい場合はパスワード付きzipや、より強い暗号化強度が必要であればGPGを使用して暗号化した上で添付する、もしくは信頼できるオンラインストレージサービスを利用してhttpsで通信路を暗号化してファイル共有するか、PGP/MIMEやS/MIMEなどでメール全体を暗号化するなどして代替し、このような悪しき文化を早く根絶していくべきです。

これまで紹介してきた設定で運用していると、この他にもいくつかの不具合に直面することがあります。そのときは、不具合がルールや運用を工夫することで回避できるかを検討していく必要があります。また、今回はマルウェアに感染しないことに特化して記述しましたが、よりセキュアに運用するためには、例えばプロセス生成やファイルの生成、書き込みイベントなどの監査ポリシーを設定したり、サードパーティの監査ソフトウェアなどを用いて監視するなど、他の対策も検討すべきです。Windows 10では、最新の脅威に合わせ、Device Guard（※63）やCredential Guard（※64）など、セキュリティを守るためのより強力で新しい実装があります。これらも導入を検討していくと良いでしょう。また日々新しい脅威が発見されているため、情報収集を行い、それらの脅威に対応するための方法を考え、定期的にポリシーの見直しを行う必要があります。