hacktricks/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox/macos-sandbox-debug-and-bypass/macos-office-sandbox-bypasses.md

7.4 KiB
Raw Blame History

Contournements du bac à sable macOS Office

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

Autres moyens de soutenir HackTricks :

Contournement du bac à sable Word via les Launch Agents

L'application utilise un bac à sable personnalisé avec le droit com.apple.security.temporary-exception.sbpl et ce bac à sable personnalisé permet d'écrire des fichiers n'importe où tant que le nom du fichier commence par ~$ : (require-any (require-all (vnode-type REGULAR-FILE) (regex #"(^|/)~$[^/]+$")))

Par conséquent, s'échapper était aussi simple que d'écrire un plist LaunchAgent dans ~/Library/LaunchAgents/~$escape.plist.

Consultez le rapport original ici.

Contournement du bac à sable Word via les éléments de connexion et zip

Rappelez-vous que depuis la première évasion, Word peut écrire des fichiers arbitraires dont le nom commence par ~$, bien qu'après le correctif de la vulnérabilité précédente, il n'était plus possible d'écrire dans /Library/Application Scripts ou dans /Library/LaunchAgents.

Il a été découvert qu'à partir du bac à sable, il est possible de créer un élément de connexion (applications qui seront exécutées lorsque l'utilisateur se connecte). Cependant, ces applications ne s'exécuteront pas à moins qu'elles ne soient notarisées et il n'est pas possible d'ajouter des arguments (vous ne pouvez donc pas simplement exécuter un shell inversé en utilisant bash).

À partir du contournement précédent du bac à sable, Microsoft a désactivé l'option d'écrire des fichiers dans ~/Library/LaunchAgents. Cependant, il a été découvert que si vous mettez un fichier zip comme élément de connexion, l'Archive Utility va juste décompresser le fichier à son emplacement actuel. Donc, parce que par défaut le dossier LaunchAgents de ~/Library n'est pas créé, il était possible de zipper un plist dans LaunchAgents/~$escape.plist et de placer le fichier zip dans ~/Library afin que lors de la décompression, il atteigne la destination de persistance.

Consultez le rapport original ici.

Contournement du bac à sable Word via les éléments de connexion et .zshenv

(Rappelez-vous que depuis la première évasion, Word peut écrire des fichiers arbitraires dont le nom commence par ~$).

Cependant, la technique précédente avait une limitation, si le dossier ~/Library/LaunchAgents existe parce qu'un autre logiciel l'a créé, elle échouerait. Une autre chaîne d'éléments de connexion a donc été découverte pour cela.

Un attaquant pourrait créer les fichiers .bash_profile et .zshenv avec la charge utile à exécuter, puis les zipper et écrire le zip dans le dossier utilisateur de la victime : ~/~$escape.zip.

Ensuite, ajoutez le fichier zip aux éléments de connexion puis à l'application Terminal. Lorsque l'utilisateur se reconnecte, le fichier zip serait décompressé dans le fichier de l'utilisateur, écrasant .bash_profile et .zshenv et donc, le terminal exécutera l'un de ces fichiers (selon si bash ou zsh est utilisé).

Consultez le rapport original ici.

Contournement du bac à sable Word avec Open et les variables d'environnement

Depuis des processus en bac à sable, il est toujours possible d'invoquer d'autres processus en utilisant l'utilitaire open. De plus, ces processus s'exécuteront dans leur propre bac à sable.

Il a été découvert que l'utilitaire open a l'option --env pour exécuter une application avec des variables d'environnement spécifiques. Par conséquent, il était possible de créer le fichier .zshenv dans un dossier à l'intérieur du bac à sable et d'utiliser open avec --env en définissant la variable HOME sur ce dossier en ouvrant l'application Terminal, qui exécutera le fichier .zshenv (pour une raison quelconque, il était également nécessaire de définir la variable __OSINSTALL_ENVIROMENT).

Consultez le rapport original ici.

Contournement du bac à sable Word avec Open et stdin

L'utilitaire open prenait également en charge le paramètre --stdin (et après le contournement précédent, il n'était plus possible d'utiliser --env).

Le fait est que même si python était signé par Apple, il n'exécuterait pas un script avec l'attribut quarantine. Cependant, il était possible de lui passer un script depuis stdin afin qu'il ne vérifie pas s'il était mis en quarantaine ou non :

  1. Déposez un fichier ~$exploit.py avec des commandes Python arbitraires.
  2. Exécutez open stdin='~$exploit.py' -a Python, qui exécute l'application Python avec notre fichier déposé servant d'entrée standard. Python exécute joyeusement notre code, et comme c'est un processus enfant de launchd, il n'est pas lié aux règles du bac à sable de Word.
Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :