3/15/2017

CIAのマルウェア開発ノウハウ

シュナイアーのブログより

CIAからマルウェア作者に役立つベストプラクティスて提供された。多くの素晴らしいアドバイスがあるようだ

一般

  • ツールの機能に直接関係する全ての文字列と設定データを難読化または暗号化する。データが必要な瞬間にメモリ内の文字列を非難読化することだけでも考慮する必要すべきである。すでに難読化されていない値が不要になった場合、メモリから消去する必要がある。
    理由: 文字列データや設定データは分析者やリバースエンジニアにとって非常に役立つ。

  • 実行時に全ての文字列データあるいは設定データを即座に復号化または非難読化しないこと。
    理由: 機密データを見つけるためにバイナリの自動化動的分析の困難さを高める。

  • データがプレーンテキスト形式で必要とされなくなったらすぐに機密データ(暗号鍵、生の収集データ、シェルコード、アップロードモジュールなど)をメモリから明示的に削除すること。実行の終了時にこれを行うことをオペレーティングシステムに依存しないこと。
    理由: インシデント対応とフォレンジックレビューの困難さを高める。

  • 機密性の高い文字列と設定データの難読化/非難読化にデプロイ時の固有鍵を使用すること。
    理由: 同じツールの複数デプロイの分析の困難さを高める。

  • 全てのデバッグシンボル情報、マニフェスト(MSVC中間生成物)、ビルドパス、バイナリの最終ビルドの開発者のユーザ名を取り除くこと。
    理由: 分析やリバースエンジニアリングの困難さを高め、帰属先/起点に使用される中間生成物を削除する。

  • ツールの最終ビルドから全てのデバッグ出力(例えば、printf()、OutputDebugString()などの呼び出し)を取り除くこと。
    理由: 分析やリバースエンジニアリングの困難さを高める。

  • ツールの明白な機能(例えば、ノートパッドの置き換えを想定するバイナリのためのWriteProcessMemory、VirtualAlloc、CreateRemoteThreadなど)と一致しない関数を明示的にimport/呼び出さないこと。
    理由: バイナリの潜在的な精密調査を減らし、静的解析とリバースエンジニアリングの困難さをわずかに高める。

  • 機密の関数名をエクスポートしない; バイナリのためにエクスポートが必要になったら、序数あるいは無害な関数名を利用する。
    理由: 分析やリバースエンジニアリングの困難さを高める。

  • プログラムがクラッシュした場合、クラッシュダンプファイル、コアダンプファイル、ブルースクリーン、Dr Watsonあるいは他のダイアログポップアップ、その他中間生成物を生成しないこと。これをきちんと検証するためにユニットテスト中に強制的にプログラムをクラッシュさせるようにする。
    理由: エンドユーザやシステム管理者による疑念を避け、インシデント対応やリバースエンジニアリングの困難さを高める。

  • ターゲットとなるコンピュータがユーザへの反応がなくなるような操作(CPUスパイク、画面の点滅、画面のフリーズなど)を行わないこと。
    理由: ユーザやシステム管理者からツールの存在や動きへの不要な注目を避ける。

  • リモートターゲットに(パッカーや圧縮を使用せずに)アップロードする全てのバイナリのファイルサイズを最小限に抑えるための全ての妥当な努力を行うこと。理想的なバイナリファイルサイズは、フル機能ツールでは150KB未満にする必要がある。
    理由: ツールをターゲットにするだけでなく、機能性や除去を実行するのに時間が必要なので、全体で通信時間は短かくすること。

  • 可能であれば、インプラント、関数フック、注入されたスレッド、レジストリキー、サービス、落とされたファイル、フォークされたプロセスなどを完全にアンインストール/削除する手段を提供すること。手順、必要な権限、削除の副作用を明確に文書化する(たとえ、文書が"これをアンインストールしない"であっても)。
    理由: 不要データがターゲットに残らないようにする。また、適切な文書化で、オペレータが運用リスク評価をうまく行い、ツールあるいはツールの特定機能を使用することの意味合いを完全に理解できる。

  • 一般的な米国のコア労働時間(例: 東部時間8pm-6pm)に関連するコンパイルのタイムスタンプ、リンカーのタイムスタンプ、ビルド時間、アクセス時間などのデータを残さないこと。
    理由: 米国が起点だと直接関連付けられることを避ける。

  • CIA、USG、バイナリ/ツールの作者・利用者に関連するウィッティング・パートナー企業を示すバイナリファイルに日付を残さないこと。
    理由: 敵対者によるバイナリ/ツールなどの帰属は過去、現在、将来のUSGの作戦やエクイティに取り返しのつかない影響を与える可能性がある。

  • バイナリの中にCIAやUSGがカバーする期間、区画、オペレーションコード名、あるいはCIAやUSG特有の用語を含むデータを持たないこと。
    理由: 敵対者によるバイナリ/ツールなどの帰属は過去、現在、将来のUSGの作戦やエクイティに取り返しのつかない影響を与える可能性がある。

  • バイナリに"卑猥な言葉(dirty word)" (卑猥な言葉リスト - TBD)を使わないこと。
    理由: ハッカー用語のような卑猥な言葉は、問題になっているバイナリファイルの不当な(unwarranted)調査を招く要因になる。

ネットワーキング:

  • 全てのネットワーク通信でエンドツーエンドの暗号を使うこと。ペイロードの暗号について、エンドツーエンド原則を破るようなネットワークプロトコルを決して使わないこと。
    理由: ネットワークトラフィックの分析を抑止し、運用/収集データを調査することを防ぐ。

  • 転送中のデータの安全性をSSL/TLSだけに依存しないこと。
    理由: 多数の中間者攻撃ベクトルと公に公開されたプロトコル上の欠陥。

  • 再生可能なC2パケットのようなネットワークトラフィックは許可しないこと。
    理由: 運用エクイティの完全性を保護する。

  • ブレンドレイヤとしてIETF RFC準拠のネットワークプロトコルを利用すること。ネットワーク越しの転送には暗号化されなければならない実データは、周知の標準プロトコル(例、HTTPS)を通じてトンネルすべきである。
    理由: カスタムプロトコルはネットワーク分析やIDSフィルタで目立ってしまう。

  • ブレンドレイヤとして使用される場合、RFCプロトコル準拠を破らないこと。(例えば、Wiresharkが、トラフィックが破られたあるいはズタズタになったとフラグを立てるべきではない。)
    理由: 規準外のネットワークプロトコルは簡単にIDSフィルタやネットワーク分析で目立ってしまう。

  • ビーコン/ネットワーク通信の可変長サイズやタイミング(別名ジッタ)を使わないこと。固定長/タイミングのパケットを予測的(predicatively)に送信しないこと。
    理由: ネットワークの分析やネットワーク活動の相関の困難さを高める。

  • ネットワーク接続の適切な後片付けを行うこと。古いネットワーク接続を散らかしておかない。
    理由: ネットワーク分析やインシデント対応の困難さを高める。

ディスクI/O:

  • リモートターゲットへのバイナリ/ツールの様々な機能によって、潜在的に作成されるディスク・フォレンジック・フットプリントを明示的に文書化しておくこと。
    理由: 潜在的なファイルシステム・フォレンジックの中間生成物の知識を使って運用リスク評価を可能にする。

  • 不必要にディスクにキャッシュデータを読み書きしないこと。サードパーティコードを認識するキャッシュデータが暗黙のうちにディスクに書き込まれるかも知れない。
    理由: 中間生成物のフォレンジックや潜在的な署名の可能性を低下する。

  • ディスクにプレーンテキストの収集データを書き込まないこと。
    理由: インシデント対応とフォレンジック分析の困難さを高める。

  • ディスクに書き込まれる全てのデータを暗号化すること。
    理由: ファイル(コレクション、機密データなど)の意図を隠蔽し、フォレンジック分析やインシデント対応の困難さを高める。

  • ディスクからファイルを削除する、少なくともファイル名、日時スタンプ(作成、変更、アクセス)、コンテンツを消去する場合、安全な消去を利用すること。(注意: "安全な消去"の定義は、ファイルシステムによって異なるが、少なくとも1回は0のデータを渡す必要がある。ここで重要な点は、フォレンジック分析の際に役立つファイルシステムの中間生成物を全て削除することである。)
    理由: インシデント対応とフォレンジック分析の困難さを高める。

  • システムがユーザ応答しなくなる、あるいはシステム管理者に警告を引き起こすようなディスクI/O操作を行わないこと。
    理由: ユーザやシステム管理者からのツールの存在や動作に無用な注意を避ける。

  • ディスクに書き込まれた暗号化されたファイルには"マジック・ヘッダ/フッタ"を使用しないこと。暗号化されたファイルは全て完全にオペイク・データファイルであるべきだ。
    理由: カスタムファイル形式のマジック値の署名を避ける。

  • ディスクにファイルを書き込む際、ハードコードされたファイル名やファイルパスを使用しないこと。これはデプロイ時にオペレータが設定しなければならない。
    理由: オペレータは運用ターゲットに合った適切なファイル名を選択することができる。

  • 暗号化された出力ファイルを書き込むための設定可能な最大サイズ制限及び出力ファイル数を持つこと。
    理由: 収集タスクが制御不能になり、ターゲットのディスクをいっぱいにしてしまう状況を避ける。そうしないと、ツールや操作に無用な注意を引くことになる。

日付/時刻:

  • 日付/時刻を比較する場合、タイムゾーンとしてGMT/UTC/Zuluを使うこと。
    理由: 一貫性のある行動を提供し、"トリガー/ビーコンなど"が期待通りに発火する手伝いをする。

  • "MM-DD-YYYY. YYYYMMDD"のような米国中心のタイムスタンプ形式を使用しないこと。
    理由: ツール間の一貫性を維持し、米国との関連性を避ける。

PSP/AV:

  • "無料"のPSP製品が"リテール"コピーと同じだと仮定しないこと。可能であれば、全てのSKUをテストすること。
    理由: PSP/AV製品は同じベンダーから提供され、異なるSKUを持っていても同じ機能を持つように見えるかも知れないが、そうではない。可能であれば、全てのSKUでテストすること。

  • 可能であれば、ライブ(または最新のライブ)のインターネット接続でPSPをテストすること。注意: これは慎重に検討する必要があり、開発中のソフトウェアで行うべきではなく、リスクと利益とのバランスである。ライブインターネット接続ができるPSP/AV製品は、様々な基準をベースにサンプルソフトウェアをアップロードすることができることがよく知られている。
    理由: PSP/AV製品は逆にインターネット接続した時の動作と検出に大きな違いを見せる。

暗号化: NODは暗号化標準を公開している: "NOD Cryptographic Requirements v1.1 TOP SECRET.pdf"。ここで提供されるガイダンスに加え、その文書の要件を満たす必要もある。

暗号要件は複雑で興味深い。私は別の投稿でそれらのコメントを保存するだろう。

ニュース記事

Hacker News