煙と消えるその前に

一服してるうちに忘れる、自分のための備忘録。とかとか

SECCON 2014 オンライン予選（日本語）に参加してきた！

ctf

昨年に続き、今年も参加しました！
昨年同様 Route9というチームで、計6名で参加しました。

結果は16位！
昨年よりいい成績で終えることができました。

今年は12時間と比較的短い(?)時間で、前回より気軽に参加できてよかったかなーという感じ。

今回も私が解けた問題をつらつらと書きます。

ネットワーク100 このパケットを解析せよ

pcapファイルの中身はFTPでやりとりしているらしき通信。
サイズが小さいので上からだーっと眺めると、露骨にflag.txtをリクエストしてるパケットが目に入ります。

f:id:paty_fakename:20140719130414p:plain

その直後に中身を取っているので、そこの部分を抜き出すと以下の文字列が。

RkxBR3tGN1AgMTUgTjA3IDUzQ1VSM30=

decodeすればいいのかなと思って、とりあえずBase64でデコードしたらビンゴ

FLAG{F7P 15 N07 53CUR3}

暗号100 decode me

問題のファイルを見ると、こんな文字列が "ebg13/47"
そういや、以前参加したpythonの勉強会で、rot-13encodeされたpythonファイルにこんなのがあったなーと思い出し、rot-13でdecodeしてみる。

...ASCII部分は読めたけど、他はバケバケorz

チームメンバーに教えてもらったところ、rot-13/47という暗号方式(?)があるとのこと
早速調べてみると、nkfに実装が入ってるみたい。

てなわけでnkfでdecodeしてみると、答えが出ました。
(nkfはCentos6.4で実行したため、SJISが読めませんでした。decoded.txtをwin環境に持っていって確認)

nkf -r encoded.txt > decoded.txt

FLAG{Have fun SECCON2014}

フォレンジック100 879,394bytes

与えられたFilesystem001.binから879,394バイトのファイルの名前を探す問題。
調べたところ、Filesystem001はFAT形式のようでした。

ファイルサイズが書かれているので、879,394を16進に変換して"0d6b22"を探します。
・・・が見つからない。
FATの仕様を見たところ、リトルエンディアンでしたorz

気を取り直して、"226b0d"を探したところ、CHRYSA~1で拡張子がJPGなファイルがヒット。
~1ってなんだっけと思っていたら、ファイル名のショートネームとのこと。
長いファイル名は省略されてこの形になるので、すぐ近くに埋まってるChrysanthemumがファイル名と推測。

Chrysanthemum.jpgが答えでした。

Web 300点 箱庭XSSリターンズ (途中まで)

exeで起動させたアプリでXSSをする問題
複数問で構成されていて、問題を解くたびに使った文字列が制限されていきました。

以下のような感じで手を変え品を変え進めましたが、ボキャブラリー不足で力尽きましたorz
6問解いたところで途中点がもらえたのでそこで終了。

(表示を良しなにされてしまうので、記号を一部全角にしてます。書き方どうやるんだっけ...)
"onkeydown="＆＃0000097lert('＆＃0000088SS')
"onkeypress="＆＃000097lert('＆＃000088SS')
"onselect="＆＃00097lert('＆＃00088SS')
"onclick="＆＃0097lert('＆＃0088SS')
"ondblclick="＆＃097lert('＆＃088SS')
"onfocus="＆＃97lert('＆＃88SS')
">＜script＞alert('XSS')＜/script＞<"

opensslを更新することで仕込んだ爆弾

apache

最近は Qiita の方に投稿が移ってる僕です。

ちょっと前からopensslがらみの話題が出ていますね。
HeartbleedBugとかCCS injectionとか。

で、うちのサーバもopenssl更新しておかないとなーと思って更新しました。
AWSを使っていて、クラ -> ELB(https) ELB -> EC2(http)という構成にしているので、apacheの再起動はしなくていいかーと放置してたんです。
更新作業した当初は特に何も問題なかったんですが、翌週月曜日に事件が・・・。

　apache　が　落　ち　て　た


なんでだーと思ってエラーログ見てみたら、以下のようなエラーが
mod_sslが読めない！？

[notice] SIGHUP received. Attempting to restart
httpd: Syntax error on line 221 of /etc/httpd/conf/httpd.conf: Syntax error on line 12 of /etc/httpd/conf.d/ssl.conf: Cannot load /etc/httpd/modules/mod_ssl.so into server: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libssl.so.10)


事件の引き金を引いたのはcrondで動いてるlogrotatedでした。
こいつがログローテの後にapacheをreloadかけていて、それが日曜の深夜でした。

でもって、mod_ssl使ってないはずなのにおかしいなーと思って見てみたら、
デフォルト設定だからmod_ssl読み込んでたわ！


なんでもデフォルトのままはいけないなってことと、
作業後に動いたから安心ってわけにはいかないって教訓でした。

SECCON 2013 CTF オンライン予選に参加してみた

ctf

気づけば1週間も経ち、若干いまさら感がありますが記録がてら書きます。
SECCONなにそれおいしいの？な自分が、誘われるままにSECCON 2013 CTF オンライン予選に参加してきました。
いずれも初参加の4名が、Route9というチームで参加。
成績は324チーム中53位！（棄権チーム含むけど...）
初めてにしてはがんばった気がするなーと思いつつ、私が解いた/解けそうで解けなかった問題を挙げておきます。

公式サイト：

解いた問題(他にも手をつけたけど解答まで辿りつけず...)：

  • ネットワークWeb 200点 FindTheKey
  • ネットワークWeb 300点 hidden message

ネットワークWeb 200点 FindTheKey

seccon_q1_pcap.pcap(保存期間7日間なので消えてるかも) というファイルが添付されていて、そこから鍵を探す問題。

とりあえずwiresharkにくわせてみると、pingのパケットが出てきました。
なんだこれーと思いながら眺めてると、http通信しているログが・・・。

f:id:paty_fakename:20140202152847p:plain

どうやらkagi.pngという画像をHTTP GETしているみたい。
そのものずばりこのpngを復元すれば鍵が手に入るのかなと、バイナリデータを引っこ抜いてみます。
pngのフォーマットは"89 50 4E 47 0D 0A 1A 0A"から始まって"00 00 00 00 49 45 4E 44 (ここに4バイト)"で終わるそうです。
それっぽいところを探すと、No44-48にかけてビンゴなバイナリが見つかるので、それを抜き出して繋ぎ合わせてみます。
繋いだものを開いてみると・・・

  • １つ目のレスポンス郡(pcap No 44-48)

f:id:paty_fakename:20140202154858j:plain
お、おう・・・。まさかこれで答えがわかるなんて思ってなかったけど、そう来たかーな感じ。
どうも壊れた画像？を取っていたパケットのようですね。
じゃあ次どうしたものかとseccon_q1_pcap.pcapを眺めていると、kagi.pngを取ってるログがいくつかありました。
壊れた画像のレスポンスは 200 OKで画像丸ごと返してる。次のレスポンスは206で部分的に返してる。そんな感じでレスポンスが5つほどありました。
ははーん、部分的にちゃんとした画像を返して繋ぎ合わせろってことか、と思いバイナリエディタで順に切り貼りしていきます。

  • 2つ目のレスポンス郡(pcap No 58)

Content-Range: bytes 2572-2794/2795とあるので、画像ファイルの2572バイト目(0xac0)からをレスポンスのバイナリで上書きしてみたけど・・・画像変わらず
くじけず次へ。

  • 3つ目のレスポンス郡(pcap No 70-73)

1つ目と同じようにkagi.pngを丸ごと取得していましたが、1つ目の画像から進展なし。

  • 4つ目のレスポンス郡(pcap No 87-89)

Content-Range: bytes 768-2794/2795だそうで、768バイト目(0x300)から上書きしてみます。
すると・・・、おーなんか見えた！これだけでなんとか分かりそうだけど、せっかくなので最後まで復元してみます。

f:id:paty_fakename:20140202165039j:plain

  • 5つ目のレスポンス郡(pcap No 105-107)

Content-Range: bytes 1487-2794/2795なので、1487バイト目(0x5cf)から上書きしてみます。
これで完全に復元できました。keyは"deadbeeffeedbad"となります。

f:id:paty_fakename:20140202165433j:plain

ネットワークWeb 300点 hidden message

q.jpg(保存期間7日間なので消えてるかも)というファイルが添付されていて、そこから鍵を探す問題。
jpgファイルだし、とりあえずバイナリエディタにくわせてみました。
上からつつーっと眺めてみると、末尾に変な文字が。

134.133.95.10in-addrarpa

お？と思い、jpegの画像フォーマットを調べてみると、開始がFFD8、終了がFFD9とのことで、どうも終了マーカの後にこんなバイナリが付属しているようです。

D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00 FF FF 00 00 01 00 00 00 AE 39 E1 52 7D 9F 06 00 56 00 00 00 56 00 00 00 9C A3 BA 29 77 57 70 81 05 EC C7 7F 08 00 45 00 00 48 E5 2E 00 00 35 11 38 F2 CA D2 DE C3 85 F2 37 FC DE 5B 00 35 00 34 B0 23 1F CB 01 00 00 01 00 00 00 00 00 00 03 31 33 34 03 31 33 33 02 39 35 02 31 30 07 69 6E 2D 61 64 64 72 04 61 72 70 61 00 00 0C 00 01

けど何のバイナリかわからないしなー、困ったなーとなったところで、とりあえずヘッダっぽい先頭4バイト"D4 C3 B2 A1"をgoogle先生に問い合わせてみることに。
すると、どうやらこれはpcapファイルとのこと。google先生さすがです。

ということで、該当バイナリだけ切り出してwiresharkにくわせてみます。
すると、DNS問い合わせをしたらしきパケットが見つかります。
f:id:paty_fakename:20140202171653p:plain

正直、でっていう感だったわけですが、とりあえずDNSに問い合わせてみるかーということでやってみました。

dig -x @133.242.55.252 134.133.95.10

が、応答かえってこず！えーなんでー。実はダミーバイナリでJPEGの中に隠れたメッセージがあるとか？？なんて考えてたけど結局わからず。

後から調べてみたところ、オプション書く位置がまずかったとのこと・・・orz

dig @133.242.55.252 -x 134.133.95.10

実際には確認できてないのですが、
期待通りなら"You.G0t.a.H1dd3n.m3ss4g3.1n.Th15.DNS."が取れて、これがkeyになるとのこと。
後一歩だっただけに悔しい。