setodaNote CTF

常設？CTFサイトのようです。
https://ctf.setodanote.net/
今回はWeb問題に挑戦してみましたので、備忘録として残しておきます。

※最初の2問（BodyとHeader）は省略します。

3 puni_puni

問題

近所の子供から「ぷにぷにこーどあげるね」と1枚の紙を手渡されました。見ると子供の字とは思えない正確な書体で英数字がびっしりと書き込まれています。これはいったい。そう聞こうとしましたが、紙に意識を取られた一瞬のうちにその子供はいなくなっていました。

紙に書かれた文字列を解析し、フラグを入手してください。フラグは得られた文字列を flag{} で囲んで答えてください。例えば flag が得られた場合は flag{flag} と入力します。

xn--q6jaaaaaa08db0x8nc9t1b8fsviei84atb4i0lc
xn--q6jaaaaa03dpd4mb3jc5rpa0g9jpk07acadc.
xn--q6jylla3va3j6c8138a8eptvb303cxv4ft3o4ue63a
xn--v8ja6aj2a3cri3ag4a2r6cx2a1rkk1272c7j4ajd4bmf0kjhg6rb.
xn--q6j6gav1a0b2e1bh1ac2cl29ad7728kdjen6cz80dju6bqexchl9gel8b.

なんだこれ、暗号か...？それともエンコーディングされてる...？
xn--から始まる、初めて見た形式の文字列なので、とりあえず調査したところ、
Punycode（ピュニーコード）という、Unicodeのコードポイント（文字ごとに割り当てられる固有の番号）を、ASCII文字のみを使用して表現する符号化方式（ASCII Compatible Encoding）とのことです。

参考：https://jprs.jp/glossary/index.php?ID=0051

ほ～、初見ではなんかギャグっぽいなと感じていましたが、ちゃんとした規格でした。
知れて良かったです。

Punycodeの変換・逆変換をしてくれるサイトを利用して、フラグゲット。

4 Mistake

問題

作成中のサイトに不備があると外部から指摘を受けています。どうやら機密情報が漏れてしまっているようです。サイトにアクセスして機密情報を特定してください。

以下のサイトにアクセスして隠されたフラグを見つけてください。

http://ctfweb.setodanote.net/web003/

どこかに隠れているflagを探す問題です。
ブラウザ（開発者モード）で、HTTPのデータ、Cookie、ソースコードを探していたところ、
Webserver directory index?というコメントを発見。

ディレクトリをトラバーサルできるのかなーなんて考えて、
「https://ctfweb.setodanote.net/」でアクセスするも403でアクセスはちゃんと拒否されます。
いろいろ調べたけども、手応えはなく、ギブアップ。

解答

https://ctfweb.setodanote.net/web003/images/にアクセスすると、なんとimagesディレクトリにアクセスできてしまいました。
そして、画像ファイルと一緒に、pic_flag_is_here.txtが存在。フラグをゲットできます。

なるほど~、ネットワークタブから見れるasset系（画像でもJSでもCSSでも）もアクセスを試す必要があることを学びました。

5 tkys_royale

問題

んー、このサイトには重大な脆弱性があります。そう切り出してきた相手の姿にあなたは言葉が出ません。それは音信不通となっていた後輩の生き写し。聞きたいことが山ほどありますが、まずはサイトの脆弱性を修正しなければなりません。サイトを解析し、脆弱性を特定してください。

以下のサイトにアクセスしてフラグを得てください。

https://ctfweb.setodanote.net/web005/

アクセスすると、ログイン画面が表示されました。
お、これはSQLインジェクションかなー、見当がつきましたが、とりあえずソースを調査。

すると、テストユーザーと思しきログイン情報が残ってました。

ログインしてみたものの、フラグはなく（ソースコードなども調査しましたが手がかりはなさそうでした）

ここでギブアップ

解答

username, passwordどちらかに' or 1=1 -- を入力してログイン。

普通にSQLインジェクションでした。
ソースコードにあったログイン情報に気を取られて試してませんでしたね。
こういう囮のような情報には気を付けたいところです。

6 Estimated

問題

組織の関連サイトを監視している部署から「どうやら局長ブログで機密情報が漏洩しているようだ」と連絡が入りました。一部SNSで言及されているものの、幸いにしてまだ広まってはいないようです。なんとか穏便にすませたい上司に配慮し、被害を最小にすべくサイトを調査し漏洩している機密情報を特定してください。

以下のサイトにアクセスしてフラグを得てください。

https://ctfweb.setodanote.net/web006/

ブログサイトのようです。
ソースやネットワークタブ調べても手掛かりなし。早々にギブアップしました。

解答

一番下の記事に注目。
画像に問題があったため削除した旨の記述があります。
ここで、漏洩情報が、画像のことである、というところに気づくべきなのでしょう。

他の記事の画像について調べてみると、画像ファイルの名前が日付になっていることがわかります。

以上の情報より、「https://ctf.setodanote.net/web006/images/20210602001b.jpg」で直アクセスすることで、非公開の画像にアクセスできてしまう、という問題でした。

画像のアクセスについて

当ブログサイトも画像を埋め込んだ記事はありまして、直アクセスを防ぐ方法については結構考えてました。
最終的には、とりあえずUUIDの名前にして、さらにサーバー上のファイルの保存場所へのアクセスも最大限防ぐため、S3のオブジェクトURLを使うようにしました（静的コンテンツをS3に置くことは色々なメリットを享受できるのもありまして）。

7 Mx.Flag

問題

旗から手紙が届きました。

親愛なる貴方へ

こうして貴方に手紙を送るのは初めてですね。  
実はとてもうまく隠れることができたので、嬉しくなりこのような手紙を送ることにしました。  

どうか私を見つけてくれますか？

旗
以下のサイトにアクセスしてフラグを得てください。

https://ctfweb.setodanote.net/web007/

アクセスすると、とても簡素な画面が。

十八番のようにブラウザにていろいろ探してみるも、わからず。
そして、問題のタイトルにもなっているMxと、メールに関する内容であることからMXレコードのことではないか、という推測に至りました。
MXレコードを調べるも、手がかりはなくギブアップ。

解答

ネットワークタブにて、faviconにアクセスしているにも関わらず、ブラウザのタブでは表示されていないことに気づけます（なかなか気づかないよこれ...）。
ページ自体は簡素で、アクセスしているコンテンツが2つだけなのも、ヒントになっていたということなのでしょうか。

直アクセスしても、ブラウザ上ではやはり表示されないので、wget等でダウンロードします。

ほんとに画像ファイルなのか？ということで調べてみると、ASCII textであることが判明。
中身を出力してフラグをゲット。

あ、faviconブラウザで表示されてない！にまず気づかなかったし、気づいたとしても「あぁ、画像ファイル壊れちゃってますよ？」としか思わなかっただろうなと。
この問題で、気を配るべき点として知れてよかったです。

8 Redirect

問題

組織の関連サイトを監視している部署から「どうやら会長ブログが何らか侵害を受けてしまっているようだ」と連絡が入りました。再現方法が不明なものの、一部の訪問者から不審なサイトに飛ばされてしまうという指摘がされているようです。上司は休暇で不在ですが特に支障はありません。被害を最小にすべくサイトを調査し侵害状況を把握してください。

以下のサイトにアクセスしてフラグを見つけ出してください。

https://ctfweb.setodanote.net/web004/

アクセスすると、今までと違うページが表示されました。
ソースコードを調査すると、インラインスクリプトの存在に気づきました。

処理内容について調べると、リファラがwww.google.comの場合、atob関数であれやこれやした場所に飛ばしていることがわかります。
atob()について調べると、base64でエンコードする関数らしいです。
参考：https://developer.mozilla.org/ja/docs/Web/API/Window/atob

Li9iV0ZzYTJsMC5odG1sをデコードすると./bWFsa2l0.htmlとなります。
「./」がついていることから相対パスであることがわかるので、「https://ctfweb.setodanote.net/web004/bWFsa2l0.html」にアクセスしてみます。

...表示自体に特に情報なし。いろいろ調べてみると、かなりリダイレクトされていることがわかりました。
デフォルトの設定だと、一回のリダイレクトで情報がクリアされてしまうので、ブラウザの設定でログを残すようにして再度アクセス。

どのリクエストにも、2枚目のようにクエリパラメータが付与されていました。
他に、特にめぼしい情報が見つからずギブアップ。

解答

curlを使うと、リダイレクトされずに、ちゃんとレスポンス内容が確認できるらしいです。
「https://ctfweb.setodanote.net/web004/bWFsa2l0.html」を確認。
クエリパラメータの長さ（数）で条件分岐していることがわかります。
上記URLにはクエリパラメータがついてないので、elseブロックに入り、
「https://ctfweb.setodanote.net/web004/bWFsa2l0.html?callback=wantFlag&data1=2045&data2=0907&data3=BiancoRoja&data4=1704067200」にアクセスさせられます。

「https://ctfweb.setodanote.net/web004/bWFsa2l0.html?callback=wantFlag&data1=2045&data2=0907&data3=BiancoRoja&data4=1704067200」を確認。
同じレスポンスが帰ってきている様子。ただし、今回はクエリパラメータつきでアクセスしたため、ifブロックに入ります。

URLに注意して「https://ctfweb.setodanote.net/web004/bm9mbGFn/?callback=wantFlag&data1=2045&data2=0907&data3=BiancoRoja&data4=1704067200」を確認。
お！レスポンスが変わりました！

ここからは、レスポンス内容に沿って、curlしていきます。

ifの条件分岐に注意しつつ、最終的に返されるURLに、curlではなくブラウザでアクセスするとフラグが表示されます。
なぜ、curlとブラウザでレスポンスが違うか調べたところ、User-Agentフィールドによって返すレスポンスを変えているらしいです。

curlで、User-Agentフィールドをブラウザのように指定して実行したところ、ブラウザと同じレスポンスが返ってくることを確認しました。
※そういえば、SC試験にも、インターネットアクセスする際にUser-Agentフィールドをブラウザ用に設定して偽り、セキュリティの検閲をすり抜けて攻撃をするbotやマルウェアの問題があったような...。

リダイレクトにはcurl！という風に学びました。
楽しかったです。
常設していただいているsetodaNote様に感謝申し上げます。