ElfPack: Aggancio di sezioni ELF per la consegna di payload senza stadi

Punti salienti

• Panoramica dei meccanismi di bundling del payload: compilazione, linking e caricamento.
• Compatibilità binaria e creazione di payload debolmente accoppiati al loro meccanismo di consegna.
• Evitare il caricamento automatico in memoria delle sezioni.
• Utilizzo di tipi di sezione strutturati.
• Riaggancio del payload sul campo ai loader tramite sezioni ELF. Porta il tuo payload.
• Evasione delle firme con sezioni ELF precompilate staccate.
• Allegati payload drive-by ai loader con pipeline di generazione payload.
• Creazione di binari payload grassi e caso per evitare i packer binari.
• Impacchettamento di payload complessi.
• Opzioni di offuscamento del payload e protezione delle chiavi.
• Resistenza al tracciamento del caricamento del payload statico e dinamico. Binwalk ed eBPF.

Incorporamento dei payload

Inclusione esadecimale-binaria con compilazione e linking

1. Direttamente nella sezione dati predefinita o nel testo: Normalmente, il compilatore posiziona gli oggetti che genera in sezioni come .data.

payload.h:

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

Ottenuto manualmente o con strumenti come bin2c o xxd -i payload.bin > payload.h con ulteriore inclusione dell'header.

Memorizzare i payload in .text e .data in modo generico è anche una cattiva idea a causa della facilità di tracciamento del caricamento e dell'introspezione delle semantiche comportamentali del caricamento dei dati per l'esecuzione.

2. In una sezione separata. Puoi posizionare i dati del payload in sezioni aggiuntive, o hai bisogno che alcune variabili particolari appaiano in sezioni speciali. Questo si ottiene con un meccanismo dipendente dal compilatore. In gcc, si fa tramite __attribute__. Questo è un po' meglio ma ancora ben tracciabile a causa di come viene creato e caricato l'ELF.

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

main()
{
    /* Inizializza il puntatore dello stack */
    init_sp (stack + sizeof (stack));

    /* Inizializza i dati inizializzati */
    memcpy (&init_data, &data, &edata - &data);
}

3. Inclusione binaria tramite linker

Una direttiva simile a .incbin dipendente dall'assembler può creare una sezione e incorporare un payload. Es: gcc -c payload.s o 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

Con ulteriore recupero nel loader come:

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

Nota: Possiamo includere un ELF completamente funzionale in payload.bin, cosa importante quando si tratta di creare binari "grassi", contenenti elementi di diversi toolkit.

Nota:: Esistono strumenti più ergonomici per svolgere il compito, come INCBIN di @graphitemaster [link]

Una variazione sul tema è ASM inline come segue:

/* Dati immagine grezzi per tutte le immagini incorporate */
 #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
 
 /* Strutture immagine per tutte le immagini incorporate */
 #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
 };
 

Nota: Nota PROGBITS nella definizione di una sezione, sarà importante.

L'inclusione binaria del payload basata su compilatore/linker non è ideale

Ci sono compromessi:

• Il processo di incorporamento è strettamente accoppiato alla creazione del loader del payload.
• Cosa succede per i cambiamenti di formato del payload?
• Per impostazione predefinita, le sezioni che trasportano dati hanno il flag PROGBITS impostato e verranno caricate in memoria dal loader del sistema operativo per impostazione predefinita. Potremmo non volere questo.

Rappresentazione su disco/memoria di una sezione ELF

Il tipo di sezione e i flag impostati sulla nuova sezione che la contiene determinano se il loader del sistema operativo la carica in memoria all'avvio dell'eseguibile. Alcune sezioni vengono caricate automaticamente per impostazione predefinita, altre no (es. .symtab, .strtab)

Dal punto di vista offensivo, quali efficienze possiamo ottenere da questo?

Incorporamento dei payload: seconda versione

1. Possiamo evitare di impostare flag sulle sezioni che presuppongono il caricamento predefinito in memoria.

2. Possiamo utilizzare un tipo diverso di sezione che non carica in memoria.

Un fornitore o un ingegnere di sistema potrebbe aver bisogno di contrassegnare un file oggetto con informazioni speciali che altri programmi possono verificare per conformità o compatibilità. Le sezioni di tipo SHT_NOTE e gli elementi di programma header di tipo PT_NOTE possono essere utilizzati per questo scopo.

In quest'ultimo caso, possiamo vedere l'uso di questo tipo di sezione nei binari di sistema:

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

E possiamo ispezionarne il contenuto:

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

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

Il risultato finale della creazione di una sezione SHT_NOTE apparirà così nell'ELF:

Bonus: SHT_NOTE ci fornisce una struttura se ne abbiamo bisogno (e la useremo ulteriormente):

Aggancio di sezioni ELF

Finora siamo stati in grado di creare una sezione, evitando di caricarla in memoria da parte del loader del sistema operativo. La sezione è effettivamente dormiente nell'immagine ELF in questo momento. Discuteremo come caricarla un po' più tardi. Tuttavia, una domanda più pressante è il fatto che stiamo ancora operando a livello di compilatore e linker, e la sezione è un oggetto che viene intrecciato nella struttura dell'ELF finale, creando relazioni e indirizzi di memoria dal codice del loader che fa riferimento al suo contenuto.