サイバーセキュリティ＆人工知能研究所

「たのしいバイナリの歩き方」勉強メモ＃３

ソフトウェアの脆弱性はこうして攻撃される

2014/09/05 : CTF

「たのしいバイナリの歩き方」の勉強メモ第３弾です。
実行環境は、Windows7(64bit版)です。

---

VMWare Player
http://www.vmware.com/products/player/

FreeBSD-8.3
http://07c00.com/tmp/FreeBSD_8.3_binbook.zip

Ubuntu-12.04
http://07c00.com/tmp/Ubuntu-12.04_binbook.zip

３．１　バッファオーバーフローを利用して任意のコードが実行される仕組み

ソフトウェアの脆弱性は、「セキュリティホール」と呼ばれる。
最も有名なセキュリティホールの１つが「バッファオーバーフロー(Buffer Overflow)」である。

setuid：実行ユーザーではなく、そのプログラムの所有者の権限でプログラムを動作させる仕組み

アクセス権の「s」が、setuid が有効になっているプログラムであることを意味する(例：/usr/bin/passwd)。

スタックとは、「筒や積み上げられる皿のような使われ方をするメモリ空間」。
スタックは、メモリアドレスの低位(減算方向)に向かって成長する。
push を実行し続ければ、その分だけ、メモリの低位に向かって値が格納されていく。

情報工学的には、
スタックをLIFO( Last In, First Out )、
キューのような最初に push したものを最初に pop するものを FIFO( First In, First Out )
と呼ぶ。


gcc で「-S」オプションをつけてコンパイルすると、アセンブラになった「.s」ファイルができる。

Ｃ言語において引数に渡しているデータが、アセンブラでは func が call される前にスタックへ格納される。
スタックに引数を格納し、call でサブルーチンを呼び出す。
call は jmp と違い、自分が呼び出されたアドレスを覚えておかなければならないため、サブルーチンへジャンプする前に、戻るべきリターンアドレスをスタックへ push する。

リターンアドレスは、処理が終了したあと、main へ戻るためのアドレスが格納されている。
これが上書きされると、攻撃者はあらゆる場所へ処理をジャンプさせることができる。
攻撃者が用意したコードに飛べるとしたら、それは「任意のコードが実行できる脆弱性」となる。

gdb は、UNIX 系 OS における有用なデバッガ(コマンドラインツール)。

主要コマンド

コマンド名	説明
r	プログラムを実行する(そのまま引数も渡せる)
b	ブレイクポイントをセットする(＊をつけてアドレスを渡す)
c	ブレイクポイントで止まった後、そのまま処理を実行させる
x/[数字]i	任意の命令数だけ、逆アセンブルする
disas	同上
x/[数字]s	任意の数だけ、データを表示する ※引数には、アドレスもレジスタも渡せる ※レジスタを渡す場合は、＄をつける
i　r	レジスタの値を表示する
set	レジスタうあメモリへ値を書き込む
q	デバッガを終了する

gdb でプログラムをデバッグする２つの方法
①プログラムのパスを gdb の引数に渡して起動する
(例)gdb test00
②gdb を起動してからプロセスをアタッチする
(例)(gdb)attach 1234

攻撃者が実行したいコードのことを、shellcode と呼ぶ。
基本的に、/bin/sh が起動できれば何でもできるため、これを起動するための最小のマシン語のことを指したりもする。

gcc でコンパイルするときに、static オプションを指定すると、execve(関数)本体も実行ファイルにリンクされる。

gdb で execve を逆アセンブルすると、「int $0x80」が呼び出されていることがわかる。
int $0x80 は、システムコール呼び出し。

usr/include/sys/syscall.h に、カーネルがそれぞれのシステムコールを識別するためのシステムコール番号の一覧がある。
execve のシステムコール番号は「59(16進数で0x3b)」。

Linux 環境では、/usr/src/linux/include/asm/unistd.h にシステムコール番号の一覧がある。
execve のシステムコール番号は「11(16進数で0x0b)」。

このように、
・システムコール番号は環境によって異なる
・shellcode は OS によって異なる
→環境に応じて作る必要がある。

shellcode に (マシン語における)0x00 が使われていると、strcpy が 0x00 を終端として認識するため、shellcode 全体をプログラムにコピーできない。
　↓
[解決策]
①/bin/sh を、/bin//sh という８バイトの文字列にする
　→コマンドを実行するにあたって、スラッシュは複数あっても問題ない。
②その前に、push $0 をしておく
　→終端文字 0x00 を、xor と push を併用してスタックに積んでおく。

通常は、shellcode がターゲットプロセスのどのアドレスにあるかわからないので、推測しなければならない。
メモリを可能な限り NOP(0x90) で埋めて、最後に shellcode を置き、shellcode が実行される確率(成功率)を上げる。

近年はデフォルトでさまざまなセキュリティ機能がオンになっており、このような典型的なバッファオーバーフローはブロックされるようになっている。

コラム：printf 系関数に起因するフォーマットストリングバグ

printf 系関数に起因するフォーマットストリングバグ(format string bug)
→printf 系関数には、引数に渡されたポインタへデータサイズを書き込む変換指定文字があり、これを利用することで、任意のアドレスへ任意の値を書き込める。

３．２　攻撃を防ぐ技術

ASLR(Address Space Layout Randomization)
スタックや各モジュール、動的に確保したメモリなどのアドレス(配置先)をランダムに決定する仕組み
/proc/sys/kernel/randomize_va_space で設定を確認／変更できる。
０：無効
１：ヒープ以外をランダム化
２：すべてランダム化(デフォルト)

Exec-Shield
メモリ領域の読み書き実行権限を制限する仕組み

スタックとして使用されているメモリ領域に実行すべきマシン語が置かれることは、通常ありえないので、スタック領域は、読み書きのみを許可して、実行を不可にするのが一般的。
コードセンクションにはマシン語が置かれているが、そのマシン語を書き換える必要は一般的なソフトウェアではまずないので、そのメモリ領域は書き込み不可にする。
仮にスタックに shellcode をコピーできても、それが実行できなければ、Segmentation fault でプログラムは終了する。

任意のプログラム内のメモリ領域の読み書き実行権限を確認するには、プログラムを実行した状態で、/proc/<PID>/maps を出力する(<PID> は、ps コマンドで確認する)。

StackGuard
コンパイル時に、各関数の入口と出口にスタックが破壊されたことを検知するマシン語を挿入する(コンパイラの機能)。
ebp や ret_addr を守るための仕組みで、典型的なスタックバッファオーバーフローに対する防御手法。

３．３　セキュリティ機能を迂回する技術

Return-into-libc
Exec-Shield の攻略法として考えられた、shellcode の代わりにライブラリ(libc)を利用する攻撃手法。
「(Exec-Shield 等のセキュリティ機能のせいで)任意のコード(shellcode)を実行できなくとも、最終的に任意のプログラムを実行できれば権限を奪える」
　↓
「うまく引数を設定し、スタックを調整して、libc.so の中にある system 関数や exec 系関数へジャンプさせれば、/bin/sh などのプログラムを実行できる」

ldd コマンドを使うと、プログラムが実行時にロードするライブラリを確認できる。

libc.so は、ほとんどのプログラムで実行時にロードされるか、コンパイル時に静的にリンクされているため、libc の中にある system 関数や exec 系関数をうまく呼び出せれば、権限を奪える。

ASLR によってロードされるモジュール群のアドレスが実行ごとにランダム化されていると、system や exec のアドレスがわからないために、攻撃は失敗する。

ROP(Return-Oriented-Programming)
「ランダム化されていないモジュール内にあるアセンブラコードを使って、うまく実行させたい処理をつなぎ合わせられないだろうか？」
詳細は、５章で。

コラム：セキュリティがいたちごっこになる理由

セキュリティにおいては、必ず明確な「敵」が存在する。
米国や韓国では「サイバー戦争」という言葉が一般的で、軍事や国防とセットで語られたりする。

---

記述に際しては、細心の注意をしたつもりですが、間違いやご指摘がありましたら、こちらからお知らせいただけると幸いです。

←「たのしいバイナリの歩き方」勉強メモ＃４
←「たのしいバイナリの歩き方」勉強メモ＃２


«　戻る