ファジングテストがIoTデバイスのセキュリティをどのように強化するか

ファジングテストは、組み込みデバイスの弱点を見つけるためにエンジニアが利用できる重要な場所であり、IoTデバイスインターフェイスを強化するために検討する必要があります。

IoTデバイスの急増に伴い、組み込みセキュリティ攻撃が増加しています。歴史的に、組み込みシステムエンジニアは、バグに対して脆弱な組み込みデバイスの多くの領域にもかかわらず、デバイス層のセキュリティを無視してきました。シリアルポート、無線インターフェイス、さらにはプログラミング/デバッグインターフェイスでさえ、ハッカーによって悪用される可能性があります。ファジングテストは、組み込みデバイスの弱点を見つけるためにエンジニアが利用できる重要な場所であり、IoTデバイスインターフェイスを強化するために検討する必要があります。

ファジングテストとは何ですか？

ファジングテストは、シェイクスピアを書くためにランダムに入力する神話上の百万匹のサルのようなものです。実際には、フィクションの作品は、単純なフレーズを生成するために多くのランダムな組み合わせを必要としますが、組み込みシステムの場合、既知の適切な文から数文字を変更する必要があります。

ファズ攻撃を実装するために、多数の商用およびオープンソースツールが利用可能です。これらのツールは、ファズベクトルまたは攻撃ベクトルとも呼ばれるランダムバイトの文字列を生成し、それらをテスト対象のインターフェースに送信して、バグを示す可能性のある結果の動作を追跡します。

ファズテストはナンバーゲームですが、可能な入力を無限に試すことはできません。代わりに、ファズベクトルの送信率、ファズベクトルの有効性、およびバグ検出アルゴリズムを最大化することにより、テスト時間を最適化することに重点を置いています。

ファジングテストの概念

多くのファジングテストツールはPCアプリケーションをテストするように設計されているため、組み込みコードをネイティブにコンパイルされたPCアプリケーションとして実行すると、それらを簡単に適応させることができます。 PCで埋め込みコードを実行すると、パフォーマンスが大幅に向上しますが、2つの欠点があります。まず、PCマイクロプロセッサは組み込みマイクロコントローラと同じようには反応しません。次に、ハードウェアに影響を与えるコードを書き直す必要があります。ただし、実際には、PCで実行することの利点は欠点を上回ります。本当の障壁は、PC上でネイティブにコンパイルするためにコードを移植することの難しさです。

ファズベクトルがバグをトリガーするタイミングをどのように知ることができますか？クラッシュは簡単に見つけることができますが、リセットの原因となるファズベクトルを特定するのは困難です。メモリオーバーフローのバグや漂遊ポインタの書き込み（ハッカーにとって最も価値のあるバグの種類）は、通常、クラッシュやリセットを引き起こさないため、システムの外部から識別することはほとんど不可能です。

GCCやClangなどの多くの最新のコンパイラには、メモリサニタイズと呼ばれる機能があります。これにより、メモリのブロックが使用中かどうかに応じて、クリーンまたはダーティとしてマークされ、ダーティメモリへのアクセスの試みにフラグが立てられます。ただし、メモリのサニタイズはフラッシュ、RAM、およびCPUサイクルを消費するため、組み込みデバイスでの実行が困難になります。そのため、代わりに、コードのサブセットをテストしたり、より多くのリソースを使用してデバイスのバージョンを構築したり、PCを使用したりする場合があります。

テストの有効性は、実行されたコードの量によって評価できます。ここでも、コンパイラはパンくずリストサブルーチン呼び出しを使用してメモリ使用量を追跡できます。コードカバレッジライブラリは、各コードパスの使用値のテーブルを維持し、パンくずが実行されるときにそれらをインクリメントします。

ただし、コードの多くはファズベクトルにアクセスできないため、コードカバレッジ数を埋め込みファズテストで解釈するのは困難です。たとえば、インターフェイスとは独立して動作する周辺機器用のデバイスドライバ。したがって、組み込みシステムの「完全なコードカバレッジ」を定義することは困難です。おそらく、組み込みコードの20％しかアクセスできません。コードカバレッジはまた、大量のフラッシュ、RAM、およびCPUサイクルを消費し、実行するには専用のハードウェアまたはPCターゲットが必要になります。

バグレポート

ファズテストで望ましくない動作を引き起こすベクトルが見つかった場合、詳細な情報が必要です。バグはどこで発生しましたか？コールスタックの状態はどうなっていますか？特定の種類のバグは何ですか？このすべての情報は、トリアージし、最終的にバグを修正するのに役立ちます。

バグのトリアージは、ファズテストで非常に重要です。新しいファズプロジェクトでは多くのバグが見つかることが多く、その重大度を自動的に判断する方法が必要です。また、ファズバグは、コードパスのさらに下にある追加のバグをマスクすることが多いため、バグをブロックする傾向があります。ファジングテスト中に発生する問題については、迅速な回避策が必要です。

組み込みクライアントは、PCほど情報を公開することをいとわない。通常、クラッシュは単にデバイスをリセットして再起動する原因になります。これは現場では望ましいことですが、デバイスの状態が消去されるため、クラッシュが発生したかどうか、発生した場所と理由、または取得したコードパスを知ることが困難になります。エンジニアは、一貫性のある再現ベクトルを見つけてから、デバッガーを使用して不正な動作を追跡し、バグを見つける必要があります。

ファジングテストでは、テストによっていくつかのバグに対して数千のクラッシュベクトルが生成され、バグのあるシステムの誤った印象を与える可能性があります。どのベクトルが同じ根本的なバグに関連付けられているかをすばやく判断することが重要です。組み込みデバイスの場合、クラッシュ自体の場所は通常、バグに対して一意であり、通常、完全なコールスタックトレースを見つける必要はありません。

継続的なファジングテスト

ファジングテストは確率的な性質があるため、長期間実行すると、問題が見つかる可能性が高くなります。しかし、開発終了時の長いファジングテストサイクルによる遅延を吸収できるプロジェクト計画はありません。

実際には、ファズテストはリリースプロセスの後に独自のブランチで開始されます。新しく発見されたバグはローカルブランチで修正されるため、新しいバグが追加のバグ発見をブロックすることなくテストを続行できます。リリースサイクルの一部として、以前のリリースのファジングテストで発見されたバグは、新しいリリースに含まれるかどうか評価されます。最後に、バグを発見したファズベクターを通常の品質保証プロセスに追加して、修正を検証し、これらのバグが誤ってコードに再導入されないようにする必要があります。

さまざまなシナリオでデバイスのファジングテストを実行する必要があります。たとえば、ネットワーク化されている場合、デバイスは接続要求に対して異なる方法で応答します。考えられるすべてのシナリオでファジングテストを実行することは実用的ではありませんが、考えられる状態の値ごとにファジングテストを含めることができます。たとえば、他の変数を同じに保ちながら、異なるデバイスタイプごとにファズテストを実行します。次に、1つのデバイスタイプについて、ネットワーク接続状態などの別の変数に対して異なる値を実行します。

ファジングテストアーキテクチャ

2つの著名なファジングテストアーキテクチャは、ファジングベクトルがテスト前にエンジニアによって指定されるファジングと、ファジングツールがテストベクトルの初期セットから始まり、パケットの浸透度に基づいて自動的に変化するカバレッジガイドファジングテストを対象としています。コード。

さらに、すべてのコードがPCで実行されるわけではなく、テスト対象によっては、組み込みアプリケーション用のPCシミュレーターの開発が実用的でない場合があります。

以下は、4つのファジングテストアーキテクチャの概要です。

• 組み込みハードウェアでの直接インターフェーステスト—インターフェースを介して注入されたファズパケットを使用して、組み込みデバイスで通常の本番イメージを実行します
• パケット（スタック）インジェクションテスト-無線でインターフェイスを実行することなく、着信パケットルーチンを直接呼び出す
• シミュレータを使用したファジングの指示—埋め込みコードの開発とテストにPCベースのシミュレーション手法を使用
• シミュレーターを使用したカバレッジガイド付きファジング（以下にLibfuzzとして表示）

複数のファズテスター

デバッグインターフェイスロックとセキュアブートを使用して組み込みデバイスをロックダウンした後、デバイスのインターフェイスのファジングテストを検討する必要があります。 Webサーバーを保護するために使用されるものと同じツールや概念の多くは、組み込みデバイスでの使用に適合させることができます。

仕事に適したツールを使用してください。継続的なファジングテストにはカバレッジガイド付きファジングが必要ですが、コードが組み込みハードウェアでのみ実行される場合は、ある程度のファジングテストカバレッジを提供するために有向ファジングが適しています。

最後に、できるだけ多くのシナリオで複数のファズテスターを使用する必要があります。それぞれがデバイスをわずかに異なる方法でテストし、カバレッジを最大化して、組み込みデバイスのセキュリティを最大化します。

>>この記事はもともと姉妹サイトのEDN。