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

6.5 KiB
Raw Blame History

Contournement de la Sandbox de Word sur macOS

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Contournement de la Sandbox de Word via les Launch Agents

L'application utilise une Sandbox personnalisée en utilisant l'entitlement com.apple.security.temporary-exception.sbpl et cette Sandbox personnalisée permet d'écrire des fichiers n'importe où tant que le nom de fichier commence par ~$ : (require-any (require-all (vnode-type REGULAR-FILE) (regex #"(^|/)~$[^/]+$")))

Par conséquent, l'évasion était aussi facile que d'écrire un fichier plist LaunchAgent dans ~/Library/LaunchAgents/~$escape.plist.

Consultez le rapport original ici.

Contournement de la Sandbox de Word via les Login Items et zip

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

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

À partir de la précédente évasion de la Sandbox, Microsoft a désactivé l'option d'écriture de fichiers dans ~/Library/LaunchAgents. Cependant, il a été découvert que si vous mettez un fichier zip en tant que Login Item, l'Archive Utility va simplement le décompresser à son emplacement actuel. Ainsi, comme par défaut le dossier LaunchAgents de ~/Library n'est pas créé, il était possible de compresser un plist dans LaunchAgents/~$escape.plist et de placer le fichier zip dans ~/Library afin que lorsqu'il est décompressé, il atteigne la destination de persistance.

Consultez le rapport original ici.

Contournement de la Sandbox de Word via les Login Items 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éé, cela échouera. Une chaîne de Login Items différente 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 compresser et écrire le zip dans le dossier de l'utilisateur victime : ~/~$escape.zip.

Ensuite, ajoutez le fichier zip aux Login Items et ensuite l'application Terminal. Lorsque l'utilisateur se reconnecte, le fichier zip sera décompressé dans les fichiers de l'utilisateur, écrasant .bash_profile et .zshenv et donc, le terminal exécutera l'un de ces fichiers (selon que bash ou zsh est utilisé).

Consultez le rapport original ici.

Contournement de la Sandbox de Word avec Open et les variables d'environnement

À partir des processus Sandbox, il est toujours possible d'appeler d'autres processus en utilisant l'utilitaire open. De plus, ces processus s'exécuteront dans leur propre Sandbox.

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 de la sandbox et d'utiliser open avec --env en définissant la variable HOME sur ce dossier en ouvrant cette 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 de la Sandbox de Word avec Open et stdin

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

Le truc, c'est que même si python était signé par Apple, il n'exécutera 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é en tant qu'entrée standard. Python exécute joyeusement notre code, et comme c'est un processus enfant de launchd, il n'est pas soumis aux règles de la Sandbox de Word.