kimtetの日記

CTFのwriteupとか、勉強したこととか

SECCON 2014 横浜大会 CTF ネットワーク予選 write up 問7

年を越しましたが7問目。 07フォルダにもquestion.txtがあって、こんな感じ。

通信相手のIPアドレスは?次の4つのパケットを見て答えよ。

-- 1 --
000000: FF FF FF FF  FF FF 00 66  77 88 99 AA  08 06 00 01 : .......f w.......
000010: 08 00 06 04  00 01 00 66  77 88 99 AA  C0 A8 01 02 : .......f w.......
000020: 00 00 00 00  00 00 C0 A8  01 01                    : ........ ..
==
-- 2 --
000000: 00 66 77 88  99 AA 00 11  22 33 44 55  08 06 00 01 : .fw..... "3DU....
000010: 08 00 06 04  00 02 00 11  22 33 44 55  C0 A8 01 01 : ........ "3DU....
000020: 00 66 77 88  99 AA C0 A8  01 02 00 00  00 00 00 00 : .fw..... ........
000030: 00 00 00 00  00 00 00 00  00 00 00 00              : ........ ....
==
-- 3 --
000000: 00 11 22 33  44 55 00 66  77 88 99 AA  08 00 45 00 : .."3DU.f w.....E.
000010: 00 54 00 00  40 00 40 01  50 C3 C0 A8  01 02 0A 14 : .T..@.@. P.......
000020: 1E 28 08 00  D0 C0 7A 07  00 01 EA 6C  02 54 C9 72 : .(....z. ...l.T.r
000030: 0C 00 08 09  0A 0B 0C 0D  0E 0F 10 11  12 13 14 15 : ........ ........
000040: 16 17 18 19  1A 1B 1C 1D  1E 1F 20 21  22 23 24 25 : ........ .. !"#$%
000050: 26 27 28 29  2A 2B 2C 2D  2E 2F 30 31  32 33 34 35 : &'()*+,- ./012345
000060: 36 37                                              : 67
==
-- 4 --
000000: 00 66 77 88  99 AA 00 11  22 33 44 55  08 00 45 00 : .fw..... "3DU..E.
000010: 00 54 02 95  40 00 40 01  4E 2E 0A 14  1E 28 C0 A8 : .T..@.@. N....(..
000020: 01 02 00 00  D8 C0 7A 07  00 01 EA 6C  02 54 C9 72 : ......z. ...l.T.r
000030: 0C 00 08 09  0A 0B 0C 0D  0E 0F 10 11  12 13 14 15 : ........ ........
000040: 16 17 18 19  1A 1B 1C 1D  1E 1F 20 21  22 23 24 25 : ........ .. !"#$%
000050: 26 27 28 29  2A 2B 2C 2D  2E 2F 30 31  32 33 34 35 : &'()*+,- ./012345
000060: 36 37                                              : 67
==

問題の考え方

それぞれのパケットの通信先を読み取って回答する。 なんで4つあるのかは謎。

解法

解けなかった。

調べた結果

4つのパケットをそれぞれ確認してみる。
1個目2個目の長さが短くてIPパケットじゃない気がするので、まずはethernetフレームのタイプ(1行目13-14byte目)を確認すると、以下の通りだった。

パケットNo ethernet typeの値 意味するところ
1 08 06 ARPパケット
2 08 06 ARPパケット
3 08 00 IPパケット
4 08 00 IPパケット

ARPパケットなんて真面目に見たことないや……。そりゃわからんわな。
この並びだと、最初にARPで宛先のMACアドレスを確認して、その次にその情報を使ってIPでの通信を行ったという感じだろうか。
パケットの正体もわかったところで具体的にどことどこが通信を行っているのか確認していこう。

-- 1 -- の情報

まずはEthernetフレームから。1byte目から6つが送信先、次の6つが送信元なので確認は簡単。

MACアドレス
送信先 FF FF FF FF FF FF(ブロードキャスト)
送信元 00 66 77 88 99 AA

送信先が FF FF FF FF FF FF なので、ブロードキャスト要求だということがわかる。
ARPでブロードキャストするのってARP要求パケット(このIPアドレスMACを教えてください)の場合だよね。

続いてARPフレームの確認。ここには送信元のMACアドレスIPアドレスの対比、あとMACを知りたいIPアドレスの情報が載ってる。
2行目の7byte目から読んでく。送信元MACアドレスIPアドレス、知りたいMACアドレス、知りたいIPアドレスの順に並んでる。

MACアドレス IPアドレス(16進数) IPアドレス(10進数)
送信元 00 66 77 88 99 AA C0 A8 01 02 192.168.1.2
知りたい情報 00 00 00 00 00 00 C0 A8 01 01 192.168.1.1

送信元 192.168.1.2 がブロードキャストで 192.168.1.1 のMACアドレスを教えてーってってのがわかった。

-- 2 -- の情報

同じようにEthernetフレームを見ると、次のようになってる。

MACアドレス
送信先 00 66 77 88 99 AA(問い合わせ元)
送信元 00 11 22 33 44 55(ARP情報の送り主)

続いてARPフレームも同様にチェック。

MACアドレス IPアドレス(16進数) IPアドレス(10進数)
知りたい情報 00 11 22 33 44 55 C0 A8 01 01 192.168.1.1
送信先 00 66 77 88 99 AA C0 A8 01 02 192.168.1.2

1の要求に対して返事してるのがわかった。ふぅ。

-- 3 -- の情報

続いてIPパケットのほうを見てみる。さっきのARP情報が生かされているはずだ!
Ethernetフレームは以下の通り。おなじみ最初の6つずつ。

MACアドレス
送信元 00 11 22 33 44 55
送信先 00 66 77 88 99 AA

続いてIPフレームの送信元/送信先IPアドレスは以下の通り(2行目の11-14byte目と15byte目-3行目の2byte目)。この辺は慣れてきてすぐ見つけられるようになった。

IPアドレス(16進数) IPアドレス(10進数)
送信元 C0 A8 01 02 192.168.1.2
送信先 0A 14 1E 28 10.20.30.40

あれ?送信先がARPで見つけたIPアドレスと違うな。考えられるのは、192.168.1.1がルーターで、それ経由で10.20.30.40で通信しているとかかな? ひとまず4個目のパケットを見てみよう。

-- 4 -- の情報

Ethernetフレームは以下の通り。

MACアドレス
送信元 00 66 77 88 99 AA
送信先 00 11 22 33 44 55

IPフレームは以下の通り。

IPアドレス(16進数) IPアドレス(10進数)
送信元 0A 14 1E 28 10.20.30.40
送信先 C0 A8 01 02 192.168.1.2

通信先は10.20.30.40で決まりだね。ARPの確認だけで決めつけないように、というひっかけ問題かな。

ちなみに3個目と4個目のパケットのトランスポート層のタイプを調べると、ICMPだってことがわかる。ICMPのタイプとコードを調べると、3個目がping要求、4個目がping応答だってのもわかるので、3問目の復習にどうぞ。

別解

これもtext2pcapにかけるとズバッと答えが……と思いきや、4つ目以外は [Malformed Packet] って言われちゃう。4つ目が残っているのでこれの送信元から答えを類推することは可能かも。
出題者はわざと壊れたパケットにしておいたのかなあ?

f:id:kimtet:20150103183459p:plain

SECCON 2014 横浜大会 CTF ネットワーク予選 write up 問6

続いて問6を解くよ。 06フォルダにはquestion.txtがあって、こんな感じ。

空欄となっている箇所の2バイトの値は?

00 66 77 88  99 AA 00 11  22 33 44 55  08 00 45 00
00 54 03 76  00 00 40 01  F3 DF C0 A8  01 01 C0 A8
01 02 08 00  48 FD 3B 04  00 6F 54 01  8D C5 00 0C
A6 B9 08 09  0A 0B 0C 0D  0E 0F 10 11  12 13 14 15
16 17 18 19  1A 1B 1C 1D  1E 1F 20 21  22 23 24 25
26 27 28 29  2A 2B 2C 2D  2E 2F 30 31  32 33 34 35
36 37

00 11 22 33  44 55 00 66  77 88 99 AA  08 00 45 00
00 54 1E 0A  00 00 40 01  D9 4B C0 A8  01 02 C0 A8
01 01 00 00  -- -- 3B 04  00 6F 54 01  8D C5 00 0C
A6 B9 08 09  0A 0B 0C 0D  0E 0F 10 11  12 13 14 15
16 17 18 19  1A 1B 1C 1D  1E 1F 20 21  22 23 24 25
26 27 28 29  2A 2B 2C 2D  2E 2F 30 31  32 33 34 35
36 37

ntpのパケットじゃないのが出てきた。
"-- --" って書いてあるところの正しい値を答えろってことみたい。

問題の考え方

パケットの並びから何のデータが入る場所か特定して、その場所に入るべき値を調べればいい。
2つあるのは多分関連しているパケットで、1個目の内容から2個目の内容を推測しろってことだと思う。

解法

時間内に解けなかった。

調べた結果

トランスポート層プロトコルの確認。
トランスポート層プロトコルがわかるのは2行目の8個目01。問3参照。01だとICMP。
2つのパケットデータの両方とも01なので、ICMPでのやり取りかなと推測できる。

ICMPのタイプとコードを確かめてみる。
3行目の3番目がタイプ、4番目がコードなので確認する。
1個目のフレーム

08 00

ICMPのエコー要求であることがわかる。
2個目のフレーム

00 00

ICMPのエコー応答であることがわかる。

以下は念のため送信元と送信先のIPアドレスを確認する。 送信元IPアドレスは2行目の11番目-14番目、送信先IPアドレスは2行目の15番目-3行目の2番目を見る。

  • 1個目のフレーム
    • 送信元:C0 A8 01 01 → 192.168.1.1
    • 送信先:C0 A8 01 02 → 192.168.1.2
  • 2個目のフレーム
    • 送信元:C0 A8 01 02 → 192.168.1.2
    • 送信先:C0 A8 01 01 → 192.168.1.1

うん、やっぱり往復の通信だね。

問題の個所はICMPヘッダーのチェックサムなので、ICMPのチェックサム計算手順に沿って計算してあげればOK。 ためしに手作業で計算してみる。手順は以下の通り。

  1. 計算に当たり、チェックサム部分の16bitはゼロ (00 00) とする。
  2. ICMPヘッダ部とデータ部全部を16bit区切りの値(要するに4桁ずつ)にする。
  3. すべての値の「1の補数和」を求める。
  4. 値の1の補数を求める。

実際に計算すると次のような式になる。
Windows関数電卓を16進数に設定してコピペすると計算してくれるので便利。Microsoftさんすごい。

0000+0000+3B04+006F+5401+8DC5+000C+A6B9+0809+0A0B+0C0D+0E0F+1011+1213+1415+1617+1819+1A1B+1C1D+1E1F+2021+2223+2425+2627+2829+2A2B+2C2D+2E2F+3031+3233+3435+3637 = 4AEFE

4AEFEはただの和なので、桁あふれ処理をして「1の補数和」にする。

AEFE+0004 = AF02

1の補数にする(ビット反転)

AF02 = 1010111100000010
ビット反転
0101000011111101 = 50FD

解は50FD。できたー。

最初計算したときに「1の補数和」と「1の補数する」の意味を正しく理解していなくて下の別解の結果と合わなくて悩んだ。 「りろんはしってる(実践はできない)」はいざというときつらい(手動でチェックサム計算するなんてどういうときだ)。

参考資料

別解1

ping ICMP echo のパケットの特性(ICMPタイプ以外は全部コピーして送り返される)を考えると、1個目のフレームの内容から類推して答えることもできる。

行きのパケットのチェックサムが 48 FD。
ICMP echo の場合、リクエストとレスポンスの違いは、タイプの違いだけ。
そうすると、タイプとコードの部分の数値が 08 00 か 00 00 かという違いだけ。
つまりチェックサムの値も 08 00 と 00 00 の差だけ異なる。
チェックサムの値は1の補数を取っているので、あれやこれや計算すると受信時のチェックサムの値は送信時のチェックサムの値に 0x0800 を足した値になる。

48FD + 0800 = 50FD

こっちのほうが速いね! ちくしょー!

別解2

問1で書いた通りtext2pcapを使用する。
ただし今回のデータはオフセット(行の初めの数値)がないので、オフセットを追加して、-- -- となっているところをテキトーな 値(FF FFとか)にしてからtext2pcapにかける。

するとなんと、パケットを見ると [incorrect, should be 0x50fd] と出てご丁寧に正しい値を教えてくれる。wiresharkさんマジステキ。惚れる。

f:id:kimtet:20141129145755p:plain

SECCON 2014 横浜大会 CTF ネットワーク予選 write up 問5

かなり間が空いたけど問5の解説。
解けなかった問題なので改めて書くのがたいへんだった。

このパケットによると、日本時間で今何月何日何時何分何秒?

0000   00 1a a0 89 a3 7f 44 94 fc 7e 1a ba 08 00 45 00  ......D..~....E.
0010   00 4c 00 00 40 00 36 11 11 2c d2 ad a0 1b c0 a8  .L..@.6..,......
0020   00 04 00 7b 00 7b 00 38 6d 96 1c 02 11 e8 00 00  ...{.{.8m.......
0030   06 8b 00 00 02 9e ac 1d 02 32 d7 ad 09 99 d8 db  .........2......
0040   8b 49 d7 ad 0a 44 7a a8 0f 7e d7 ad 0a 46 42 28  .I...Dz..~...FB(
0050   23 a6 d7 ad 0a 46 42 2b 5a b3                    #....FB+Z.

問4と同様、データ部分は問3と同じ。問題文が異なっている。

問題の考え方

データは問3と同じ。 今何時何分何秒なのか、とのことなので、このパケットの保存している時間情報を探して、NTPのプロトコルに従って送受信の間ののネットワーク伝送による誤差を加味して答えればいい。

簡単だと思ってたよ、この時までは。

解法

ntpパケットには時刻情報が4つある。

名称 パケットの中の位置
Reference Timestamp 4行目の11個目-5行目の2個目
Origin Timestamp 5行目の2個目-10個目
Receive Timestamp 5行目の11個目-6行目の2個目
Transmit Timestamp 6行目の2個目-10個目

それぞれ64bitの値であるこれをゴニョゴニョして人間に見られるようにして、計算して回答する。

こっから先は当日はわからなくて時間切れ。
どのTimestampを参照すればいいのかも、
64bitの値をどうやって西暦に直すのかも。

調べた結果

それぞれのタイムスタンプの意味は以下の通り。

名称 意味
参照タイムスタンプ(Reference Timestamp) ローカル時計が最後に設定、修正された時刻
開始タイムスタンプ(Originate Timestamp) クライアントからサーバへリクエストを発信した時間
受信タイムスタンプ(Receive Timestamp) サーバへリクエストが到着した時間
送信タイムスタンプ(Transmit Timestamp) サーバからクライアントに応答が発信された時間

UNIXタイムは32bitで保存されているという話をよく聞くけど、NTPの情報はどう扱ったらいいのかわからない。
64bitの値をどうやって西暦に変換するか。RFCより以下の情報を得た。

NTPタイムスタンプは、64ビット符号無し固定小数点数として表現されており、 このタイムスタンプは、1900年1月1日0時との相対的な差を秒単位で表している。 整数部分は、最初の上位32ビット、小数点以下は、下位32ビットとなっている。 小数部分については、あまり重要でない下位ビットは、0に設定される。

また、同じくRFCより保存形式はビッグエンディアン(上位桁から順に記述)と得られたので、 上位32bitを記述順に扱い、十進数に直す。

d7 ad 09 99 d8 db 8b 49 → 3618441625
d7 ad 0a 44 7a a8 0f 7e → 3618441796
d7 ad 0a 46 42 28 23 a6 → 3618441798
d7 ad 0a 46 42 2b 5a b3 → 3618441798

これが1900年01月01日からの経過秒数になる。 西暦に直すために計算するんだけど、手作業じゃしんどいのでツールを探す。

UNIXタイムスタンプ→西暦のツールはあまたあるけど、 NTPタイムスタンプ→西暦のツールは全然見ない。 で、いろいろ調べていたら、両者の差を書いてあるところがあった。

NTP時刻 - 2208988800秒 = UNIX (POSIX) 時刻

NTP時刻が1900年01月01日~の秒数で、UNIX時刻が1970年01月01日~の秒数だから、 その差を計算すればよい。 両者とも形式的な(うるう秒等を考慮しない)秒数なので、精密な処理は不要。

3618441625 - 2208988800 = 1409452825 = 2014/8/31 11:40:25 JST
3618441796 - 2208988800 = 1409452996 = 2014/8/31 11:43:16 JST
3618441798 - 2208988800 = 1409452998 = 2014/8/31 11:43:18 JST
3618441798 - 2208988800 = 1409452998 = 2014/8/31 11:43:18 JST

で、ここまで出したんだけどこの数字から現在時刻を求める方法がわからない。 いろいろ調べたら、NTPの時刻同期には以下の4つの情報が必要とある。 最初の4つはそのうちの一番最後の「クライアントがサーバのレスポンスを受信した時刻」が このデータからだとわからない。
なにか別の求め方があるのだろうか。教えて詳しい人!

  1. クライアントがリクエストを送信した時刻
  2. サーバがクライアントのリクエストを受信した時刻
  3. サーバがレスポンスを送信した時刻
  4. クライアントがサーバのレスポンスを受信した時刻

参考資料

別解

問1で書いた通りtext2pcapを使用すると時刻情報が一目瞭然なんだけど、 やっぱりここから補正して現在時刻が何時になるのかはわからない。
自分のやった手計算が間違っていなかったことだけ確認できた。
なお、出てくる情報はUTCなので+9:00:00してJSTにしなければならない。

f:id:kimtet:20141123201605p:plain

SECCON 2014 横浜大会 CTF ネットワーク予選 write up 問4

やっとこさ問4の解説だよ。この調子でいくと年が明けそうだね。 まあでも来年のSECCONに間に合えばいいや。 今までと同じように04フォルダを開くとquestion.txtがひとつのみ。ひらくとこんな感じ。

サーバの名前は何?
FQDNでお答えください。

0000   00 1a a0 89 a3 7f 44 94 fc 7e 1a ba 08 00 45 00  ......D..~....E.
0010   00 4c 00 00 40 00 36 11 11 2c d2 ad a0 1b c0 a8  .L..@.6..,......
0020   00 04 00 7b 00 7b 00 38 6d 96 1c 02 11 e8 00 00  ...{.{.8m.......
0030   06 8b 00 00 02 9e ac 1d 02 32 d7 ad 09 99 d8 db  .........2......
0040   8b 49 d7 ad 0a 44 7a a8 0f 7e d7 ad 0a 46 42 28  .I...Dz..~...FB(
0050   23 a6 d7 ad 0a 46 42 2b 5a b3                    #....FB+Z.

あれ? 問3と同じじゃない……? そう思ったあなた、半分正解。 パケットデータのほうは問3と全く一緒。ただし問題文が異なっているね。

問題の考え方

データは問3と同じ。 通信してるIPアドレスを調べ、サーバのほうのIPアドレスを名前解決してFQDNを答える。

簡単だね!

解法

問3でちょこっと見たIPヘッダを見て、どのIPアドレス同士が通信しているか見てみよう。 IPヘッダは1行目の終わりから始まっているけど、肝心のIPアドレスが入っているのは2行目の終わりのほうから。

0010   00 4c 00 00 40 00 36 11 11 2c d2 ad a0 1b c0 a8  .L..@.6..,......
0020   00 04 00 7b 00 7b 00 38 6d 96 1c 02 11 e8 00 00  ...{.{.8m.......
  • 送信元アドレスがわかるのは、2行目の11-14byte目 = d2 ad a0 1b
  • 送信先アドレスがわかるのは、2行目の15byte目から3行目の2byte目 = c0 a8 00 04

IPアドレスは1byteずつ10進数になおして、区切りに.を入れればいいので計算は楽ちん。

  • d2 ad a0 1b = 210 173 160 27 = 210.173.160.27
  • c0 a8 00 04 = 192 168 0 4 = 192.168.0.4

さて、どっちがサーバでどっちがクライアントなのか、だ。

FQDNで答えなくてはいけないので、どうにかしてFQDNを入手できるほうが答えになる。 そうするとグローバルIPアドレスを持っているほうが当然サーバってことになる。

ってことで210.173.160.27を名前解決してみよう。

>nslookup 210.173.160.27 8.8.8.8
サーバー:  google-public-dns-a.google.com
Address:  8.8.8.8

名前:    ntp1.jst.mfeed.ad.jp
Address:  210.173.160.27

ntp1.jst.mfeed.ad.jp は「インターネットマルチフィード時刻情報サービス」の公開しているntpサーバのひとつ。これが回答で間違いないでしょ。

問3の続き問題だったので、あっさり解答できた。

参考情報

8.8.8.8 は高速で有名なgoogleの公開DNSです。 nslookupコマンドは通常はネットワークの設定で指定されたDNSに問い合わせに行くけど、第2引数にIPアドレスやサーバ名を指定すると、そのアドレスに問い合わせに行く。 私の環境では既定のサーバが内部ネットワークのものなので、解法を公開するにあたり公開されているものを明示的に使用してみた。

SECCON 2014 横浜大会 CTF ネットワーク予選 write up 問3

つづいて3問目を解説するよ。同じように03フォルダを開くとquestion.txtがひとつのみ。ひらくとこんな感じ。

このパケットデータのアプリケーションプロトコルは何でしょう?
英字でお答えください。

0000   00 1a a0 89 a3 7f 44 94 fc 7e 1a ba 08 00 45 00  ......D..~....E.
0010   00 4c 00 00 40 00 36 11 11 2c d2 ad a0 1b c0 a8  .L..@.6..,......
0020   00 04 00 7b 00 7b 00 38 6d 96 1c 02 11 e8 00 00  ...{.{.8m.......
0030   06 8b 00 00 02 9e ac 1d 02 32 d7 ad 09 99 d8 db  .........2......
0040   8b 49 d7 ad 0a 44 7a a8 0f 7e d7 ad 0a 46 42 28  .I...Dz..~...FB(
0050   23 a6 d7 ad 0a 46 42 2b 5a b3                    #....FB+Z.

問題の考え方

アプリケーションプロトコルを答えよとのことなので、とりあえず以下を確認する。もしTCP/IPじゃないプロトコルだったりして、これでもわからなかったらほかのところにも手を伸ばすことにしよう。

解法

まず、問題文のパケットデータから得られる情報を最初からみていこう。 最初はイーサネットフレームのヘッダです。ネットワークをかじっている人ならおなじみのMACアドレスとか入ってるとこ。データの先頭から14byte分を見る。

0000   00 1a a0 89 a3 7f 44 94 fc 7e 1a ba 08 00 45 00  ......D..~....E.

プロトコルタイプの部分が 08 00 だったので、上位プロトコルがIPプロトコルであることがわかる。正直ほかのプロトコルだとどの値がどのプロトコルかすらわからないのでたすった。当初の「考え方」の通りすすめて大丈夫そう。

データ上ではイーサネットヘッダに続いてのIPヘッダが出てくる。IPアドレスとか入っているこれもおなじみのところ。さくっとIPヘッダのうちのプロトコル番号の部分を見てみよう。プロトコル番号フィールドはIPヘッダの10byte目なので、イーサネットヘッダの終わりから数えて……ひぃふぅ……2行目の8byteめをみる。

0010   00 4c 00 00 40 00 36 11 11 2c d2 ad a0 1b c0 a8  .L..@.6..,......

ここの値がTCPだと06(10進数で06)、UDPだと11(10進数で17)になる。上のデータだと11になってるのでUDPだってことがわかった。

次はIPヘッダの後ろに続くUDPプロトコルのヘッダをみる。UDPヘッダにはポート番号が書かれているので、これで解答であるアプリケーションプロトコルがわかるわけだけど、ここでちょっと事前調査が必要になる。
UDPヘッダの前にあるIPヘッダの長さは時と場合によって変わるので、どこからがUDPのヘッダなのかを調べなければいけない。
IPヘッダの長さはIPヘッダの最初に書いてあるので確認。1byte目の数字の最初4bitがプロコルバージョンで、次の4bitがヘッダ長となる。

0000   00 1a a0 89 a3 7f 44 94 fc 7e 1a ba 08 00 45 00  ......D..~....E.

みてみると "45" となっているのでプロトコル番号は4(IPv4ってこと)、ヘッダ長は5。ヘッダ長5byte……ではなく、ここにある数字に4byte(ヘッダ長は32bit (=4byte) 区切りで伸び縮みさせるというルールがある)をかけたものが実際のヘッダ長になる。5に4byteをかけて20byteということ。

これでUDPヘッダの開始場所がわかった。イーサネットヘッダ14byteとIPヘッダ20byteを足して34。ということは35byte目からUDPヘッダになる。3行目の3byte目からだね。

0020   00 04 00 7b 00 7b 00 38 6d 96 1c 02 11 e8 00 00  ...{.{.8m.......

最初の2byteが送信先ポート番号、次の2byteが送信元ポート番号。両方とも同じ007bで、これを10進数に直すと123。
123/udpといえば泣く子も黙るNTP。すんなりとけた!

別解

問1で書いたように、問題文のパケットデータ部分をtext2pcapに読み込ませるとものの数秒で回答が得られます。wiresharkってすごいなー(遠い目)。
でもわざわざテキスト形式にして参考書持ち込み可にした運営の意図を考えると、こうやってテキスト上で解いてもらいたかったんじゃないかなーとか思ってみたり。

SECCON 2014 横浜大会 CTF ネットワーク予選 write up 問2

そいでは問2の解説をするよ。 02フォルダの中にquestion.txtとnmaped.pcapというファイルがある。 question.txtを開くとこんな感じ。

問2

開いてるTCPポートを列挙せよ

nmaped.pcap は見たければ下からダウンロードしてね。

問題の考え方

どうやらnmaped.pcapファイルはnmapを実行したネットワークのパケットをキャプチャしたものらしい。pcapファイルはパケットキャプチャファイルとして一般的な形式なので、それ用のアプリケーションで開くことができる。あとは以下の2つをどうにかして求める。

  • 問題の対象となっている「開いているTCPポート」をもつサーバはどれか。
  • 何をもってして「開いているTCPポート」と判定するか。

対象となっているサーバは、nmap実施元がどこかに対して大量のSYNパケットを投げているはずなので、それを探す。 そして「開いているTCPポート」はnmap実施元からのSYNパケット(こんにちは!)に対してSYN ACKパケット(ようこそ!)をお返事しているはず。よって、そのようこそメッセージ(SYN ACKパケット)を抽出してその送信元のポート番号をリストすればいい。

解法

pcapファイルはパケットキャプチャソフトのWiresharkで開くことができる。 開いたら、SYNパケットを投げているnmap実施元を探るために filter: のところに以下を入力する。

tcp.flags.syn==1

f:id:kimtet:20140924002417p:plain

ざっと見て、nmap実施元が 192.168.44.131 で サーバが 192.168.44.133 なんじゃないかなというのがわかる。

次に、192.168.44.133 からのSYN ACKパケットを探すため、フィルタに以下を入力する。

ip.src == 192.168.44.133 && tcp.flags.syn==1 && tcp.flags.ack==1

f:id:kimtet:20140924002418p:plain

ちょっとたくさん出てくるし、重複しているのもあるけれど目grep(人力で抽出作業の意)でどうにかなる量なので、今回はそのまま回答!

最後力技になっちゃったのはちょっと反省。たとえば開いているポートが10000ポートとかあった場合を考えると、何らかの方法で機械的に抽出しないといけないよね。ただ、今回は回答方法が回答用紙にペンで記入だったため、人間が書ける量に制限されてて助かりました。

しかし、回答用紙に回答を記入するハッカーの大会って斬新だったわ。試しに入力して正解かどうか確かめるっていうのができないのが結構プレッシャーでした。

参考情報

SECCON 2014 横浜大会 CTF ネットワーク予選 write up 問1

さっそく問1の解説をするよ。 01フォルダの中にquestion.txtというのがあって、開くとこんな感じ。

問1

Find the Key!

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E.
0010 00 34 f3 ed 00 00 40 01 88 d9 7f 00 00 01 7f 00 .4....@. ........
0020 00 01 08 00 bd c8 18 18 00 00 5a 6d 78 68 5a 33 ........ ..ZmxhZ3
0030 74 7a 5a 57 4e 6a 62 32 35 7a 5a 57 4e 6a 62 32 tzZWNjb2 5zZWNjb2
0040 35 39

問題の考え方

いきなり「キーを探せ!」とか言われて16進数の数字が並んだテキストファイル(上のやつ)がぺろりと渡される。 CTFの問題ってこういう説明不足気味なのがほとんどで、問題から「わかってるよな?」感と「わかってないやつはお断り」感がすさまじい勢いで出てる。

私も初心者なので一瞬面食らったけど、ネットワークの問題というくらいだからきっとネットワークパケットなんだろう。 このデータのどっかに「キー」があるらしいので、それっぽいものを探すことにする。

解法

テキストデータは一般的なバイナリエディタで開いた際の形式で並んでする。 それぞれの位置の数字に意味があるので、一応説明。

  • 一番左側の4けた数字
    「オフセット」と言って、その右に並んでるデータの位置(16進数で何個目か)を表してる。
  • 真ん中の16進数の羅列
    実際にやり取りされているデータ。コンピューターに必要なのはこれだけ。
  • 右側のドットとかアルファベット
    HEX ASCII dumpと言って、真ん中の16進数の羅列のデータを16進数ASCIIコードに割り当てて変換してみたもの。文字にならないところはドットになってる。
    機械的に変換しただけなので、文字になっててもそのまま文字の意味に使われているとは限らない点に注意。

んで、右側のASCII dumpを見てると、データの最後の方がまとまって文字になっていてあやしい。 ネットワークパケットのデータの最初のほうはネットワークの中を通り抜けるためのお決まりの情報(送信元とか送信先とかね)なので、データが入っているとしたら最後のほうになるっていうのもあってここに目をつける。

ZmxhZ3tzZWNjb25zZWNjb2

文字の並びがなんとなくbase64エンコードっぽいので、ダメもとでデコードしてみる。 こういった変換のためにコマンドラインツールnkfを入れていると便利。Windows用のもあるよ。

>echo ZmxhZ3tzZWNjb25zZWNjb2 |nkf -mB
flag{secconsecc

やった!なんか答えっぽい文字列が出た! でもなんか尻切れトンボ……。

そして問題文を見ると、最後の行の2文字分だけASCII dumpがないことに気づく(出題ミス?)。 しかたないので "35" と "39" を16進数ASCIIに変換して追加し、もう一度nkfにかける。

>echo ZmxhZ3tzZWNjb25zZWNjb259 |nkf -mB
flag{secconseccon}

正答は公開されていませんので断言できないけど、今度こそ正解だよね。以上!

参考情報

別解

実は超有名なネットワークパケットキャプチャソフトwiresharkに付いているコマンドラインツール text2pcap を使用すると、今回の問題のようなテキストデータのパケットをpcapファイルに変換してくれる。超便利!(SECCON挑戦時は知らなかった……くやしい)

変換したファイルをwiresharkで開くとICMPパケットだということがわかる。このICMPパケットのDataセクションに上で私があてずっぽうに求めた文字列が格納されているのがまるわかりなので、後は変換するだけ。