ネットワーク分析におけるリバース・エンジニアリング

新しい脆弱性や脅威に対して最適な検知ルールを作成するためには,包括的な調査が必要である.しかし,「最良」とはどういう意味だろうか？まあ,「最良」の解釈は,脆弱性について私たちが何を知っているかによって異なりますが,重要な情報が利用できないこともあります.したがって,悪意のある活動を追跡できる正確な検出ルールを開発するには,悪意のあるツールのバイナリコードのような,従来とは異なる領域でこの情報を検索する必要があります.

このブログでは,バックドアエクスプロイトのソースコードを詳細に分析することにより,正確なネットワークシグネチャを作成するプロセスについて詳しく説明します.ネットワーク分析におけるリバースエンジニアリングは,悪意のあるネットワークパケットを効果的に検出し,誤検出を減らし,最終的に悪意のある脅威から身を守るためのルールを構築するために不可欠です.OT/IoT

脅威の検知

ある脆弱性に関して利用可能な唯一の情報が,同じ研究者によって作成されたコマンドとエクスプロイトを実行するルーターの基本的で非技術的な記述であるとしよう.この限られた情報でも,そのエクスプロイトを検出する最初のルールを作成することは可能です.図1は,Nozomi Networks Labs IoT ハニーポットによって採取されたインテリジェンスとネットワークトレースの例を示しています.この例は,CVE-2022-27255を悪用するネットワークパケットを示していますが,悪用はすぐには明らかになりません.誤検出を防ぐためには,より多くのコンテキストが必要です.

ネットワークパケットの搾取 — **図1.**CVE-2022-27255を悪用するネットワークパケット.

この悪用を検知するには,使用されているプロトコルを調べ,特定のオフセットに存在すべきデータと存在すべきでないデータを理解する必要がある.SANSは,特定の文字列と,正当なパケットのパラメータに基づくパケットサイズに基づく検出戦略を提案している.

SANSは素晴らしい脅威検知戦略を提供してくれましたが,私たちの目標は,攻撃者が特定の脆弱性を悪用するさまざまな方法を検知することです.そのエクスプロイトの複数の亜種を検出できるような柔軟性のあるルールを作成し,誤検出の可能性を冒すか,あるいは,1つの亜種だけを検出することに焦点を絞った狭いルールを作成するかは,難しい決断です.

エクスプロイトに基づく検出ルールの作成

CVE-2022-27255を悪用した図1のようなパケットは,脆弱性が悪用されるたびにカスタムメイドされるわけではありません.そのため,この種のエクスプロイトが一般に公開されるようになると,これらのネットワークパケットがどのように作成されるかをより深く理解できるようになり,より優れた効率的な検出ルールを作成するのに役立ちます.

ほとんどの場合,脆弱性を発見した研究者が公開した最初のバージョンを基に,新たなエクスプロイトが作成されます.私たちは,IoT ,公開されているエクスプロイトのソースコードを模倣したマルウェアに狙われているデバイスを確認しています.私たちは,同じ脆弱性を悪用する異なる攻撃者間で,同じようなループ,文字列,実行フローロジックが存在することに気づきました.唯一の違いは,エラーをチェックする方法やデータ構造を初期化する方法にわずかな違いがあるだけです.

なぜだろうか？既存のエクスプロイトを複製することは,マルウェア作者にとって,すでに行われた研究に費やす時間とエネルギーを節約する便利な方法だからだ.つまり,新しい亜種はたいてい以前のバージョンと似ているため,ネットワークシグネチャの作成が容易になるのだ.

そのため,実際の脅威を検出する際に邪魔になる不要な検出を避けるために,追加情報が必要となる.これを達成するために,ルールは悪用に厳密に必要なコードにのみ依存しなければならない.

図2のTP-Link Archerデバイスのエクスプロイトを見てください.

この例では,次の文字列を検出するルールを作成できる. host=127.0.0.1;, しかし,この文字列が正規のトラフィックにも現れる危険性がある.このような事態を防ぐには,さらに条件を追加することでコンテキストを増やすことができる. X_TP_ConnName=ewan_ipoe_s. または IPPING_DIAG.提案された検出が機能しない問題が発生するのは,1. IPPING_DIAG 攻撃者がIPアドレスを変更した場合.一方,攻撃者がすべての可能な変数を変更し始めた場合,例えば X_TP_ConnName=ewan_ipoe_s. への X_TP_ConnName=none_none あるいはそのパラメータを削除することで,エクスプロイトが役に立たなくなる可能性がある.そのため,マルウェア作者はむしろ他のエクスプロイトのソースコードをコピーし,修正を最小限に抑えようとするのだ.

TP-Linkアーチャーの悪用. — **図2.**TP-Link Archerの悪用.

バックドア攻撃の調査

私たちのチームは,リモートアクセスツール(RAT),ボットネット,バックドアエクスプロイト,その他の悪意のあるツールのバイナリをリバースエンジニアリングすることにより,ネットワークシグネチャを日々作成しています.

例えば,数年前に検出され,現在も悪用されているバックドア悪用について考えてみよう.一部のNetisデバイス(中国ではNetcore)には,そのデバイスから任意のコマンドを実行したり,ファイルをアップロード／ダウンロードしたりできるようにするバックドアが仕込まれていた.コマンドの送信を開始するには,バックドアを有効にするための特定の文字列を送信する必要があった.いったん有効になると,バックドアはコマンドを受け付け,実行し,その結果を返すようになる.これはエクスプロイトそのものではないが,必要な調査手順は本質的に似ている.

私たちが調査を始めたとき,このバックドアにアクセスするための3つの異なるエクスプロイトを目にした：

これらすべてのエクスプロイトにおいて,図3に見られるように,バックドアを有効にするための共通の文字列が見られました.

ネティスのバックドアを有効にするエクスプロイトコード. — **図3.**Netisバックドアを可能にするエクスプロイトコード.

しかし,優れたネットワークシグネチャを作成する前に,まずネットワークのパターンを特定する必要があります.図3に見られるように,Netisバックドアを有効にするエクスプロイトコードは,このバックドアの活動を検出するパターンを作成するための良い出発点であると思われます.いくつかの調査の後,Netisバックドアでこのプロトコルを実装する亜種をさらに発見しましたが,その方法は異なっていました.この場合ギットハブそしてエクスプロイトDB は最初のUDPパケットを別の header'：\x00\x00\x00\x00\x00\x00\x00\x00netcore.という文字列を検出するルールを作成したとします. AAAAAAAAnetcoreそうなれば,重要な割合の攻撃を逃してしまうことになる.

脅威検出の複雑さ

脅威検知の基本的な方法を確認したので,さらに一歩進んでみよう.ログインコマンドの検知だけに焦点を当てると,検知システムは新しい接続を識別することしかできません.バックドア実行ファイルが最初のログインパケットを受信すると,バックドアは有効化され,コマンドの実行を要求してパケットを処理する準備が整います.コマンドを実行するこれらのパケットはログインコマンドとは異なるため,同じ検出ロジックを使用して検出することはできません.

悪意のある接続では,最初のログインコマンドは1つですが,コマンド実行を要求するパケットは複数あります.もし私たちの検知システムがログインコマンドの検知だけに集中すれば,以前にバックドアを有効化した悪意のある接続を検知することはできないでしょう.もし私たちの検知エンジンが,バックドアがすでに有効になっているネットワーク上でリッスンを開始したらどうなるでしょうか？これは珍しい状況ですが,そのウィンドウを開いたままにすることはできません.このシナリオでは,検出システムはバックドアと相互作用している人を検出しないため,このバックドアへの接続を検出するには別のアプローチが必要になります.

パターンを見つけるための異なるアプローチ

このプロトコルがめったに使われない53413 UDPポートで実行されるという事実はさておき,検出パターンの研究に集中しよう.ログインコマンドを実行する方法にはかなりの一貫性があるが,異なるコマンドをすべて検出する単一のパターンを開発しようとすると,困難さが増す.

Exploit-DBに見られるように,8つのゼロで始まるパターンを送信するものもあれば,GitHubに見られるように,アルファベットの「A」とゼロを混ぜて送信するもの(AAx00x00x00AAAA)もある.また,Exploit-DBには,コマンドのヘッダーに0と1が混在している例もある！これらの例を見ると,いくつかの疑問が生じる.これらはすべて同じ目的を果たすものなのだろうか？これらのヘッダは厳密に必要なのか,それとも攻撃者は検出を避けるためにヘッダを完全にランダム化することができるのか？いくつかの異なるソースコードがありますが,私たちはバックドアにコマンドを送るこれら3つの異なる方法を見ました.私たちは,バックドアとやりとりする3つの方法がこれらだけであると確信することはできません.最悪の場合,私たちはこれら3つの異なる攻撃しか検出することができませんが,理想的には,バックドアとのすべての可能な相互作用を検出することが望ましいです.

のように,8つのゼロで始まるパターンを送信するものもある. エクスプロイトDBまた,「A」の文字にゼロを混ぜたものもある. (AAx00x00AAAA)で見たとおりである. ギットハブ.もう1つある. エクスプロイトDB コマンドのヘッダーに0と1がある例！これらの例を見ると,いくつかの疑問が浮かぶ.それらはすべて同じ目的を果たすのだろうか？これらのヘッダーは厳密に必要なのだろうか,それとも攻撃者は検出を避けるためにヘッダーを完全にランダム化することができるのだろうか？いくつかの異なるソースコードがありますが,私たちはバックドアにコマンドを送るこれら3つの異なる方法を見ました.私たちは,バックドアとやりとりする3つの方法がこれらだけであると確信することはできません.最悪の場合,私たちはこれら3つの異なる攻撃しか検出することができませんが,理想的には,バックドアとのすべての可能な相互作用を検出することが望ましいです.

いつものように,このバックドアに関する公式なドキュメントはありません...しかし,私たちの調査によってバックドアされた実行ファイルを見つけることができました.Metasploitの共同研究者の何人かは,開発中のコードがバックドアと適切にやりとりできるかどうかをチェックするために,バックドアシステムを実行しました.公式なドキュメントやバックドアのソースコードがない中で,バックドアのバイナリを手に入れたことは非常に良いニュースです.

バイナリーを逆工学してパターンを見つける

ここで,リバースエンジニアリングのプロセスによって,バックドアがどのように動作するのか,その内部ワークフロー,そして侵害されたデバイス上でコマンドを実行できるようにするために受信したインバウンド接続に対して行われるチェックを完全に理解することができます.既にリバースエンジニアリングは行われているので,サンプルを完全にリバースエンジニアリングするつもりはありません.

このバックドアの検出ルールを作成する方法を理解するために,コードのロジックを大まかに追い,受信したUDPパケットを解析するバイナリの部分に焦点を当てる.こうすることで,コードに関する知識を得て,バックドアとの相互作用をより正確に検出できるルールを作成できるようになります.

バックドアのサンプルを開けると イグドンプト を呼び出すことで初期化を開始します. バインド 関数を使い,UDPプロトコルを使ってポート53413をリッスンする.これでコネクションのフィルタリングを開始できる.初期化の後,メイン・ループはこのポートからパケットを読み込み,それを call_mptlogin 関数である.

について call_mptlogin function, as seen in Figure 4, is responsible for verifying if the content of these packets meets the necessary conditions for accepting commands. This function receives the content of the received packets after discarding the first 8 bytes. The only condition for a successful return from this function (returning 0) is that the first bytes must be ネットコア.見てわかるように,最初の8バイトの内容に制限はない.つまり,もしルールを作成して AAAAAAAAnetcore 文字列を使用すると,成功したバックドア・ログイン・コマンドの多くを捕捉できない.

最初の ネットコア 文字列の比較が成功すると,バックドアは実行フローを別のループにリダイレクトし,そのループが受信したUDPパケットを解釈する新しいコードとなる.

受信パケットの内容は レフバフ 変数に格納される. コマンドドプト 変数.その コマンドドプト 変数は,パケットがどのアクションを要求しているかを知るためにチェックされる.この値が「◎」,「◎」,「◎」のいずれであるかによって,感染したデバイスとやりとりするためのコードの機能が異なる.最も一般的なオプション \x009バイト目以降のbashコマンドを直接実行できる.

この2バイトを比較した後,残りのバイトについて追加の重要なチェックは行われない.つまり,このヘッダーの他のバイトをランダムに変更しても,パケットは完全に有効である.にもかかわらず,私たちは依然として,同じオリジナルのエクスプロイトを使用するエクスプロイトの試みを検出しています. AAx00x00AAAA この脆弱性が発見されてから8年後のことである.
一方では,私たちのハニーポット調査は,2つのヘッダーのみを使用する最初の公開エクスプロイトを検出するためのネットワークシグネチャを作成することを示唆している(AAx00x00AAAA そして x00\x00\x00\x00\x00\x00\x00\x00)であれば,8年後でもネットワークシグネチャの作成プロセスを簡略化できただろう.その一方で,バックドアのリバースエンジニアリング解析により,このヘッダーの最初のバイトにわずかな変更を加えるだけで,これらの攻撃のほとんどを検知するように設計された検知ロジックを回避できることが明らかになった.