はじめに

書籍『セキュリティコンテストチャレンジブック』はCTFで戦うために必要となる情報技術の基本や注意点をわかりやすく解説しています。この連載では2章「pwn」の記事より2.1～2.3節を掲載していきます！ 前回の記事『ステップ1: Pwn とは』はこちら

ステップ2: 下調べ

2.1 ローカルエクスプロイトとリモートエクスプロイト

Pwn の問題にはローカルエクスプロイトとリモートエクスプロイトの2種類の出題方法があります。

■ ローカルエクスプロイト

ローカルエクスプロイト問題では、問題サーバーに対して SSH でログインをして問題を解きます。ログインしたユーザーのままではフラグを読むことはできず、代わりにフラグが入ったテキストファイルを読み出せる権限で動く実行ファイルが設置されているので、その実行ファイルをエクスプロイトしてフラグを読み出すことになります。また、 SSH が利用できるため、問題文で実行ファイルが提供されることはほぼ無く、各種ファイルは SCP などでダウンロードしてから解析することになります。/proc/[pid]/mapsを見てメモリマップを確認したり、遅延が少ないことを利用してレースコンディションを引き起こしたりすることができるため、トリッキーな解き方をする問題が出題されることがあります。

■ リモートエクスプロイト

リモートエクスプロイトの問題は、問題文にnc 192.0.2.10 31337のようなホスト名とポートの組が書かれているのが特徴です。これは、ここに接続すると問題のアプリケーションが待ち受けていますよ、という意味です。また、待ち受けているアプリケーションの実行ファイルは普通は問題文とともに添付されていますから、これを解析することになります。 CTF の Pwn 問題ではよく出る形式ですので、接続等の問題の本質以外の部分で手間取らないように日頃から練習しておきましょう。

■ fork 型

fork 型の問題は、実行ファイル自身がソケット待ち受けを行い、 fork した子プロセスで問題部分の処理を実行します。大きな特徴として、親プロセスが再起動しない限り ASLR や Stack Canaryの値が変化しないということが挙げられます。難しい問題になるとこの特徴を利用して解く場合があるので必ず頭に入れておきましょう。

■ xinetd 型

xinetd 型の問題は標準入出力を使った実行ファイルを xinetd などの別のアプリケーションから呼び出してソケットに接続します。 fork 型の問題とは異なり、接続のたびにサーバー側で実行ファイルを起動するため、毎回 ASLR や Stack Canary は変わってしまいます。 xinetd を使って問題を実行するのは手間がかかるため、よく socat で代用されます。

2.2 実行ファイルのセキュリティ機構の確認

最近のコンパイラには、脆弱性の被害を緩和するためにいくつかのセキュリティ機構を実行ファイルに付加します。これらは問題を解くときに障壁となり得るため、逆アセンブルして脆弱性を探すよりも前に、実行ファイルにどのようなセキュリティ機構が備わっているかを調べておくと問題の見通しが良くなります。

■ RELRO

RELRO はRELocation ReadOnlyを略したもので、メモリ上に配置されるデータのどの部分に対して ReadOnly 属性をつけるかを決定します。No RELROとPartial RELRO(Lazy)とFull RELRO(Now)の3種類が存在し、CTFにおいては問題を解くときにで GOT Overwrite という攻撃を行えるかどうかの判断を行うために使います。checksec.shでは RELRO の項目に状態が表示されます。

$ checksec.sh --dir .
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   ./full
No RELRO        No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   ./norelro
Partial RELRO   No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   ./partial

GOT Overwrite 攻撃が成功するのは No RELRO と Partial RELRO の場合です。Partial RELRO は RELRO 自体は有効になっていますが、共有ライブラリの関数を最初に呼び出した時に関数のアドレスをキャッシュする領域を確保する目的で GOT 領域は書き込み可能になっています。

一方で Full RELRO はプログラムの起動時に共有ライブラリのアドレスをすべてキャッシュした後に GOT 領域を読み込み専用に変更してしまうため、 GOT Overwrite 攻撃を行うことができません。

■ Stack Smash Protection

Stack Smash Protection (SSP) はスタック上でのバッファオーバーフローを防ぐための仕組みです。スタックフレームのローカル変数領域と Saved EBP の間に Canary (カナリア) と呼ばれる値(図)を挿入し、関数の終了時にその値が書き換えられているかどうかを判定することでバッファオーバーフローの検出を行います。もしバッファオーバーフローが発生していた場合にはその場でプログラムを強制終了します。

Canary の値には現在乱数が用いられていますが、メモリ上で先頭が NULL バイトになるような値 (スモールエンディアンでは 0xXXXXXX00) が設定されます。これにはローカル変数に置かれた文字列が NULL バイトで終わっていなかったときに、文字列出力で Canary が流出するのを防ぐ効果があります。

現在多くのコンパイラでこの Stack Smash Protection が有効になっていますが、 gcc では -fno-stack-protector オプションをコンパイル時に指定することで意図的に無効化することができます。

NX bit

NX bit は No eXecute bit を略したもので、Windowsにおいては DEP (Data Execution Prevention) と呼ばれています。メモリ上の実行する必要のないデータを実行不可能に設定することで、攻撃者がシェルコードを使って攻撃するのを困難にします。任意コードの実行が妨げられているため、 NX bit が有効な環境に対して攻撃を行う場合は、実行可能コードの断片をうまく組み合わせて攻撃することになります。

NX bit もこの機能が利用可能な環境では多くのコンパイラで有効になっています。 gcc では -z execstack オプションをコンパイル時に指定することで NX bit を無効にしてコンパイルすることができます。

ASLR

Address Space Layout Randomization (ASLR) はスタックやヒープ、共有ライブラリなどをメモリに配置するときにアドレスの一部をランダム化することで攻撃者がアドレスを推測するのを困難にします。

Ubuntu 14.04 LTS では、次のコマンドで ASLR の ON/OFF を切り替えることができます。

OFF:

  $ sudo sysctl -w kernel.randomize_va_space=0

ON:

  $ sudo sysctl -w kernel.randomize_va_space=2

最近の CTF ではほとんどの問題で ASLR が有効になっています。問題を解くときは ASLR が有効な状態で解く方法を優先して考えるとよいでしょう。ASLR を回避する方法についてはステップ 4 で解説します。

PIE

Position Independent Executable (PIE) は実行コード内のアドレス参照をすべて相対アドレスで行うことで、実行ファイルがメモリ上のどの位置に置かれても正常に実行できるようにコンパイルされた実行ファイルです。よく共有ライブラリに適用されるオプションですが、実行ファイルをメモリにロードする際の位置をランダムに決定できるようになるため、 ASLR では行われない実行ファイルの配置アドレスもランダム化されるようになります。

PIE については本書では紹介程度になってしまいますが、既知のアドレスが全く存在しないため、エクスプロイトの際は基本的にアドレスのリークから攻めることになります。