ファジング
ファジングとは、ソフトウェアの不具合(とくに脆弱性を意図することが多い)を発見するためのテスト手法の一つである。ファズ(英:fuzz)(予測不可能な入力データ)を与えることで意図的に例外を発生させ、その例外の挙動を確認するという方法を用いる。ファズテストと呼ばれることもある。
目次 |
概要[編集]
ファジングは、自動化あるいは半自動化されたブラックボックステストないしはグレーボックステストに分類される。ブラックボックステストとして使うこともあるが、リバースエンジニアリングによってどのような機能を持っているか(ネットワークアプリケーションであれば、どのライブラリのどのAPIを呼び出しているか、など)を特定することで入力機能に関する情報が得られるため、このようにして得られた情報を付随してグレーボックステストとして行なわれることもある。また、自動化はファジングの本質の一つである。従来はセキュリティの専門家によって手動で経験と感性に頼ってテストを行なっていたところを、自動化を図ることによって発展してきた経緯がある。但し、入力データの決定方法という要素では半自動化を選択する場合もあり、一部の分野(ファイル形式のファジングなど)では手動ファジングがなおも効果的な場合もあるとする専門家もいるという。
用語[編集]
- ファズ(英:fuzz)
- ファジングにおける「予測不可能な入力データ」を指す。
- ファズツール、ファザー(英:fuzzer)
- ファジングを行なうために「予測不可能な入力データ(ファズ)を与える」ための自動化あるいは半自動化されたツールを指す。
歴史[編集]
ファジングの歴史は、1989年にさかのぼると言われている。Barton Millerがウィスコンシン大学での講義において作成した、UNIXアプリケーションの脆弱性テストに作成したツールが、ファズツールの原始的なものである。また、1995年には再度テストが行なわれ、このときには様々なUNIXアプリケーションに対して脆弱性が発見されている。この時点ではまだ用いられているテスト内容も単に「クラッシュするか否か」「ハングするか否か」レベルのものであり、ファジングという用語も概念も登場する前のことであったが、これらのことを行なったBarton Millerは「ファジングの父」と呼ばれている。
ファジングに対してより体系だったものは、オウル大学でのPROTOSプロジェクトであるといわれる。PROTOSテストスイート開発は1999年に始まり、2002年には同プロジェクトのメンバーによって商用ファズツールの設計開発会社Codenomiconが設立、2005年には商用ファズツール[1]がリリースされている
また、2002年はDave Aitelによって作成されたオープンソースのファズツールフレームワークSPIKE[2]およびそれを使ったファズツールsharefuzz[3]などが登場する時期でもある。これ以降、Webブラウザを対象としたファジング(mangleme、CSSDIEなど)、ファイル形式を対象としたファジング(FileFuzz、SPIKEfileなど)、ハードウェアファジング機器(Mu Security)、ActiveXを対象としたファジング(AxMan)など、特定分野における様々なファズツールが作られることとなった。
2005年にはファジング専門のメーリングリストが作成されるなど、セキュリティ研究家の中でも取り上げられる存在となった。
フェーズ[編集]
ファジングにおいては、一般的に以下のフェーズを適用する。
- ターゲットに関する情報の入手(同社の過去製品の脆弱性調査、リバースエンジニアリングなども含まれる)
- ターゲットアプリケーションの中に含まれる、ファジングでテストされるべき機能の特定
- ファズデータの生成
- ファズデータの投入
- 例外発生の監視
- 攻撃可能性の判定(例外が発生した場合の、攻撃への発展可能性の検証)
ファズデータの生成方法[編集]
ファズツールは、ファズデータの生成方法によって以下の様に大きく分類される。
- テストケースの事前生成
- 初期のツール、PROTOSなどが用いていた方法である。ターゲットがもつ機能から、その入力対象となるデータのうち、問題を生じる可能性が高いもの(0、1、その他境界値周辺の値など)を事前に生成しておく。テストデータの範囲内だけでテスト可能であるという欠点をもつ。
- ランダム
- 問題を特定するのにはあまり効果的でないが、最低品質を満たしていることを容易に確認する目的として有用な方法である。
- 手動
- ファイル形式のファジングなど、特定分野においては有用とする専門家の意見もある。
- 突然変異、ブルートフォース
- 入力データを連続的に変化させてテストする方法。突然変異は指定値からの変動であり、ブルートフォースは総当たりの範囲で網羅的に、入力データを連続的に変化させる。テストに時間がかかるという欠点がある。
- 自動プロトコル生成
- 入力データのプロトコル仕様から、静的に決定する部分と動的に決定する部分を切り分け、動的部分に対して変動の自動化を図る手法。静的部分と動的部分が記された定義ファイルの作成を必要とし、その作成を行なうセキュリティ担当者の力量に依存するところが大きい。
ファジングの種類[編集]
- コマンドラインのファジング
- 環境変数のファジング
- ファイル形式のファジング(不正なjpegファイルを読み込ませても大丈夫か[4]、といった類のファジング)
- Webブラウザのファジング(アプリケーションが広範に用いられている事情から、この分野に特化したツールも多く登場している)
- ネットワークプロトコルのファジング
- Webアプリケーション(サーバー側)のファジング
限界[編集]
ファジングはセキュリティにおける万能薬ではない。以下のようなものはファジングでは問題を見つけることができない。
- アクセス制御の欠陥
- 粗悪な設計ロジック(リバースエンジニアリングの段階で見つかる可能性はあるが、それはファジング自体によるものではない)
- バックドアの検出(ファジングツールでは、本来の動作との見分けはつかない)
- メモリ破壊(スタックの書き換え等による権限昇格など)
- 複数の脆弱性の合わせ技
また、テスト終了条件、つまりどれだけの入力データを投入すれば充分にテストされたといえるかといった点や、コード網羅率を現状よりも高めるにはどのような入力値を与えればよいのかといった点が判断しづらいという問題もある。
脚注[編集]
- ^ “Codenomicon Products”. 2009年2月15日閲覧。
- ^ “The Advantages of Block-Based Protocol Analysis for Security Testing”. 2009年2月15日閲覧。
- ^ “Sharefuzz”. 2009年2月15日閲覧。
- ^ “JPEG 処理 (GDI+) のバッファ オーバーランにより、コードが実行される (833987) (MS04-028)”. 2009年2月15日閲覧。
関連項目[編集]
参考文献[編集]
- Michael Sutton, Adam Greene, Pedram Amini 『ファジング ブルートフォースによる脆弱性発見手法』 園田道夫(監訳)、伊藤裕之(訳)、毎日コミュニケーションズ、2008年6月6日(原著2007年)、初版(日本語)。ISBN 978-4839926298。
外部リンク[編集]
- Barton Miller(ファジングの父). “Fuzz Testing of Application Reliability”. 2009年2月15日閲覧。
- IATAC. “Look out! It's fuzz (PDF)”. 2009年2月15日閲覧。