[CB16] Cyber Grand Challenge (CGC) : 世界初のマシン同士の全自動ハッキングトーナメント by Tyler Nighswander

世界初のマシン同士のハッキングトーナメント

Tyler Nighswander

THE CYBER GRAND CHALLENGE

動機▸ ソフトウェアのセキュリティ査定はスケールしない

▸ 推定 50:1　コードを書く人間対コードをレビューする人間

▸ コードを書く側は１週間で200行?

▸ 分析官は１週間で1万行、年間50万行をレビュー

Good luck

‣ また、完全に追いつくまでは新しいコードが書かれ続けられる!


動機▸ 帯域の問題:

▸ 分析されるプログラムよりも書かれるプログラムの方が多い。

▸ レイテンシー問題:

▸ プログラムの査定を更から始めるには時間がかかる。

▸ セキュリティ問題の切り出し・対応には時間がかかる


動機

高帯域

低帯域

高レイテンシー


動機

高帯域

中帯域

中程度レイテンシー

非現実的


動機

中帯域

低帯域


事業に不向き


動機

高帯域

中帯域


経済的で無い


動機

高帯域

高帯域

低レイテンシー

まだ現実的では無い


動機

高帯域

高帯域

低レイテンシー


始まり▸ Defense Advanced Research Projects Agency (DARPA) ▸ Internet、GPS、ステルス技術、オニオンルーティング等の現実化

▸ 様々な”チャレンジ”を主催

CMU Sandstorm Google Self Driving Car


始まり▸ アイディア: コンピュータセキュリティのチャレンジを主催

▸ CTF協議モデルの採用

▸ 入賞上位７チームに賞金USD$750,000

▸ 決勝戦優勝者に賞金USD$2,000,000

▸ Cyber Grand Challenge


自己紹介▸ PPPのメンバーとして７年以上CTFへ参加

▸ 世界トップランクのCTFチーム (通常は) !

▸ CMUを卒業

▸ 複数のDARPAチャレンジの優勝・入賞者

▸ ForAllSecureにてリサーチャー

▸ １０年以上にセキュリティ自動化の研究を行ってきた

Perfect fit !


CGCについて

▸ 攻撃＆防衛形式の CTF: REFEREE

PLAYERS


CGCについて

▸ 攻撃＆防衛形式の CTF:


CGCについて

▸ 攻撃＆防衛形式の CTF:+10 POINTS

FOR RED

-10 POINTS FOR GREEN


CGCについて

▸ 攻撃＆防衛形式の CTF:IS YOUR

SERVICE RUNNING?


CGCについて

▸ 攻撃＆防衛形式の CTF:


CGCについて

▸ 攻撃＆防衛形式の CTF: サービスダウン！ -20ポイントサービスは稼働

してるか？


CGCについて

▸ 以下がスコア条件:

▸ セキュリティ:

▸ 自分のシステムが侵害されると減点

▸ 攻撃:

▸ 他のチームの侵害に成功すれば加点

▸ 冗長性:

▸ パフォーマンスが低下すれば減点

▸ 機能が低下すれば減点


CGCについて

▸ スコアリングの公正性を保つためにDARPAが全てを運用

▸ DARPAに実行用バイナリーを渡す

▸ DARPAにエキプロイトを送信するプログラムを渡す

マシンはAPIを

使って通信

レフリーは自分の

ゲームを展開


ABOUT CGC

▸ 冗長性のスコアリングは厳正!

▸ 機能が停止すれば減点

▸ プログラム用の仮死確認で図られる

▸ 仮死確認プログラムは隠されているがトラフィックは見える

▸ 仕様は非公開!

▸ 時間・メモリー使用量が5%増えるたびに減点

15% OVERHEAD 70% SCORE


CGCについて

▸ ELFを模した新しい実行フォーマットを作る

▸ 7つのシステムコール:▸ exit ▸ transmit ▸ receive ▸ fdwait

▸ allocate ▸ deallocate ▸ random

▸ 異質のコード実行を安全に行える

▸ Linux/Windows/OSXに比べて自動分析が容易


CGCについて

▸ ファイルシステムが無い、forkやexecも無い、エキスプロイトとは？

▸ タイプ 1:

▸ レジスターと命令ポインターをコントロール

▸ タイプ 2:

▸ 機密情報の漏洩

Codenomicon/Synopsys


CGCについて

▸ ７つのシステムコールがあり複雑性は十分!

▸ プログラムは:

▸ 複数のバイナリーが通信

▸ User-space スレッド

▸ 非決定性, ノンス, チェックサム

▸ C もしくは C++ コードをX86アセンブリ用にコンパイル


CGCについて

▸ 幾つかの有名なバグが容易に再現可能:

▸ Heartbleed

▸ LNK exploit (Stuxnet感染ベクター)

▸ Crackaddr バグ

▸ SQL Slammer

▸ 全部が良い簡素なCGCフレームワーク内で可能


MAYHEM

▸ System created by ForAllSecure ▸ (spoiler alert: winning system!)

▸ Overall architecture roughly similar to other teams

▸ Several independent components with different tasks

▸ Use centralized database for sharing information

▸ Let’s dive in!


MAYHEM: 頑強性

▸ 100%自動化でなければいけない!

▸ システムを稼働し続けるのは困難!

▸ 信頼されないコードの実行は困難!

▸ 不明なプログラムの分析を行うソフトウェアの開発は困難!

▸ 分散システムは難しい!

▸ 以上のことを全て敵対条件下で行う!


MAYHEM: 頑強性

▸ ステップ 1: 全部を三度ボックス化

▸ ツール実行はseccompを使う

▸ … リソースは制限する

▸ … VM内で行う

▸ ステップ 2: 全ての要素に冗長性を持たせる

▸ 最低でもどの単一ノードの正規フェイルオーバー

▸ ステップ 3: いずれ障害は発生すると仮定、発生すればリカバーを行う

▸ 生存性は全コンポーネントを確認

▸ コンポーネントの再起動が簡単であることを必ず行う


MAYHEM: バグの発見

▸ シンボリック実行

▸ 学界では最先端のテクノロジー

▸ プログラムをシンボリック表現として表す

▸ SAT/SMT ソルバーを使ってインプットを生成する

int main(int argc, char** argv) { if (argc < 3) return -1; int a = atoi(argv[1]); int b = atoi(argv[2]); if (a == 42) {

if (b == 31337) { puts(“You made it!”);

} return 1;

} return 0;

}

シンボリックとして扱う！

LEN(ARGV) >= 3

RETURN -1

42 == ATOI(ARGV[1])

31337 == ATOI(ARGV[2])

RETURN 0 RETURN 1

PRINT



▸ ファジング

▸ 業界で標準の技術

▸ 確定値をプログラムに送って実行する

▸ また、プログラムの”計測”も可能

▸ 内部状況の開示、インプットをどう処理したか

▸ 様々な手法を使って行うことが可能…

A = 239075, B = 75291

if (a == 42) { if (b == 31337) {

puts(“You made it!”); } return 1;

} return 0;

42 == A

31337 == B

PRINT

0.00000002%

0.00000002%

RETURN 0

99.99999998%

A = 239075, B = 31337A = 42, B = 9852756A = 42, B = 24752A = 42, B = 31337



▸ ファジングの観測:

▸ 効率的な観測手法はまだ研究領域を脱していない

▸ QEMU, PIN, DynInst, DynamoRIO, 等 ?

▸ 全て、2-10倍の失速を発生させる

▸ ファザーをより高性能にすれば遅くなるだけ!



ファジング

セットアップと実行が簡単

毎秒10-1万の実行

無知

リソース負荷が低い

浅いパスの調査が早い失速

シンボリック実行

通常はとても複雑

1-∞ 秒ごとの”実行”

プログラムを”理解”

リソース負荷が高い

深いパスの調査が遅い計算爆発



▸ ファジングとシンボリック実行

▸ 同時の両方の良いところを取り込む

▸ ファジングを使って浅いパスを明らかにする

▸ シンボリック実行を使って深い、複雑なパスの発見を行う

▸ 協業するには入力系統を共有

▸ どの入力が”興味深い”結果を生んだかを記録

▸ 興味深い入力を共有


MAYHEM: バグのエキスプロイト

▸ バグを発見したあとはエキスプロイト化が必要!

▸ 再びシンボリック実行を行う:

▸ パス制限値とEIPを使って値を設定する

▸ SMTソルバーをエキスプロイトスクリプト内での利用が可能!

▸ ここでもハイブリットなアプローチが有効:

▸ クラッシュのファジングを使ってさらに深い階層のクラッシュを誘発 ▸ シンボリック実行を使ってエキスプロイトの生成を行う

▸ 我々の多くのエキスプロイトは実はシェルコードを実行してる!


MAYHEM: バグのエキスプロイト

▸ 単一のnullバイトの書き込みが可能という点を使ってエキスプロイトを生成する

▸ 基本的なエキスプロイトチェーン:

▸ EBPによってセーブされた最低のバイトを0で書き換える

▸ 上位のスタックフレームはEBP-相対アドレスを使用

▸ Future はこのバッファーへ書き込み、メモリーを叩く

▸ さらなる書き込み、バッファーオーバーフローする指令を送る

▸ EIPを書き換えて勝利！

▸ 難しく聞こえる？

▸ Mayhemはこのバグの発見とエキスプロイトを105分で行った


MAYHEM: パッチ適用

▸ はじめに: コンパイルされたプログラムの改修には?

▸ “ホットパッチ”

▸ 静的なバイナリーの改修

▸ 再コンパイル



▸ ホットパッチ

▸ プログラム内で空き領域の検索もしくは作り出す

▸ 基本ブロックを新しい領域に向け直す



▸ ホットパッチ

▸ プログラム内で空き領域の検索もしくは作り出す

▸ 基本ブロックを新しい領域に向け直す

▸ 利点:

▸ 書くのが簡単、プログラムを壊す率が低い

▸ 欠点:

▸ 実行速度が遅い、メモリーのパフォーマンスが低い




▸ “バイナリー内のコードを変えれば良い”

▸ そして….もどって、壊れた部分全部を直す




▸ “バイナリー内のコードを変えれば良い”

▸ そして….もどって、壊れた部分全部を直す

▸ 利点:

▸ メモリーのパフォーマンスが非常に良い、スピードも早い

▸ 欠点:

▸ ブログラムの機能を容易に壊す




▸ プログラムの高階層表現を行う

▸ 高階層にパッチを適用、コンパイルする

0:CMPEAX,ECX1:JNEEXIT2:MOVEAX,[EDX+4]

IF(A==B)A=D[1]ELSEEXIT()

IF(A!=B++)A=D[1]ELSEEXIT()

0:INCEDX1:CMPEBX,EDX2:JEEXIT3:MOVEBX,[ECX+4]

上位へ昇格

高階層のパッチ適用

コンパイル




▸ プログラムの高階層表現を行う

▸ 高階層にパッチを適用、コンパイルする

▸ 利点:

▸ コンパイラに匹敵するパフォーマンス

▸ 高階層の変換とパッチが容易

▸ 欠点:

▸ ほぼ完璧なディコンパイラーが必要、

▸ 最適化を行わなければパフォーマンスが劣化する



▸ 有力はヒント: ファイジングの計測にパッチを使う!

▸ パッチ処理プロセスに高性能なコードを挿入する

▸ コードパスに関する情報を記録するコードを追加する

▸ コンパイル時の計測の代わりにこれらを使う!



▸ プログラムの改修が可能ならば:

▸ どこにパッチを適用?

▸ どのような保護処理を追加?



▸ バイナリーにおいて、どこにパッチを適用すれば良い?

▸ 全メモリーアクセス?

▸ 遅すぎる…

▸ 安全と確認ができない全てのメモリーアクセス?

▸ より効率的がだ、まだ遅い…

▸ 問題がありそうなメモリーアクセス?

▸ 並みのパフォーマンス、でも安全では無い

▸ どこを守るべきかの決定が難しい



▸ バイナリーにおいて、どこにパッチを適用すれば良い?

▸ バグが発見された箇所!

▸ 最良の選択肢… 全バグを見つけることができれば

▸ 最低限の負荷、見つけた箇所は守れる

▸ 制御フローへの影響があり得る箇所

▸ ジャンプ、戻り値、コール等を守る

▸ 全てが守られれば制御フローのハイジャックは不可能

▸ 並程度の負荷


MAYHEM: トリアージ

▸ ”バグのパッチを行う”とは?

▸ プログラムとクラッシュを誘発する入力ではどっちに”責任”？

▸ アクセス違反:アクセスに使われたレジスター

▸ 実行違反:制御フロー命令の回帰

▸ 命令がクラッシュを誘発しないようにチェックする

▸ これらの処置は根本的な問題解決にはならない…


MAYHEM: トリアージ

▸ 根本的な問題の検知に”通常”の入力を使う

▸ プログラムを実行し、クラッシュ直前のプログラムの状況を調べる

▸ この情報をもとにクラッシュによって影響を受けた不変異要素を導き出す

▸ パッチするにはこれらの不変異要素に対する明示的なチェックを追加する!


MAYHEM: パッチの適用

▸ 全バグの100%を見つけられない場合は?

▸ 包括的なパッチの適用も行える

▸ 通常の保護策はコンパイラで行われる

▸ スタックカナリア

▸ Control Flow Integrity ▸ データ実行保護

▸ 領域外の読み込み・書き込み保護

▸ コンパイラーに取ってもこれらの保護は決して無償というわけではない

▸ コンパイラーと違って、我々の手元にはソースコードがない。

RETURN ADDRESS

SAVED EBP LOCAL BUFFER LOCAL ARGS

RETURN ADDRESS CANARY

SAVED EBP LOCAL BUFFER LOCAL ARGS

… if (a == 5) foo() return 0; }

次は何だろう？


MAYHEM: PATCHING

▸ Use static analysis to recover program information

▸ Take shortcuts! ▸ Perfect CFI requires a lot of program information ▸ “Pretty good” CFI is still very powerful!

▸ Get free registers, etc. as a compiler would have

▸ Generate efficient, lightweight patches

▸ Run thousands of benchmarks to ensure performance!


MAYHEM: パフォーマンスの確認

▸ パフォーマンスは入力がわかっている場合のみ計測可能

▸ 正規値の入力の実行を行い、実行スピードとメモリー使用を測る

▸ 出力が未対応バージョンと同様になることを確認する。

▸ オフラインでのテストには有効なこの手法、CTFでは?

▸ ノイズと実態トラフィックの違いを知らない

▸ プログラムによる”正規”の出力を知らない

▸ バグ発見向けコンポーネントによって生成された入力を使う

▸ クラッシュを発生させない入力こそ”興味深い”!

▸ 興味深いとは：プログラムを意味のある形で使っている


MAYHEM: 決定を行う

▸ 自動システムはどのように情報に基づく決定を行うのか?

▸ 複数のパッチがある場合、どれが最良か?

▸ システムは攻撃を受けているか?

▸ どのエキスプロイトを使うのが良いのか?

▸ これらはサイバーセキュティにとって重要な問題!



▸ この問題の対処は複数:

▸ 固定戦略

▸ コードが簡単、不確定要素が無い

▸ 戦略の集合体

▸ コードが簡単、より繊細、不確定要素が少ない

▸ 完全にダイナミク、学習型戦略

▸ コードが難しい、不確定要素が多い！



▸ 意外な結果は必ずしも悪いことでは無い!

▸ 事前に設定された戦略は想定内の対応しかできない!

▸ もし：

▸ チームは予想よりも、弱い・強い

▸ 他のチームが自分が見つけてないバグを発見

▸ チャレンジに複数の予期しないバグがある

▸ 新しく大規模に要素が壊れる(ほぼ、ありゆる。)



▸ いろいろあるアプローチの一つ: ベイズ推定

▸ ファジングを使ってクラッシュを見つける可能性は？

▸ ランダムなクラッシュのエキスプロイトの可能性は?

▸ 幾つのクラッシュ・エキスプロイトを発見できたか？

▸ 自分たちのエキスプロイトと他のチームの相互関係は？

▸ チームXのパッチがランダムの確率は？

▸ チームXのパッチとエキスプロイトの相互関係は？

▸ 全部を合わせて：攻撃される可能性は？



▸ どの決定が”正しい”かの判断は難しい！

▸ しかし、全体では決定はインテリジェント

▸ これはゲームの世界だけでは無い！

▸ このトラフィックは有害・無害？

▸ サーバを一時的に停止すべきか？

▸ パッチの費用対効果は？

▸ これらの事項を全てリアルタイムで決定する必要がある！


MAYHEM: 全部をまとめる…

1. コンパイル済みのプログラムを受け取る

2. パッチされたバージョンと計測可能バージョンを生成

3.シンボリック実行とファジングを行って新しい入力を発見する

4. クラッシュを発生しない入力を使ってパッチのテストを行う

5.クラッシュを発生させる入力を使ってエキスプロイトを生成

6.勝利


THE FUTURE

▸ このテクノロジーの未来像は？

▸ テスト：

▸ ソフトウェアの開発過程でセキュリティのテストを行う

▸ ソフトの実装過程でセキュリティのテストを行う

▸ この未来像はすぐそこの現実！


未来像▸ トリアージ＋攻撃リサーチ：

▸ 様々なファザーがクラッシュが誘発する

▸ クラッシュの多くのはセキュリティとは無関係

▸ 全てを精査するには時間がかかる！

▸ 自動化システムはエキスプロイトを生成可能⇒セキュリティ要素


未来像▸ 対策:

▸ 0ディエキスプロイトの発見は未だに困難

▸ 人間によるエキスプロイトの発見と分析には時間がかかる

▸ 自動的にエキスプロイトを発見する

▸ 自動的にエキスプロイトのトリアージを行い人為的対応を援助する

▸ 自動的にエキスプロイトを使ってパッチを生成する{


未来像▸ 防衛:

▸ 自動ソフトウェアパッチ適用

▸ すでにサポート対象外のソフトウェアのハーデニング・パッチ適用

▸ 対応が遅いベンダーのソフトウェアのハーデニング・パッチ適用

▸ パッチの自動テスト


未来像▸ 現在の状況は?

CMU Sandstorm

Google Self Driving Car

Mercedes Concept

X


未来像▸ まだ行われなければいけない要点は：

▸ 近代システムへのポーティング/移植（すでに一部は済み）

▸ 大規模プログラムへの適用・基準化

▸ より高度なエキスプロイト技術


未来像

Image credit: Orion Pictures


未来像

Japan Daily Press: Robotic band Z-Machines with human band Amoyamo

Technology

[CB16] Cyber Grand Challenge (CGC) : 世界初のマシン同士の全自動ハッキングトーナメント by Tyler Nighswander