Hackers' Dream 優勝してしまいました
意外にも。というわけで今回はここまでの経緯について。
イベントを教えてもらう
私は PacSec 2010 にスピーカーとして参加した。PacSec の終了後に飲み会があったのだが、そのときに韓国人グループと話をしていたのだ。今回スピーカーとして参加した韓国人は 3 人 (2 セッション; Vangelis, ChakYi and Externalist) で、さらに韓国で開催されるカンファレンスである POC のスタッフである Kancho 氏もいっしょだった。ブログで話をしたように、PacSec のプレゼンで、私は韓国におけるハッカーシーンといえるものを見たくなっていた。どのような話の流れでそうなったのか忘れたが、POC でリバースエンジニアリングのコンテストがあるよ！と。興味深かったので、参加してみると彼らに話したことを覚えている。
韓国 POC のサイトを開くと、すぐに答えは見つかった。(厳密にはリバースエンジニアリングだけではないものの、) Hackers' Dream というコンテストだ。興味深かったのはその日程。普通のハッキング関連コンテストは 1〜3 日で終わってしまうのが普通な気がしていたのだが、これは 11/22〜29、8 日間という長丁場。これは参加するしかないと決め込んだ。*1そして興味深いのは、問題の形式は決まった鍵を見つけ出せば OK なだけではなく、問題を解く過程まで含めてレポートを提出しなければならないという点だ。これはおそらく、問題の作成者や主催者によって審査される。これも結果的には吉と出た気がする。
イベント参加
Day 1
「！？」
問題ファイルをダウンロードした瞬間私はおののいた。厳密には、問題ファイルをダウンロードした瞬間におののいた Kaspersky に表示した情報を見て私もおののいた。「実在の脆弱性が使われている！？」
そう、本当に、本物の、脆弱性が使われているのだ。問題ファイルを見た限り脆弱性は二個で、パッチ状況を調べてみると…
- IE に関連する脆弱性 (CVE-2010-3962)
- IE6〜IE8 に影響
- コンテスト参加時点で未修正
- ただし PoC、Metasploit などで攻撃手法は既知。
- Adobe Reader に関連する脆弱性 (CVE-2010-3654)
ただし後で調べてわかったことだが、シェルコードの有害さは打ち消されている。(元々 Drive-by-Download をやる悪意あるペイロードっぽかったのが、パッチにより無害化されていたり。) またセキュリティをちゃんとやっている人間ならば、簡単には引っかからないようにもなっている。(例えば、DEP や ASLR の回避といったテクニックは最近当たり前のように使われているが、これらシェルコードの半分では半ば意図的に使用されていない。もう半分は脆弱性そのものの性質によって ASLR 回避の必要こそないが、同じ性質によって DEP 回避がほぼ不可能という代物。)
問題は 4 問あり、それぞれについてレポートを書く必要がある。
- Application (PDF; 壊れた PDF ファイルを修正し、シェルコードが何をするのか調べる。)
- Mobile (APK; 悪意ある Android アプリを調べる。)
- Packet (PCAP; 攻撃真っ最中のパケットから、攻撃の種類を特定し、さらに攻撃の「開始」「終了時間」も特定する。)
- Web (HTML; JavaScript の難読化を解き、IE の脆弱性を突く exploit を調べる。)
この日は Mobile を真っ先に解いてしまい、Web もその日のうちに解く。
Web の問題には罠があるかもと思ってシェルコードやペイロードの奥底まで解析をしてみたが、何もなかった☆
Day 2
本格的なパケット解析は初めてだったが、Packet 問題における攻撃の種類はいち早く特定 (ただしこの時点では答えが不十分。) しかしこれだけではまだ半分。Packet のもう半分が解けない。同時進行で Web 問題のボーナスポイントを得るため、最近有償アップグレードした VMware Workstation を総動員して、IE の脆弱性を徹底的にいじめる。Application は読み始めをしただけだが、PDF のファイルフォーマットが基本的にテキストだということがわかって一安心。これでイチから知らないフォーマットを解析する問題だったら諦めていたかも。(いや、実際 Packet でそうなったけどね。)
Day 3
Packet を後回しにする方向にして、Application から先に解く。様々な部分が壊れていることを疑ったが、実際にはバイナリエディタを使ってできる程度の修正ですべて有効な PDF になることが判明。JavaScript はかなり読みにくいが、それでもシェルコードにまで到達する。Web に使われるシェルコードと違って結構解析に苦労するも、これがどのような種類の攻撃コードか、ということまではある程度理解する。
Day 4
静的解析。細かい部分までの追跡を行い、コードのありとあらゆる動作を明らかにした。これで解いていない問題は Packet のみに。
少なくとも良いところまで行けるという確信を得る。
Day 5
苦難の日々のはじまりはじまり。
Packet 問題に関しては、攻撃の「種類を特定する」部分について、Ethernet / MAC フレームを見れば一目瞭然ということに気がつく。しかし、残りがわからない。
間違ったファイル (wrong files) を集め、パスワードを取得せよ。そして、攻撃の開始と終了時間を明らかにせよ。
ここからして、明らかにパケットキャプチャ中の SYN flood 攻撃が示す時間は攻撃の本質を明らかにしていないと推測 (SYN flood の途中でキャプチャが終わっているので、少なくとも終了時間を推測することが不可能。) 様々な部分を探すが良い結果は得られず。Transfer-Encoding が chunked なテキストに仕様上挟まる 16 進数のテキストがヒントかもと勘違いしたり、あるいは SYN flood のポート番号に規則性を見出すも答えは得られず。そうするうちに体調を崩してしまった。
Day 6
回復中…
Day 7
私には (Forensics の) 才能がないのかもと諦めかけたその 11 分後*2、決定的な証拠っぽいものを掴みとる。ふつう、Web ブラウズをしている最中の HTTP リクエストのほとんどには、Referer ヘッダがついてくる。というのも、リンクをクリックする、画像や CSS を読み取るといった行動においてはそれがついてくるからだ。つかないのは、「手動での URL 入力」「お気に入り」「動的コンテンツ」「怪しいファイル」くらいだと当たりをつけて、次の Wireshark フィルタを適用する。
http.request && !http.referer
ビンゴ！HTTP リクエストをほとんど手動で解析できるくらいに減らせた。しかもこの中に、HTML ファイルと URL には記述されているのにパスワードつき ZIP ファイルが送り返されているモノがあるぞ？となれば…
ここから、Packet の完全解析完了までは早かった。あとはレポートをちゃんとまとめることと、ボーナスポイントを限界まで稼ぐことだけだ。
Day 8
日本語に訳しながら英語の明らかな間違いを修正する。(某所で公開しているレポートはそのときに書いたものだ。) 最後にボーナスポイントのための 2 コンフィギュレーションを試し、レポートに書き加え、提出。これが 21:00 ぐらい。もう結果に賭けるしかない。
結果発表
そして昨日 (2010/12/2)、結果発表があった。結果は優勝。他の追随を許さない勢いで。
| 名前 (チーム) | Application | Mobile | Packet | Web | 合計 |
| Tsukasa Ooi | 86 | 90 | 100 | 91 | 367 |
| Jae-ryoung, Seong-hyun | 64 | 95 | 85 | 80 | 324 |
| Jo Hyun-ho | 42 | 97 | 95 | 88 | 322 |
これを見る限り、勝負を分けたのは Application だったようだ。Mobile を除いてすべての問題で上位よりさらに高い点数を獲得できた。
考察
Application は、シェルコードの解析が比較的難しいものだったことが明暗を分けた理由かもしれない。あるいは PDF を修復しなかったとか。Mobile の点数が低いのは納得。真っ先に解いて、レポートの作成もその…サボったのだ。Packet は意外。完全解答は意外と難しかったか?Web もなんとか。ボーナスポイントチャンスであるこの問題は他の上位陣もなかなか良い点数を取っている。
このコンテストは、いわゆる「早解き」が問われない。つまり早解きが苦手でも、洞察と解析の深いスキルさえあれば優勝できるようになっているものと理解した。スピードがなくてもパワーさえあれば、というヤツだね。今回私は迂回することが多かったけど。というのも、実在するシェルコードの、実在する Heap Splay を解析するというのはなかなか楽しかったのだ。実際の脆弱性には色々なテクニックが内在しているということも。
これから
というわけで、副賞として POC 2010 にタダで入れる (ふだんは $400 する) ので、韓国に行ってきます。*3新型 MacBook Air も受け取れる*4ということで、次からは Mac が主要開発環境になっているということも…まだそれはないか。
