BASS：BASS 自動署名シンセサイザー
執筆者：Jonas Zaddach
、Mariano Graziano.
エグゼクティブ サマリー
新たな続々と脅威が現れ、既存の脅威が常に進化している脅威環境は、防御する側にとっても大きな悩みの種です。Talos では 1 日あたり何百万もの新旧サンプルを分析していますが、こうしたことも問題の深刻さを物語っています。それ以外にも、マルウェア自動化分析ツールによるリソースの枯渇、マルウェア ファミリを効果的に識別できるウイルス対策シグネチャの開発、分析サンプルの増加に応じたツール拡張性の確保、などの問題もあります。これらの課題に取り組むため、Talos では「BASS」と呼ばれる新しいオープン ソース フレームワークを開発しています。
BASS（「バース」と発音）は、以前に生成されたマルウェア クラスタに属するサンプルからウイルス対策シグネチャを自動生成するためのフレームワークです。ハッシュベースの署名ではなく、よりパターン ベースの署名を生成することで、ClamAV によるリソースの使用量を低減します。パターン ベースの署名を作成するアナリストにとっては、作業が軽減される効果もあります。フレームワークは Docker により容易に拡張可能です。
ただしフレームワークはまだアルファ（検討）段階にあり、未完成な部分もあります。フレームワークはオープンソースとして公開されており、BASS の機能向上に役立つ皆様からのご意見を積極的に受け付けています。BASS のソースコード：
https://github.com/Cisco-Talos/bass
BASS はカナダのモントリオールで行われた REcon 2017 で発表されました。
開発の背景
Talos では 1 日あたり約 150 万件のユニーク サンプルを受け取ります。サンプルの大部分は既知の脅威であり、マルウェア スキャン（ClamAV）を使用すれば瞬時にフィルタ処理して除外できますが、さらなる分析が必要なファイルも相当数残ります。残ったファイルは動的分析のためサンドボックス内で実行され、悪意の有無によってさらに分類されます。悪意があると判断されたファイルは ClamAV シグネチャを生成するために処理されます。こうして生成された ClamAV シグネチャは、後のマルウェア スキャンの初期段階で該当する脅威を排除します。
ClamAV のデータベースには、2017 年のわずか 3 か月間（2 月 ～ 4 月）で約 56 万件の署名が追加されました。これは 1 日あたり 9,500 件の増加ペースです。これらのシグネチャの大部分は、ハッシュベースのシグネチャとして自動生成されたものです。パターンベースまたはバイトコードベースのシグネチャ（= ClamAV がサポートする他の 2 種類のシグネチャ）と比べて、ハッシュベースのシグネチャではシグネチャごとに 1 個のファイルしか照合できないという欠点があります。また、署名数が多い場合には ClamAV シグネチャ データベースのメモリー占有率が増大するという欠点もあります。バイトコード シグネチャとパターンベース シグネチャを比較すると、後者の方が高速かつ管理も容易で、しかも単一のファイルではなくクラスタ全体を識別できるという利点があります。
BASS
BASS は、上記のギャップを埋めるためのものです。そのため、大量のバイナリ実行可能コードから ClamAV パターン シグネチャを生成できるように設計されています。
BASS はマルウェア クラスタを取り込みます。BASS を可能な限りシンプルかつ柔軟に保つため、マルウェア クラスタリング機能は省かれています。入力インターフェイスは、新しいクラスタリング ソースにも容易に適応できるよう、あえて汎用的な設計がされています。現在、Talos ではいくつかのクラスタ ソースを使用しています。それらには、独自サンドボックスにある侵害の兆候（IoC）クラスタ、構造ハッシュ（悪意のある既知の実行可能ファイルと構造が類似した追加サンプルを発見した場合に使用）、スパム キャンペーンから収集されたマルウェアなどが含まれます。
最初のステップでは、マルウェア ファイルが ClamAV の専用ツールにより解凍されます。ClamAV は多様なアーカイブ形式を展開・解凍できますが、圧縮された実行可能ファイル（UPX など）や入れ子のドキュメント（Word ドキュメント内の EXE ファイルなど）にも対応しています。解凍されたファイルは情報収集のために検査されます。フィルタ処理の段階では、現時点で Unix ファイル ツールの file size と magic string を使用しています。
次に、マルウェア クラスタがフィルタ処理されます。ファイルが BASS による予想される入力と合致していない場合、クラスタから削除されるか、または（十分な数のファイルが残っていない場合は）クラスタが完全に拒否されます。予想される入力とは現時点で PE 実行ファイルですが、ELF および MACH-O バイナリのサポートも簡単に追加できます。
フィルタ処理されたクラスタは、シグネチャ生成ステップに送られます。ここでは、まずバイナリを逆アセンブルします。現在使用している逆アセンブラは IDA Pro ですが、radare2 などの逆アセンブラも同じ結果を生成するため、簡単に代用できます。
逆アセンブリの後は、シグネチャを生成するためサンプル間に共通のコードを見つけます。この手順が不可欠な理由は 2 つあります。1 つ目の理由は、シグネチャ生成アルゴリズムが多額のマシン リソースを消費し、少量サンプルでも効果があることです。2 つ目の理由は、構文上だけでなく意味的にも同様のコードから署名を生成することが望ましいことです。コード比較ツールには BinDiff を使用します。ここでも、BinDiff は他のツールで簡単に代用できます。将来的には他の比較ツールを統合するかもしれません。
BinDiff は、各実行可能ファイルを小規模クラスター内の他のファイルと比較します。大規模なクラスタでは数が爆発的に増加するため、比較回数が制限されます。関数上の類似性を基に、関数をノード、類似性をエッジとするグラフが生成されます。優れた共通関数を特定できれば、全体的に類似性が高い直線的な部分グラフが得られます。
上の例では、全体的な類似度の高さから判断して、ƒ1、ƒ2、ƒ4、ƒ6 の部分グラフが共通関数の有力候補です。
バイナリ内で一連の関数候補を特定した後は、関数を関数ホワイトリストと照合します。この手順により、サンプルに静的にリンクされた良性ライブラリ関数からシグネチャを生成してしまうことを避けられます。これらの関数は、確認済みのクリーン サンプル関数が事前入力されたデータベースの Kam1n0 インスタンスに送信されます。
関数のクローンが見つかった場合は、上記の部分グラフ選択ステップを次善候補に対して繰り返します。関数のクローンが見つからなかった場合、一連の関数は次のシグネチャ生成ステップで使用されます。
この時点で、シグネチャの生成を開始できます。ClamAV のパターン シグネチャはバイナリ データのサブシーケンスを認識するためのものです。そこで、抽出された関数すべてにアルゴリズムを適用し、関数間の最長共通部分列（LCS）を特定します（「最長共通部分文字列」と「最長共通部分列」の違いについては付録をご覧ください）。
アルゴリズムを数個のサンプルだけに実行するのは（マシン リソースの消費量を考えると）非常に割高となるため、今回は C. Blichmann が説明するヒューリスティック バージョンを実装しました。出力例は次のようになります。
最後のステップでは、シグネチャを公開する前にテストします。ここでは偽陽性のテストセットを用いてシグネチャが自動的に検証されますが、Sigalyzer による追加検証も実施しています。Sigalyzer は Talos が誇る CASC IDA Pro ClamAV シグネチャ生成・分析プラグインの新機能です（後に更新される予定）。Sigalyzer は（バイナリで ClamAV シグネチャがトリガされると）バイナリの一致部分を強調表示するため、シグネチャを視覚的に判断するのに役立ちます。
アーキテクチャ
BASS は Docker コンテナのクラスタとして実装されており、Python で記述されているため使用するツールとは Web サービスを通じて対話します。BASS は、同じく IDA Pro と BinDiff を使用して ClamAV シグネチャを生成する VxClass を参考にしています（ただし VxClass はすでに提供が終了しており、BASS とは反対に公開もされていません）。
制限事項
シグネチャはサンプルのコード部分から生成されるため、BASS はバイナリ実行可能ファイルに対してのみ使用できます。また、BASS が解析できるのは x86/x86_64 バイナリに限られています（ただし、将来的に他のアーキテクチャもサポートされる可能性はあります）。
これまでの検証では、ホスト バイナリに小規模で多様に変化するスニペットを挿入するファイル感染ウイルスや、大量の（多くは盗まれた）悪意のないバイナリコードと共に悪意のあるコードを含むバックドアには効果が薄いことが判明しています。これらの問題に対処できるよう、クラスタリング ステップの改善を進めています。
最後に、BASS はまだアルファ（検討）段階にあるため、未完成な部分もあることに注意してください。いずれにせよ、私たちはオープンソースという枠組みの中でコミュニティに貢献したいと考えています。フィードバックや改善点などがあれば、どうぞお寄せください。
付録
「最長共通部分文字列」と「最長共通部分列」の違い
次の図は、「最長共通部分文字列」と「最長共通部分列」の違いを示しています。記事の中では、最長共通部分列を LCS として表記しています。
本稿は 2017年6月19日に Talos Group
Tags:
