IoT診断とファジング

こんにちは。ねこやなぎです。

今回は有名なファジングツールである Peach Fuzzer Professionalの大部分がオープンソース化されたことについてふれたのち、組み込み機器にファジングを行うときの課題についてお話しします。

 ファジングとは

ファジングとは、テスト対象に未知の脆弱性が含まれていないかを検出するためのテスト手法で、問題が起こりそうなデータを大量に対象へ送信し、異常な動作が発生しないかを確認します。

 GitLab Protocol Fuzzer Community Editionを試す

今年3月、GitLabはブラックボックスファザー ¹ として有名なPeach Fuzzer Professional（有償版）の大部分をオープンソースにして、「GitLab Protocol Fuzzer Community Edition」として公開することを発表 ² しました。

無料版にはなかったWeb UI

以前からPeachの無料版であるCommunity Editionが公開されていたのですが、ドキュメントがお世辞でも十分とは言えない量しか公開されておらず、機能を拡張するのにも一苦労でした。しかし、新しくGitLabから公開されたバージョンは、豊富なドキュメントとサンプルが用意されているだけではなく、新しいバージョンのPeachをベースにしているためにWeb UIが実装されていたり、対応するプロトコルが拡充されたりと機能も充実しました。

インストール時の手順が厄介なこと、（筆者の環境では）Web UIのいくつかのページは機能しなかったことなど、いくつか改善を望む点はありますが、その点を差し引いても歓迎すべき変更です。

また、ファズデータを生成するために最も重要なPitsと呼ばれる定義ファイルは公開されておらず、今年中にGitLab Ultimateのサービスの一環として提供されるとのことです。そのため、ファジングを開始するためには従来どおりPitsを作成する必要がありますが、Github等で有志が開発したPitsが公開されていますし、そこまで気にする必要はありません。

 Gitlab Ultimate のセキュリティテスト

Pitsを含めたファザーが将来統合される予定のGitLabでは、現在複数のセキュリティテストツールが組み込まれています。こちら のページに一覧が記載されていますが、以下のようなツールが含まれます。

• ソースコードの静的解析による脆弱性診断
• 依存関係のあるモジュールに既知の脆弱性がないかを検索する機能
• グレーボックスファジング

AFLなどのツールを用いたグレーボックスファジングはすでに利用できる状態ですが、将来的に前述のブラックボックスファザーを追加して利用できる選択肢を増やすということのようです。

これらのセキュリティテストツールによる診断をCI/CDパイプラインに組み込むことによって、ソースコードに変更がなされたときに自動でセキュリティテストが行われるため、脆弱性の早期発見と修正コストの削減ができるようになります。このような取り組みはMicrosoftやGoogleをはじめとして多くの企業で行われており、成果をあげています。また、WindowsやLinuxなどの汎用OSでは脆弱性の原因となるメモリ破壊やメモリアクセス違反を検知するためのツール群 (例: Address Sanitizer) を利用できるために効果的なテストを行えます。ただし、ファジングはテストケースがすべてパスすれば合格する通常のテストと異なり、ある意味で終わりがないテストですので、実行時間をあまり短くしてしまうと十分な効果が得られないことに注意する必要があります。

セキュリティテストツールが検出した脆弱性の確認画面

 組み込みシステムに対するファジングの課題

一方、組み込みシステムの場合、OSにリアルタイムOS（RTOS）が採用されることが多く、アーキテクチャも様々、メモリや処理能力にも制限があることから、Linuxで使われている既存のSanitizerなどをそのまま再利用することは難しく、現時点では一部のコンパイラやRTOSでの対応にとどまっています。これらのモニターと呼ばれるテスト対象で異常が発生したかを検知する仕組みはファジングにおいて非常に重要で、例えば組み込み機器に対するファジングの有効性を評価した論文³では、Sanitizerの支援なしでシステムがクラッシュしたかのみを監視（死活監視）するだけでは、表面化しない異常の多くを検出できていないことが示されています。また、エミュレーションによってSanitizerと同等の機能を実現する方法もありますが、機器が搭載しているSoCのエミュレータを用意し、ペリフェラルのエミュレーションをする必要があります。

弊社のような情報セキュリティ企業が組み込みシステムにペネトレーションテストを実施する場合、必ずしも診断対象となる機器のファームウェアやソースコードが入手でき、機器のデバッグポートが有効になっているとは限りません。ファームウェアすら入手できないケースでは、グレーボックス・ホワイトボックスファジングを適用することは困難です。その時はブラックボックスファジングのみを使用することになります。

ファームウェアすら手に入らない状況であっても、機器と連携するスマートフォンアプリの解析によって効果的なファジングを行おうとする手法⁴も存在します。実際に弊社で行っているIoTデバイスペネトレーションテストでは、ファームウェアの解析とともに、スマートフォンアプリのリバースエンジニアリングや動的解析によって得られた情報をもとにして攻撃を行い成功することも多く、こいったアイディアはとても有効な手段であると考えます。

 ファジングをしていればペネトレーションテストは必要ない？

ファジングは未知の脆弱性を多数発見する優れた手法であるから、それさえクリアすればペネトレーションテストは必要ないと思われる方もいらっしゃるかもしれませんが、そうではありません。現在のファジングツールが検出するのは主にメモリ破壊やメモリアクセス違反などの脆弱性ですが、ペネトレーションテストではそれ以外にも、本来は設計段階で発見すべき脆弱性や、ファジングでは発見できない実装上の脆弱性も含めてファームウェアのリバースエンジニアリングやハードウェアからの攻撃を行い調査します。そのため、ファジングはペネトレーションテストにおける有効な調査手法の1つとも考えることができ、結論としては、どちらも必要だと考えます。

市販のファジングツールを使用している場合（特にブラックボックスファザー）、対応するプロトコルリストに調査したいプロトコルが載っているからと言って十分なテストができているとは限りません。たとえばBluetoothのL2CAPなど標準化されている通信に対するファジングができたとしても、アプリケーションレベルの通信に独自のプロトコルを用いていれば、自分で定義ファイルを追加して別途実施する必要があります。

テスト対象となる機器の開発を外部の業者に委託しているために実装の詳細を知らない場合、リバースエンジニアリングをして独自の通信プロトコルの仕様を調べなければ有効なファジングを実施できないケースもあります。

 おわりに

今日では、組み込みシステムに関するセキュリティ意識の高まりから、セキュアなシステムを作るためのガイドラインや国際標準が自動車、医療、家電など様々な分野で整備されています。このような流れにのり、組み込み機器に対するファジングの課題も、ツールの拡充や、RTOSの対応などで将来的に解決していくと思われます。また、自動推論ツールによる安全性の検証など、より高度な取り組みも行われていますので、今後もこれらの分野での研究について調査して行きたいと思います。

 参考文献

---

1. テスト中におけるテスト対象の内部状態、ソースコード、ファームウェアなどの情報を、テストデータの生成に利用しないファジングツールのこと↩

2. We’re open sourcing Protocol Fuzzer Community Edition! - GitLab https://about.gitlab.com/blog/2021/03/23/gitlab-open-sources-protocol-fuzz-test-engine/↩

3. Marius Muench, Jan Stijohann, “What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices,”, in Network and Distributed System Security Symposium (NDSS), 2018. https://www.eurecom.fr/publication/5417/download/sec-publi-5417.pdf↩

4. N. Redini, et al., “DIANE: Identifying Fuzzing Triggers in Apps to Generate Under-constrained Inputs for IoT Devices,” in 2021 2021 IEEE Symposium on Security and Privacy (SP), 2021. https://conand.me/publications/redini-diane-2021.pdf↩