セキュリティ技術

マルウェアの自動解析の方法

はじめまして。リサーチエンジニアの舟久保と申します。

今回は、マルウェアの自動解析の手法について調査する機会があったので、備忘録も兼ねて、簡単にご紹介させていただきたいと思います。

弊社ではウイルス対策ソフトウェア(yarai)の開発や、マルウェア解析サービスを提供している都合上、日々発生するマルウェアを解析し、どのようなタイプのマルウェアが存在しているのか常に把握しておく必要があります。しかし、毎日平均で約5,000個、多い時は10,000個を超えるマルウェアを収集しているため、解析ツールやデバッガ等を使って1つ1つ手作業で解析していては、日が暮れてしまいます。

そこで登場するのが今回のテーマでもあるマルウェアの自動解析という技術です。これを利用すれば自動的にマルウェアを解析できるため、手作業での解析から解放され、大量のマルウェアを短時間で捌けるようになるというわけです。

読者の皆さんはご存知かもしれませんが、既に無料でウェブ上からマルウェアの自動解析をしてくれるサービスがあります。例えば、Norman Sandbox、CWSandbox、anubisなどが有名です。マルウェアを持っていたら、そこへ読み込ませてみると興味深い解析結果が得られるかもしれません。

マルウェアの自動解析という分野は、壮大な研究分野なので、ここで全てを解説することはできませんし、なにより私自身全て把握できているわけではございません。マルウェアの自動解析には、大きく分けて、静的解析(動作させずに解析)と動的解析(実際に動作させて解析)があるのですが、今回は動的解析の「自動解析システムが任意の時点でマルウェアから制御を奪う方法」について焦点を当ててまとめてみたいと思います。

■1つ目の方法: ブレークポイントを使う方法

最もオーソドックスな方法でデバッガ等で良く使われる方法です。詳しい仕組みは、色々なところで解説されていますので割愛させていただきます。この方法は、とても簡単に実装でき、任意の時点で制御を奪うことができますが、マルウェアによって検出されやすいという欠点があります。

2つ目の方法: ステルスブレークポイントを使う方法

1つ目の方法で解説したブレークポイントとは異なるアプローチのブレークポイントです。メモリページの属性を一時的にnot present状態にしておき、そこにアクセスした瞬間にページフォールトを発生させ、ページフォールトハンドラで制御を奪うという方法です。ページ単位でブレークポイントを仕掛けるため、ページフォールトが頻発するという欠点がありますが、マルウェアに検出されずに任意の時点で制御を奪うことが可能です。

下記の論文が詳しいです。
Stealth Breakpoints

3つ目の方法: マルウェアコードをブロックに分割してブロック毎に実行する方法

マルウェアのコードを直接実行するのではなく、ブランチ命令やcall命令などの制御が変わる部分などでコードの固まり(ブロック)に分割し、ブロック単位で少しずつマルウェアコードを実行する方法です。実装が複雑になりますが、ブロック単位でマルウェアの制御を奪うことができます。また、ブロック内の命令コードを自動解析システムが都合のよい命令コードに書き換えることもできます。

下記の論文が詳しいです。
Cobra: Fine-grained Malware Analysis using Stealth Localized-executions

4つ目の方法: PCエミュレータ(QEMU)を使う方法

QEMU上のゲストOSでマルウェアを動作させることによって、QEMUの実行命令ブロック(Translation Block)単位でマルウェアの制御を奪う方法です。ゲストOSやマルウェア自身には一切手を加える必要がないために、マルウェアによる検出を避けつつ制御を奪うことができます。ただし、ゲストOSで利用されている構造体や関数等の情報(例えば存在するメモリアドレス等)をあらかじめ知っておかないと制御を奪った後、解析できないという欠点があります。

下記のプロジェクトがこの方式を利用しています。
TEMU: The BitBlaze Dynamic Analysis Component

5つ目の方法: CPUの仮想化支援機能を使う方法

ハイパーバイザ上のゲストOSにおいて、トラップフラグを設定しておき、マルウェアが1命令実行するごとデバッグ例外を発生させることにより、マルウェアから制御を奪う方法です。デバッグ例外は、ゲストOSに届く前にハイパーバイザで処理されますので、ゲストOSに影響を与えることはありません。マルウェアがトラップフラグを参照することによるデバッグ検出を避けるため、トラップフラグを参照しようとしたら、あたかもトラップフラグが設定されていないかのように、値をねつ造します。

下記の論文が詳しいです。
Ether: Malware Analysis via Hardware Virtualization Extensions

最後に

今回は、「自動解析システムが任意の時点でマルウェアから制御を奪う方法」という、マニアックな視点からマルウェアの自動解析をまとめてみましたが、いかがでしたでしょうか。

次回は別の視点からマルウェアの自動解析を紹介してみたいと思います。

お楽しみに!

| | トラックバック (1)
|

KHOBEに見るTOCTOU問題

セキュリティ技術カテゴリ担当の村上です。今回は、少し前に話題になったKHOBE(Kernel HOoking Bypassing Engine)と呼ばれるセキュリティ機能回避の問題について説明します。

今月5日、matousec.comによってKHOBEと呼ばれる技術を利用することで多くのセキュリティソフトが備えるセキュリティ機能が回避可能であることが報告されました。こうしたセキュリティソフトの多くは、APIフックを行うことでOSが提供している正規の処理をインターセプトし、独自のセキュリティ機能を実装した代替処理を実行します。例えば、統合セキュリティソフトやデスクトップIPSの場合、マルウェアによって自身のプロセスが強制終了させられないようにプロセスを停止させるAPI、サービスを停止させるAPI、ドライバをアンロードするAPI等をフックしているケースがあります。他にもファイル、レジストリ、プロセス等へのアクセス制御を実現するためにこうしたリソースにアクセスするAPIをフックし、定義されたポリシーとの比較検証ロジックを実装しているケースも存在します。KHOBEは、セキュリティ機能をバイパスする技術です。

この問題は、APIフックの代替関数における引数の取扱いに起因します。例えば、OSが提供しているファイルを開くAPIをフックするケースを考えてみましょう。ここでは当該APIを便宜上、OpenFileと呼びます。APIフックを行うプログラムは、このOpenFile APIを、独自のセキュリティ機能を実装したCustomOpenFile関数でフックします。以下にAPIフックを行うプログラムの疑似コードを示します。


---

some_func(...)
{
  // OpenFile APIをCustomOpenFile関数でフックし、
  // OpenFile APIのアドレスをOrigOpenFileに保存する

  OrigOpenFile = ApiHook(OpenFile, CustomOpenFile);
  ...
}

CustomOpenFile(char *filename, ...)
{
  // ファイルオープンの妥当性を引数に含まれる
  // filenameに基づいて比較検証する

  if (filename && check_policy(filename)) {
    return ACCESS_DENIED;
  }

  // ※1

  // 保存しておいたアドレスを利用して、元のOpenFile APIを呼び出す
  return OrigOpenFile(filename, ...);
}

---

一見するとなんの問題もないように見えますが、CustomOpenFile関数にはレースコンディションの脆弱性が存在します。これは、より具体的には、TOCTOU(time-of-check, time-of-use)問題と呼ばれており、攻撃者は、※1のfilenameチェック後のタイミングでfilenameを変更することで、チェックを回避してOrigOpenFile APIを呼び出すことができます。
攻撃を行うプログラムは、例えばマルチスレッドで動作し、スレッドAがOpenFileを繰り返し呼び出し、スレッドBがスレッドA中で呼び出されたOpenFile APIの引数であるfilenameを絶えず変更します。スレッドBのfilenameの変更がちょうど※1のタイミングで行われれば、チェックを回避することが可能です。

ご想像の通り一回でこの攻撃を成功させることは確率的に考えて非常に難しく、数千回、数万回試行してやっと一回成功する、という性質の問題です。攻撃の成功確率はプロセッサ環境(シングル・マルチプロセッサ)、値のチェックと利用の間に行われる処理の有無・量、タスクスケジューラーの実装等によって変動します。とは言っても、一回でも成功すればそれで十分というケースもあるため軽視することはできません。対策としては、チェック時の値が実際に利用されることを保証する必要があります。そのため、下記のような修正が有効です。


---
CustomOpenFile(char *filename, ...)
{
  char *copy_filename = NULL;
  int ret;

  if (!filename)
    return OrigOpenFile(NULL, ...);

  // filenameのコピーを作成する
  // ※このstrdupは必ず成功する

  copy_filename = strdup(filename);

  // 作成したコピーを利用してチェックを行う

  if (check_policy(copy_filename)) {
    // 関数を抜ける前にコピーを解放する
    free(copy_filename);
    return ACCESS_DENIED;
  }

  // 作成したコピーを利用する

  ret = OrigOpenFile(copy_filename, ...);

  // 関数を抜ける前にコピーを解放する

  free(filename);

  reutrn ret;
}
---

matousec.comの報告では、実際に多くのセキュリティ製品がこうした問題を含んでおりセキュリティ機能を回避することが可能とのことです。興味のある方は、一次情報もチェックするお勧めします。余談ですが、一次情報では、SSDTフックを例に問題の説明がされていますが、この問題自体はSSDTフックに限らずフック全般に関連した実装の脆弱性だと言えます。

KHOBE – 8.0 earthquake for Windows desktop security software

| | トラックバック (0)
|

Windows XPでも保護機能:Google Chromeのサンドボックス

こんにちは。リサーチエンジニアの丹田です。前回はInternet Explorerのセキュリティ機能「保護モード」のお話をしました。

Windows Vistaからの保護機能:保護モードと整合性レベル
http://blog.fourteenforty.jp/blog/2010/03/windows-vista-e.html

今回もウェブブラウザのセキュリティつながりということで、Google Chromeのお話をしたいと思います。ポイントは、Google ChromeはXPでもセキュアに動く、です。

■ プログラムの脆弱性はなくならない

前回にも触れたとおり、ウェブブラウザのセキュリティの確保はほとんどのPC利用者にとってとても大切です。しかし、ウェブブラウザは攻撃者から見たとき非常に脆弱性を悪用しやすいソフトウェアであるため、攻撃者が最初に脆弱性を見つけて悪用してしまう「ゼロデイ」が頻繁に発生しています。意識して見ると、Microsoftの定例外更新の対象がInternet Explorerであったり、Firefoxが毎月のように更新していたりすることに気付きます。

このことは、ウェブブラウザの脆弱性を開発段階で洗い出すのは難しいということを示しています。この事実に対して、Internet Explorerは保護モードを導入し、「攻撃されても被害を抑える」戦略をとったと言えそうです。

そしてこの戦略をさらに強力に実現したのがGoogle Chromeです。Google Chromeは2008年末に公開された後発のウェブブラウザです。複数のプロセスで構成するマルチプロセスアーキテクチャを持ち、サンドボックスと呼ばれる仕組みを使ってセキュリティを提供しています。そこで今回は、このサンドボックスと、サンドボックスに関連するGoogle Chromeの特徴を紹介してみたいと思います。

■ 危険性の高いコードを分離する

Google Chromeは、バッファオーバーフローなど致命的な脆弱性を生み出す可能性が高いと見込まれるコードを、別のプロセスとして分離しています。この結果、高い安定性と、サンドボックスによる強いセキュリティが実現できています。

プロセスを分離するマルチプロセスアーキテクチャは、Internet Explorer 8でも採用されました。Firefoxでも同様に、プラグインを別プロセスに分離する計画があることが告知されています。

・IE8 と Loosely-Coupled IE (LCIE)
http://msdn.microsoft.com/ja-jp/ie/cc787974.aspx

・Firefox の安定性が大幅に改善しているという調査結果が発表されました
http://mozilla.jp/blog/entry/5425/

 Google Chromeは、タブ、エクステンション、プラグインひとつひとつまで単一のプロセスとして動作する点でやや異なります。これはとりわけ安定性に貢献します。

■ 分離したプロセスの権限を落とす

分離された危険性の高いコードは、極めて権限の抑えられたプロセスとして動作します。権限が抑えられ、できることが限られているため、攻撃者に制御を奪われても被害を最小限に抑えることができます。この権限を抑え、被害を最小化する仕組みが「サンドボックス」です。

もしWindows Vista以降をお使いでしたら、Google Chromeを起動して、Process Explorerから「Integrity」列を確認してみてください。Chrome.exeのうちいくつかが、整合性レベル「Low」で動作していることが確認できます。 

Chrome_2

これは、分離されたプロセスの権限が抑えられていることを示しています。前回お話したInternet Explorerの保護モードと同じ仕組みです。

■ 保護モード以上に厳しい制約を課す

Google Chromeのサンドボックスの面白いところは、整合性レベル以外にもさまざまな制約を課す点です。たとえば、子プロセスを生成することができません。クリップボードの読み書きが禁止されています。サンドボックスの外とウインドウメッセージをやり取りすることも許されていません。また、ファイルを読み取ることもできません。保護モードのInternet Explorerは、ファイルの読み取りは可能(書き込みは禁止)であるため、攻撃者の手に落ちた場合、情報漏えいを防ぐことができませんでした。

■ UAC無効でも、XPでも機能する

私はXPも頻繁に使っています そんな私ですから、この点は特に感心しています。前回も少し触れましたが、UACが無効の場合、Internet Explorerの保護モードは無効になります。またXPでは保護モードは使えません。

それに対して、Google Chromeのサンドボックスは、これらの状況にあっても変わりなく動作します。もちろんXPに整合性レベルはありませんが、XPだからといってサンドボックスの機能が損なわれることはありません。

■ なぜ?

端的にいえば、サンドボックスの実装は、保護モードで使われていた整合性レベルの機能に依存していません。ドキュメントを読むと分かるのですが、整合性レベルの調整はオマケのような扱いです。実装は古くからあるWindows APIを巧みに組み合わせたもので、サンドボックスのドキュメントには、この仕組み自体はWindows 2000から動作すると書かれています。

サンドボックスの実装は、具体的には以下のような仕組みが使われています。

•制限トークンの利用で各種カーネルオブジェクト(ファイルもここに含む)へのアクセスを制限
•デスクトップの変更でウインドウアクセスやウインドウメッセージの送受信を制限
•ジョブオブジェクトの制限機能でクリップボードへのアクセスなどを制限

疑わしい!と思った方や、実装に興味がある方は、ぜひドキュメントやソースコードをあたってみてください。なかなか面白い仕組みを学ぶことができると思います。

・The Chromium Projects > Design Documents > Sandbox
http://dev.chromium.org/developers/design-documents/sandbox

・The Security Architecture of the Chromium Browser
http://seclab.stanford.edu/websec/chromium/

・ソースツリー
http://src.chromium.org/viewvc/chrome/releases/

・Google Chrome の内部構造
http://code.google.com/intl/ja/events/developerday/2009/sessions.html

■ 余談

実は、Google Chrome 4.1では、フラッシュプレイヤーのようなプラグインは上記のサンドボックス機能の管理下にありません。つまりプラグインに脆弱性があり、プラグインプロセスの制御が攻撃者の手に渡った場合には保護されないことを意味します。

先ほどの画像を見てみましょう。整合性レベル「Medium」になっているChrome.exeうちの1つが「--type=plugin」になっています。これがプラグインプロセスです。

プラグインにサンドボックスが適用されないのは、プラグインの仕様上やむをえない措置だったようです。この問題に対してブラウザ利用者ができることは、プラグインを利用しないか、プラグインを確実にアップデートすることだけです。

この問題を解決するために、GoogleやMozilla、Adobeは共同でプラグインの新しいAPIを策定しています。

・Bringing improved support for Adobe Flash Player to Google Chrome
http://blog.chromium.org/2010/03/bringing-improved-support-for-adobe.html

次のバージョンとなるGoogle Chrome 5では、この新しいAPIを利用したプラグインがサンドボックスの管理下に入り、プラグイン経由の攻撃からも保護できるようになるかもしれませんね。

ではまた。

---
このブログ中における株式会社フォティーンフォティ技術研究所(以下FFR)の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

:0 :0 :0
:0 :0 :0
:0 :0 :0

| | トラックバック (0)
|

CanSecWest2010発表報告

リサーチエンジニアの鈴木です。

CanSecWest2010にて、SEH Overwriteに関する発表をしてきました。今回は、その時の報告、発表内容の要旨、そしてそこから出てく防御機能に対する考え方をご紹介したいと思います。

まずは、簡単に参加報告を。CanSecWestに参加するのは初めてで、緊張しながらいったのですが、会場を見てさらに緊張しました。せいぜい100人ぐらいの入る小さな部屋でやるんだろうと思っていたら、ざっと数えて500人は入る会場でした。

R0012942
緊張しましたが、いざ発表が始まると意外に落ち着いて、約1時間の発表も特に問題なく終えることができました。

R0012950
発表後には、興味を持ってくれた人たちが何人か来てくれて、いろいろ話をしたり、名刺交換したり。

R0012958

より詳しく知りたい方は「SEHオーバーライトの防御機能とそのExploit可能性」と「発表スライド」をご覧ください。

今回のリサーチペーパーは、いろいろある攻撃防御機能がどれくらい有効なのかをSEH Overwriteという手法を題材にしてまとめようという目的のもと始まったものでした。進めるうちに、SEHOPという防御機能の回避というものは一般に紹介されておらず(2009年8月時点)、その他の防御機能も一緒にバイパスできてしまいそうだと感じ始め、それらの可能性について調べました。

もともとSEHOPはSafeSEHやSoftware DEPという防御機能がバイパスされることがあるということで、これを難しくしようという経緯で提案され実装されました。しかし、実際にはバッファオーバーフローを起こすアドレスが分かっていれば比較的簡単にSEHOPも一緒にバイパスして攻撃できてしまうというものです。さらにReturn-into-libcを用いてHardware DEPもバイパスして任意のコードが実行できる可能性があるということを示しました。

最終的な結論として、ASLRを組み合わせるとSEH Overwriteによるエクスプロイトはかなり難しいということがわかりました。

ただし、ここで重要なことはASLRがすべてではないということです。ASLRさえ有効になっていれば、他はどうでもよいということではありません。SEH Overwriteに関して言えば、ASLRとSEHOPという組み合わせがお互いの有効性を高めあい相乗効果があるということです。たまに、Hardware DEPだけで安心だという声も聞かれますが、これもそれだけでは心もとないです。ASLRとHardware DEPと組み合わせると有効性が一気に増します。
しかし、ASLRとHardware DEPだけの防御機能も回避される例は存在します[Bypassing Browser Memory Protections(Alexander Sotirov, Mark Dowd)]。しかしここでもSEHOPを組み合わせると防御機能回避は難しくなります。

いろいろなエクスプロイト手法を考察すると、やはり各防御機能は確実に組み合わせて用いるのが有効です。一方で単独の防御機能だけでは現在の攻撃者のレベルから考えるとちょっと心もとないです。セキュリティを考えるならば1つより2つ、2つより3つと、防御機能をできるだけ有効にしておいた方がよいのは間違いありません。

しかし、ただやみくもに増やせばよいということではないということも今回のリサーチの中で分かりました。先ほども書いたように、SEHOPはSafeSEHやSoftware DEPのバイパスを防ぐということを1つの目的として実装されましたが、実際にはASLRが一緒に有効になっていないと、その効果がほとんどでなくなってしまいます。このように、どのような組み合わせで効果が出るかは、新しい防御技術が出るたびに考える必要がありそうです。
(Windows 7ではASLRはデフォルトで有効で、SEHOPはデフォルトで無効です。ASLRを無効にしてSEHOPを有効にするという使い方はあまり想定していないのかもしれません。)

そして現実に目を向けると、残念ながらWindows XPにはASLRやSEHOPという機能がありません。Windows XPは防御機構の充実度という点では少し弱いと言わざるを得ません。Hardware DEP単独ではなかなか高度な攻撃手法から防御することは難しいかもしれません。

セキュリティを考えるのであれば、やはりWindows 7という選択肢はよいのではないかと思います。ただし、きちんとASLRやSEHOPなどの設定をしておかなくてはいけません。(互換性の問題もありますので、注意して有効にするようにしてください。)こうすることで、Windows XPに中途半端なウィルスソフトを入れるよりはずっと安全になることと思います。

ただし、残念ながらこれで完璧に守れるということはありません。
CanSecWest2010でのPwn2OwnコンテストではASLRとDEPが有効なWindows 7でIE8がハックされました。

セキュリティを第一に考えるのであれば、まだまだ足りないということなのかもしれません。
そこで、おすすめするのがZDP・・・とここから先はマーケティングにお任せすることとして、今回はこの辺で。

| | トラックバック (0)
|

Windows XPのデータ実行防止

はじめまして、リサーチチームの本郷です。
日々のリサーチの中で気がついたちょっとしたことを紹介していきたいと思います。
どうぞよろしくお願いします。

今回はWindows のデータ実行防止(Data Execution Prevention 以下DEP)について話したいと思います。

DEPはWindows XP SP2 および Windows Server 2003 SP1から導入されたWindows のセキュリティ機構の一つです。

DEPにはソフトウェアDEPとハードウェアDEPがありますが、今回はハードウェアDEPについて取り上げます。

メモリ内部のセクションには大きく分けて、コードセクションとデータセクションがあります。コードセクションでは読み・実行が許可されており、データセクションでは読み・書きが許可されています(ここではそういう解釈で話を進めます)。

DEPはメモリ内の実行不可領域でのコード実行を防ぐもので、許可されてない領域でコードを実行しようとすると例外が発生します。

みなさんもこのような画面を見たことがあるのではないでしょうか

Photo_3

DEPの設定

DEPは4つの設定が用意されており、OptIn、OptOut、AlwaysOn、AlwaysOffがあります。

・OptIn
特定のプログラム(システムプログラムなど)のみDEPが適用されます。
・OptOut
すべてのプログラムにDEPが適用され、指定されたプログラムのDEPを解除することが可能です。
・AlwaysOn
すべてのプログラムにDEPが適用されます。
・AlwaysOff
すべてのプログラムにDEPが適用されません。

現在の状態はbootcfg /Queryで確認することができます。

Bootcfg_3

Windows XP ではデフォルトでOptInに設定されており、特定のプログラムにだけDEPが適用されています。

システムのプロパティの詳細設定->パフォーマンス オプションのデータ実行防止タブから「次に選択するものを除くすべてのプログラムおよびサービスについてDEPを有効にする」を選択することでOptInからOptOutに変更することが可能です。

Photo_2

画面の状態はOptInに設定されている状態です。

AlwaysOnやAlwaysOffにする場合はboot.iniファイルを変更する必要があります。

各プロセスに対するDEPの設定

DEPはプロセスごとに設定されます。DEPが設定されている場合の設定として、通常のDEPとDEP(permanent)があります。

通常のDEPに設定されている場合は、アプリケーション実行後にDEPの設定を変更することができ、DEP(permanent)に設定されている場合、DEPの設定を変更することはできません。

通常のDEPが適用されている場合、NtSetProcessInformation APIを使用することでDEPのON/OFFを操作することが可能です。
そのため、以前このブログでも紹介したReturn-Into-Libcを利用して、NtSetProcessInformation APIでDEPを無効化することで、実行不可領域に置いた攻撃コードを実行することが可能となります。

この手法は、NtSetProcessInformation API 呼び出しの際、引数にNULLバイトが必要となるため、
文字列処理のAPIによるバッファオーバーフローなどの脆弱性を利用する場合には使えません。

また、Uninformed - vol 2 article 4 でntdll内部のマシン語命令を利用してDEPを回避する方法が紹介されています。

Uninformed - vol 2 article 4

一方、DEP(permanent)はこのNtSetProcessInformationを使用してもON/OFFを切り替えることはできません。よって上述した攻撃を防ぐことが可能です。

Windows XP でデフォルトではDEP(permanent)は有効になっておらず、DEP(permanent)を有効にしたい場合は、AlwaysOnに設定するか、OptIn/OptOutに設定し、アプリケーション内部でDEP(permanent)を有効にする必要があります。
そのため、ユーザー側でDEP(permanent)にするにはAlwaysOnを選択する必要があります。

また、プロセスごとのDEPの適用状態はSysinternal SuiteのProcessExplorerで確認することができます(Vista以降であれば、タスクマネージャーから確認できます)。
Google ChromeやFirefoxではOptIn/OptOutの場合もDEP(permanent)となっていることが確認できます。

アプリケーション開発時の設定

アプリケーション開発時に/NXCOMPAT オプションを有効にしてリンクした場合、Vista以降ではDEP(permanent)が有効になるのですがXPでは適用されません。

前述の通り、システムがOptInおよびOptOutに設定されている場合にDEP(permanent)を有効にするには
アプリケーション内で明示的に有効にしてあげる必要があります。
Windows XP SP3 からはSetProcessDEPPolicy APIを使用することで、DEP(permanent)に設定することが可能です。
実際、SetProcessDEPPolicy API内部でNtSetProcessInformation APIを呼び出し、設定を行っています。

Windows XP SP3上でOptIn、OptOutが適用されている場合に/NXCOMPAT オプションをつけてリンクしたDep.exeとDEP(permanent)をアプリケーション内部で有効にしたDepPermanent.exeの違いを比較してみます。

ProcessExplorer上で通常のDEPが適用されている場合はDEPと表示され、DEP(permanent)が適用されている場合にはDEP(permanent)が表示されます。

システムにOptInが適用されている場合
Dep.exeはDEPが適用されていないが、DepPermanent.exeにはDEP(permanent)が適用されています。

Optindep

システムにOptOutが適用されている場合
Dep.exeはDEPが適用されており、DepPermanent.exeにはDEP(permanent)が適用されています。

Optoutdep

このようにWindows XPのデフォルト設定では、特定のアプリケーションにのみDEPが適用されています。デフォルトの設定で使用しているユーザーが多いことを考えると、アプリケーションを開発する側でDEPの設定を行ってあげることで、攻撃の可能性を減らすことが可能です。

---
このブログ中における株式会社フォティーンフォティ技術研究所(以下FFR)の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

| | トラックバック (0)
|

Windows Vistaからの保護機能:保護モードと整合性レベル

こんにちは、リサーチエンジニアの丹田です。Windowsのさまざまな仕組み(やその他もろもろ)を、わかりやすくお伝えしていきたいと思っています。どうぞよろしくお願いします。

今回はWindows Vistaから導入されたInternet Explorerの「保護モード」と、その背景にある「整合性レベル」についてお話しします。

保護モードとは、Internet Explorerの動作権限を自動的に小さくすることで、Internet Explorerが攻撃を受けてしまった場合でもその影響を抑えることができる仕組みです。この仕組みには、Windows Vistaからの新しい権限管理機能「整合性レベル(Integrity Level)」が利用されています。今回は、これらの仕組みがなぜ必要で、どのように機能するかについて見ていきます。

●保護モードの必要性

先日の記事でもありましたが、Internet Explorerに未修正の脆弱性が見つかりました。Internet Explorerなどのウェブブラウザーの脆弱性は、そのウェブブラウザーの利用者が攻撃用のウェブページにアクセスしただけで脆弱性が突かれ、悪意あるコードが実行されてしまうケースがあります。Microsoftのセキュリティアドバイザリによれば、今回の脆弱性もこのような攻撃シナリオが想定されています。

仮に脆弱性に対する攻撃が成立してしまった場合、多くの場合その脆弱性を持つプロセスが攻撃コードを実行するため、攻撃コードの動作権限は、その脆弱性を持つプロセスの動作権限と同じになります。Windowsは管理者権限のアカウントで利用されていることが多く、攻撃コードも管理者権限で動作することになってしまいます。

そこで Microsoft は、Internet Explorer 7 から「保護モード」と呼ばれる仕組みを導入しました。

保護モードと整合性レベルの働き

保護モードは、冒頭でも触れたとおり「整合性レベル」という機能を利用して実現されています。整合性レベルとは、プロセスそれぞれに対して「整合性レベル:高/中/低」という3つの権限レベルを割り当て、これを基に、従来のアカウントベースの権限チェックに先立ってアクセス権の検証を行うものです。

整合性レベルが低いほど動作は制限され、保護モードで動作する Internet Explorerは整合性レベル「低」で動作するようになります。これにより、万が一Internet Explorerの脆弱性が突かれ、攻撃コードが実行されてしまった場合でも、システムに対する影響を最小化できます。

以下に、それぞれの整合性レベルによるアクセス権の違いの一部を示します。

  • 整合性レベル「高」のプロセスはいわゆる昇格したプロセスです。システム全体に関する場所への書き込みが可能です。たとえば、Program FilesやWindowsフォルダ以下、HKEY_LOCAL_MACHINE以下など、ほぼ無制限に環境を変更できます。
  • 整合性レベル「中」のプロセスは通常のプロセスです。そのプロセスを動作させたユーザー環境だけに関する場所への書き込みが可能です。たとえば%USERPROFILE%以下や、HKEY_CURRENT_USER以下を変更できます。
  • 整合性レベル「低」のプロセスは制限されたプロセスです。特別に許可された場所だけへの書き込みが可能です。たとえば%USERPROFILE%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low以下や、HKEY_CURRENT_USER\Software\LowRegistry以下を変更できます。

保護モードによって整合性レベル「低」で動作するInternet Explorerは、上記のような制限が設けられ、攻撃コードの影響範囲が抑えられます。

なお、あるフォルダが整合性レベル「低」でも書き込み否かを確認するには、icaclsコマンドを利用できます。次の画像は、icaclsコマンドを使い整合性レベル「低」でも書き込み可能なフォルダであることを確認しています。

Icacls_1_3
icaclsコマンドによる設定の確認

●整合性レベルの決定

では、この保護モードを実装する、プロセスの整合性レベルがどのように決まるかを簡単にまとめます。これは通常、UAC(User Account Control)の設定状態とアカウントの権限によって次のように決まります。

  • UAC が無効の状態で、制限ユーザーが起動したプロセスの整合性レベルは「中」になります。
  • UAC が無効の状態で、管理者が起動したプロセスの整合性レベルは「高」になります
  • UAC が有効の状態で、保護モードを有効にしたInternet Exploreの整合性レベルは「低」になります。
  • UAC が有効の状態で、制限ユーザーが起動したプロセスの整合性レベルは「中」になります。
  • UAC が有効の状態で、管理者が起動したプロセスの整合性レベルは「中」になります。
  • UAC が有効の状態で、「管理者として実行」により起動したプロセスの整合性レベルは「高」になります。

プロセスの整合性レベルはProcess Explorerを使って簡単に確認できます。Process Explorerでは整合性レベルの高中低が、それぞれ「Integrity」列に High、Medium、Lowと表示されます。

次の画像は、UAC が有効の環境において、それぞれ次の方法でInternet Explorerを起動した様子です。整合性レベルの違いが確認できるかと思います。

  • 「管理者として実行」により起動したもの(Integrity: High)
  • 保護モードを無効で起動したもの(Integrity: Medium)
  • 保護モードを有効で起動したもの(Integrity: Low)

3ie_1_5

Internet Explorerの各動作状態における整合性レベルの表示

なお、UAC が無効の場合、2つの点で注意が必要です。

  1. 保護モードは自動的に無効になります。つまり整合性レベルは「低」にならず、上記のルールに基づいて「中」や「高」が設定されます。
  2. 管理者が起動したプロセスの整合性レベルは「高」になります。これはWindows XP 以前と同様の使い勝手を実現しますが、プロセスが攻撃を受けた場合のリスクが高まります。

UAC を無効にする場合、これらの点を考慮するようにしてください。

以上です。いかがでしたでしょうか。最後に、保護モードや整合性レベルについてのより詳細な資料をいくつかご紹介します。これらの情報が、Windowsの安全な利用の助けとなれば幸いです。

●参考資料

---

このブログ中における株式会社フォティーンフォティ技術研究所(以下FFR)の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

| | トラックバック (0)
|

Internet Explorer iepeers 0-day 脆弱性 vs FFR yarai

金居です。

Internet Explorer 6/7に、未パッチのセキュリティ脆弱性が発見されており、攻撃コードが出回っています。近年猛威を振っているGumblar型の攻撃に悪用される懸念がありますので、Internet Explorer 6/7をお使いの方は注意して下さい。

セキュリティホールmemoに、詳しい情報が時系列に整理されて掲載されています。

http://www.st.ryukoku.ac.jp/~kjm/security/memo/2010/03.html#20100311_IE

■参考情報
・マイクロソフトセキュリティアドバイザリ
http://www.microsoft.com/japan/technet/security/advisory/981374.mspx
・JVNVU#744549
http://jvn.jp/cert/JVNVU744549/
・NTT データセキュリティ
http://www.nttdata-sec.co.jp/article/vulner/pdf/report20100312.pdf
・so-netセキュリティ通信
http://www.so-net.ne.jp/security/news/view.cgi?type=2&no=2182

Internet Explorer 8は本脆弱性の影響を受けませんので、Internet Explorer 8にアップグレードしてください。また、「iepeers.dll のピア ファクトリ クラスを無効にする」ことで本問題を回避する事ができます。

http://support.microsoft.com/kb/981374/en

なお、FFR yaraiは、本攻撃に対してZDPエンジンで検出出来ています。

環境および攻撃コード:
yarai ZDP v1.1.528
Windows XP SP3 / IE 7.0
exploit/windows/browser/ie_iepeers_pointer (metasploit 3.3.4-dev.8793)

| | コメント (0) | トラックバック (0)
|

Hardware DEPとReturn-into-libc

こんにちは、村上です。予定を変更して今回は、今月の始めに公開されたHardware DEP(Data Execution Prevention)回避版のInternet ExplorerのPoCについてお話したいと思います。

ご存知の方もいらっしゃると思いますが今月1日、SkyLinedことBerend-Jan Wever氏によってWindows XPSP2以降に搭載されているセキュリティ機能であるHardware DEPの回避に対応したPoCが公開されました。

Internet Exploiter 2 - bypassing DEP

はじめに断っておくと、攻撃対象となるIEの脆弱性は、既にマイクロソフトからセキュリティ更新プログラムが提供されているためWindows Updateを実施しているユーザーは影響を受けません。この脆弱性が発見された当初に公開された攻撃コードは、Hardware DEPの回避に対応しておらずHardware DEPが有効に設定された環境下では、攻撃は成功しませんでした。余談ですが、Windows XPSP2の既定状態では、Hardware DEPは有効化されていないため可能であれば有効化することをお薦めします。

[HOWTO] Windows XP SP2 におけるメモリ保護の構成方法

Wever氏が公開したPoCは、Return-into-libcと呼ばれるテクニックを利用してHardware DEPを回避しての攻撃が可能であることを実証するものです。Return-into-libc自体は、特段目新しいものではなく私が知る限り初めてそのアイディアが公開されたのは、1997年のことです。その後、いくつかリサーチによりブラッシュアップされ近年、実際の攻撃でも利用されるようになってきています。興味のある方は、下記をご参照ください。

Getting around non-executable stack (and fix)

The advanced return-into-lib(c) exploits

Hardware DEPの基本的な考え方は、プロセッサがサポートしているNX/XDビットを利用してコード実行可能なメモリ領域とコード実行不可能なメモリ領域を明確に分離し、意図しないコード実行を防止するというものです。メモリ破壊に起因する脆弱性では、一般的に「(1)脆弱性を利用した制御フローの奪取」、「(2)スタック領域・ヒープ領域に読み込まれた攻撃コードの実行」の2つのステップから成り立ちます。Hardware DEPが有効化された環境下では、プログラムが明示的に実行可能とマークしない限りスタック領域・ヒープ領域はコード実行不可能となり、前述の(2)を防止することができます。これは、攻撃者から見ると「脆弱性を攻撃して制御は奪えたものの、意味のある悪事がなにもできない」(プロセスのクラッシュによるDoS攻撃は例外)という状況です。

Return-into-libcは、発想を転換し、プロセスが利用しているDLL上のAPIを実行する手法です。これらのAPIはそもそも実行すべきものであるため、そのメモリ領域は元からコード実行可能とマークされています。ただし、当然、そこにはDLLが提供しているAPIしか存在しないため、必ずしも「攻撃者が行いたいこと」を行えるわけではありません。

さて、任意のWin32 APIを呼び出せるとしたらなにを呼び出すでしょうか? Windowsには都合の良いことにメモリ属性を変更するAPIが存在します。そこで、より実践的な攻撃手法としては、「(1)脆弱性を利用して制御フローを奪取する」、「(2)Return-into-libcによりメモリ属性を変更するAPIを呼び出しスタック領域・ヒープ領域をコード実行可能にマークする」、「(3)スタック・ヒープ領域に置かれた攻撃コードを実行する」という流れになります。

このようにReturn-into-libcを用いることでHardware DEPを回避することは可能です。ただし、前述のようにこの技術は目新しいものではありません。また、Wever氏が氏のブログでもコメントしている通りHardware DEP及びASLR(Address Space Layout Randomization)が有効化された環境では攻撃は成立しません。こうしたOSや開発環境が提供しているセキュリティ機能の組み合わせと攻撃可能性については、社内でもリサーチしており弊社のWebページでリサーチペーパーを公開しています。

SEHオーバーライトの防御機能とそのExploit可能性

実は、上記のリサーチペーパーが先日お話した鈴木のCanSecWest 2010での発表内容になっています。手前味噌ではありますが技術的に良く纏まった内容になっていますので興味のある方は是非一読ください。最後に、FFR yaraiはReturn-into-libc攻撃に対応済という点をお知らせして終わりたいと思います。

---

このブログ中における株式会社フォティーンフォティ技術研究所(以下FFR)の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

| | トラックバック (0)
|

FFRのリサーチ

セキュリティ技術のカテゴリーリーダを担当する村上純一です。

このカテゴリーでは、最新セキュリティトピックの技術解説やFFR社内でのリサーチについて取り上げていく予定です。

初回ですので自己紹介を兼ねて簡単に私自身の興味やリサーチについてお話します。私は、2000年頃からルートキットを中心としたマルウェアの検出・分析手法の研究に取り組んできました。当時、ルートキットと言うとSolaris等のサーバでハッカーが利用するツールキットと言う意味合いが強く、今のようにクライアント端末でマルウェアが隠れ蓑に利用する、と言った用途は想像することができませんでした。これは、ITが十分に普及した事、それに伴ない悪意の矛先がサーバからクライアント、一般ユーザに広がった事が大きく関係しています。それだけ「IT」や「セキュリティ」という言葉も変わった・多様になったという事だと思います。
話が脱線しましたが、この2、3年は仮想化技術を応用してこうしたマルウェアを検出・分析するための研究に取り組んできました。仮想化技術が登場した当初は、それ自体のセキュリティがリサーチャーの間で熱く議論されました。現状そうしたフェーズは一段落しており、「仮想化技術を応用したセキュリティシステム」や「仮想化技術を利用したシステムにおけるセキュリティ」の2種類の話題が多いように感じます。私の研究も前者に該当し、研究成果の一部を国内外のカンファレンスで発表して参りました。

Hypervisor IPS based on Hardware Assisted Virtualization Technology
http://www.fourteenforty.jp/research/research_papers/bh-usa-08-Murakami.pdf

FFR GreenKiller - Automatic kernel-mode malware analysis system
http://www.fourteenforty.jp/research/research_papers/avar-2009-murakami.pdf

FFR社内では、この他にもExploitation技術、IPv6、組み込みセキュリティ等について各リサーチャーがそれぞれの課題に取り組んでいます。そうした研究の成果についても段階的に公開していければと考えています。直近では、今月末にカナダで開催されるCanSecWest Vancouver 2010で弊社の鈴木が「SEH overwrite and its exploitability」と言うタイトルで発表する予定です。

CanSecWest Vancouver 2010 - Speakers
http://cansecwest.com/speakers.html

参加される方がいらっしゃいましたら是非お声掛けください。次回は、鈴木からのCanSecWest参加報告になる予定です。

それではこれからよろしくお願いします。

---
このブログ中における株式会社フォティーンフォティ技術研究所(以下FFR)の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

| | トラックバック (0)
|