SECCON 2018 参戦記

SECCON 2018予選にnegainoidoで参加して、ReversingのSepecial Device FileとSpecial Instructionsを解きました。

Special Instructions

バイナリファイルが与えられ、それを実行してフラグを得る。いろいろなアーキテクチャのクロスコンパイラも与えられる。
とりあえず、そのツールチェーンをビルドしつつ、バイナリを眺める。fileコマンドではアーキテクチャを特定できなかったが、stringsコマンドを使うと、

1
2
3
4
5
6
7
8
This program uses special instructions.
SETRSEED: (Opcode:0x16)
    RegA -> SEED
GETRAND: (Opcode:0x17)
    xorshift32(SEED) -> SEED
    SEED -> RegA
GCC: (GNU) 4.9.4
moxie-elf.c

というのが見えるので、moxieというアーキテクチャだということがわかる。
ツールチェーンにはエミュレータも含まれているが、stringsの結果にもあるとおり、xorshift専用の命令が組み込まれている。
xorshiftのアルゴリズムについてはwikipedia参照。xorとshiftによって簡単かつそこそこ質のよい乱数が生成できるらしい。
この専用命令を関数としてどこかにねじ込み、命令をその関数の呼び出しに書き換えるという戦略も考えられるが、今回はやっていることがバイナリ内のロジックが比較的シンプルなので、
それを適当なプログラミング言語に再実装して手元で走らせるのが楽。
moxieのアーキテクチャマニュアルはその時は見つけられなかったが、割と素直な構成なので、ある程度他のアセンブラを触った人ならなんなく読めるはず。
やっていることは、初めになんやかんやputsで文字列を出した後、decode関数で暗号化されたflagをデコードし、それをputsしている。
デコードの仕組みは暗号化された文字に対して、更に別のrandvalという埋め込まれている定数とxorshiftによって生まれる乱数とのxorをとっているだけ。

乱数の初期シードをコピペミスするとかして無駄に時間を浪費してしまったが、なんとか提出できた

Special Device File

今度はaarch64のバイナリが与えられる。今度は/dev/xorshift64というデバイスを叩いているためそのままでは実行できない。
xorshift64は名前から察するにxorshiftで乱数を生成しているだけであろうと予想できる。

ARMv7-Aのアセンブラは読み書きしたことがあるが、aarch64ははじめてだったので、少々戸惑ってしまったが、
ちょっと公式ドキュメントを読めば理解できた。64bitアーキテクチャのため、馴染みのない命令がそこそこあったが、
Arm公式で提供しているドキュメントがそこそこ親切なので調べれば大丈夫。
やっていることはSpecial Instructionと大差ない。xorshift64の初期シードを探すのに多少手間取ったが、よく見ると初めにスタックに64bitの定数を積んで、スタックポインタをwrite関数に渡していたのに気がつき、それがシードだった。

取り組んだが解けなかった問題

Needle in a haystack

恒例(?)の動画問題。題名から察するにどこか数フレームにフラグがあるのかなあ、とチームメイトがいろいろ試行錯誤。
自分もいろいろアイデアを出したが、結局何も掴めず。

結論はビルの一室のあかりがモールス信号になっていたらしい。まあ、この問題は解けなくても仕方ないかなあという気分。

GhostKingdom

唯一のWeb問題。ウェブサービスが与えられていて、/FLAG以下のアドレスのどこかにフラグがあるらしい。
そのウェブサービスでできることは

  • ユーザーの登録とログイン
  • メッセージの送信フォーム
  • URLを与えて、そのページのスクリーンショットの取得

メッセージの送信フォームにはプレビュー機能があって、そこにcssという名前の怪しいパラメータがあった。
適当な値を入れると、プレビュー部分のstyleタグに壊れた文字が入っていたので、何らかの形式でエンコードされたcssであろうと考え、base64を試したら見事正解。

他にはスクリーンショットの取得部分で、自分で適当なページをつくって、その中でlocalhostにリダイレクトさせることで、ページにlocalhostとしてアクセスすることで画像アップロード機能を使える、というところまでは掴んだ。
ログインはiframe内でログイン用のURLを叩かせた。

しかし、それ以上をつかむことができず終了。
答えとしてはCSS injectionとして知られている技法でフォームの値を抜き出し、セッションIDを取得すること、
その後、画像アップローダーで使われているImageMagicの脆弱性をつくことだったらしい。
参考：http://hakatashi.hatenadiary.com/entry/2018/10/28/211034

CSS injectionのことを知らなかったほか、セッションIDがcsrfトークンとしてフォームに埋め込まれていたことに気がつけなかった。
たとえそれらに気がついたとして、ImageMagicの脆弱性までたどり着けるかどうかも怪しい。
任意CSSを埋め込めることに気がつけた時点で、もっとCSSを利用したテクニックについて調べていればよかった。
常日頃CTFをやっている人間でないのでその場で知識を調達してこなければならないのが厳しい。