ページの先頭です
インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策につなげています。ここでは、これまでに実施した調査のうち、Volatility Frameworkプロファイルの生成、マルウェアに感染しないためのWindowsクライアント要塞化(後編)の2つのテーマについて紹介します。
Volatility Framework(以下、Volatility)はコンピュータフォレンジックの際にメモリイメージを解析するために使用されるオープンソースソフトウェアです(※48)。
Volatilityを実行する際にはプロファイルを指定する必要があります。プロファイルは、OSやサービスパック、アーキテクチャごとに用意されており、メモリイメージを取得したシステムと同じものを指定しなければ正しく解析することができません。図-14はVolatilityにデフォルトで同梱されているプロファイルの一覧になります。
この図を見れば分かるとおり、デフォルトではWindowsのプロファイルしか同梱されていません。LinuxやMac OS Xのメモリイメージを解析する場合は、VolatilityのGitHubページ(※49)からプロファイルをダウンロードする必要があります。しかし、すべてのOSバージョンに対応したプロファイルが提供されているわけではありません。また、Linuxでは、Kernelのバージョンアップも多く行われますので、同じOSバージョンでもLinux Kernelのバージョンが異なるという状況も考えられます。
このような場合、使用しているシステムに合わせたプロファイルを自身で生成する必要があります。本稿では自身でLinux Kernel用のVolatilityプロファイルを生成する際の手順を解説します。
解析対象システムのバージョンの確認
Volatilityのプロファイルを生成するには、メモリイメージの解析対象となるシステムと同じバージョンのシステムにVolatilityをインストールする必要があります。主なLinuxディストリビューションでのOSバージョンとLinux Kernelのバージョンを確認する方法は図-15を参照してください。なお、今回は、CentOS Linux 7.2-1511、Linux Kernel 3.10.0- 327.22.2.el7.x86_64を例に解説します。
プロファイル生成マシンの準備
Volatilityプロファイルを生成するためのマシンを用意します(解析対象システムへの変更を最小限にするため、別途マシンを用意してください)。このとき、OSバージョンとLinux Kernelバージョンは上記で確認したものと同じバージョンのものを用意することが望ましいです。なお、プロファイルを生成するマシンはバーチャルマシンでも問題ありません。
Volatilityのダウンロード
Volatilityの実行とプロファイルの生成に必要なライブラリをインストールします(図-16)。一部、gitを使用していますが、Linuxディストリビューションによっては、これらのライブラリのパッケージが用意されている場合もあると思いますので、適宜、インストールを行ってください。
次に、Volatilityをダウンロードします(図-17)。Volatilityはシステムにインストールしなくても実行することができるため、今回はこのまま使用します。Volatilityをダウンロードしたディレクトリ内で「$ python ./vol.py --info」と実行して、エラーが発生しないことを確認してください。
Linux Kernel開発環境インストール
プロファイル生成の際にカーネルモジュールのコンパイルが必要になるため、Linux Kernelの開発環境をインストールします(図-18)。その他、makeやgccなどのコマンドが必要となりますので、必要に応じて各コマンドをインストールしてください。以上で準備は完了です。
「volatility/tools/linux」ディレクトリ内で、makeコマンドを実行します。問題がなければ、同じディレクトリに「module.dwarf」というファイルができているはずです。次に、「volatility/volatility/plugins/overlays/linux/」ディレクトリに、module.dwarfとSystem.mapファイルをまとめたZIPファイルを作成します(図-19)。
このZIPファイルがVolatilityのプロファイルとなります。プロファイルに命名規則はありませんが、最低限OSバージョンが分かるようなプロファイル名が望ましいでしょう。より細かく管理するのであれば、Linux Kernelバージョンもプロファイル名に含めてください。
生成したプロファイルがVolatilityに認識されているかどうかは、図-20のようなコマンドで確認することができます。
ここまで説明した手順で、現在動作しているLinux KernelのVolatilityプロファイルは生成できるようになりました。しかし、同じOSバージョンでも異なるバージョンのLinux KernelやカスタマイズされたLinux Kernelのプロファイルを生成する場合は、作業手順を少し変える必要があります。
Linux Kernelのバージョンが異なる場合
「Linux Kernel開発環境インストール」のステップの代わりに、図-21のように適当なディレクトリにプロファイルを生成したいLinux Kernelのパッケージを展開します。
この他の手順は基本的に同じですが「プロファイル生成」に関しては、図-22のようにmakeコマンドの引数として、KDIRとKVERを指定しなければなりません。
注意点として、CentOS 7の場合、/lib/modules/<kernel_ver>/buildのシンボリックリンクがリンク切れとなるため、makeを実行すると「/home/admin/ksrc/lib/modules/<kernel_ver>/buildは存在しない」旨のエラーが発生してしまいます。この場合、図-23のように、buildファイルのシンボリックリンクを張り直すことでエラーを回避することができます。
カスタマイズされたLinux Kernelの場合
特定の機器や用途向けにLinux Kernelがカスタマイズされている場合、Linuxディストリビューションが配布しているパッケージをそのまま利用することはできません。このような場合、以下のいずれかの対応を行い、Linux Kernelのソースコードを用意します。
このように解析対象システムで動作しているLinux Kernelに近い状態のソースコードが必要になりますが、これ以外の作業はこれまで解説した手順と変わりません。
なお、Mac OS X用のプロファイルは本稿の冒頭で書いたように、VolatilityのGitHubページからダウンロードすることができますが、新バージョンのリリース直後など、タイミングによっては最新版用のプロファイルをダウンロードすることができない場合があります。生成手順はLinux Kernelとおおよそ同じ(※51)ですので、自分でOS X用プロファイルを生成することを検討してみてはいかがでしょうか。
前号のIIRではパッチ適用や一般ユーザ権限のみを付与するなどの基本的な対策に加え、アプリケーションホワイトリスティングと呼ばれる要塞化設定について紹介しました。本稿では残りの対策について紹介します。まだ前号を読んでいない方は、IIR Vol.31「マルウェアに感染しないためのWindowsクライアント要塞化(前編)」(※52)も合わせてご覧ください。
EMET(Enhanced Mitigation Experience Toolkit)は脆弱性の悪用を緩和するためのツールで、マイクロソフトが配布しています(※53)。Windowsのセキュリティ機能を最大限有効化すると共に、既知の攻撃手法への緩和策が実装されています。EMETはドメイン配下のクライアントに一斉インストールし、ポリシーを強制することも可能です(※54)。本稿執筆時点での最新版は5.5であり、それを元にEMETを単一ホストで利用する場合の説明します。インストール後、スタートメニューからEMET GUIを起動すると、EMETの管理ツールが起動します。
これで基本的な設定は終了です。以降は管理画面からAppsをクリックし、環境に応じて個別のアプリケーションを追加したり、テスト中や利用中に不具合が出たアプリケーションについて、干渉している機能を個別に外すなどの対処を行いながら、運用をしていきます。
UAC(ユーザアカウント制御)はVista以降導入された機能で、管理者権限アカウントであっても通常は特権を無効化しておきます。OSにとって重要な変更が実行中のプログラムによって行われようとした場合に、ユーザに対してその変更は自身が行ったものであるか確認を求めることで、悪意のある変更を検出する機能です。
UACには大きく分けて4段階の設定値が存在し、Vistaではデフォルトで最高値である「常に通知する」が設定されていました。しかし、XPを単体で利用していたユーザはそのほとんどが常時管理者権限を使用しており、Vistaに乗り換えた際、頻繁にUACのポップアップが出現したため、多くのユーザがこの機能を批判しました。そのため、Windows7以降のデフォルトはそれよりも一段低い「アプリがコンピュータに変更を加えようとする場合のみ通知する」に変更になっています。しかし、これにはいくつか欠陥があり、UACを回避してユーザの同意なしに管理者権限に自動昇格してしまう攻撃が実際の事案でも確認されています(※55)。このような脆弱性を避けるため、UACを常に通知する、に変更して運用した方がよいでしょう(※56)。
これで自動昇格が起こらず、常にポップアップが出現し、管理者ユーザが異常に気づきやすくなります。
WSH(Windows Script Host)はホスト上でVBScriptやJScriptを実行するための機能です。前号のIIR Vol.31「1.4.1 各種のランサムウェアとその対策」でも記載したとおり、TeslaCryptやLockyではJScript(.js)がメールに添付された事例が確認されています。また、過去にはショートカットファイル(.lnk)内にVBScript(.vbs)を埋め込んだものをメールで送信する手口も確認されています。このような攻撃を防ぐために、レジストリエディターを使用して以下のキーに値を追加し、この機能を無効化します。
無効化すると、.jsや.vbsをダブルクリックしたり、cscript.exeを実行した場合、警告が出ることが確認できます(図-27)。
rundll32.exe、regsvr32.exeはVBScript(.vbs)やJScript(.js)ファイルをリモートのホストからhttpなどを経由して取得し、実行する機能があります。これは攻撃者に使われうる機能であるため、禁止すべきです。ただし、rundll32.exeやregsvr32.exeは通常のWindowsの処理中にも使われているため、実行そのものを禁止することはできません。そこで、セキュリティが強化されたWindowsファイアウォールの送信の規則など、パーソナルファイアウォールの機能を用いて、これらの実行ファイルが外部と通信するのをブロックします。64bit環境の場合、SysWOW64側にも実行ファイルが存在するため、同様にブロックします。
また、C:\Windows\WinSxS以下のフォルダ内にもこれらの実行ファイルが存在する可能性があるため、それも禁止する必要があります。
PowerShellはWindowsの管理やWindows APIを呼び出したりできるなど、非常に強力なWindowsのスクリプティング言語です。デフォルトではファイル化されたスクリプトが実行できないようになっていますが、この制限は簡単に回避できてしまいます。また、ショートカットや外部に存在するスクリプトをHTTP経由で直接実行することができるなど、実際の攻撃に利用されていることが確認されているため、一般ユーザが実行できないようにAppLockerやソフトウェアの制限のポリシーなどで、次のパス以下を全体的に制限すると良いでしょう。
また、C:\Windows\WinSxS以下のフォルダ内にもpowershell.exeやpowershell_ise.exeが存在する可能性があるため、それも禁止する必要があります。
HTA(.hta)はHTMLで記述されたアプリケーションであり、HTML、VBScriptやJScriptを用いてコードを記述することが可能です。例えば最近ではLockyを使う攻撃者が.htaファイルを添付したメールを送信し、それをユーザに開かせることで感染を試みた事例が存在します。それ以外にも、少なくとも2007年からマルウェアが悪意のあるHTAを利用した事例が存在します(※57)。これに対処するために、mshta.exeをAppLockerやソフトウェアの制限のポリシーなどで制限すると良いでしょう。C:\Windows\WinSxS以下のフォルダ内にも存在する可能性があるため、それも禁止する必要があります。グループポリシーエディターで.htaの関連付けを外す手法も限定的な解決策の1つですが、厳密に言えば、mshta.exeをショートカット経由で呼び出された場合に回避されてしまうため、完全な解決策ではありません。
Google ChromeやFirefoxにはClick to Playと呼ばれる、ユーザが明示的に許可した場合のみWebブラウザプラグインの実行を許可する設定を行うことができます(※58)。これにより、Flashなどが自動的に実行されなくなり、これらの脆弱性を悪用してマルウェアに感染させる攻撃(ドライブバイダウンロード)を緩和することができます。
Google Chrome
Firefox
Firefoxのアドオンには、NoScript Security Suite(※59)やRequestPolicy Continued(※60)のような、スクリプトの実行を許可するサイトを限定したり、URLバーに入力したドメインとは異なるドメインへのアクセスを制限するプラグインが存在します。これらを利用することで、普段閲覧しているWebページが改ざんされていても外部サイトにはリダイレクトされないため、悪意のあるWebサイトに誘導されにくくなり、結果としてマルウェア感染を緩和することが可能です。
Windows 8以降では、ストアアプリが利用できますが、ユーザが自由にアプリをインストールできてしまうため、ストア内にマルウェアなどが混入していた場合に誤ってインストールしてしまう可能性があります。また、デフォルトでもゲームなどが含まれており、ビジネス環境においては好ましくありません。そこで、ストアアプリの利用を一律禁止します。
無効にした後にストアにアクセスすると、アプリにアクセスできなくなっているのが分かります(図-33)。また、AppLockerでもアプリを制御することができます。
各侵入経路ごとの各対策の有効性を以下の表-1にまとめました。
上記対策を行うことで多くのマルウェア感染を止められますが、以下のような条件下では攻撃を防ぐことはできません。
ただし、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)など、セキュリティを守るためのより強力で新しい実装があります。これらも導入を検討していくと良いでしょう。また日々新しい脅威が発見されているため、情報収集を行い、それらの脅威に対応するための方法を考え、定期的にポリシーの見直しを行う必要があります。
ページの終わりです