misolog

CTFとか勉強とか諸々

SharkyCTF 2020 write-up

5/9~5/11(JST)に開催されたSharkyCTF 2020にソロで参加してみた。 CTFへの参加は初めてという事もありほとんど解けなかった。 今後に向けてwriteupをつらつら書いていこうかと思います。

f:id:mis0kin:20200511133616p:plain

basic LSB [Steganography]

online steganoツールに画像を入れるとフラグゲット。

stylesuxx.github.io

trolled [Misc]

クリックすると何らかの画像?が読み込まれるみたいだが、すぐにchallengeページが読み込まれる。 通信の中身を見るためにburp suiteを使う。 何度かrequestをforwardすると、GETリクエストにflag発見

f:id:mis0kin:20200511134828p:plain
flag

flag入力欄のところで通信を止め、flagを入力してforwardすればOK POSTリクエストのパラメータにちゃんとflagが入ってた

f:id:mis0kin:20200511135136p:plain

Pain in the ass [Forensics]

問題文を見る限り、ファイル内のSQL関連のパケットにflagがありそう。 ProtocolをPGSQLでフィルタし、TCP streamを見ると大量のSQLクエリを発見。 usernameは固定でpasswordを何度も変更してクエリを投げ、エラーが返ってきている。 このため、blind SQL injectionを試行しているように見える。 よく見ると、所々レスポンスが異なる部分があり、flagっぽく見える。

f:id:mis0kin:20200511140015p:plain
赤枠の箇所が「s」で始まり「}」で終わるところまでがflag

そのときのpasswordの文字列を抽出し繋げるとflagゲット。

TACACS [Network]

wiresharkプロトコル階層を見ると、TACACS+の通信があるのでフィルタして詳細を見る。しかし暗号化されていて中身が読めない。 TFTPでフィルタすると、Cisco機器のconfig通信を発見 更に調べていくとTACACSの暗号化鍵の設定を発見

tacacs-server host 192.168.1.100 key 7 0325612F2835701E1D5D3F2033

7はオプションで、鍵が暗号化される事を示している

Ciscoのパスワードクラッカーに入れるとTACACS+のパスワードを復号できる

www.ifm.net.nz

Password: AZDNZ1234FED 設定>Protocols>TACACS+の鍵に入力するとパケットが復号される No.27の復号されたパケットからflagゲット

問題を解く際に参考にしたサイト github.com

以下、考察したが解けなかった問題

XXExternal [Web]

xmlファイルを読み込ませる点や問題名から、XXE攻撃と推測。 ただし、具体的な攻撃手法まで理解できなかったので断念…

Romance Dawn

PNGが壊れているため、chunkを修正する問題と推測。 EASY chunkに問題があるみたいだが、chunk formatにそんなものはないためググる。 private chunkが作れるらしい。

labs.gree.jp

PCRTやpngcheckを使ってchunkの値の整合性を取ってみたが、flagゲットならず… そもそもIDATがないらしいのだが、IDAT chunkの入れ方がよくわからなかったため断念。

(5/13追記)

他のwriteupを見ると、どうやらEASYをIDATに変えるだけでいけるっぽい。 EASYをIDATとしたとき、Lengthが0x00002000(4bytes)、typeがIDAT(4bytes)、その後Dataが0x00002000分続き、最後にCRCが4bytes設置されているとする。 そうすると、Length(4bytes)+type(4bytes)+Data(0x00002000)+CRC(4bytes)=0x0000200cとなる。 はじめのEASYから0x0000200c bytes後を見ると他のEASYがあったため、これもIDATとなる。 よって、EASYをIDATに書き換えるとpng formatが正しくなり、画像が表示されてflagゲット。

www.setsuki.com

Give away 0 [pwn]

ソースは64-bitのELFファイル。gdbで見るとmain関数の他にinit_buffering関数とvuln関数があった。 また、vuln関数内にはfgets関数があり、ここでbuffer overflowを使って攻撃ができそう。 やり方としては、vuln関数内でbuffer overflowを起こしリターンアドレスを書き換え、そこにシェルコードを入れサーバ側のflagファイルを開くのではと推測。 buffer sizeは32byte、offsetは40byteなので40byte分適当な文字+シェルコードでいけそうだったがうまくいかなくて断念。

(5/13追記)

objdumpすると、/bin/shを起動するwin_func関数というのがあるらしい。 よって、40byte分適当な文字+win_exec関数のアドレスを送ればシェルが起動しcat flag.txtでflagゲット。

今後はもっと問題を解けるように頑張ろう