この記事は前回記事の続きです。
まずは前回をどうぞ！
k-hyoda.hatenablog.com
今回は前回記事にて宣言していた「解けなかった問題で触って色々考えた問題」について書いていきます。
こういう場合ってWrite upって言うんですかね？よくわかりません。
問題を考える方などの参考になれば幸いです。
はじめに
このWrite upでは解けなかった問題のうち、私が何をしてどうなったかが記載されます。
解けていないのでフラグはありません。
ただすでに他の方がWrite upを書いているようなので、Twitterのハッシュタグ「#sckosen」で検索してもらえればいい感じのWrite upが見つかると思います。
twitter.com
02. 伝統的な暗号
暗号化された文字列が記載されて、それを復号化すればフラグになるようでした。
伝統的な暗号といえば？
もちろんシーザー暗号ですよね。
ja.wikipedia.org
ということで適当にROT13(13個分ずらす)で解けるかと思ったのですが、解けない。
しかも他のROTでもうまく復号化できません。なんでじゃー
ということでチームメンバーにお願いしてみたところ、うまく復号化してくれました。
08. 拡張されたIPv6
最近は名前を耳にする機会も増えてきたIPv6の問題です。
IPv6のアドレスのルールは何で規定されているか？という問題でした。
こんなのRFCだろうなぁってことでWikipediaでIPv6の記事の中からそれっぽいRFCドキュメントの番号(ex. RFC 5952)を入れてみるものの解けず。 ja.wikipedia.org
結構な数のRFCを試したものの全くヒットせず、これも他のチームメンバーにお願いしましたが最後まで解けませんでした。
Twitterで調べるなんて考えてなかった。
11. 新人エンジニアの発明
ncコマンドでとあるサーバーにアクセスすると、どうやらSQLを管理者としてガッツリ触れるプログラムが登場します。
このプログラム、果たして安全？というのが問題です。
なんとなくSQLインジェクションかコマンドインジェクションだろうなぁと予想してコマンドを入力してみます。
まずはSQLインジェクション狙いでコマンドを入力していたところ、たまたま入力したコマンドでエラーが発生して使われているデータベースがSQLiteであることが判明しました。
しかし、SQLインジェクションはうまくいかず、コマンドインジェクションも同じようにうまくいかずで手詰まりに。
最後まで解けませんでした。
14. お茶をさぐれ
apkファイルがダウンロードできるようになっており、この中からフラグを探せというのが問題でした。
apkはおなじみAndroidのアプリケーションパッケージファイルです。
早速展開して逆コンパイルしようと思ったところ、JDKが入っていないことに気づきました。
JDK、早速インストールしようとOracleのサイトにアクセスしたところ、Javaのライセンス変更に関する画面が。
その画面を見て萎えてしまったのでチームメンバーにパスしたところ、うまく解いてくれました。
チームメンバー、とても頼りになりますね。
18. you are not admin
Webサイトのアドレスが記載されており、そこでadminになればフラグを得られるような感じの問題でした。
サイトにアクセスしたところ、you are not adminの文字が。
ここで早速Cookieを見たところ、どうやらSessionが突っ込まれていました。
Cookie Session CTFとかで検索をかけると、Flaskのセッションに関する記事が出てきます。
qiita.com
これっぽいなぁと思いながらセッションの解読をしてみます。
セッションの改ざんを行えばうまくadminになれそうです。
ただ、ここでFlaskが使われているとすれば、セッションの改ざんにはセッションのSECRET_KEYを入手しておく必要があります。
しかし、それをどうやって入手するのか検討が付かないのでセッション改ざんからFlaskのサーバーサイドテンプレートインジェクションをやってみることにしました。
今となってはなぜサーバーサイドテンプレートインジェクションやり始めたのか謎です。セッションのSECRET_KEYを探そうと最初は思っていたのでしょうが、後半はずっと「インジェクションでフラグがわかれば...」って考えていました。
完全に方向性を間違えています。
この問題のインジェクションを行っている途中でタイムアップになりました。
よってこの問題は解けませんでした。
19. JWT
18の問題に近い感じですが、今回はSessionの代わりにJWTが使われているようです。
JWTの仕組みもFlaskのSessionに似ていますが、JWT 脆弱性で調べてみるとこんな記事が出てきます。
qiita.com
これかなぁと思いつつJWTの中身を解析してみます。
解析にはjwt.ioを使うと簡単です。
jwt.io
脆弱性を使えば、signatureの部分を自分の好きなアルゴリズムに変更できるようで、しかもHS256を選択すればサーバの公開鍵でsignatureを作れると知って早速プログラムでこしらえてみました。(ちなみにプログラムは残っていないです。)
できたデータで上書きしてページをリロードしてみましたがうまくいかず。
何回か試してみたものの、軒並みうまく行かなかったため諦めて18の問題に移りました。
そのためこちらも最後まで解けませんでした。
最後に
これらが私が実際に解こうとして解けなかった問題です。
おそらく最後のJWTはもうちょっと粘っていれば解けたんじゃないかなぁと思っています。
ちゃんと手順は確認したほうがいいですね。
