1001001

73。CTFのWrite-upや技術的な備忘録を書きとめたいです。

CSAW CTF 2017 Write-up

CSAW CTF 2017にチームm1z0r3で出ていました.

Misc 100とCrypto 350を解いたのでそのWrite-upになります.

CVV ( Misc 100 pts)

CVVとはCard Verification Valueの略で,クレジットカード番号のこと.

netcatでサーバに接続すると,"I need a new Visa!" , "I need a new American Express!" のようにクレジットカード会社の番号を求められる.なお,newと付いているのは一度の接続で同じ数字を使いまわしてはいけないということを表している.

つまりこの問題は,指定された会社のクレジットカード番号として正しい番号を送り続ける問題である.では,クレジットカードの番号として正しい値がどのような値かというと,以下の二つを満たす値である.

  1. クレジットカード会社ごとのプレフィックスを満たす
  2. Luhnアルゴリズムを満たす

1.クレジットカード会社ごとのプレフィックスというのは決まっていて,Wikipediaにも記載されている.詳細はこちらを参照してほしい.

2.Luhnアルゴリズムというのはクレジットカード番号を決定する際に用いられるアルゴリズムである.1954年にハンス・ペーター・ルーンという当時IBMの研究者だった方が考案したアルゴリズムで,当初は特許化されていたが現在ではISOにより世界標準となっている(ISO/IEC 7812).

このアルゴリズムの説明は割愛するが,こちらもWikipediaに詳細が記載されているので参考にしてほしい.なんとPythonのコードまで記載されていたので拝借した.

スクリプトを書いて何度か試行していると,求められる条件が以下のように変動することがわかる.

  • "I need a new ...": 特定のクレジットカード会社の正当な番号を答える
  • "I need a new card that starts with ...": ある数列で始まる正当な番号を答える
  • "I need a new card that ends with ...": ある数列で終わる正当な番号を答える
  • "I need to know if ... is valid! (0 = No, 1 = Yes)": 与えられた番号が正当かどうか答える(16桁?)

これらによって条件分岐するようなスクリプトを書いた.

The flag is "flag{ch3ck-exp3rian-dat3-b3for3-us3}"

 

baby_crypt ( Crypto 350 )

crypto.chal.csaw.io:1578 にnetcatにアクセスする.usernameを入力するとクッキーを発行してくれるというだけのサーバが動いている.

問題文に

The cookie is input + flag AES ECB encrypted with the sha256 of the flag as the key.

とあったみたいなのだが,私は完全に見落としていて入力検証から始めた.(途中で追記されたものと信じたい)

ひたすら入力検証をしていると以下のことが分かった.

  1. クッキーの長さは入力の長さに依存
  2. 長さは16文字おきに変化し,その差は32文字
  3. "a"*16個と,"a"*32個の時のクッキーを比較すると前のブロックに依存していないことが分かる
  4. 同じ長さの複数の入力を比較したとき,後ろ32文字が同じ

1.から,クッキーは入力を共通鍵暗号などで暗号化されて作られているのではないかということはわかる(自明という説もある).2.から,1ブロック16文字のブロック暗号ではないかと推測できる.3.によりモードはECBであることが分かる.4.により,パディング以外に後ろに何かくっついていることが分かる.

もう少し詳しく説明すると,3.は以下のような検証をした.

Enter your username (no whitespace): aaaaaaaaaaaaaaaa # "a"*16
Your Cookie is: 469ac6eba774ac471777f35c88d9dd6a / f9cc1330ae5830732a18d1a23211ffbce3725519adb9e6f10d658d87c80825ed
Enter your username (no whitespace): aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa # "a"*32
Your Cookie is: 469ac6eba774ac471777f35c88d9dd6a / 469ac6eba774ac471777f35c88d9dd6a / f9cc1330ae5830732a18d1a23211ffbce3725519adb9e6f10d658d87c80825ed

もしもCBCモードのようにIVが使われていたり前の暗号化結果が依存するならこのような結果にはならない."a"16個のクッキーの1ブロック目と"a"32個のクッキーの2ブロック目はまず同じにならない(きちんと検証するなら"b"16個+"a"16個などが分かりやすい).

そして,もしもブロック暗号だとすると,基本的にはパディングが施されるので,ブロックごとに分けられた入力の最後はブロック長にパディングされる.しかし,上の結果を見てみると,入力とは関係ない末尾の部分がパディングだけにしては長すぎる.従ってこの問題は,入力の末尾にflagをくっつけた後にパディングをしてAES ECBモードで暗号化してるのではないかという推測をした.

もしそうであれば,flagが"flag{...}"であるとき,以下の二つの入力のクッキーの1ブロック目は同じになるはずである.

  • "aaaaaaaaaaaaaaaf" ("a"*15個+"f") -> "aaaaaaaaaaaaaaaf / flag{.....}padpadpad...."
  • "aaaaaaaaaaaaaaa"   ("a"*15個)        -> "aaaaaaaaaaaaaaaf / lag{.....}padpad...."

よって,仮に上のfの部分が未知でも,アルファベットを総当たりすることで1文字特定可能である.あとは以下のようにずらしていけば1文字ずつ特定することが可能である.

  • "aaaaaaaaaaaaaaf?" ("a"*14個+"f"+"?") -> "aaaaaaaaaaaaaaf? / flag{......}padpad..."
  • "aaaaaaaaaaaaaa"    ("a"*14個)                 -> "aaaaaaaaaaaaaafl / ag{......}padpad..."

?の部分を総当たりすればlで当たるはずである.

実際に推測できる"flag{"の部分を試すと同じになるので,この方針でスクリプトを書いた.なお,フラグが1ブロック長より長い可能性があるのでスクリプトでは"a"*32から始めた.

The flag is "flag{Crypt0_is_s0_h@rd_t0_d0...}"

まとめ

時間中に解いた二つの問題(CVV, baby_crypt)のWrite-upでした.Almost Xorが解けなかったので精進が必要です.