dsnezhkov/elfpackELF-Binärabschnitts-Andock-Toolkit für stageless Payload-Bereitstellung, das das Anhängen von Payloads vor Ort, Signaturumgehung und Widerstand gegen statisches/dynamisches Laden durch benutzerdefinierte ELF-Abschnittsmanipulation ermöglicht.
.data.payload.h:
const data[3432] = {
0x43, 0x28, 0x41, 0x11, 0xa3, 0xff,
...
0x00, 0xff, 0x23
};
Manuell oder mit Werkzeugen wie bin2c oder xxd -i payload.bin > payload.h mit weiterer Header-Inklusion erreicht.
Das Speichern von Payloads in .text und .data auf generische Weise ist ebenfalls eine schlechte Idee aufgrund der einfachen Nachverfolgbarkeit des Ladens und der Introspektion des Verhaltenssemantik beim Laden von Daten zur Ausführung.
__attribute__'s. Dies ist etwas besser, aber aufgrund der Art und Weise, wie ELF erstellt und geladen wird, immer noch gut nachverfolgbar.char stack[10000] __attribute__ ((section ("binstack"))) = {
0x43, 0x28, 0x41, 0x11, 0xa3, 0xff,
...
0x00, 0xff, 0x23 };
int init_data __attribute__ ((section ("bindata"))) = 0;
main()
{
/* Stack pointer initialisieren */
init_sp (stack + sizeof (stack));
/* initialisierte Daten initialisieren */
memcpy (&init_data, &data, &edata - &data);
}
Eine assemblerabhängige .incbin-ähnliche Direktive kann eine Sektion erstellen und einen Payload einbetten.
Bsp.: gcc -c payload.s oder 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
Mit weiterem Abruf im Loader als:
int main(void) {
extern uint8_t payload_start;
uint8_t *ptrPayload = &payload_start;
...
}
Hinweis: Wir können ein voll funktionsfähiges ELF in der payload.bin einbinden, was wichtig ist, wenn es um die Erstellung "fetter" Binaries geht, die Elemente mehrerer Toolkits enthalten.
Hinweis: Ergonomischere Werkzeuge existieren, um die Aufgabe zu erledigen, wie INCBIN von @graphitemaster [Link]
Eine Variation des Themas ist Inline-ASM wie folgt:
/* 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
};
Hinweis: Beachten Sie PROGBITS in der Definition einer Sektion, es wird wichtig sein.
Compiler-/Linker-basierte Payload-Binär-Inklusion ist nicht ideal
Es gibt Kompromisse:
Der Typ der Sektion und die Flags, die auf der neuen Sektion gesetzt sind, die den Payload enthält, bestimmen, ob der OS-Loader sie beim Start des ausführbaren Programms in den Speicher lädt. Manche Sektionen werden standardmäßig automatisch geladen, andere nicht (z. B. .symtab, .strtab).
Aus Angreifersicht, welche Effizienzen können wir daraus ziehen?
Wir können vermeiden, Flags auf Sektionen zu setzen, die ein standardmäßiges Laden in den Speicher voraussetzen.
Wir können einen anderen Sektionstyp verwenden, der nicht in den Speicher lädt.
Ein Anbieter oder Systemingenieur muss möglicherweise eine Objektdatei mit speziellen Informationen markieren, die andere Programme auf Konformität oder Kompatibilität prüfen können. Sektionen vom Typ
SHT_NOTEund Programm-Header-Elemente vom TypPT_NOTEkönnen für diesen Zweck verwendet werden.
Im letzteren Fall sehen wir die Verwendung dieses Sektionstyps in System-Binaries:
$ readelf --sections /bin/tar | grep NOTE
[ 2] .note.gnu.bu[...] NOTE 00000000000002c4 000002c4
[ 3] .note.ABI-tag NOTE 00000000000002e8 000002e8
Und können ihren Inhalt inspizieren:
$ readelf -p .note.ABI-tag /bin/tar
String dump of section '.note.ABI-tag':
[ c] GNU
Das Endergebnis der Erstellung einer SHT_NOTE-Sektion wird im ELF wie folgt aussehen:
Bonus: SHT_NOTE gibt uns eine Struktur, falls wir sie benötigen (und wir werden sie später verwenden):
Bisher konnten wir eine Sektion erstellen und vermeiden, dass sie vom OS-Loader in den Speicher geladen wird. Die Sektion liegt im ELF-Image momentan faktisch ruhend. Wie wir sie laden, besprechen wir etwas später. Eine dringendere Frage ist jedoch die Tatsache, dass wir immer noch auf Compiler- und Linker-Ebene operieren, und die Sektion ist ein Objekt, das in die Struktur des endgültigen ELF eingewebt wird, wodurch Beziehungen und Speicheradressen aus dem Loader-Code entstehen, der auf ihren Inhalt verweist.
