namdicul's blog

気ままに更新します. CTFと暗号理論について勉強中です.

CTF ネットワーク問題の基本問題(1)

CTFの勉強をサボりすぎていたのでそろそろ勉強を再開しようと思います.

今回はネットワーク問題に焦点を絞って, 学んだことを書いていきたいと思います.

以下のCTFビギナーズで使用された練習問題を元に勉強をしていきます.
https://onedrive.live.com/?authkey=%21ANE0wqC_trouhy0&id=5EC2715BAF0C5F2B%2110056&cid=5EC2715BAF0C5F2B

www.slideshare.net

sample.pcap

まずはWiresharkでパケット情報を見てみましょう.

f:id:tomonori4565:20181019003335p:plain

以上のようになっています. HTTPやTCPプロトコルが使われていることや, 「GET /ctf_web/login/index.php HTTP/1.1\r\n」というな記述が散見されることから, どうやら端末とwebサーバーとのやりとりが記述されているようです.

http通信について詳しくみていきましょう.

display filterのウィンドウに「http」と入力し, http通信のみを閲覧できる状態にします.

f:id:tomonori4565:20181019140534p:plain

Info. に「HTTP/1.1 200 OK」と書かれていますが, これはリクエストを正しく受理したことを表します. 私たちがいつもPCやスマホでウェブサイトを閲覧できている際の多くがこの番号を受信している状態です.

ただ注意しておきたいことがあって, ログインするときにログインに失敗してしまった時も「HTTP/1.1 200 OK」というステータスコードが返されます.

sample.pcapにおける大部分の通信での「HTTP/1.1 200 OK」は, 後者に当たります.

しかし, 違うステータスコードが返されているものも存在します.
f:id:tomonori4565:20181019141023p:plain

「HTTP/1.1 302 Found」というステータスコードは, リダイレクション処理が行われていることを指します.

CTFでネットワーク問題を解くときは, 他のものとは違う通信を重点的に分析する必要があるので, この通信を分析してみましょう.
TCPストリーム」という機能を使用して, データを見ていきましょう. すると, この通信の流れを一覧として閲覧することができます.

f:id:tomonori4565:20181019141923p:plain

このような画面が出てくると思います. 赤文字は端末が送信したパケット, 青文字は端末が受信したパケットをさします. このストリームでは, データの送受信を4往復していることがわかりますね(赤文字と青文字のやりとりが4回実行されているため).

ここで一旦元の画面に戻ってみましょう.

f:id:tomonori4565:20181019143313p:plain

display filterのウィンドウに「tcp.stream eq 7」と入力されていることがわかります. 先ほど選択したストリームのパケットが順に並んでいますね. ここでもGETやPOSTなどのアクションと, ステータスコードのやりとりが4往復されていることが確認できます.

再度, TCPストリーム画面に戻ってみましょう. 中盤にこのような記述があるかと思います.

f:id:tomonori4565:20181019142845p:plain

「FLAG is this accout password」と書かれていますね. なので, FLAGはこのアカウントのパスワードであることがわかります.

ではパスワードはどこに存在するか. それは, ログイン時にPOSTしたパケットの中に存在します.

f:id:tomonori4565:20181019143104p:plain

画面下部に「Form item: "password" = "c2bd8772532521ef2e127c020503f09f"」とありますね. これがアカウントのパスワードなのです.


従って答えは「c2bd8772532521ef2e127c020503f09f」となります.

sample2.pcap

wiresharkでパケットを見てみましょう. 今回は, ARPプロトコルやICMPプロトコルが散見されます.

ARPプロトコルは, IPアドレスから物理層のネットワーク・アドレス(MACアドレス)を求めるために利用されるプロトコルのことで, ICMPプロトコルTCP/IPが動作するために必要な、補助的な役割を果たすためのプロトコルです.


まず一番最初に, arpプロトコルを使ってMACアドレスを求め, その後にpingコマンドを使ってやりとりをしているようです. 途中で, TCPパケットがあるので, 前回同様「TCPストリーム」を追跡してみましょう.

f:id:tomonori4565:20181019144642p:plain

f:id:tomonori4565:20181019144713p:plain

なんと, そのままflagを発見することができました.


sample3.pcap

sample3.pcapはパケット数が9268もあって, 一つ一つを確認していくのは無理そうです. こういうときは,

  1. パケットの統計を見る
  2. 暗号化されていないプロトコルの分析
  3. 特定のポート・アドレスの通信を分析

を実行していきましょう.

パケットの統計を見る

「統計 > 対話」を選択すると, パケットの統計を一覧で確認することができます. ここで異常なデータ量の通信が行われている場合は, 作問者がわざとデータを発生させたんじゃないかと疑いましょう.

f:id:tomonori4565:20181019150232p:plain

暗号化されていないプロトコルの分析

「統計 > プロトコル階層」で, どのようなプロトコルが使用されているかを確認しましょう.

f:id:tomonori4565:20181019150415p:plain

また, 暗号化されていないパケットを重点的に分析しましょう. 具体的には, http, telnet, smtp, ftpなどが挙げられます.

まずftpパケットの分析をしてみましょう.

display filterのウィンドウに「ftp-data」と入力してみましょう(ftp-dataでデータのやりとりをチェックできます).

f:id:tomonori4565:20181019150731p:plain

データ量が大きいパケットを「TCPストリーム」で追跡しましょう.

f:id:tomonori4565:20181019150818p:plain

よってこのデータは「png」ファイルであることがわかりますね. 「save as」でデータを保存してチェックしてみましょう(Raw(無加工)形式で)保存.

すると,
f:id:tomonori4565:20181019150957p:plain
というflagをゲットすることができます.



続いて, smtpパケットを分析してみましょう.

smtpパケットの「Info」部分が「C: DATA」になっているものをチェックしていきましょう.

f:id:tomonori4565:20181019151525p:plain

f:id:tomonori4565:20181019151610p:plain

f:id:tomonori4565:20181019151613p:plain

するとメールの本文らしきものが見えましたね. 本文に書かれている通り, デコードして見るとflagをゲットすることができます.


特定のポート・アドレスの通信を分析

httpでは一般的に80番ポートが使用されているのですが, 今回は8080番ポートが使用されているところがあります. このように, 特定ポートで通信している場合は怪しいと疑いましょう.

f:id:tomonori4565:20181019152034p:plain

検証部分でflagが見えていますね.


終わりに

今回はメモ書きのように解説してしまいました...

まだまだ僕もCTF勉強中なので, 今後も頑張っていきたいと思いました.