2007/04/09 リバースエンジニアリングまつりのメモ

• 2007/4/9に開催された「情報セキュリティのためのリバースエンジニアリング」に参加した際のメモです。
  • http://cmuj.jp/070409workshop/index.html
• 個人的なメモなので、公演内容と異なっている場合があります。ご利用は自己責任でお願いします。

きっかけ

• リバースエンジニアリングは情報セキュリティにとって重要な技術
• そろそろきっちり体系化した方がいいんでは？

リバースエンジニアリングの目的

• ウイルス・ワームなどの解析・対策
• 脆弱性の発見
• ソースが無いソフトウェアのメンテナンス
• 悪い面？
  • 競合製品の解析
  • DRMの回避
  • チート

手法

• 2つの軸で表にまとめてあった
  • 静的解析、動的解析
  • 共通、マルウェア向け、脆弱性発見向け

リバースエンジニアリング環境

• VMを使った環境
  • VMWare, VirtualPC, Parallels, Xen, etc...
  • 最近のマルウェアではVMの検出を行うものもある？
• 実マシンをつかった解析環境

静的解析・動的解析

• 動的解析
  • プログラムの入出力を監視
    • ファイル、レジストリ、ポート(socket)、通信
  • デバッガ

Fuzzing

• プログラムの入力に対して、ブルートフォース的にいろいろ入力してエラーを発生させる。
• ファザーはいろいろなプロトコルに対応して、効率よくバグを探索できることが望ましい。
• Application Fuzzing, Protorol fuzzing, File Fuzzing
• プログラムの自動テストという面でもFuzzingが使われてきている。

リバースエンジニアリングへの対抗技術

• 暗号化
• アンチディスアセンブル
  • 逆アセンブラで解釈できないようなコードを生成
• バイナリパッキング
• アンチデバッガ
• 難読化

バイナリパッキング

• • UPXとか

アンチデバッギング

• 検出方法
  • 処理時間の検出
• 検出後の動作

研究動向

• プログラムの復元
• プロトコル解析
• P2Pアプリケーションなどの解析
• マルウェア解析
• 脆弱性解析の自動化
• 難読化
• Fuzzing

法的課題

• Sega vs Accoladeのケース
• Mega Driveをリバースエンジニアリング、互換機を販売
• このケースでのリバースエンジニアリングは合法との判決が出た

DMCA

• リバースエンジニアリングから著作権保護技術の回避を禁止
• DMCAは著作権保護技術のみに適用される
• 例外: 互換性の確保、暗号技術の研究、セキュリティテスト、教育機関および公共図書館(評価目的)、政府機関による調査・規制、プライバシの保護

• ハッカーアンダーグラウンドの脆弱性解析能力が飛躍的に向上
• セキュリティ分野のリバースエンジニアリングは社会的に重要

脆弱性監査

• ソースコード監査
  • ソースコードがないと監査できない
• トライ＆エラー監査
  • ソースコードがなくても監査可能
  • 簡単な脆弱性は短時間で発見可能
  • 一部自動化可能(Fuzzing)
  • 見落としが発生しやすい
• バイナリ監査
  • 見落としが少ない
  • 一定の経験が必要
  • 時間がかかる

脆弱性脅威分析

• 正確な脆弱性の脅威を把握したい
• 過大評価されるケース
  • デマ、コード実行が不可なケース…
• 過小評価されるケース
  • 実際はコード実行が可能なケース
  • Winnyとか？

exploitの安定化

• 環境によって安定性が変わる
• 安定したexploitが作成できるほと危険
• レジスタジャンプ
• ファンクションポインタ書き換え
• ブルートフォース

パッチ差分解析

• 新モジュールと旧モジュールの差分をとって、修正内容を解析
• ベンダーのアナウンスが常に正しいとは限らない
  • 他の脆弱性が修正されているかもしれない
  • 脆弱性が完全に修正されていないかもしれない
• 脆弱性の正確な脅威分析
  • その脆弱性は本当に危険性が高いのか？
• アタックベクタの確認
• セキュリティ対策製品の開発

サイドエフェクト解析

• パッチを適用することで、パッチ適用前にはなかった挙動(サイドエフェクト)が発生する場合がある

バイナリパッチング

• 関数ポインタ書き換えでパッチング
• ランタイムパッチング
  • ファイルを書き換えないので安全

脆弱性監査例

• ツール
  • IDA Pro, Windows Symbols, Visual Studio, SoftICE, WinDbg, バイナリエディタ,Process Explorer, TCP View, DbgView
  • ツールのおかげで効率良く監査可能に

• アプローチ
  • トップダウン
  • ボトムダウン

• 最近の脆弱性のトレンド
  • str*系のバッファオーバーフローは消滅
    • 教育、コンパイラ警告、コンパイラ保護などによりメジャーシステムでは消滅
    • 監査されていないものには残っている可能性がある
  • 整数オーバーフローによるバッファオーバフローや関数ポインタ書き換えが主流
    • バイナリベースのプロトコルに見つかりやすい。
    • テキストベースのプロトコルでは、ほとんど無い。
  • Fuzzingによって発見困難だった脆弱性が洗い出されている

Windows ANI File Parsing Buffer Overflow(MS05-002)

• UFuz3(Fuzzer)で発見
• FD FF FF FFを指定しているのは、FFFFFFFFだとエラーコードとして解釈される可能性があるため、わざと外しておくのがコツ？

• 先日のANIファイルの脆弱性については、もう1箇所同様の問題の箇所があったが、こちらは修正されていなかったため。

Windows LSA Service Remote Buffer Overflow(MS04-011)

• Sasserワームやボットなどに悪用された
• リモートから攻撃可能(139/tcp,445/tcp)
• Undocumentedな関数にバッファオーバーフローがある
  • DsRoleUpgradeDownlevelServer()(netapi32.dll)

まとめ

解析作業の効率化が必要

• バイナリ脆弱性監査の半自動化
• パッチ差分抽出技術(diffing)の性能向上
• exploit解析支援

そのほか

微妙に資料の初めの方は見たことがあるような気が…(笑

マルウェアのリバースエンジニアリング

• いかに解析を速くするか？が課題

解析の手がかり

• IAT(インポートアドレステーブル)
  • 対象プログラムが呼び出すAPIを知ることができる
  • 通信するプログラムはsocket()とかconnect()とか
• 文字列

問題

• 時間と手間がかかる
• OS,ネットワーク、プログラミング言語など幅広い知識が必要
• パッカーが使われていると、アンパックの必要がある
• 難読化・アンチデバッギングなどのテクニックが使われている
• コードの巨大化
  • 解析に労力が必要
  • Sdbotのある亜種はアセンブリコードで50000行以上

パッカー

• パックされている状態では逆アセンブルできない。
• アンパックが必要
• 解析に時間がかかる。

アンチデバッギング

• IsDebuggerPresent()
• INT3
• GetTickCount()
• アンチPEアナリシス
  • PEファイルのヘッダを改ざんする
  • デバッガや逆アセンブラで読み込めなくする
  • WindowsのPEローダはヘッダに存在する無効な値に関しては寛大
    • 無効な値がある場合は自動で修正、問題なく実行してくれる

難読化

• 簡単なパターンマッチングでは検出不可能
• コードを暗号化するポリモーフィック、コードを変更するメタモーフィック
• メタモーフィック技術は、同じ挙動をするマルウェアが異なるコードになる

まとめ

• リバースエンジニアリング手法の体系化が必要
  • 解析の効率化
  • スキルによらない解析結果の確保
  • エンジニアの育成
• 情報共有
  • 解析時間の短縮
  • 日本語で情報共有ができるとうれしいかも？
• 自動化

Windows / Microsoft製品

• EULAにリバースエンジニアリングを許可しない。ということが明記されている。

• 誰かが訴えられてくれないと、リバースエンジニアリングはOKなのかわからない？
  • 今日のプレゼンは小野寺さん個人の異見。MS公式な見解ではない。

ソフトウェア開発者・提供者として

• ソフトウェアの秘密は守りたい
  • 企業秘密・特許・ノウハウがいっぱい
• 開発サポートを円滑に進めたい
  • アプリケーション、ミドルウェアのデバッグ
  • リバースエンジニアリングが必要

安全な?リバースエンジニアリング

• デバッグ
  • Microsoftはデバッガ、デバッグ用のシンボルを提供している
• Malware解析
  • アプリケーションと同じ扱い
  • 開発者が権利を主張することは無い
• 脆弱性解析
  • グレーゾーン
  • 製品解析ではなく、製品の"不思議な挙動"による

   アプリケーションへの影響を解析していると解釈

リバースエンジニアリングの阻止

• 難読化
  • .NET Framefork(CLI)向けに必要
  • Dotfuscator community editionがVS2005に添付されている
  • .NET Frameworkの主要コンポーネントは難読化がされていない
• デバッガの検出
• Protected Process(Vistaのみ)
  • Kernel(OS)レベルでプロセスを保護
  • Microsoft公認rootkit?
    • デバッガのアタッチなどから保護する機能を提供
  • ただしMicrosoftの認証が必要

これからの人へ

• 自分で作ってみる
• WinDbgのHelpを読む
  • デバッグのテクニックがかかれている
• 試してみる

おまけ

• Microsoft開発者の人はほとんどソースコードをみていない
• 時間がかかる
• ソースコードを見てしまうことで、誤解析

• マルウェア解析のある一定のところまでは自動化されている
  • 最後のつめだけ人間が判断
  • 専用の解析ツールが作成されている

もう少し、リバースエンジニアリングについてオープンに 話し合うべきじゃないかな？という御意見

質問タイム

• Protected Processについての質問
  • デバッグはCheck Build版のWindowsを使う
  • 作れるのはProctected Processのライセンスを受けている人

• 一般的な判断
  • 公正使用(フェアユース)にあたる場合
    • 思想や機能的要素にアプローチできる唯一の方法であること
    • 正当な理由のある場合
  • 著作権が保護しているのは表現

• DMCA
  • コピープロテクト破りは禁止
  • 例外規定がある
    • 相互流用性のため、暗号研究、セキュリティテスト、政府の調査…とか

• UCITA(Uniform Computer Information Transaction)
  • リバースエンジニアリング禁止事項などを正当化するもの
  • 採用している州は少ない。
  • 規定もあいまい。

• EUディレクティブではリバースエンジニアリングを認めている
  • 6条

• 日本ではどうなの？
  • 逆コンパイルの過程で出力されたソースコードはプログラムの複製物に相当するか？
  • リバースエンジニアリングを認める異見が大多数
    • 説の根拠については、明確ではない

• 鵜飼さん
  • 日本でリバースエンジニアリングってどうよ？
• 高橋さん
  • 公のバックアップを得られるのがいいんじゃないの？
• 鵜飼さん
  • けっこうびびりながら解析してますよw
  • Microsoftさんのようにリーダシップあるところが音頭とって欲しいなぁ…
• 小野寺さん
  • もちあげても何もでないですよw
  • 安心できるラインというのが明言できないはがゆさ？
  • 逆にみなさんから、こういったところをEULAから外してほしいとか、

   そういう声がほしいかも？

• 武田さん
  • こういう問題に遭遇している人が少ない？

• 武田さん
  • ShareとWinnyの解析はちょっと性質が違う
    • 特定のアプリケーションで起こっている事象を解明する必要があるというのは、特殊なケース？
    • メンテナンスされていないソフトはリバースエンジニアリングするしかないのかな？
    • Share同梱のtextファイルに明記されているリバースエンジニアリングだめよの禁止条項は有効？

• 高橋さん
  • 権利が侵害されてはじめて訴えることが可能？
  • そもそも利用者の権利が侵害されているのか？

• 武田さん
  • 競合製品の開発のニュアンスを含んでいると良くない？
  • Shareの場合は、本来のリバースエンジニアリング
  • たとえば、星沢さんがマルウェアリバースエンジニアリングをしていてマルウェアの作者の権利を侵害しているとか？

• 星沢さん
  • そういった意識を持ってる人はいないんじゃないか？
  • 正義の味方的な意識でリバースエンジニアリング

• 高橋さん
  • 作者が表に出てきて、権利を主張するとは思えないw
  • 事実上は無視していいんじゃないの？

• 武田さん
  • リバースエンジニアリングで遭遇した困ったことは？

• 星沢さん
  • 情報共有重要
  • 実は、攻撃側の人達は、うまく情報共有しているのか？
  • そもそもそういう情報が欲しいという人っているの？
    • 会場の7割ぐらい手をあげる
  • 日本語の情報

• 武田さん
  • なぜ日本ではそういう情報が少ない状態なのか？

• 小野寺さん
  • リバースエンジニアリングってうしろめたいイメージがあるかも？
  • EULAに書いてる
  • Microsoftの権利が侵害されなければおk？
  • リバースエンジニアリングした結果、何をするか？
    • 昔は攻撃などにつかわれていたから、アンダーグラウンドなイメージ

• 鵜飼さん
  • 昔はソフトウェアのクラックに使われていたケースが多かった。
  • そういう歴史があって、リバースエンジニアリングはアンダーグラウンドなイメージがあったのでは？

• 武田さん
  • このイベントを開催するにあたって、微妙に後ろめたい気持ちがなきにしもあらず。
  • 企業がこういったイベントを開催するのは、いまの時期だと微妙だったのかな？
  • 日本にもリバースエンジニアリング系の資料はあるけど、クラック系の話題が多い
  • リバースエンジニアリングのイメージアップが必要かも。
  • 足りないところは？＞all

• 星沢さん
  • 仕事では解析のトレーニングをビジネスとしてるけど、
  • 技術はオープンにしていきたい
  • 共有できる場があるといいなーと思う

• 鵜飼さん
  • リバースエンジニアリングに関する技術がオープンになっていない
  • 最近、なんで話題にしないのか？
  • 日本だけ特殊な事情がある？＞道徳的にとか？

• 小野寺さん
  • これをやったらつかまるのでは？という不安が大きいのでは？
    • ここまでならOKという線引きが欲しいのかも。
  • 教育でデバッグ技術を教えていることが少ない？
    • 低レベルなところの知識が足りない

• 高橋さん
  • どこまでOKなのかがはっきりしていないのが問題
  • リバースエンジニアリングを社会的に認知してもらう必要がある。

• 武田さん
  • 昔tcpdumpをかけるのは悪いイメージがあった。
  • それに近い雰囲気があるのでは。
  • 有用性を知ってもらう必要がある。

• 高木さん
  • リバースエンジニアリングを市民権を得ていないというのがWIkipediaにかいてある
    • Wikiをみんなで編集すればいいんでは？w
  • 言葉が良くない？＞リバースエンジニアリング

• • ライセンス(使用許諾)をやぶると、どうなるのか？
    • 評価する際には許諾が必要な生体認証装置があるみたい？

• 小野寺さん
  • 民事で争うケースが多い
  • 刑事告発になるケースもまれにある？

• 高橋さん
  • 複製権の侵害とか以外だったら、普通はライセンスを侵害したことでの刑事罰はない

• 会場から
  • どうして「監査」という言葉をつかってるのか？英語でauditing
  • セキュリティのリバースエンジニアリングにはプロセスが確立されているのでは？
    • 発見から公開までの一連のプロセスがある
  • 日本では2バイトコードに関する不具合の報告がおおい
    • これをセキュリティとして扱われていない
    • 悪用されるとどうなるか？というモチベーションが足りない？

• 鵜飼さん
  • 「監査」を使っているのは、同僚がつかってるから？
  • 別に深い意味はない？

• 武田さん
  • 脆弱性の報告制度について

• 鵜飼さん
  • 静寂制の取扱いプロセスには、紳士協定がある。

• 高橋さん
  • 生体認証の評価を勝手にすると
  • ありえない条項だと、それは無効
    • 普通に使おうとしている行為を禁止すること自体、無効

• 高木さん
  • 石橋を叩いて渡らずべからす
  • 使用許諾の文章自体を公表するのはあり？w

• 武田さん
  • 合理的な引用ならおkじゃないのw

• 小野寺さん
  • EULAにいろいろ書いてるけど、MSの権利を侵害しないでねという意味で書いている
  • 常識的な範囲で、技術をみがいてほしいです。
  • 手をうごかすところから

• 鵜飼さん
  • いまの日本のリバースエンジニアリングに関しての風潮を打破するような流れができるといいかも。
  • 日本からすばらしい技術者が出てほしい

• 星澤さん
  • 情報共有できる場・しくみがほしいなー

• 高橋さん
  • 法律的にグレーなのが問題
  • 公的な機関もまきこんで
  • ライセンスの禁止事項は何を保護したいのか？の分析が必要

• 武田さん
  • 教育プログラム

• ちょっとネタかぶり気味？
• ちょっと具体的な話に欠けてるかな？と思ったり。
  • 客層を考えると…
  • なんだかんだ言っても、解析のノウハウが企業秘密になってるとか？
• 解析時間の短縮が重要課題
• リバースエンジニアリングに関する情報共有が必要
• どこまで解析していいのか？の線引きがない
• リバースエンジニアリングのイメージアップキャンペーンが必要そう？ｗ