macOS Auto Start
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Dieser Abschnitt basiert stark auf der Blogreihe Beyond the good ol' LaunchAgents, das Ziel ist es, mehr Autostart-Standorte hinzuzufügen (wenn möglich), anzugeben, welche Techniken heutzutage mit der neuesten Version von macOS (13.4) noch funktionieren und die erforderlichen Berechtigungen zu spezifizieren.
Hier findest du Startorte, die nützlich für Sandbox-Bypasses sind, die es dir ermöglichen, einfach etwas auszuführen, indem du es in eine Datei schreibst und wartest auf eine sehr häufige Aktion, eine bestimmte Zeitspanne oder eine Aktion, die du normalerweise innerhalb einer Sandbox ohne Root-Berechtigungen ausführen kannst.
/Library/LaunchAgents
Auslöser: Neustart
Root erforderlich
/Library/LaunchDaemons
Auslöser: Neustart
Root erforderlich
/System/Library/LaunchAgents
Auslöser: Neustart
Root erforderlich
/System/Library/LaunchDaemons
Auslöser: Neustart
Root erforderlich
~/Library/LaunchAgents
Auslöser: Neu anmelden
~/Library/LaunchDemons
Auslöser: Neu anmelden
Als interessantes Faktum hat launchd
eine eingebettete Property-Liste im Mach-o-Bereich __Text.__config
, die andere bekannte Dienste enthält, die launchd starten muss. Darüber hinaus können diese Dienste die RequireSuccess
, RequireRun
und RebootOnSuccess
enthalten, was bedeutet, dass sie ausgeführt und erfolgreich abgeschlossen werden müssen.
Natürlich kann es aufgrund der Code-Signierung nicht geändert werden.
launchd
ist der erste Prozess, der vom OX S-Kernel beim Start ausgeführt wird, und der letzte, der beim Herunterfahren endet. Es sollte immer die PID 1 haben. Dieser Prozess wird die Konfigurationen lesen und ausführen, die in den ASEP Plists in:
/Library/LaunchAgents
: Benutzeragenten, die vom Administrator installiert wurden
/Library/LaunchDaemons
: Systemweite Daemons, die vom Administrator installiert wurden
/System/Library/LaunchAgents
: Benutzeragenten, die von Apple bereitgestellt werden.
/System/Library/LaunchDaemons
: Systemweite Daemons, die von Apple bereitgestellt werden.
Wenn sich ein Benutzer anmeldet, werden die Plists, die sich in /Users/$USER/Library/LaunchAgents
und /Users/$USER/Library/LaunchDemons
befinden, mit den Berechtigungen des angemeldeten Benutzers gestartet.
Der Hauptunterschied zwischen Agenten und Daemons besteht darin, dass Agenten geladen werden, wenn sich der Benutzer anmeldet, und die Daemons beim Systemstart geladen werden (da es Dienste wie ssh gibt, die ausgeführt werden müssen, bevor ein Benutzer auf das System zugreift). Außerdem können Agenten eine GUI verwenden, während Daemons im Hintergrund laufen müssen.
Es gibt Fälle, in denen ein Agent vor der Benutzeranmeldung ausgeführt werden muss, diese werden PreLoginAgents genannt. Zum Beispiel ist dies nützlich, um unterstützende Technologien bei der Anmeldung bereitzustellen. Sie sind auch in /Library/LaunchAgents
zu finden (siehe hier ein Beispiel).
Neue Daemons oder Agenten-Konfigurationsdateien werden nach dem nächsten Neustart oder mit launchctl load <target.plist>
geladen. Es ist auch möglich, .plist-Dateien ohne diese Erweiterung mit launchctl -F <file>
zu laden (jedoch werden diese plist-Dateien nach dem Neustart nicht automatisch geladen).
Es ist auch möglich, mit launchctl unload <target.plist>
zu entladen (der Prozess, auf den verwiesen wird, wird beendet),
Um sicherzustellen, dass es nichts (wie eine Überschreibung) gibt, das einen Agenten oder Daemon daran hindert, auszuführen, führen Sie aus: sudo launchctl load -w /System/Library/LaunchDaemos/com.apple.smdb.plist
Liste aller Agenten und Daemons, die vom aktuellen Benutzer geladen sind:
Wenn eine plist einem Benutzer gehört, wird die Aufgabe als der Benutzer und nicht als root ausgeführt, selbst wenn sie sich in systemweiten Daemon-Ordnern befindet. Dies kann einige Privilegieneskalationsangriffe verhindern.
launchd
ist der erste Benutzerprozess, der vom Kernel gestartet wird. Der Prozessstart muss erfolgreich sein und er darf nicht beendet oder abstürzen. Er ist sogar gegen einige Kill-Signale geschützt.
Eine der ersten Aufgaben von launchd
ist es, alle Daemons wie folgt zu starten:
Timer-Daemons, die basierend auf der Zeit ausgeführt werden:
atd (com.apple.atrun.plist
): Hat ein StartInterval
von 30 Minuten
crond (com.apple.systemstats.daily.plist
): Hat StartCalendarInterval
, um um 00:15 zu starten
Netzwerk-Daemons wie:
org.cups.cups-lpd
: Lauscht in TCP (SockType: stream
) mit SockServiceName: printer
SockServiceName muss entweder ein Port oder ein Dienst aus /etc/services
sein
com.apple.xscertd.plist
: Lauscht in TCP auf Port 1640
Path-Daemons, die ausgeführt werden, wenn sich ein bestimmter Pfad ändert:
com.apple.postfix.master
: Überprüft den Pfad /etc/postfix/aliases
IOKit-Benachrichtigungs-Daemons:
com.apple.xartstorageremoted
: "com.apple.iokit.matching" => { "com.apple.device-attach" => { "IOMatchLaunchStream" => 1 ...
Mach-Port:
com.apple.xscertd-helper.plist
: Gibt im MachServices
-Eintrag den Namen com.apple.xscertd.helper
an
UserEventAgent:
Dies unterscheidet sich von dem vorherigen. Es lässt launchd Apps als Reaktion auf spezifische Ereignisse starten. In diesem Fall ist jedoch die Haupt-Binärdatei nicht launchd
, sondern /usr/libexec/UserEventAgent
. Es lädt Plugins aus dem SIP-eingeschränkten Ordner /System/Library/UserEventPlugins/, wo jedes Plugin seinen Initialisierer im Schlüssel XPCEventModuleInitializer
angibt oder im Fall älterer Plugins im CFPluginFactories
-Dict unter dem Schlüssel FB86416D-6164-2070-726F-70735C216EC0
seiner Info.plist
.
Writeup: https://theevilbit.github.io/beyond/beyond_0001/ Writeup (xterm): https://theevilbit.github.io/beyond/beyond_0018/
Nützlich, um die Sandbox zu umgehen: ✅
TCC-Umgehung: ✅
Aber Sie müssen eine App mit einer TCC-Umgehung finden, die eine Shell ausführt, die diese Dateien lädt
~/.zshrc
, ~/.zlogin
, ~/.zshenv.zwc
, ~/.zshenv
, ~/.zprofile
Auslöser: Öffnen Sie ein Terminal mit zsh
/etc/zshenv
, /etc/zprofile
, /etc/zshrc
, /etc/zlogin
Auslöser: Öffnen Sie ein Terminal mit zsh
Root erforderlich
~/.zlogout
Auslöser: Beenden Sie ein Terminal mit zsh
/etc/zlogout
Auslöser: Beenden Sie ein Terminal mit zsh
Root erforderlich
Möglicherweise mehr in: man zsh
~/.bashrc
Auslöser: Öffnen Sie ein Terminal mit bash
/etc/profile
(funktionierte nicht)
~/.profile
(funktionierte nicht)
~/.xinitrc
, ~/.xserverrc
, /opt/X11/etc/X11/xinit/xinitrc.d/
Auslöser: Erwartet, dass es mit xterm ausgelöst wird, aber es ist nicht installiert und selbst nach der Installation wird dieser Fehler ausgegeben: xterm: DISPLAY is not set
Beim Initiieren einer Shell-Umgebung wie zsh
oder bash
werden bestimmte Startdateien ausgeführt. macOS verwendet derzeit /bin/zsh
als Standard-Shell. Diese Shell wird automatisch aufgerufen, wenn die Terminal-Anwendung gestartet wird oder wenn ein Gerät über SSH zugegriffen wird. Während bash
und sh
ebenfalls in macOS vorhanden sind, müssen sie explizit aufgerufen werden, um verwendet zu werden.
Die Man-Seite von zsh, die wir mit man zsh
lesen können, hat eine lange Beschreibung der Startdateien.
Die Konfiguration der angegebenen Ausnutzung und das Ab- und Anmelden oder sogar das Neustarten haben bei mir nicht funktioniert, um die App auszuführen. (Die App wurde nicht ausgeführt, vielleicht muss sie laufen, wenn diese Aktionen durchgeführt werden)
Writeup: https://theevilbit.github.io/beyond/beyond_0021/
~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist
Auslöser: Neustart von wiedereröffnenden Anwendungen
Alle Anwendungen, die wiedereröffnet werden sollen, befinden sich in der plist ~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist
Um die wiedereröffnenden Anwendungen dazu zu bringen, Ihre eigene zu starten, müssen Sie einfach Ihre App zur Liste hinzufügen.
Die UUID kann durch Auflisten dieses Verzeichnisses oder mit ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'
gefunden werden.
Um die Anwendungen zu überprüfen, die wiedereröffnet werden, können Sie Folgendes tun:
Um eine Anwendung zu dieser Liste hinzuzufügen, können Sie Folgendes verwenden:
Nützlich, um Sandbox zu umgehen: ✅
TCC-Umgehung: ✅
Terminal verwendet die FDA-Berechtigungen des Benutzers, der es verwendet
~/Library/Preferences/com.apple.Terminal.plist
Auslöser: Terminal öffnen
In ~/Library/Preferences
werden die Einstellungen des Benutzers in den Anwendungen gespeichert. Einige dieser Einstellungen können eine Konfiguration enthalten, um andere Anwendungen/Skripte auszuführen.
Zum Beispiel kann das Terminal einen Befehl beim Start ausführen:
Diese Konfiguration wird in der Datei ~/Library/Preferences/com.apple.Terminal.plist
wie folgt reflektiert:
Also, wenn die plist der Einstellungen des Terminals im System überschrieben werden könnte, kann die open
-Funktionalität verwendet werden, um das Terminal zu öffnen und dieser Befehl wird ausgeführt.
Sie können dies über die CLI hinzufügen mit:
Nützlich, um die Sandbox zu umgehen: ✅
TCC-Umgehung: ✅
Terminal wird verwendet, um FDA-Berechtigungen des Benutzers zu nutzen
Überall
Auslöser: Terminal öffnen
Wenn Sie ein .terminal
-Skript erstellen und öffnen, wird die Terminal-Anwendung automatisch aufgerufen, um die dort angegebenen Befehle auszuführen. Wenn die Terminal-App über besondere Berechtigungen verfügt (wie TCC), wird Ihr Befehl mit diesen besonderen Berechtigungen ausgeführt.
Versuchen Sie es mit:
Sie können auch die Erweiterungen .command
, .tool
verwenden, mit regulärem Shell-Skriptinhalt, und sie werden ebenfalls von Terminal geöffnet.
Wenn das Terminal Vollzugriff auf das Laufwerk hat, kann es diese Aktion ausführen (beachten Sie, dass der ausgeführte Befehl in einem Terminalfenster sichtbar sein wird).
Writeup: https://theevilbit.github.io/beyond/beyond_0013/ Writeup: https://posts.specterops.io/audio-unit-plug-ins-896d3434a882
/Library/Audio/Plug-Ins/HAL
Root erforderlich
Trigger: Coreaudiod oder den Computer neu starten
/Library/Audio/Plug-ins/Components
Root erforderlich
Trigger: Coreaudiod oder den Computer neu starten
~/Library/Audio/Plug-ins/Components
Trigger: Coreaudiod oder den Computer neu starten
/System/Library/Components
Root erforderlich
Trigger: Coreaudiod oder den Computer neu starten
Laut den vorherigen Writeups ist es möglich, einige Audio-Plugins zu kompilieren und sie zu laden.
Writeup: https://theevilbit.github.io/beyond/beyond_0028/
/System/Library/QuickLook
/Library/QuickLook
~/Library/QuickLook
/Applications/AppNameHere/Contents/Library/QuickLook/
~/Applications/AppNameHere/Contents/Library/QuickLook/
QuickLook-Plugins können ausgeführt werden, wenn Sie die Vorschau einer Datei auslösen (drücken Sie die Leertaste, während die Datei im Finder ausgewählt ist) und ein Plugin, das diesen Dateityp unterstützt, installiert ist.
Es ist möglich, Ihr eigenes QuickLook-Plugin zu kompilieren, es an einem der vorherigen Standorte zu platzieren, um es zu laden, und dann zu einer unterstützten Datei zu gehen und die Leertaste zu drücken, um es auszulösen.
Das hat bei mir nicht funktioniert, weder mit dem Benutzer-LoginHook noch mit dem Root-LogoutHook
Writeup: https://theevilbit.github.io/beyond/beyond_0022/
Sie müssen in der Lage sein, etwas wie defaults write com.apple.loginwindow LoginHook /Users/$USER/hook.sh
auszuführen
Lo
cated in ~/Library/Preferences/com.apple.loginwindow.plist
Sie sind veraltet, können aber verwendet werden, um Befehle auszuführen, wenn sich ein Benutzer anmeldet.
Diese Einstellung wird in /Users/$USER/Library/Preferences/com.apple.loginwindow.plist
gespeichert.
Um es zu löschen:
Der Root-Benutzer wird in /private/var/root/Library/Preferences/com.apple.loginwindow.plist
gespeichert.
Hier finden Sie Startorte, die nützlich für Sandbox-Umgehungen sind, die es Ihnen ermöglichen, etwas einfach auszuführen, indem Sie es in eine Datei schreiben und nicht sehr häufige Bedingungen wie spezifische installierte Programme, "ungewöhnliche" Benutzeraktionen oder Umgebungen erwarten.
Writeup: https://theevilbit.github.io/beyond/beyond_0004/
Nützlich zur Umgehung der Sandbox: ✅
Sie müssen jedoch in der Lage sein, die crontab
-Binärdatei auszuführen
Oder Root sein
TCC-Umgehung: 🔴
/usr/lib/cron/tabs/
, /private/var/at/tabs
, /private/var/at/jobs
, /etc/periodic/
Root erforderlich für direkten Schreibzugriff. Kein Root erforderlich, wenn Sie crontab <file>
ausführen können
Trigger: Hängt vom Cron-Job ab
Listen Sie die Cron-Jobs des aktuellen Benutzers mit auf:
Sie können auch alle Cron-Jobs der Benutzer in /usr/lib/cron/tabs/
und /var/at/tabs/
(benötigt Root) einsehen.
In MacOS finden sich mehrere Ordner, die Skripte mit bestimmter Häufigkeit ausführen:
Dort finden Sie die regulären cron jobs, die at jobs (nicht sehr häufig verwendet) und die periodic jobs (hauptsächlich zum Reinigen temporärer Dateien verwendet). Die täglichen periodischen Jobs können beispielsweise mit: periodic daily
ausgeführt werden.
Um programmgesteuert einen Benutzer-Cronjob hinzuzufügen, ist es möglich, Folgendes zu verwenden:
Writeup: https://theevilbit.github.io/beyond/beyond_0002/
~/Library/Application Support/iTerm2/Scripts/AutoLaunch
Trigger: iTerm öffnen
~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt
Trigger: iTerm öffnen
~/Library/Preferences/com.googlecode.iterm2.plist
Trigger: iTerm öffnen
Skripte, die in ~/Library/Application Support/iTerm2/Scripts/AutoLaunch
gespeichert sind, werden ausgeführt. Zum Beispiel:
oder:
Das Skript ~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt
wird ebenfalls ausgeführt:
Die iTerm2-Einstellungen, die sich in ~/Library/Preferences/com.googlecode.iterm2.plist
befinden, können einen auszuführenden Befehl angeben, wenn das iTerm2-Terminal geöffnet wird.
Diese Einstellung kann in den iTerm2-Einstellungen konfiguriert werden:
Und der Befehl wird in den Einstellungen angezeigt:
Sie können den auszuführenden Befehl mit folgendem festlegen:
Hochwahrscheinlich gibt es andere Möglichkeiten, die iTerm2-Einstellungen zu missbrauchen, um beliebige Befehle auszuführen.
Writeup: https://theevilbit.github.io/beyond/beyond_0007/
Nützlich, um die Sandbox zu umgehen: ✅
Aber xbar muss installiert sein
TCC-Umgehung: ✅
Es werden Zugriffsberechtigungen angefordert
~/Library/Application\ Support/xbar/plugins/
Auslöser: Sobald xbar ausgeführt wird
Wenn das beliebte Programm xbar installiert ist, ist es möglich, ein Shell-Skript in ~/Library/Application\ Support/xbar/plugins/
zu schreiben, das ausgeführt wird, wenn xbar gestartet wird:
Writeup: https://theevilbit.github.io/beyond/beyond_0008/
Nützlich, um die Sandbox zu umgehen: ✅
Aber Hammerspoon muss installiert sein
TCC-Umgehung: ✅
Es fordert Zugriffsberechtigungen an
~/.hammerspoon/init.lua
Trigger: Sobald Hammerspoon ausgeführt wird
Hammerspoon dient als Automatisierungsplattform für macOS und nutzt die LUA-Skriptsprache für seine Operationen. Bemerkenswert ist, dass es die Integration von vollständigem AppleScript-Code und die Ausführung von Shell-Skripten unterstützt, was seine Skripting-Fähigkeiten erheblich verbessert.
Die App sucht nach einer einzelnen Datei, ~/.hammerspoon/init.lua
, und beim Start wird das Skript ausgeführt.
Nützlich, um die Sandbox zu umgehen: ✅
Aber BetterTouchTool muss installiert sein
TCC-Umgehung: ✅
Es fordert Berechtigungen für Automatisierungs-Shortcuts und Barrierefreiheit an
~/Library/Application Support/BetterTouchTool/*
Dieses Tool ermöglicht es, Anwendungen oder Skripte anzugeben, die ausgeführt werden sollen, wenn bestimmte Shortcuts gedrückt werden. Ein Angreifer könnte in der Lage sein, seinen eigenen Shortcut und die auszuführende Aktion in der Datenbank zu konfigurieren, um beliebigen Code auszuführen (ein Shortcut könnte einfach das Drücken einer Taste sein).
Nützlich, um die Sandbox zu umgehen: ✅
Aber Alfred muss installiert sein
TCC-Umgehung: ✅
Es fordert Berechtigungen für Automatisierung, Barrierefreiheit und sogar Vollzugriff auf die Festplatte an
???
Es ermöglicht die Erstellung von Workflows, die Code ausführen können, wenn bestimmte Bedingungen erfüllt sind. Potenziell ist es möglich, dass ein Angreifer eine Workflow-Datei erstellt und Alfred dazu bringt, sie zu laden (es ist erforderlich, die Premium-Version zu bezahlen, um Workflows zu verwenden).
Writeup: https://theevilbit.github.io/beyond/beyond_0006/
Nützlich, um die Sandbox zu umgehen: ✅
Aber ssh muss aktiviert und verwendet werden
TCC-Umgehung: ✅
SSH benötigt FDA-Zugriff
~/.ssh/rc
Trigger: Anmeldung über ssh
/etc/ssh/sshrc
Root erforderlich
Trigger: Anmeldung über ssh
Um ssh zu aktivieren, ist Voller Festplattzugriff erforderlich:
Standardmäßig, es sei denn, PermitUserRC no
in /etc/ssh/sshd_config
, werden beim Login via SSH die Skripte /etc/ssh/sshrc
und ~/.ssh/rc
ausgeführt.
Schreibweise: https://theevilbit.github.io/beyond/beyond_0003/
Nützlich, um die Sandbox zu umgehen: ✅
Aber du musst osascript
mit Argumenten ausführen
TCC-Umgehung: 🔴
~/Library/Application Support/com.apple.backgroundtaskmanagementagent
Auslöser: Login
Exploit-Payload gespeichert, die osascript
aufruft
/var/db/com.apple.xpc.launchd/loginitems.501.plist
Auslöser: Login
Root erforderlich
In den Systemeinstellungen -> Benutzer & Gruppen -> Anmeldeobjekte kannst du Objekte finden, die ausgeführt werden, wenn der Benutzer sich anmeldet. Es ist möglich, sie aufzulisten, hinzuzufügen und über die Befehlszeile zu entfernen:
Diese Elemente werden in der Datei ~/Library/Application Support/com.apple.backgroundtaskmanagementagent
gespeichert.
Anmeldeelemente können auch über die API SMLoginItemSetEnabled angezeigt werden, die die Konfiguration in /var/db/com.apple.xpc.launchd/loginitems.501.plist
speichert.
(Siehe vorherigen Abschnitt über Anmeldeelemente, dies ist eine Erweiterung)
Wenn Sie eine ZIP-Datei als Anmeldeelement speichern, wird das Archivierungsprogramm
es öffnen, und wenn die ZIP beispielsweise in ~/Library
gespeichert wurde und den Ordner LaunchAgents/file.plist
mit einem Backdoor enthielt, wird dieser Ordner erstellt (er ist standardmäßig nicht vorhanden) und die plist wird hinzugefügt, sodass beim nächsten Anmelden des Benutzers die im plist angegebene Backdoor ausgeführt wird.
Eine weitere Möglichkeit wäre, die Dateien .bash_profile
und .zshenv
im Benutzer-Home zu erstellen, sodass diese Technik weiterhin funktioniert, wenn der Ordner LaunchAgents bereits existiert.
Schriftliche Ausarbeitung: https://theevilbit.github.io/beyond/beyond_0014/
Nützlich, um die Sandbox zu umgehen: ✅
Aber Sie müssen at
ausführen und es muss aktiviert sein.
TCC-Umgehung: 🔴
Muss at
ausführen und es muss aktiviert sein.
at
-Aufgaben sind dafür ausgelegt, einmalige Aufgaben zu bestimmten Zeiten auszuführen. Im Gegensatz zu Cron-Jobs werden at
-Aufgaben nach der Ausführung automatisch entfernt. Es ist wichtig zu beachten, dass diese Aufgaben bei Systemneustarts persistent sind, was sie unter bestimmten Bedingungen zu potenziellen Sicherheitsbedenken macht.
Standardmäßig sind sie deaktiviert, aber der Root-Benutzer kann sie mit aktivieren:
Dies wird in 1 Stunde eine Datei erstellen:
Überprüfen Sie die Job-Warteschlange mit atq:
Über uns sehen wir zwei geplante Jobs. Wir können die Details des Jobs mit at -c JOBNUMBER
ausdrucken.
Wenn AT-Aufgaben nicht aktiviert sind, werden die erstellten Aufgaben nicht ausgeführt.
Die Job-Dateien befinden sich unter /private/var/at/jobs/
Die Dateiname enthält die Warteschlange, die Auftragsnummer und die Zeit, zu der sie geplant ist. Zum Beispiel schauen wir uns a0001a019bdcd2
an.
a
- das ist die Warteschlange
0001a
- Auftragsnummer in Hex, 0x1a = 26
019bdcd2
- Zeit in Hex. Es repräsentiert die Minuten seit der Epoche. 0x019bdcd2
ist 26991826
in Dezimal. Wenn wir es mit 60 multiplizieren, erhalten wir 1619509560
, was GMT: 27. April 2021, Dienstag 7:46:00
ist.
Wenn wir die Auftragsdatei drucken, stellen wir fest, dass sie die gleichen Informationen enthält, die wir mit at -c
erhalten haben.
Writeup: https://theevilbit.github.io/beyond/beyond_0024/ Writeup: https://posts.specterops.io/folder-actions-for-persistence-on-macos-8923f222343d
Nützlich, um die Sandbox zu umgehen: ✅
Aber Sie müssen in der Lage sein, osascript
mit Argumenten aufzurufen, um System Events
zu kontaktieren, um Ordneraktionen konfigurieren zu können
TCC-Umgehung: 🟠
Es hat einige grundlegende TCC-Berechtigungen wie Desktop, Dokumente und Downloads
/Library/Scripts/Folder Action Scripts
Root erforderlich
Trigger: Zugriff auf den angegebenen Ordner
~/Library/Scripts/Folder Action Scripts
Trigger: Zugriff auf den angegebenen Ordner
Ordneraktionen sind Skripte, die automatisch durch Änderungen in einem Ordner ausgelöst werden, wie das Hinzufügen, Entfernen von Elementen oder andere Aktionen wie das Öffnen oder Ändern der Größe des Ordnerfensters. Diese Aktionen können für verschiedene Aufgaben genutzt werden und können auf unterschiedliche Weise ausgelöst werden, z. B. durch die Finder-Benutzeroberfläche oder Terminalbefehle.
Um Ordneraktionen einzurichten, haben Sie Optionen wie:
Erstellen eines Ordneraktions-Workflows mit Automator und Installation als Dienst.
Manuelles Anhängen eines Skripts über die Ordneraktionskonfiguration im Kontextmenü eines Ordners.
Verwendung von OSAScript, um Apple Event-Nachrichten an die System Events.app
zu senden, um programmgesteuert eine Ordneraktion einzurichten.
Diese Methode ist besonders nützlich, um die Aktion im System einzubetten und ein gewisses Maß an Persistenz zu bieten.
Das folgende Skript ist ein Beispiel dafür, was durch eine Ordneraktion ausgeführt werden kann:
Um das obige Skript für Ordneraktionen verwendbar zu machen, kompilieren Sie es mit:
Nachdem das Skript kompiliert wurde, richten Sie Ordneraktionen ein, indem Sie das folgende Skript ausführen. Dieses Skript aktiviert die Ordneraktionen global und fügt das zuvor kompilierte Skript speziell zum Desktop-Ordner hinzu.
Führen Sie das Setup-Skript mit aus:
Dies ist der Weg, um diese Persistenz über die GUI zu implementieren:
Dies ist das Skript, das ausgeführt wird:
Kompiliere es mit: osacompile -l JavaScript -o folder.scpt source.js
Bewege es nach:
Dann öffnen Sie die App Folder Actions Setup
, wählen Sie den Ordner, den Sie überwachen möchten und wählen Sie in Ihrem Fall folder.scpt
(in meinem Fall habe ich es output2.scp genannt):
Jetzt, wenn Sie diesen Ordner mit Finder öffnen, wird Ihr Skript ausgeführt.
Diese Konfiguration wurde im plist gespeichert, das sich in ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist
im base64-Format befindet.
Jetzt versuchen wir, diese Persistenz ohne GUI-Zugriff vorzubereiten:
Kopieren Sie ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist
nach /tmp
, um es zu sichern:
cp ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist /tmp
Entfernen Sie die gerade festgelegten Folder Actions:
Jetzt, da wir eine leere Umgebung haben
Kopieren Sie die Sicherungsdatei: cp /tmp/com.apple.FolderActionsDispatcher.plist ~/Library/Preferences/
Öffnen Sie die Folder Actions Setup.app, um diese Konfiguration zu verwenden: open "/System/Library/CoreServices/Applications/Folder Actions Setup.app/"
Und das hat bei mir nicht funktioniert, aber das sind die Anweisungen aus dem Bericht :(
Bericht: https://theevilbit.github.io/beyond/beyond_0027/
Nützlich, um den Sandbox zu umgehen: ✅
Aber Sie müssen eine bösartige Anwendung im System installiert haben
TCC-Umgehung: 🔴
~/Library/Preferences/com.apple.dock.plist
Auslöser: Wenn der Benutzer auf die App im Dock klickt
Alle Anwendungen, die im Dock erscheinen, sind im plist angegeben: ~/Library/Preferences/com.apple.dock.plist
Es ist möglich, eine Anwendung hinzuzufügen nur mit:
Mit etwas Social Engineering könntest du zum Beispiel Google Chrome im Dock nachahmen und tatsächlich dein eigenes Skript ausführen:
Writeup: https://theevilbit.github.io/beyond/beyond_0017
Nützlich, um die Sandbox zu umgehen: 🟠
Eine sehr spezifische Aktion muss stattfinden
Du wirst in einer anderen Sandbox enden
TCC-Umgehung: 🔴
/Library/ColorPickers
Root erforderlich
Auslöser: Verwende den Farbwähler
~/Library/ColorPickers
Auslöser: Verwende den Farbwähler
Kompiliere ein Farbwähler-Bundle mit deinem Code (du könntest dieses hier zum Beispiel verwenden) und füge einen Konstruktor hinzu (wie im Bildschirmschoner-Bereich) und kopiere das Bundle nach ~/Library/ColorPickers
.
Dann, wenn der Farbwähler ausgelöst wird, sollte dein Code ebenfalls ausgeführt werden.
Beachte, dass die Binärdatei, die deine Bibliothek lädt, eine sehr restriktive Sandbox hat: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/LegacyExternalColorPickerService-x86_64.xpc/Contents/MacOS/LegacyExternalColorPickerService-x86_64
Writeup: https://theevilbit.github.io/beyond/beyond_0026/ Writeup: https://objective-see.org/blog/blog_0x11.html
Nützlich, um die Sandbox zu umgehen: Nein, weil Sie Ihre eigene App ausführen müssen
TCC-Umgehung: ???
Eine spezifische App
Ein Anwendungsbeispiel mit einer Finder Sync Erweiterung kann hier gefunden werden.
Anwendungen können Finder Sync Extensions
haben. Diese Erweiterung wird in eine Anwendung integriert, die ausgeführt wird. Darüber hinaus muss die Erweiterung, um ihren Code ausführen zu können, mit einem gültigen Apple-Entwicklerzertifikat signiert sein, sie muss sandboxed sein (obwohl entspannte Ausnahmen hinzugefügt werden könnten) und sie muss mit etwas wie registriert sein:
Writeup: https://theevilbit.github.io/beyond/beyond_0016/ Writeup: https://posts.specterops.io/saving-your-access-d562bf5bf90b
Nützlich, um die Sandbox zu umgehen: 🟠
Aber du wirst in einer gemeinsamen Anwendungs-Sandbox enden
TCC-Umgehung: 🔴
/System/Library/Screen Savers
Root erforderlich
Trigger: Wähle den Bildschirmschoner aus
/Library/Screen Savers
Root erforderlich
Trigger: Wähle den Bildschirmschoner aus
~/Library/Screen Savers
Trigger: Wähle den Bildschirmschoner aus
Erstelle ein neues Projekt in Xcode und wähle die Vorlage, um einen neuen Bildschirmschoner zu generieren. Füge dann deinen Code hinzu, zum Beispiel den folgenden Code, um Protokolle zu generieren.
Baue es und kopiere das .saver
-Bundle in ~/Library/Screen Savers
. Öffne dann die GUI für den Bildschirmschoner und wenn du einfach darauf klickst, sollte es viele Protokolle generieren:
Beachten Sie, dass Sie sich aufgrund der Berechtigungen des Binärprogramms, das diesen Code lädt (/System/Library/Frameworks/ScreenSaver.framework/PlugIns/legacyScreenSaver.appex/Contents/MacOS/legacyScreenSaver
), in der com.apple.security.app-sandbox
befinden, also innerhalb des gemeinsamen Anwendungs-Sandboxes.
Saver-Code:
writeup: https://theevilbit.github.io/beyond/beyond_0011/
Nützlich, um die Sandbox zu umgehen: 🟠
Aber du wirst in einer Anwendungssandbox enden
TCC-Umgehung: 🔴
Die Sandbox sieht sehr eingeschränkt aus
~/Library/Spotlight/
Trigger: Eine neue Datei mit einer von dem Spotlight-Plugin verwalteten Erweiterung wird erstellt.
/Library/Spotlight/
Trigger: Eine neue Datei mit einer von dem Spotlight-Plugin verwalteten Erweiterung wird erstellt.
Root erforderlich
/System/Library/Spotlight/
Trigger: Eine neue Datei mit einer von dem Spotlight-Plugin verwalteten Erweiterung wird erstellt.
Root erforderlich
Some.app/Contents/Library/Spotlight/
Trigger: Eine neue Datei mit einer von dem Spotlight-Plugin verwalteten Erweiterung wird erstellt.
Neue App erforderlich
Spotlight ist die integrierte Suchfunktion von macOS, die entwickelt wurde, um den Benutzern schnellen und umfassenden Zugriff auf Daten auf ihren Computern zu bieten. Um diese schnelle Suchfunktion zu ermöglichen, verwaltet Spotlight eine proprietäre Datenbank und erstellt ein Index, indem es die meisten Dateien analysiert, was schnelle Suchen sowohl durch Dateinamen als auch durch deren Inhalt ermöglicht.
Der zugrunde liegende Mechanismus von Spotlight umfasst einen zentralen Prozess namens 'mds', was für 'Metadaten-Server' steht. Dieser Prozess orchestriert den gesamten Spotlight-Dienst. Ergänzend dazu gibt es mehrere 'mdworker'-Dämonen, die eine Vielzahl von Wartungsaufgaben durchführen, wie das Indizieren verschiedener Dateitypen (ps -ef | grep mdworker
). Diese Aufgaben werden durch Spotlight-Importer-Plugins oder ".mdimporter-Bundles" ermöglicht, die Spotlight in die Lage versetzen, Inhalte über eine Vielzahl von Dateiformaten hinweg zu verstehen und zu indizieren.
Die Plugins oder .mdimporter
-Bundles befinden sich an den zuvor genannten Orten, und wenn ein neues Bundle erscheint, wird es innerhalb von Minuten geladen (kein Neustart eines Dienstes erforderlich). Diese Bundles müssen angeben, welche Dateitypen und Erweiterungen sie verwalten können, damit Spotlight sie verwendet, wenn eine neue Datei mit der angegebenen Erweiterung erstellt wird.
Es ist möglich, alle mdimporters
zu finden, die gerade geladen sind:
Und zum Beispiel /Library/Spotlight/iBooksAuthor.mdimporter wird verwendet, um diese Art von Dateien (Erweiterungen .iba
und .book
unter anderem) zu parsen:
Wenn Sie die Plist anderer mdimporter
überprüfen, finden Sie möglicherweise nicht den Eintrag UTTypeConformsTo
. Das liegt daran, dass dies ein integrierter Uniform Type Identifiers (UTI) ist und keine Erweiterungen angegeben werden müssen.
Darüber hinaus haben die Standard-Plugins des Systems immer Vorrang, sodass ein Angreifer nur auf Dateien zugreifen kann, die nicht anderweitig von Apples eigenen mdimporters
indiziert werden.
Um Ihren eigenen Importer zu erstellen, könnten Sie mit diesem Projekt beginnen: https://github.com/megrimm/pd-spotlight-importer und dann den Namen, die CFBundleDocumentTypes
ändern und UTImportedTypeDeclarations
hinzufügen, damit es die Erweiterung unterstützt, die Sie unterstützen möchten, und sie in schema.xml
reflektieren.
Ändern Sie dann den Code der Funktion GetMetadataForFile
, um Ihre Payload auszuführen, wenn eine Datei mit der verarbeiteten Erweiterung erstellt wird.
Schließlich bauen und kopieren Sie Ihr neues .mdimporter
in einen der vorherigen Speicherorte, und Sie können überprüfen, ob es geladen wird, indem Sie die Protokolle überwachen oder mdimport -L.
überprüfen.
Es sieht nicht so aus, als würde das noch funktionieren.
Writeup: https://theevilbit.github.io/beyond/beyond_0009/
/System/Library/PreferencePanes
/Library/PreferencePanes
~/Library/PreferencePanes
Es sieht nicht so aus, als würde das noch funktionieren.
Hier finden Sie Startorte, die nützlich für die Sandbox-Umgehung sind, die es Ihnen ermöglicht, einfach etwas auszuführen, indem Sie es in eine Datei schreiben, während Sie root sind und/oder andere seltsame Bedingungen erfordern.
Writeup: https://theevilbit.github.io/beyond/beyond_0019/
/etc/periodic/daily
, /etc/periodic/weekly
, /etc/periodic/monthly
, /usr/local/etc/periodic
Root erforderlich
Auslöser: Wenn die Zeit gekommen ist
/etc/daily.local
, /etc/weekly.local
oder /etc/monthly.local
Root erforderlich
Auslöser: Wenn die Zeit gekommen ist
Die periodischen Skripte (/etc/periodic
) werden aufgrund der Launch-Daemons ausgeführt, die in /System/Library/LaunchDaemons/com.apple.periodic*
konfiguriert sind. Beachten Sie, dass Skripte, die in /etc/periodic/
gespeichert sind, als der Eigentümer der Datei ausgeführt werden, sodass dies nicht für eine potenzielle Privilegieneskalation funktioniert.
Es gibt andere periodische Skripte, die ausgeführt werden, die in /etc/defaults/periodic.conf
angegeben sind:
Wenn Sie es schaffen, eine der Dateien /etc/daily.local
, /etc/weekly.local
oder /etc/monthly.local
zu schreiben, wird sie so oder so ausgeführt.
Beachten Sie, dass das periodische Skript als Eigentümer des Skripts ausgeführt wird. Wenn also ein regulärer Benutzer das Skript besitzt, wird es als dieser Benutzer ausgeführt (dies könnte Privilegieneskalationsangriffe verhindern).
Writeup: Linux Hacktricks PAM Writeup: https://theevilbit.github.io/beyond/beyond_0005/
Root immer erforderlich
Da sich PAM mehr auf Persistenz und Malware konzentriert als auf die einfache Ausführung innerhalb von macOS, wird dieser Blog keine detaillierte Erklärung geben, lesen Sie die Writeups, um diese Technik besser zu verstehen.
Überprüfen Sie die PAM-Module mit:
Eine Persistenz-/Privilegienerhöhungstechnik, die PAM ausnutzt, ist so einfach wie das Ändern des Moduls /etc/pam.d/sudo, indem man am Anfang die Zeile hinzufügt:
So wird es aussehen wie etwas wie dies:
Und daher wird jeder Versuch, sudo
zu verwenden, funktionieren.
Beachten Sie, dass dieses Verzeichnis durch TCC geschützt ist, sodass es sehr wahrscheinlich ist, dass der Benutzer eine Aufforderung zur Zugriffsanfrage erhält.
Ein weiteres schönes Beispiel ist su, wo Sie sehen können, dass es auch möglich ist, Parameter an die PAM-Module zu übergeben (und Sie könnten auch diese Datei mit einem Backdoor versehen):
Writeup: https://theevilbit.github.io/beyond/beyond_0028/ Writeup: https://posts.specterops.io/persistent-credential-theft-with-authorization-plugins-d17b34719d65
Nützlich, um die Sandbox zu umgehen: 🟠
Aber du musst root sein und zusätzliche Konfigurationen vornehmen
TCC-Umgehung: ???
/Library/Security/SecurityAgentPlugins/
Root erforderlich
Es ist auch notwendig, die Autorisierungsdatenbank zu konfigurieren, um das Plugin zu verwenden
Du kannst ein Autorisierungs-Plugin erstellen, das ausgeführt wird, wenn sich ein Benutzer anmeldet, um Persistenz aufrechtzuerhalten. Für weitere Informationen darüber, wie man eines dieser Plugins erstellt, siehe die vorherigen Writeups (und sei vorsichtig, ein schlecht geschriebenes kann dich aussperren und du musst deinen Mac im Wiederherstellungsmodus bereinigen).
Verschieben Sie das Bundle an den Ort, an dem es geladen werden soll:
Schließlich fügen Sie die Regel hinzu, um dieses Plugin zu laden:
Die evaluate-mechanisms
wird dem Autorisierungsrahmen mitteilen, dass er einen externen Mechanismus zur Autorisierung aufrufen muss. Darüber hinaus wird privileged
bewirken, dass es von root ausgeführt wird.
Triggern Sie es mit:
Und dann sollte die staff-Gruppe sudo-Zugriff haben (lesen Sie /etc/sudoers
, um dies zu bestätigen).
Writeup: https://theevilbit.github.io/beyond/beyond_0030/
Nützlich, um die Sandbox zu umgehen: 🟠
Aber Sie müssen root sein und der Benutzer muss man verwenden
TCC-Umgehung: 🔴
/private/etc/man.conf
Root erforderlich
/private/etc/man.conf
: Wann immer man verwendet wird
Die Konfigurationsdatei /private/etc/man.conf
gibt das Binary/Skript an, das beim Öffnen von man-Dokumentationsdateien verwendet werden soll. Der Pfad zur ausführbaren Datei könnte so geändert werden, dass jedes Mal, wenn der Benutzer man verwendet, um einige Dokumente zu lesen, ein Backdoor ausgeführt wird.
Zum Beispiel in /private/etc/man.conf
festgelegt:
Und dann erstelle /tmp/view
als:
Writeup: https://theevilbit.github.io/beyond/beyond_0023/
Nützlich, um die Sandbox zu umgehen: 🟠
Aber du musst root sein und Apache muss laufen
TCC-Umgehung: 🔴
Httpd hat keine Berechtigungen
/etc/apache2/httpd.conf
Root erforderlich
Auslöser: Wenn Apache2 gestartet wird
Du kannst in /etc/apache2/httpd.conf
angeben, ein Modul zu laden, indem du eine Zeile wie folgt hinzufügst:
Auf diese Weise werden Ihre kompilierten Module von Apache geladen. Das Einzige ist, dass Sie es entweder mit einem gültigen Apple-Zertifikat signieren müssen oder Sie müssen ein neues vertrauenswürdiges Zertifikat im System hinzufügen und es damit signieren.
Dann, falls erforderlich, um sicherzustellen, dass der Server gestartet wird, könnten Sie ausführen:
Codebeispiel für das Dylb:
Writeup: https://theevilbit.github.io/beyond/beyond_0031/
Nützlich, um die Sandbox zu umgehen: 🟠
Aber du musst root sein, auditd muss laufen und eine Warnung auslösen
TCC-Umgehung: 🔴
/etc/security/audit_warn
Root erforderlich
Auslöser: Wenn auditd eine Warnung erkennt
Wann immer auditd eine Warnung erkennt, wird das Skript /etc/security/audit_warn
ausgeführt. Du könntest also deinen Payload dort hinzufügen.
You could force a warning with sudo audit -n
.
Dies ist veraltet, daher sollte in diesen Verzeichnissen nichts gefunden werden.
Der StartupItem ist ein Verzeichnis, das entweder innerhalb von /Library/StartupItems/
oder /System/Library/StartupItems/
positioniert sein sollte. Sobald dieses Verzeichnis eingerichtet ist, muss es zwei spezifische Dateien enthalten:
Ein rc-Skript: Ein Shell-Skript, das beim Start ausgeführt wird.
Eine plist-Datei, die speziell StartupParameters.plist
genannt wird und verschiedene Konfigurationseinstellungen enthält.
Stellen Sie sicher, dass sowohl das rc-Skript als auch die StartupParameters.plist
-Datei korrekt im StartupItem-Verzeichnis platziert sind, damit der Startprozess sie erkennen und nutzen kann.
Ich kann diese Komponente in meinem macOS nicht finden, also für weitere Informationen siehe den Bericht
Bericht: https://theevilbit.github.io/beyond/beyond_0023/
Eingeführt von Apple, emond ist ein Protokollierungsmechanismus, der unterentwickelt oder möglicherweise aufgegeben zu sein scheint, jedoch weiterhin zugänglich bleibt. Während es für einen Mac-Administrator nicht besonders vorteilhaft ist, könnte dieser obskure Dienst als subtile Persistenzmethode für Bedrohungsakteure dienen, wahrscheinlich unbemerkt von den meisten macOS-Administratoren.
Für diejenigen, die sich seiner Existenz bewusst sind, ist die Identifizierung jeglicher böswilliger Nutzung von emond unkompliziert. Der LaunchDaemon des Systems für diesen Dienst sucht nach Skripten, die in einem einzigen Verzeichnis ausgeführt werden sollen. Um dies zu überprüfen, kann der folgende Befehl verwendet werden:
Writeup: https://theevilbit.github.io/beyond/beyond_0018/
/opt/X11/etc/X11/xinit/privileged_startx.d
Root erforderlich
Auslöser: Mit XQuartz
XQuartz ist nicht mehr in macOS installiert, also wenn Sie mehr Informationen möchten, überprüfen Sie den Bericht.
Es ist so kompliziert, kext selbst als Root zu installieren, dass ich dies nicht in Betracht ziehen werde, um aus Sandkästen zu entkommen oder sogar für Persistenz (es sei denn, Sie haben einen Exploit)
Um ein KEXT als Startobjekt zu installieren, muss es in einem der folgenden Standorte installiert werden:
/System/Library/Extensions
KEXT-Dateien, die in das OS X-Betriebssystem integriert sind.
/Library/Extensions
KEXT-Dateien, die von Drittanbieter-Software installiert wurden
Sie können derzeit geladene kext-Dateien auflisten mit:
Für weitere Informationen über Kernel-Erweiterungen überprüfen Sie diesen Abschnitt.
Schreibweise: https://theevilbit.github.io/beyond/beyond_0029/
/usr/local/bin/amstoold
Root erforderlich
Offensichtlich verwendete die plist
von /System/Library/LaunchAgents/com.apple.amstoold.plist
dieses Binary, während ein XPC-Dienst exponiert wurde... das Problem ist, dass das Binary nicht existierte, sodass Sie dort etwas platzieren konnten und wenn der XPC-Dienst aufgerufen wird, wird Ihr Binary aufgerufen.
Ich kann das in meinem macOS nicht mehr finden.
Schreibweise: https://theevilbit.github.io/beyond/beyond_0015/
/Library/Preferences/Xsan/.xsanrc
Root erforderlich
Auslöser: Wenn der Dienst ausgeführt wird (selten)
Offensichtlich ist es nicht sehr verbreitet, dieses Skript auszuführen, und ich konnte es nicht einmal in meinem macOS finden, also wenn Sie mehr Informationen möchten, überprüfen Sie die Schreibweise.
Das funktioniert nicht in modernen macOS-Versionen
Es ist auch möglich, hier Befehle zu platzieren, die beim Start ausgeführt werden. Beispiel eines regulären rc.common-Skripts:
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)