CTF for ビギナーズ 2016 東京 Write-up

Forensics 300（盗まれたデータはどれ？）

はじめに

この問題はたしか正解者が１名しかいなかったと思うのですが、復習をかねて演習後の解説を思いだしながら解きなおしてみました。

問題は以下のようなものでした。

データベースからデータが窃取され、実行犯の所持していたディスクイメージが押収された。被害に遭ったサーバーで取得していたパケットファイルをもとに、窃取されたファイルを特定して FLAG を入手せよ。

添付ファイル：for3.zip

要は「for3.zip の中から FLAG を探せ」というのが課題のようです。

ファイル内容の確認

まず unzip コマンドで for3.zip を解凍したところ、二つのファイルが出てきました。

unzip

ctf4b@ctf4b-vm:~/2016-10-22/for3$ unzip for3.zip
Archive:  for3.zip
  inflating: for3.bin
  inflating: for3.pcap

ctf4b@ctf4b-vm:~/2016-10-22/for3$ ls -l
合計 65612
-rw-r--r-- 1 ctf4b ctf4b 67108864 10月 21 14:50 for3.bin
-rw-r--r-- 1 ctf4b ctf4b      494 10月 21 14:50 for3.pcap
-rw-r--r-- 1 ctf4b ctf4b    71533 10月 22 17:07 for3.zip

どうやら「押収されたディスクイメージ」が for3.bin で、「被害に遭ったサーバーで取得していたパケットファイル」が for3.pcap のようです。

念のため for3.bin がディスクイメージかどうかも確認しておきます。

file

ctf4b@ctf4b-vm:~/2016-10-22/for3$ file for3.bin
for3.bin: DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x0,32,33), end-CHS (0x8,40,32), startsector 2048, 129024 sectors, extended partition table (last)

for3.bin の中身を表示してみると、 SQLite 3 形式のデータファイルが全部で 10 ファイルありました。

binwalk

ctf4b@ctf4b-vm:~/2016-10-22/for3$ binwalk for3.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
1048576       0x100000        Linux EXT filesystem, rev 1.0, ext2 filesystem data, UUID=1e560c56-9ced-44e1-a5b0-e1ef43864386
9437184       0x900000        Linux EXT filesystem, rev 1.0, ext2 filesystem data (mounted or unclean), UUID=1e560c56-9ced-44e1-a5b0-e1ef43864386
9962496       0x980400        SQLite 3.x database,
9970688       0x982400        SQLite 3.x database,
9978880       0x984400        SQLite 3.x database,
9987072       0x986400        SQLite 3.x database,
9995264       0x988400        SQLite 3.x database,
10003456      0x98A400        SQLite 3.x database,
10011648      0x98C400        SQLite 3.x database,
10019840      0x98E400        SQLite 3.x database,
10028032      0x990400        SQLite 3.x database,
10036224      0x992400        SQLite 3.x database,
26214400      0x1900000       Linux EXT filesystem, rev 1.0, ext2 filesystem data (mounted or unclean), UUID=1e560c56-9ced-44e1-a5b0-e1ef43864386
42991616      0x2900000       Linux EXT filesystem, rev 1.0, ext2 filesystem data (mounted or unclean), UUID=1e560c56-9ced-44e1-a5b0-e1ef43864386
59768832      0x3900000       Linux EXT filesystem, rev 1.0, ext2 filesystem data (mounted or unclean), UUID=1e560c56-9ced-44e1-a5b0-e1ef43864386

データファイルの抽出

続いて、ディスクイメージに含まれるファイルを抽出してみます。その際、先ほどの file コマンドの実行結果をもとに、 fls コマンドの -o オプションにファイルシステムの開始位置（startsector 2048）を指定しました。

fls

ctf4b@ctf4b-vm:~/2016-10-22/for3$ fls -o 2048 -r for3.bin
d/d 11: lost+found
d/d 2017:       ...
+ r/r 2018:     database_1.db
+ r/r 2019:     database_5.db
+ r/r 2020:     database_3.db
+ r/r 2021:     database_8.db
+ r/r 2022:     database_10.db
+ r/r 2023:     database_9.db
+ r/r 2024:     database_4.db
+ r/r 2025:     database_7.db
+ r/r 2026:     database_2.db
+ r/r 2027:     database_6.db
d/d 16129:      $OrphanFiles

実行結果から lost+found ディレクトリ（fsck コマンドを実行した際、破損したファイルの断片が格納される場所）の中に複数のデータファイルがあり、それらのファイル名と i-node 番号がわかりました。

先ほどのファイルシステムの開始位置と i-node 番号を指定し、データファイルを抽出します。

icat

ctf4b@ctf4b-vm:~/2016-10-22/for3$ icat -o 2048 -r for3.bin 2018 > database_1.db
ctf4b@ctf4b-vm:~/2016-10-22/for3$ icat -o 2048 -r for3.bin 2019 > database_5.db
ctf4b@ctf4b-vm:~/2016-10-22/for3$ icat -o 2048 -r for3.bin 2020 > database_3.db
... 省略 ...
ctf4b@ctf4b-vm:~/2016-10-22/for3$ icat -o 2048 -r for3.bin 2025 > database_7.db
ctf4b@ctf4b-vm:~/2016-10-22/for3$ icat -o 2048 -r for3.bin 2026 > database_2.db
ctf4b@ctf4b-vm:~/2016-10-22/for3$ icat -o 2048 -r for3.bin 2027 > database_6.db

念のため database_*.db がデータファイルかどうかを確認しておきます。

file

ctf4b@ctf4b-vm:~/2016-10-22/for3$ file database_*.db
database_1.db:  SQLite 3.x database
... 省略 ...
database_6.db:  SQLite 3.x database

データファイルの調査

抽出したデータファイルを使用してスキーマを表示し、どのような表名や列名があるか確認しておきます。

sqlite3

ctf4b@ctf4b-vm:~/2016-10-22/for3$ for f in ./database_*.db; do sqlite3 $f '.schema'; done
CREATE TABLE flag(id integer primary key, flag varchar(50));
... 省略 ...
CREATE TABLE flag(id integer primary key, flag varchar(50));

どのデータファイルも flag 表しか格納しておらず、 flag 表には flag 列しか作成されていないようです。

flag 表の flag 列には同一の値が複数格納されているため、重複を除外しながら Base64 形式で符号化された文字列をデコードしていきます。

base64

ctf4b@ctf4b-vm:~/2016-10-22/for3$ for f in ./database_*.db; do sqlite3 $f 'select flag from flag;'; done | sort | uniq | base64 -d
ctf4b{DUMMY}
ctf4b{dummy}
ctf4b{dummydummydummy}
ctf4b{dummydummy}
ctf4b{flag_janai_YO}
ctf4b{kore_ha_dummy}
ctf4b{kore_ha_flag_janai}
ctf4b{m4c71m3l1n3}ctf4b{}

最終行のみ若干表示がおかしくなっていますが、この「ctf4b{m4c71m3l1n3}」の部分が FLAG に相当します。

おわりに

今回、パケットファイル（for3.pcap）は使用しませんでしたが、解説していただいた方によれば、本来は Wireshark などで Pcap 形式のファイルを表示し、データを窃取したと思われる時間帯を絞りこんで mactime コマンドで生成したタイムラインと比較していく必要があるのだそうです。

FLAG に含まれる「m4c71m3l1n3」という文字列は「mactimeline」を Leet で表記したものですが、問題を作成した方のそうした意図が込められているように感じました。