macOS Dirty NIB

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

Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
Découvrez The PEASS Family, notre collection exclusive de NFT
Obtenez le swag officiel PEASS & HackTricks
Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦@carlospolopm.
Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Cette technique a été tirée de l'article https://blog.xpnsec.com/dirtynib/

Informations de base

Les fichiers NIB sont utilisés dans l'écosystème de développement d'Apple pour définir les éléments de l'interface utilisateur (UI) et leurs interactions au sein d'une application. Créés avec l'outil Interface Builder, ils contiennent des objets sérialisés tels que des fenêtres, des boutons et des champs de texte, qui sont chargés au moment de l'exécution pour présenter l'interface utilisateur conçue. Bien qu'ils soient encore utilisés, Apple recommande désormais l'utilisation de Storyboards pour une représentation plus visuelle du flux de l'interface utilisateur d'une application.

{% hint style="danger" %} De plus, les fichiers NIB peuvent également être utilisés pour exécuter des commandes arbitraires et si le fichier NIB est modifié dans une application, Gatekeeper autorisera toujours l'exécution de l'application, ce qui permet d'exécuter des commandes arbitraires à l'intérieur des applications. {% endhint %}

Injection de Dirty NIB

Tout d'abord, nous devons créer un nouveau fichier NIB, nous utiliserons XCode pour la majeure partie de la construction. Nous commençons par ajouter un objet à l'interface et définir la classe sur NSAppleScript :

Pour l'objet, nous devons définir la propriété initiale source, ce que nous pouvons faire en utilisant les attributs d'exécution définis par l'utilisateur :

Cela configure notre gadget d'exécution de code, qui va simplement exécuter AppleScript sur demande. Pour déclencher réellement l'exécution de l'AppleScript, nous allons simplement ajouter un bouton pour le moment (vous pouvez bien sûr faire preuve de créativité avec cela ;). Le bouton sera lié à l'objet Apple Script que nous venons de créer, et invoquera le sélecteur executeAndReturnError: :

Pour les tests, nous utiliserons simplement l'Apple Script suivant :

set theDialogText to "PWND"
display dialog theDialogText

Et si nous exécutons cela dans le débogueur XCode et appuyons sur le bouton :

Avec notre capacité à exécuter du code AppleScript arbitraire à partir d'un NIB, nous avons ensuite besoin d'une cible. Choisissons Pages pour notre démonstration initiale, qui est bien sûr une application Apple et ne devrait certainement pas être modifiable par nous.

Nous allons d'abord faire une copie de l'application dans /tmp/ :

cp -a -X /Applications/Pages.app /tmp/

Ensuite, nous lancerons l'application pour éviter tout problème de Gatekeeper et permettre la mise en cache des éléments :

open -W -g -j /Applications/Pages.app

Après avoir lancé (et tué) l'application une première fois, nous devrons écraser un fichier NIB existant avec notre fichier DirtyNIB. À des fins de démonstration, nous allons simplement écraser le fichier NIB du panneau À propos afin de pouvoir contrôler l'exécution :

cp /tmp/Dirty.nib /tmp/Pages.app/Contents/Resources/Base.lproj/TMAAboutPanel.nib

Une fois que nous avons écrasé le nib, nous pouvons déclencher l'exécution en sélectionnant l'élément de menu À propos :

Si nous examinons de plus près Pages, nous constatons qu'il dispose d'une autorisation privée permettant d'accéder aux photos des utilisateurs :

Nous pouvons donc mettre notre POC à l'épreuve en modifiant notre AppleScript pour voler les photos de l'utilisateur sans demander la permission :

{% code overflow="wrap" %}

use framework "Cocoa"
use framework "Foundation"

set grabbed to current application's NSData's dataWithContentsOfFile:"/Users/xpn/Pictures/Photos Library.photoslibrary/originals/6/68CD9A98-E591-4D39-B038-E1B3F982C902.gif"

grabbed's writeToFile:"/Users/xpn/Library/Containers/com.apple.iWork.Pages/Data/wtf.gif" atomically:1

{% endcode %}

{% hint style="danger" %} Exemple de fichier .xib malveillant exécutant du code arbitraire. {% endhint %}

Contraintes de lancement

Elles empêchent essentiellement l'exécution d'applications en dehors de leurs emplacements prévus, donc si vous copiez une application protégée par des contraintes de lancement dans /tmp, vous ne pourrez pas l'exécuter.
Trouvez plus d'informations dans cet article.

Cependant, en analysant le fichier /System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4, vous pouvez toujours trouver des applications qui ne sont pas protégées par des contraintes de lancement, vous pouvez donc toujours injecter des fichiers NIB dans des emplacements arbitraires dans ces applications (consultez le lien précédent pour apprendre comment trouver ces applications).

Protections supplémentaires

Depuis macOS Somona, il existe des protections empêchant l'écriture à l'intérieur des applications. Cependant, il est toujours possible de contourner cette protection si, avant d'exécuter votre copie du binaire, vous changez le nom du dossier Contents :

Faites une copie de CarPlay Simulator.app dans /tmp/
Renommez /tmp/Carplay Simulator.app/Contents en /tmp/CarPlay Simulator.app/NotCon
Lancez le binaire /tmp/CarPlay Simulator.app/NotCon/MacOS/CarPlay Simulator pour le mettre en cache dans Gatekeeper
Remplacez NotCon/Resources/Base.lproj/MainMenu.nib par notre fichier Dirty.nib
Renommez en /tmp/CarPlay Simulator.app/Contents
Lancez à nouveau CarPlay Simulator.app