JPCERT コーディネーションセンター

安全・安心なIT社会のための、国内・国際連携を支援する

お問い合わせ 採用情報 サイトマップ English

Home > ラーニング > ライブラリ > 分析センターだより > 脆弱性を攻撃されたWebブラウザにおけるAppContainerの防御効果(2016-07-20)

最終更新: 2016-07-20

脆弱性を攻撃されたWebブラウザにおけるAppContainerの防御効果(2016-07-20)


脆弱性を攻撃されたWebブラウザにおけるAppContainerの防御効果

以前の記事「Internet Explorerの拡張保護モード」 (2015年8月) では、拡張保護モードを有効にして64bitモードで動作させると、脆弱性を悪用する攻撃に対して防御効果を発揮することを検証した結果を紹介しました。今回は、Windows 8以降の拡張保護モードに関連する、もうひとつの仕組み「AppContainer」が実際の攻撃に対してどのような効果を発揮するのかを検証します。

AppContainerとWebブラウザ

AppContainerは、アプリケーションを隔離された環境で動作させるサンドボックスです。その内側から外側へのアクセスは厳しく制限されます。「拡張」ではない保護モード (整合性レベルに基づくアクセス制限) との最大の違いは、書込み禁止に加えて、基本的には読込みも禁止されていることです。[1]

次のWebブラウザは、AppContainer内で動作します。
  •  Windows 10のEdge
  •  Windows 8.1のモダンUI(Metro)側Internet Explorer 11 (Immersiveブラウザ)

Windows 8.1やWindows 10に統合されているFlash PlayerもAppContainerに対応しています。

Windows 8.1のデスクトップ側およびWindows 10のInternet Explorer 11は、デフォルトではAppContainerで動作するようになっていません。インターネット オプションの「拡張保護モードを有効にする」を設定することにより、AppContainerで動作するようになります。64bitのWindows上で動作しているInternet Explorer 11では、「拡張保護モードで64ビット プロセッサを有効にする」というオプションもありますが、これを設定しても「拡張保護モードを有効にする」を設定しなければ、拡張保護モードは無効のままAppContainerではない64bitモードで動作しますので、ご注意ください。なお、これらを有効にすると、AppContainerや64bitモードと互換性のないアドオン等は動作しなくなります。また、「拡張保護モードを有効にする」を設定していても、信頼済みサイト ゾーンの場合など、保護モードが無効化されるときは、拡張保護モードも無効化されます。

実際の攻撃に用いられた検体での検証

Flash Playerの脆弱性を悪用する、実際の攻撃に用いられた検体で、AppContainerの効果を検証しました。検証には2つの検体を使いました。また、一方の検体については、想定される派生手法のために検体の動作を少し改変した上での検証も行いました。すなわち、次の3つのケースについて検証しました。

  •  検証1 - 脆弱性APSB15-18を悪用して実行ファイルを作成し起動する検体が動作するか
  •  検証2 - 検証1の検体を改変し、実行ファイルの起動をDLL経由にした場合に、検体が動作するか
  •  検証3 - 脆弱性APSB16-15を悪用してWindowsコマンドやスクリプトを実行する検体が動作するか

検証は、Windows 10のInternet Explorer 11で行い、拡張保護モードの設定による動作の違いを比較しました。なお、Windows 8.1でもWindows 10と同様の結果となることを確認しています。

検証1 - 実行ファイルの作成と起動

初めに、単純な事例として、拡張保護モードを様々に変えてマルウエアの実行ファイルの作成と起動がそれぞれ成功するのかどうかを調べ、AppContainerの効果を検証しました。脆弱性APSB15-18の悪用に成功した後の動作を表1に示します。

表 1: 実行ファイルの作成と起動
インターネット オプション マルウエアの実行ファイルの作成 作成した実行ファイルの起動
デフォルト(拡張保護モード無効) 成功 成功
拡張保護モード有効(AppContainer) 成功 失敗
拡張保護モードを有効にする設定
+
信頼済みサイト(保護モード無効)
成功 成功

実行ファイルの作成は拡張保護モードによらず成功しますが、作成した実行ファイルの起動については、拡張保護モードが有効な場合はAPIがエラーを返し失敗します。すなわち、拡張保護モードでは、起動できないので感染しません。ただし、信頼済みサイトゾーンでは、拡張保護モードが無効化されるため、「拡張保護モードを有効にする」と設定していても感染を防ぐことができません。

検証2 - DLL経由での起動

検証1で用いた検体は実行ファイルを作成し起動する単純なものでした。もっと巧妙な手法を使うマルウエアも考えられます。その一例として、AppContainer内でもDLLをロードできることを利用して、DLLを経由して間接的に起動するよう改変した場合、実行ファイルの起動が成功するかどうかを調べた結果を表 2に示します。

表 2: DLL経由での起動
インターネット オプション マルウエアの実行ファイルの起動
デフォルト(拡張保護モード無効) 保留 (警告画面で許可すれば起動)
拡張保護モード有効(AppContainer) 保留 (警告画面で許可すれば起動)
拡張保護モードを有効にする設定
+
信頼済みサイト(保護モード無効)
成功 (警告画面は表示されない)

信頼済みサイト ゾーンのために保護モードが無効化される場合を除き、図 1のような警告画面が表示されました。

acreport-AppContainer_01.png
図 1: 実行を許可するかの選択を伴う警告画面

この警告画面で許可を選択すると、拡張保護モードを有効にしていたとしても、AppContainerによる動作制限が解除された状態でマルウエアが実行されてしまいます。不用意に許可しないよう、ご注意ください。

実行ファイルを起動できた場合のProcess Explorer表示を図 2~図 4に示します。図 3では、AppContainer内で動作しているプロセスの「Integrity」欄は、整合性レベルではなく「AppContainer」が表示されます。なお、図 2~図 3では、プロセスの親子関係が図 4とは異なっていますが、マルウエアの実行ファイルを起動するAPIを呼び出したプロセスは、図 2~図 4いずれにおいても下から2つめのiexplore.exe (子プロセス側のiexplore.exe) です。すなわち、警告画面無しでマルウエアの実行ファイルが起動されて感染した場合 (図 4) と異なり、警告画面で許可した場合 (図 2~図 3) には、起動されたプロセスが、起動するAPIを呼び出したプロセスの子プロセスになりません。

acreport-AppContainer_02.png
図 2: 警告画面で許可した場合(拡張保護モード無効)
acreport-AppContainer_03.png
図 3: 警告画面で許可した場合(拡張保護モード有効)
acreport-AppContainer_04.png
図 4: 信頼済みサイト(保護モード無効)で感染した場合
検証3 - Windowsコマンドの起動

最後は、2016年6月に確認した最近の検体Neutrino Exploit KitのFlashファイル (SWF) 検体を用いた検証です。この検体は、脆弱性APSB16-15を悪用して、マルウエアをダウンロードし起動するためのスクリプトを作成し実行しようとします。スクリプトを作成するにはcmd.exe (Windows コマンド プロセッサ) が使用され、スクリプトを実行してマルウエアをダウンロードし起動するにはWScript.exe (Windows Script Host) が使用されます。検証結果を表 3に示します。

表 3: Windowsコマンドの起動およびスクリプトの作成と実行の成否
インターネット オプション cmd.exeの起動 スクリプトの作成 ダウンロードと起動
デフォルト(拡張保護モード無効) 成功 成功 成功
拡張保護モード有効(AppContainer) 成功 失敗 -
拡張保護モードを有効にする設定
+
信頼済みサイト(保護モード無効)
成功 成功 成功

いずれの場合もcmd.exeの起動には成功しています。この時点のProcess Explorer表示を図 5に示します。検証1~検証2と異なり、AppContainer内でプログラムが起動されています。

acreport-AppContainer_05png
図 5: AppContainer内でのプログラム起動

このように、AppContainer内でのプログラム起動も必ず失敗するわけではなく、Windowsコマンド等を起動できます。このとき、図 1のような警告画面は表示されません。ただし、起動されたコマンド等はAppContainer内であるという状態を引き継ぎ、動作が制限されます。この検体の場合には、これらコマンド等の動作制限に対応できていないため、スクリプトを作成できません。したがって拡張保護モードでは感染しません。

おわりに

WebブラウザをAppContainer内で動作させることにより、今回検証されたように、脆弱性を悪用されても、次の段階の攻撃を防げる場合があります。すなわち、悪意あるコードに対する厳しいアクセス制限によって、攻撃を受けた際の影響範囲を限定する効果だけでなく、感染する機会自体を減らす効果も期待できるのです。

ただし、攻撃によって影響を受ける範囲を限定する効果については注意が必要です。AppContainerは、Webブラウザ等のアプリケーションを隔離された環境内で動作させる仕組みに過ぎないため、Webブラウザが扱う情報を標的とした攻撃を防ぐことはできません。例えば、認証付きプロキシサーバーのパスワードハッシュなどをメモリ上から窃取する動作をAppContainerで抑止することはできません。そして、窃取された情報は他の攻撃に悪用されてしまうかもしれません。AppContainerを活用しつつも、その効果に頼り過ぎることなく、パスワードの使い回しを避ける等の基本的なセキュリティ対策も忘れないようにしましょう。

分析センター 今松 憲一

参考情報
[1] FFRI - Windows 8 セキュリティ
  http://www.ffri.jp/assets/files/monthly_research/MR201210_Window%208_AppContainer_Sandbox.pdf

[2] Microsoft - AppContainer Isolation
  https://msdn.microsoft.com/ja-jp/library/windows/desktop/mt595898(v=vs.85).aspx

[3] IBM - A Peek into IE's Enhanced Protected Mode Sandbox
  https://securityintelligence.com/internet-explorer-ie-10-enhanced-protected-mode-epm-sandbox-research/

[4] Black Hat - diving into ie 10's enhanced protected mode sandbox
  https://www.blackhat.com/docs/asia-14/materials/Yason/Asia-14-Yason-Diving-Into-IE10s-Enhanced-Protected-Mode-Sandbox.pdf



Topへ

CSIRTマテリアル
STOP!!パスワード使い回し!!キャンペーン2016
JPCERT/CCって何をやっているのですか?
Follow jpcert on Twitter
blog_banner_english