www.morihi-soc.net

誰もが安心して使える、安全なインターネットを目指して

WriteUp:FireEye CTF

どうも。ハニーポッターの森久です。

先日、「Security Tech Lounge vol. 1 by ファイア・アイ」に参加してきました。

このイベントは、マルウェア対策機器メーカのファイア・アイ社が主催しており、現場でセキュリティに携わっている人たちの親睦と相互交流を目的としたものです。
現場(最前線で活躍する)のセキュリティエンジニアが参加者層として設定されていて、他のイベントとは一味違う内容です。

「セキュリティレポートたなおろし」と題して、セキュリティベンダ各社が2016年に発表したレポートを並列に比較する発表や、「オープンソース インテリジェンスの歩き方」として、不審な URL やドメイン情報を入手した際に活用できる Web サービスの紹介と使い方、セキュリティをネタに、パネラーと参加者を交えたパネルディスカッション(サイコロトーク)など企画が盛り沢山でした。

また当初の目的にもあったように、参加者同士の交流を深めるために、座ったテーブルを1チームとした、チーム対抗 CTF(FireEye CTF)が開催されました。

本ブログの読者で CTF を知らない人は少ないと思いますが、簡単に説明しますと、CTF は出題者からの問題を参加者が分析して、問題のどこかに含まれている正解の文字列(FLAG と呼ぶ)を導き出すという知的ゲームです。

FireEye CTF(FE CTF)では、1チーム3-4人で構成され、着座するテーブルは会場到着時にランダムで決められるため、誰がチームメイトになるのかまったくの予想がつかない状態です。

イベントでは時間の都合上、問題解説はありませんでした。
大変おもしろい問題だったので、今回はいつものハニーポット観察から離れて、FE CTF の Write Up を公開します。

※  イベント主催の ファイア・アイ社様に Write Up の記事公開許可をいただいています。

長文記事なので、コーヒーでも飲みながら息抜きにゆっくり見てください〜。画像を多用しています。スマホだと読みにくいかもしれません。

ページ目次リンク
FE CTF の問題について
1問目:C2
2問目:TYPO
まとめと感想

 

FE CTF の問題について

問題は2問出題されました。正確には3問目があったのですが、問題出題の Web ページの隠し要素になっていたので気づきませんでした orz
ということで、気づいた2問のみ Write Up を書きます。
なお1問目は一部解き方が分からなかったため、イベント後に正解したチームの人に教えてもらいました。ありがとうございます!
2問目は、制限時間内に解けませんでしたが、自力で FLAG 取得までこぎつけました。

それでは各問題について解説していきます。

 

1問目:C2

10ポイントの問題です。

まずはファイルをダウンロードして、何者かコマンドで調べてみます。

ふむふむ。拡張子が .pcap で、file コマンド結果からもパケットキャプチャファイルのようです。

パケットキャプチャときたら、みなさん大好き Wireshark の出番です。ファイルを開いてみましょう。

GET メソッドが見えるので、どうやら HTTP 通信のようです。フィルタを活用して、もうちょっと詳しく調べてみます。ディスプレイフィルタに「http」と入力してみます。

GET メソッドで URI に同じ文字列を指定して、何度もアクセスしていますね。

問題のタイトルが C2 だったので、マルウェアに感染した端末が、制御サーバ(Command and Control:略して C2)へアクセスしているというストーリーなのでしょう。

通信内容を見てみます。

GET リクエストは非常に簡素で、URI の文字列(cG9 から Tg= までの文字列)が一際怪しいです。Web サーバからの応答では、0x20 とだけ返ってきているようです。(前後の4や0はチャンクの仕様)

この通信からは URI の文字列に意味が込められていそう(セキュリティエンジニアの感)で、マルウェアが C2 サーバと通信する際の常套手段である BASE64 によるエンコードがされていそう(マルウェア解析エンジニアの感)です。

というわけで、URI を BASE64 でデコードしてみます。今回は base64 コマンドの -D オプションを使いました。

2行目のpoll からはじまる文字列が得られました。BASE64 でエンコードされているのでは?という感は当たったようです。ただしデコード後の文字列は、なにやら意味がありそうでなさそうです。。。

これだけでは先に進めないので、もう一度 pcap を見返してみます。今度はフィルタにhttp.requestを指定してみます。

c2.pcap ファイルには、実は23個の HTTP リクエストが含まれていて、そのうちの21個は上記の GET リクエストでした。残り2つのリクエストはそれぞれ別 URI の GET リクエストと、POST リクエストが1個ずつ含まれていました。

もう1つの GET リクエストを見てみましょう。

リクエストの URI 以外に変わった点はありません。また Web サーバからの応答では「0x52」が返されています。

URI をまた BASE64 でデコードしてみます。

今度は、key_generate から始まる文字列が得られました。

ただ、この文字列からも先に進めそうにないので、最後に残った POST リクエストを見てみます。

 

HTTP ヘッダで特に注目すべき点はなさそうです。一方、Web サーバに送信しているデータ部分には意味がありそうです。なお Web サーバからは「404 Not Found」が返ってきているため、応答内容に意味のある情報は含まれていない可能性が高いです。

qというパラメータに指定されている文字列(FB4から%3D%3Dまで)も BASE64 でエンコードされていそうです。

なお %3D  は URL エンコードされた = を意味するので、= に置き換えてデコードします。(xxd は入力データを16進数で表示するコマンドです)

なんということでしょう。デコード後の結果で可読な文字列は得られませんでした。おそらくデコード結果に何かしらの工夫が必要なのでしょう。

出題された  c2.pcap には、上記の3つのリクエスト以外の通信は含まれておらず、これらを組み合わせることで、FLAG を得られそうです。

一旦、深呼吸して問題のストーリーと現時点で得られている情報を組み合わせて考えてみます。

  • 問題のストーリーは、マルウェアに感染した端末から C2 サーバへの通信キャプチャを解析せよ!ということだと思う。
  • 通信は3種類あって、GET リクエストが2種類と POST リクエストが1種類ある。
  • GET リクエストの URI をデコードすると、poll から始まるものが大多数で、key_generate は1件のみ。
  • POST リクエストの送信データは、BASE64 でデコードできるけど、可読な文字列ではないので、何かしら工夫が必要みたいだ。

ここでセキュリティエンジニアとしての知見が役に立ちます。

マルウェアに感染すると C2 サーバと通信し、不正操作や情報漏えいを引き起こすことはみなさん御存知かと思いますが、実はこの通信にもいくつか種類があります。

たとえば、1)マルウェアに感染していることを C2 サーバに通知するビーコン通信。2)C2 サーバに対する何からの制御命令を受け取る通信。3)マルウェア感染端末から C2 サーバにデータをアップロードする通信。などなど。

 

各通信の特徴として、1のビーコン通信は、マルウェア感染端末からC2サーバへ定期的に送られます。なぜなら、まだ C2 サーバの制御下にありますよ(アンチウイルスソフトによって駆除されたり、IPS やマルウェア対策機器で通信が阻害されたりしていないこと)と示すためです。リクエストを送ること自体に意味があるので、送信データ内容に意味はありません。

2の制御命令を受け取る通信では、マルウェア感染端末から C2 サーバへのリクエストと C2 サーバからの応答内容の両方に意味があります。

3はマルウェア感染端末から C2 サーバへの送信データに意味があります。送信時にデータが平文のままだと都合が悪いことがあるため、圧縮したり難読化したりされます。

 

これら1から3を今回の問題に当てはめて考えてみると、繰り返し発生している GET リクエストが1のビーコンで、1回だけの GET リクエストが2の制御命令、POST リクエストが3のデータアップロードと考えることができます。

FLAG を得る時は近い。もう少し頑張ろう。

 

2種類の GET リクエストをもう一度見直します。

  1. リクエストが「poll_S-1-5-21-191058668-193157475-1542849698」で、応答が「0x20」だった。
  2. リクエストが「key_generate_S-1-5-21-191058668-193157475-1542849698」で、応答が「0x52」だった。

1は、ビーコン通知と考えると送受信している情報に意味がある可能性は低い。2は「key_generate」というくらいだから、データ生成アルゴリズムにおける手順の1つかもしれない。そして応答されたデータはきっとその手順で使われるものだろう、と推測できます。

 

ここで POST リクエストのデータが可読な文字列ではなかったことを思い出します。

「可読ではない」ということは「何らかのアルゴリズムに従って難読化されている」可能性があります。そしてマルウェアが難読化するときによく使う手法で最もポピュラーで簡単なものは、ずばり XOR(排他的論理和)です。(余談:会場でもスタッフの人がヒントとして与えていました)

XOR は0と0、1と1は0。0と1、1と0は1になる計算ですね。

 

試しに、POST のデータの BASE64 デコード結果の1バイト目(0x14)を0x52で XOR してみると。。。

( ゚д゚)!

 

アルファベット大文字の「F」が得られました。同様に2バイト目(0x1e)も試してみます。

( ゚д゚)!!

 

今度はアルファベット大文字の「L」が得られました。これは・・・もしかして・・・「FLAG」の F と L なのでは!?

ということで、1文字ずつコマンドを叩くのも芸がないので、簡単なスクリプトでときます。CTF において、問題を解くプログラムのことをソルバーと言います。

c2.pcap の問題のソルバー(python スクリプト)

実行結果

無事、デコードできました!

ということで1問目のフラグは「FLAG_FIREEYE_CTF_BEGINNER」でした。すごーい!

 

そろそろ読むことに疲れてきていませんか? 大丈夫、私も書くことに疲れてきました。

チョコレートのような甘いものでも食べつつ、まったり読んで下さい。

 

2問目:TYPO

50ポイントの問題です。1問目が10ポイントだったので、5倍です。5倍。

こちらもファイルをダウンロードして簡易調査をします。

どうやら zip 形式の圧縮ファイルのようです。展開してみると「typo.eml」というファイルが出てきました。同様に簡易調査します。

ふむふむ。テキスト形式のメールファイルのようです。試しに表示してみます。

英語のみで書かれた長文で、「FireEye.jpg」というファイルが添付されていました。

※ 画像ビューアーで見た結果のスクショのためオリジナルとは異なります。

 

jpg 画像は見た目は普通で、プロパティを確認しても特に設定された情報はありませんでした。

メール本文を見ると、書き出しが「FireEye undersrands …」となっています。私自身、英語力は高くないのですが undersrands という単語は無く、入力ミスのような気がします。

ここでこの問題のタイトルを確認すると TYPO です。TYPO は打ち間違えという意味の英単語なので、この undersrands には何らかの意味がありそうです。

ただしこの1単語だけでは手がかりにならないので、他にもないか探してみます。目視で探そうとすると大変なので、スペルチェックの力を借ります。

簡単にスペルチェックができるソフトウェアといえば、Microsoft Office Word です。メール本文をコピーして、Word に貼り付けてみます。

赤色の波線が出ている単語が Word のスペルチェックに引っかかった単語です。

最初から4つの単語の誤っているものと、正確な単語を列挙します。

誤:undersrands
正:understands

誤:tecjnology
正:technology

誤:innovatove
正:innovative

誤:underatand
正:understand

各単語1文字ずつ訂正箇所がありますね。その文字を抜き出して続けると「this」となります。意味のある英単語が出てきました。そこで文字の抜き出しをスペルチェックで引っかかった単語すべてでやってみます。すると「thisispassforimage」という結果が得られました。

この文字列をどう使うのだろうかと考えると、ふとメールに添付ファイルがあったことに思い当たります。怪しい。非常に怪しい。見た目が普通なだけに余計に怪しい。

ということでバイナリエディタで jpg 画像を開いてみます。

ファイルの先頭に英語で「steghide is the tool!」という文章が書いてあります。

知っている方もいるかもしれませんが、画像ファイルの中に何らかの情報を埋め込むことをステガノグラフィといいます。埋め込まれていた英文の中の steghide はステガノグラフィ用のツールなので、このツールで画像ファイルを調査してみます。

まずは info オプションで FireEye.jpg を調べると、やはり何かしらのデータが隠されていることが分かります。

次に extract オプションで隠されたデータを抽出してみます。また抽出する際に必要となるパスフレーズを先程のスペルチェックの結果で得られた「thisispassforimage」にします。

よし! 1.txt ファイルを抽出することができました。1.txt ファイルをテキストエディタで開いてみます。

( ^ω^)・・・。どうやらもうちょっとだけ続くようです。

 

1.txt ファイルからは、またパスフレーズと考えられる文字列が得られました。しかし steghide で抽出できたのは、テキストファイルのみで、その他のファイルは隠されていませんでした。おそらくアーカイブファイルが問題のどこかに隠されているはずです。

ここまでで入手できたファイルを整理してみます。

  • typo.zip・・・zip 形式の圧縮ファイル。typo.eml だけが含まれていた。
  • typo.eml・・・eml ファイル。メールテキストとFireEye.jpg 画像が含まれていた。
  • メールテキスト・・・間違ったスペルを抜き出すと、画像ファイルで使うパスフレーズが隠されていた。
  • FireEye.jpg・・・ファイルの先頭にステガノグラフィでメッセージと 1.txt ファイルが隠されていた。
  • 1.txt・・・アーカイブファイルで使うパスフレーズが書かれていた。

これらのうち、まだどこかにデータが隠されています。

やはり気になるのは「FireEye.jpg」です。他のテキストファイルにアーカイブファイルが隠されているとは思えないし、会場でのヒントもバイナリは全体を見た方がいいと言ってたし。。。

ということでバイナリエディタでもう一度、FireEye.jpg を隅々まで見てみます。

ん?

よーく見ると、画像ファイルの一番最後に「Rar!」という文字列が見えます。この「Rar!」は rar 形式という圧縮ファイルのマジックナンバーです。

つまりこのマジックナンバーから後ろのデータは、rar 形式ファイルの可能性があります。

実際に抽出してみましょう。今回はバイナリエディタとして Stirling を利用しているので、抽出したい部分をドラッグして、右クリックから「選択した部分をファイルに保存」するが可能です。

 

 

今回は ctf.rar という名前で保存しました。そして rar ファイルを unrar コマンドで展開します。なお展開するときにパスワードが聞かれるので、1.txt から入手した「thisispassforarchive」を入力します。
すると 2.txt が生成されます。

2.txt を表示すると「FLAG_VteEgpMpnkdDE7MBdEKKCwgo」とフラグが書かれていました。やったぜ!

 

まとめと感想

今回はファイア・アイ社主催のイベントで開催された FireEye CTF で出題された問題の WriteUp を書きました。

1問目は、マルウェア感染した端末から C2 サーバへの通信のようなパケットキャプチャを分析する問題でした。
この問題に出てくるような通信内容を BASE64 でエンコードしたり、XOR をしたりすることは、実際のマルウェアでも常套手段して使われます。

2問目は、メールのメッセージおよび添付の画像ファイルから、隠された情報を解き明かす問題でした。この問題のポイントとなったステガノグラフィというテクニックは、一部のマルウェアが実際に利用しています。
たとえば ZeusVM というマルウェアは C2 サーバへの接続情報を jpg 画像のコメントに隠して利用します。

参考:JSOC INSIGHT vol.10 (4.1.2 検知した ZeusVM の通信の挙動と特徴)
https://www.lac.co.jp/lacwatch/pdf/20160106_jsoc_j001w.pdf

 

2問とも、よくある CTF の問題よりもセキュリティの知識が活かせるところがいくつもあり、独特な雰囲気でした。難易度はもう少し手数を減らしても良かったかなと思いますが、全体を通してみるとちょうど良かったのではないでしょうか。

私は最近、CTF に参加する機会が減っているのですが、今回の CTF は非常に楽しみながら問題を解くことができました。ただ2問とも制限時間内に FLAG にたどり着くことができず、くやしい思いをしました。

イベントでは1位のチームに優勝賞品とインタビューがありました。
優勝チームは4人構成で、問題を解いているときに気づいたことを話すアイデアマンと、ソルバーを作るプログラマ、それをまとめるチームリーダといった役割分担がなされていました。

競技時間は約1時間と短時間でしたが、やはり役割分担とチームワークが優れていたチームが輝いていました。セキュリティは決して1人で抱え込み孤独に対応する必要はなく、あなたとわたしの2人から、チームとして組織的に動く必要性を再認識しました。

普段の業務とは異なる頭の使い方をしたので、楽しむことができました。
主催のファイア・アイ社様、運営者のみなさま、ありがとうございました。第2回開催待ってます!

 


 

普段、本ブログではハニーポットで得たログを分析して、その内容をハニーポット観察記録と題して公開しています。そして今年の1月にブログ記事を元にした本を出版しました。

今回の勉強会では、現場のセキュリティエンジニアの方と交流することができたのですが、複数の人から、実際にアナリストトレーニングに活用していることを伺ったり、読者の方にお会いすることができました。

活用いただいているという生の声を聞けて大変嬉しく思います。

このブログをより良いものにするために、フィードバックをいただければ幸いです。

 

Written by 森久

3月 29th, 2017 at 6:00 pm

Posted in CTF,Security