Reverse Engineering の腕試し: Flare-On Challenge の紹介
最近の記事
こんにちは、インシデントレスポンスサービス担当の濱崎です。今回は日本時間で 2020/9/12 10:00 ～ 10/24 10:00 に開催された Reverse Engineering の腕を競う大会、Flare-On 7 Challenge に参加したので、その内容と結果を紹介したいと思います。
Flare-On Challenge とは
Flare-On Challenge は FireEye 社が毎年主催している Reverse Engineering に特化した Capture The Flag(CTF) 形式のセキュリティコンテストです。2014年から毎年 8～10 月の期間で開催されており、今年で7回目なので Flare-On 7 Challenge と呼ばれています。他の CTF に比べ次のような特徴があります。
- 多くの問題が Windows で動作するソフトウェアで構成されている
- FireEye 社が業務で実際に解析したマルウェアにインスピレーションを得て問題を作成しており、数ある CTF の中でも実践的な問題が多い
- 毎年 10～12 問出題され、一つ問題を解くと次の問題が提供される
- 開催期間は 6 週間と長い
多くの CTF は Linux で動作するソフトウェアを中心に構成されていると思います。また、マルウェア解析というタスクを意識した問題はそんなに多くないかと思います。そのため、Windows マルウェア解析の技術研鑽や腕試しをしたい人にはうってつけの CTF です。また、一般的なCTFは土日の間の24時間、または48時間で開催されますが、Flare-On Challenge は6週間と長い期間開催されるため、隙間時間を利用して取り組むことができます。土日にまとまった時間が取れない人にも優しい開催スケジュールとなっています。
私の普段の業務はマルウェア解析ではないのですが、趣味で楽しんでいることもあり今年は腕試しに参加してみることにしました。
チャレンジ結果
今年は計11問出題され、参加者は全部で5,668人。全問正解者は279人（全体の4.92%）という結果でした。その中で私は9問解くことができました。正直、開催前は6問くらい解ければいいなあと思ったのですが、思った以上に解けましたし、何より問題を解く中で新しい技術や知識が身についたので非常に満足しています。本業のディスクフォレンジック業務に役立つものもあり、業務の品質向上につながるものであったと感じています。ただ、10問目はかなり時間を使ったのですが解けず、まだまだ未熟だなと感じたのも正直なところです。ちなみに、Twitter などの評判を見ると、毎年最後の2問は一段とレベルがあがるそうです。見事にその壁に阻まれたことを知り、非常に悔しい気持ちでいっぱいです。臥薪嘗胆、来年は突破すると心に誓いました。
出典：https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html
FireEye社のブログには正答者に関する各種統計値が載っていますが、個人的に興味深かったのは全問解けた人が所属する国についての集計値です。（所属国の入力は任意ですしバリデーションもないので、どこまで信用できるかは不明ではあります）
出典：https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html
アメリカが見事に1位に輝いていますが、これには驚きはありません。驚いたのは、2位のシンガポールです。シンガポールの人口は570万人ほどだそうです。アメリカは約3.2億人ですので、シンガポールのセキュリティエンジニアのレベルの高さを感じさせます。また、3位ロシア、5位イスラエル、7位ベトナム、8位中国、10位ウクライナなど、サイバーセキュリティ関連のニュースで話題になる傾向が高い国は、比較的上位に位置しているように思えます。この結果は、国としてのサイバーセキュリティへの力を入れ具合、という指標になっているのかもしれません。ちなみに日本は全問正答者1名です。日本もサイバーセキュリティに力を入れていますし、多くの素晴らしい取り組みを行っていますが、こういった大会・イベントでのプレゼンスを上げたいと思うのは私だけではないと思います。
出題内容概要
はじめは WriteUp(=解法) を書こうかと思いましたが、FireEye 社公式 WriteUp が素晴らしいのでそちらを参照いただくとして、ここでは全11問について、その内容を一言でまとめてみます。一部解法のエッセンスを含みますのでご注意ください。
| challnege # | challenge title | 概要 |
|---|---|---|
| challenge1 | fidler | ゲームのクラック問題（python ソースコード付き） |
| challenge2 | garbage.exe | 壊れた packed binary の修復問題（フォレンジックなどで復元した、データの一部が壊れてしまったバイナリを想定？） |
| challenge3 | Wednesday (mydude.exe) | ゲームのクラック問題（ソースコード無し） |
| challenge4 | report.xls | VBA stomping された xls の解析 |
| challenge5 | TKApp.tpk | Tizen OS という Samsung の TV, wearable device などで使用されている OS で動作するアプリケーションパッケージ。ただ、やることは、 .NET アプリケーションの解析 |
| challenge6 | codeit.exe | Autoit マルウェアの解析からインスピレーションを得た問題。解析自体は容易だが、flag の特定にクセがあり、個人的には難問だった |
| challenge7 | re_crowd.pcapng | pcap に含まれる IIS の RCE 脆弱性(CVE-2017-7269)攻撃ペイロードの解析 |
| challenge8 | Aardvark | ゲームのクラック問題。WSL 環境のみで動くことを特定する必要あり。 |
| challenge9 | crackinstaller.exe | ソフトウェアのクラック問題。様々な暗号方式＋COM Objectの理解＋カーネルドライバの理解など、幅広い知識を求められる問題。個人的には最高に好きな問題。 |
| challenge10 | break | Linux ELFバイナリ。子プロセス、孫プロセスが親プロセスを ptrace することで RPC 通信を実現している。ptrace を使っているのでデバッグが難しく厄介。解けなかった。 |
| challenge11 | Rabbit Hole | チャレンジできなかった。かなり難問らしい。Gozi V3 を模倣しているとのこと。 |
個人的に最も好きなのは challenge9 の crackinstaller.exe です。この問題は、様々な技術要素が盛りだくさんで本当に勉強になりました。知らない知識や知っていてもあまり触れたことがない技術要素が詰まっているこの問題は大好きです。少しだけ紹介します。
この問題は、ソフトウェアのクラックをモチーフにしており、registry に正しい password が設定された状態でプログラムを特定の方法で動かすと flag を取得することができます。この password が何なのか、そして flag を取得するためのプログラムの動かし方は何なのか、を探す問題になります。
最初に渡される PE ファイルに、3つの別の PE ファイルが暗号化された状態で含まれています。一部はドロップし、一部はメモリ内で実行されます。
- 任意のユーザコードをカーネルモードで実行可能にする機能を持つ、正当な署名を持つ既知のカーネルドライバ
- 署名なしのカスタムカーネルドライバで、1の署名有カーネルドライバを通して実行される
- COM Server DLL
1,2はある文字列の SHA256 ハッシュを key とした ChaCha20 暗号方式で暗号化されており、3はシンプルな XOR で暗号化されています。
password については、2のカスタムカーネルドライバ内に ChaCha20 で暗号化された状態で保存されており、同ドライバ内の処理で復号されます。これを特定するにはカーネルドライバ特有の API や Registry Filter Driver の知識が必要です。また、その password は regedit などの一般的な viewer では閲覧できない Registry Class Type Strings に設定されるため、この辺の知識もあるとスムーズな解析が可能でした。
flag については、上記の方法で取得した password を HKEY_CLASSES_ROOT\CLSID\{CEEACC6E-CCB2-4C4F-BCF6-D2176037A9A7}\Config\Password に設定後、前述の 3. COM Server DLL の機能を呼び出せば取得できます。そのためには COM Class IID の特定と、それを呼び出す COM プログラムを書く必要があります。私は COM Class IID の特定を行う流れでそのまま静的解析をすることで flag を取得しました。その際、password を key とした RC4 暗号方式で flag を復号する処理があるため、RC4 の知識も必要になりました。他にも、AES 暗号方式で暗号化されている部分もあります。
このように、シンプルな XOR, RC4, ChaCha20, AES などの様々な暗号方式が何度も使用されています。そして、複数のバイナリが複雑に絡み合っていたり、カーネルドライバが絡んでくるため、動的解析もやりにくいものでした。結果として静的解析による暗号データ復号のとても良い訓練になりました。
ただ、カーネルデバッグの環境が整っている人は、動的解析でやってしまえば暗号方式特定作業は不要だったかもしれません。私は勉強したことがある程度で慣れてもないし、環境も用意していなかったので静的解析するしかなかった点は、経験不足を感じたところです。
最後に
私個人は challenge 9 でも十分難しく感じましたが、 SNS 上の世界のマルウェア解析者の感想では challenge 10, 11 への反応が非常に多く、まだまだレベルが追いついていないように感じました。次回は全問正解を目指したいと思いますし、日本人のプレゼンスも向上すると良いなと思っています。
This year’s winners are truly the elite of the elite!
https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html
エリート中のエリートを目指して、皆さんも一緒に挑戦しませんか？