macOS Gatekeeper / Quarantine / XProtect

Reading time: 22 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Soutenir HackTricks

Gatekeeper

Gatekeeper est une fonctionnalité de sécurité développée pour les systÚmes d'exploitation Mac, conçue pour garantir que les utilisateurs n'exécutent que des logiciels de confiance sur leurs systÚmes. Elle fonctionne en validant les logiciels qu'un utilisateur télécharge et tente d'ouvrir à partir de sources extérieures à l'App Store, comme une application, un plug-in ou un package d'installation.

Le mécanisme clé de Gatekeeper réside dans son processus de vérification. Il vérifie si le logiciel téléchargé est signé par un développeur reconnu, garantissant l'authenticité du logiciel. De plus, il s'assure que le logiciel est notarié par Apple, confirmant qu'il ne contient pas de contenu malveillant connu et qu'il n'a pas été altéré aprÚs la notarisation.

De plus, Gatekeeper renforce le contrÎle et la sécurité des utilisateurs en demandant aux utilisateurs d'approuver l'ouverture du logiciel téléchargé pour la premiÚre fois. Cette protection aide à prévenir les utilisateurs d'exécuter involontairement un code exécutable potentiellement nuisible qu'ils auraient pu confondre avec un fichier de données inoffensif.

Signatures d'application

Les signatures d'application, également connues sous le nom de signatures de code, sont un élément critique de l'infrastructure de sécurité d'Apple. Elles sont utilisées pour vérifier l'identité de l'auteur du logiciel (le développeur) et pour s'assurer que le code n'a pas été altéré depuis sa derniÚre signature.

Voici comment cela fonctionne :

  1. Signature de l'application : Lorsqu'un dĂ©veloppeur est prĂȘt Ă  distribuer son application, il signe l'application Ă  l'aide d'une clĂ© privĂ©e. Cette clĂ© privĂ©e est associĂ©e Ă  un certificat que Apple dĂ©livre au dĂ©veloppeur lorsqu'il s'inscrit au programme de dĂ©veloppement Apple. Le processus de signature implique de crĂ©er un hachage cryptographique de toutes les parties de l'application et de chiffrer ce hachage avec la clĂ© privĂ©e du dĂ©veloppeur.
  2. Distribution de l'application : L'application signée est ensuite distribuée aux utilisateurs avec le certificat du développeur, qui contient la clé publique correspondante.
  3. Vérification de l'application : Lorsqu'un utilisateur télécharge et tente d'exécuter l'application, son systÚme d'exploitation Mac utilise la clé publique du certificat du développeur pour déchiffrer le hachage. Il recalcule ensuite le hachage en fonction de l'état actuel de l'application et le compare avec le hachage déchiffré. S'ils correspondent, cela signifie que l'application n'a pas été modifiée depuis que le développeur l'a signée, et le systÚme permet à l'application de s'exécuter.

Les signatures d'application sont une partie essentielle de la technologie Gatekeeper d'Apple. Lorsqu'un utilisateur tente d'ouvrir une application téléchargée depuis Internet, Gatekeeper vérifie la signature de l'application. Si elle est signée avec un certificat délivré par Apple à un développeur connu et que le code n'a pas été altéré, Gatekeeper permet à l'application de s'exécuter. Sinon, il bloque l'application et alerte l'utilisateur.

À partir de macOS Catalina, Gatekeeper vĂ©rifie Ă©galement si l'application a Ă©tĂ© notariĂ©e par Apple, ajoutant une couche de sĂ©curitĂ© supplĂ©mentaire. Le processus de notarisation vĂ©rifie l'application pour des problĂšmes de sĂ©curitĂ© connus et du code malveillant, et si ces vĂ©rifications sont rĂ©ussies, Apple ajoute un ticket Ă  l'application que Gatekeeper peut vĂ©rifier.

VĂ©rifier les signatures

Lors de la vĂ©rification d'un Ă©chantillon de malware, vous devez toujours vĂ©rifier la signature du binaire car le dĂ©veloppeur qui l'a signĂ© peut dĂ©jĂ  ĂȘtre liĂ© Ă  du malware.

bash
# Get signer codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier" # Check if the app’s contents have been modified codesign --verify --verbose /Applications/Safari.app # Get entitlements from the binary codesign -d --entitlements :- /System/Applications/Automator.app # Check the TCC perms # Check if the signature is valid spctl --assess --verbose /Applications/Safari.app # Sign a binary codesign -s <cert-name-keychain> toolsdemo

Notarisation

Le processus de notarisation d'Apple sert de protection supplĂ©mentaire pour protĂ©ger les utilisateurs contre les logiciels potentiellement nuisibles. Il implique que le dĂ©veloppeur soumette son application Ă  l'examen du Service de Notariat d'Apple, qui ne doit pas ĂȘtre confondu avec l'App Review. Ce service est un systĂšme automatisĂ© qui scrute le logiciel soumis Ă  la recherche de contenu malveillant et de tout problĂšme potentiel avec la signature du code.

Si le logiciel passe cette inspection sans soulever de prĂ©occupations, le Service de Notariat gĂ©nĂšre un ticket de notarisation. Le dĂ©veloppeur est ensuite tenu de joindre ce ticket Ă  son logiciel, un processus connu sous le nom de 'stapling.' De plus, le ticket de notarisation est Ă©galement publiĂ© en ligne oĂč Gatekeeper, la technologie de sĂ©curitĂ© d'Apple, peut y accĂ©der.

Lors de la premiÚre installation ou exécution du logiciel par l'utilisateur, l'existence du ticket de notarisation - qu'il soit attaché à l'exécutable ou trouvé en ligne - informe Gatekeeper que le logiciel a été notarié par Apple. En conséquence, Gatekeeper affiche un message descriptif dans la boßte de dialogue de lancement initial, indiquant que le logiciel a subi des vérifications pour contenu malveillant par Apple. Ce processus renforce ainsi la confiance des utilisateurs dans la sécurité du logiciel qu'ils installent ou exécutent sur leurs systÚmes.

spctl & syspolicyd

caution

Notez qu'Ă  partir de la version Sequoia, spctl ne permet plus de modifier la configuration de Gatekeeper.

spctl est l'outil CLI pour énumérer et interagir avec Gatekeeper (avec le démon syspolicyd via des messages XPC). Par exemple, il est possible de voir le statut de GateKeeper avec :

bash
# Check the status spctl --status

caution

Notez que les vérifications de signature de GateKeeper ne sont effectuées que sur les fichiers avec l'attribut Quarantine, et non sur chaque fichier.

GateKeeper vĂ©rifiera si, selon les prĂ©fĂ©rences et la signature, un binaire peut ĂȘtre exĂ©cutĂ© :

syspolicyd est le principal démon responsable de l'application de Gatekeeper. Il maintient une base de données située dans /var/db/SystemPolicy et il est possible de trouver le code pour soutenir la base de données ici et le modÚle SQL ici. Notez que la base de données n'est pas restreinte par SIP et est écrivable par root, et la base de données /var/db/.SystemPolicy-default est utilisée comme sauvegarde originale en cas de corruption de l'autre.

De plus, les bundles /var/db/gke.bundle et /var/db/gkopaque.bundle contiennent des fichiers avec des rÚgles qui sont insérées dans la base de données. Vous pouvez vérifier cette base de données en tant que root avec :

bash
# Open database sqlite3 /var/db/SystemPolicy # Get allowed rules SELECT requirement,allow,disabled,label from authority where label != 'GKE' and disabled=0; requirement|allow|disabled|label anchor apple generic and certificate 1[subject.CN] = "Apple Software Update Certification Authority"|1|0|Apple Installer anchor apple|1|0|Apple System anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] exists|1|0|Mac App Store anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists and (certificate leaf[field.1.2.840.113635.100.6.1.14] or certificate leaf[field.1.2.840.113635.100.6.1.13]) and notarized|1|0|Notarized Developer ID [...]

syspolicyd expose également un serveur XPC avec différentes opérations comme assess, update, record et cancel qui sont également accessibles via les API SecAssessment* de Security.framework et xpctl communique en fait avec syspolicyd via XPC.

Notez comment la premiÚre rÚgle se termine par "App Store" et la deuxiÚme par "Developer ID" et que dans l'image précédente, il était activé pour exécuter des applications du App Store et des développeurs identifiés.
Si vous modifiez ce paramÚtre pour App Store, les "rÚgles de Developer ID notarié" disparaßtront.

Il existe Ă©galement des milliers de rĂšgles de type GKE :

bash
SELECT requirement,allow,disabled,label from authority where label = 'GKE' limit 5; cdhash H"b40281d347dc574ae0850682f0fd1173aa2d0a39"|1|0|GKE cdhash H"5fd63f5342ac0c7c0774ebcbecaf8787367c480f"|1|0|GKE cdhash H"4317047eefac8125ce4d44cab0eb7b1dff29d19a"|1|0|GKE cdhash H"0a71962e7a32f0c2b41ddb1fb8403f3420e1d861"|1|0|GKE cdhash H"8d0d90ff23c3071211646c4c9c607cdb601cb18f"|1|0|GKE

Ce sont des hachages provenant de :

  • /var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gke.auth
  • /var/db/gke.bundle/Contents/Resources/gk.db
  • /var/db/gkopaque.bundle/Contents/Resources/gkopaque.db

Ou vous pourriez lister les informations précédentes avec :

bash
sudo spctl --list

Les options --master-disable et --global-disable de spctl désactiveront complÚtement ces vérifications de signature :

bash
# Disable GateKeeper spctl --global-disable spctl --master-disable # Enable it spctl --global-enable spctl --master-enable

Lorsqu'il est complÚtement activé, une nouvelle option apparaßtra :

Il est possible de vérifier si une application sera autorisée par GateKeeper avec :

bash
spctl --assess -v /Applications/App.app

Il est possible d'ajouter de nouvelles rÚgles dans GateKeeper pour autoriser l'exécution de certaines applications avec :

bash
# Check if allowed - nop spctl --assess -v /Applications/App.app /Applications/App.app: rejected source=no usable signature # Add a label and allow this label in GateKeeper sudo spctl --add --label "whitelist" /Applications/App.app sudo spctl --enable --label "whitelist" # Check again - yep spctl --assess -v /Applications/App.app /Applications/App.app: accepted

Concernant les extensions de noyau, le dossier /var/db/SystemPolicyConfiguration contient des fichiers avec des listes de kexts autorisĂ©s Ă  ĂȘtre chargĂ©s. De plus, spctl a le droit com.apple.private.iokit.nvram-csr car il est capable d'ajouter de nouvelles extensions de noyau prĂ©-approuvĂ©es qui doivent Ă©galement ĂȘtre enregistrĂ©es dans la NVRAM dans une clĂ© kext-allowed-teams.

Fichiers de Quarantaine

Lors du téléchargement d'une application ou d'un fichier, des applications macOS spécifiques telles que les navigateurs web ou les clients de messagerie ajoutent un attribut de fichier étendu, communément connu sous le nom de "drapeau de quarantaine", au fichier téléchargé. Cet attribut agit comme une mesure de sécurité pour marquer le fichier comme provenant d'une source non fiable (Internet) et pouvant comporter des risques. Cependant, toutes les applications n'ajoutent pas cet attribut, par exemple, les logiciels clients BitTorrent courants contournent généralement ce processus.

La présence d'un drapeau de quarantaine signale la fonctionnalité de sécurité Gatekeeper de macOS lorsque l'utilisateur tente d'exécuter le fichier.

Dans le cas oĂč le drapeau de quarantaine n'est pas prĂ©sent (comme avec les fichiers tĂ©lĂ©chargĂ©s via certains clients BitTorrent), les vĂ©rifications de Gatekeeper peuvent ne pas ĂȘtre effectuĂ©es. Ainsi, les utilisateurs doivent faire preuve de prudence lorsqu'ils ouvrent des fichiers tĂ©lĂ©chargĂ©s Ă  partir de sources moins sĂ©curisĂ©es ou inconnues.

[!NOTE] > Vérifier la validité des signatures de code est un processus intensif en ressources qui inclut la génération de hashs cryptographiques du code et de toutes ses ressources regroupées. De plus, vérifier la validité des certificats implique de faire une vérification en ligne auprÚs des serveurs d'Apple pour voir s'il a été révoqué aprÚs son émission. Pour ces raisons, une vérification complÚte de la signature de code et de la notarisation est impraticable à exécuter chaque fois qu'une application est lancée.

Par conséquent, ces vérifications ne sont effectuées que lors de l'exécution d'applications avec l'attribut de quarantaine.

warning

Cet attribut doit ĂȘtre dĂ©fini par l'application crĂ©ant/tĂ©lĂ©chargeant le fichier.

Cependant, les fichiers qui sont en bac Ă  sable auront cet attribut dĂ©fini pour chaque fichier qu'ils crĂ©ent. Et les applications non sandboxĂ©es peuvent le dĂ©finir elles-mĂȘmes, ou spĂ©cifier la clĂ© LSFileQuarantineEnabled dans le Info.plist qui fera en sorte que le systĂšme dĂ©finisse l'attribut Ă©tendu com.apple.quarantine sur les fichiers crĂ©Ă©s,

De plus, tous les fichiers créés par un processus appelant qtn_proc_apply_to_self sont mis en quarantaine. Ou l'API qtn_file_apply_to_path ajoute l'attribut de quarantaine à un chemin de fichier spécifié.

Il est possible de vérifier son statut et d'activer/désactiver (root requis) avec :

bash
spctl --status assessments enabled spctl --enable spctl --disable #You can also allow nee identifies to execute code using the binary "spctl"

Vous pouvez également vérifier si un fichier a l'attribut étendu de quarantaine avec :

bash
xattr file.png com.apple.macl com.apple.quarantine

VĂ©rifiez la valeur des attributs Ă©tendus et trouvez l'application qui a Ă©crit l'attribut de quarantaine avec :

bash
xattr -l portada.png com.apple.macl: 00000000 03 00 53 DA 55 1B AE 4C 4E 88 9D CA B7 5C 50 F3 |..S.U..LN.....P.| 00000010 16 94 03 00 27 63 64 97 98 FB 4F 02 84 F3 D0 DB |....'cd...O.....| 00000020 89 53 C3 FC 03 00 27 63 64 97 98 FB 4F 02 84 F3 |.S....'cd...O...| 00000030 D0 DB 89 53 C3 FC 00 00 00 00 00 00 00 00 00 00 |...S............| 00000040 00 00 00 00 00 00 00 00 |........| 00000048 com.apple.quarantine: 00C1;607842eb;Brave;F643CD5F-6071-46AB-83AB-390BA944DEC5 # 00c1 -- It has been allowed to eexcute this file (QTN_FLAG_USER_APPROVED = 0x0040) # 607842eb -- Timestamp # Brave -- App # F643CD5F-6071-46AB-83AB-390BA944DEC5 -- UID assigned to the file downloaded

En fait, un processus "pourrait définir des drapeaux de quarantaine sur les fichiers qu'il crée" (j'ai déjà essayé d'appliquer le drapeau USER_APPROVED sur un fichier créé, mais il ne s'applique pas) :

Code source appliquer des drapeaux de quarantaine
c
#include <stdio.h> #include <stdlib.h> enum qtn_flags { QTN_FLAG_DOWNLOAD = 0x0001, QTN_FLAG_SANDBOX = 0x0002, QTN_FLAG_HARD = 0x0004, QTN_FLAG_USER_APPROVED = 0x0040, }; #define qtn_proc_alloc _qtn_proc_alloc #define qtn_proc_apply_to_self _qtn_proc_apply_to_self #define qtn_proc_free _qtn_proc_free #define qtn_proc_init _qtn_proc_init #define qtn_proc_init_with_self _qtn_proc_init_with_self #define qtn_proc_set_flags _qtn_proc_set_flags #define qtn_file_alloc _qtn_file_alloc #define qtn_file_init_with_path _qtn_file_init_with_path #define qtn_file_free _qtn_file_free #define qtn_file_apply_to_path _qtn_file_apply_to_path #define qtn_file_set_flags _qtn_file_set_flags #define qtn_file_get_flags _qtn_file_get_flags #define qtn_proc_set_identifier _qtn_proc_set_identifier typedef struct _qtn_proc *qtn_proc_t; typedef struct _qtn_file *qtn_file_t; int qtn_proc_apply_to_self(qtn_proc_t); void qtn_proc_init(qtn_proc_t); int qtn_proc_init_with_self(qtn_proc_t); int qtn_proc_set_flags(qtn_proc_t, uint32_t flags); qtn_proc_t qtn_proc_alloc(); void qtn_proc_free(qtn_proc_t); qtn_file_t qtn_file_alloc(void); void qtn_file_free(qtn_file_t qf); int qtn_file_set_flags(qtn_file_t qf, uint32_t flags); uint32_t qtn_file_get_flags(qtn_file_t qf); int qtn_file_apply_to_path(qtn_file_t qf, const char *path); int qtn_file_init_with_path(qtn_file_t qf, const char *path); int qtn_proc_set_identifier(qtn_proc_t qp, const char* bundleid); int main() { qtn_proc_t qp = qtn_proc_alloc(); qtn_proc_set_identifier(qp, "xyz.hacktricks.qa"); qtn_proc_set_flags(qp, QTN_FLAG_DOWNLOAD | QTN_FLAG_USER_APPROVED); qtn_proc_apply_to_self(qp); qtn_proc_free(qp); FILE *fp; fp = fopen("thisisquarantined.txt", "w+"); fprintf(fp, "Hello Quarantine\n"); fclose(fp); return 0; }

Et supprimez cet attribut avec :

bash
xattr -d com.apple.quarantine portada.png #You can also remove this attribute from every file with find . -iname '*' -print0 | xargs -0 xattr -d com.apple.quarantine

Et trouvez tous les fichiers mis en quarantaine avec :

bash
find / -exec ls -ld {} \; 2>/dev/null | grep -E "[x\-]@ " | awk '{printf $9; printf "\n"}' | xargs -I {} xattr -lv {} | grep "com.apple.quarantine"

Les informations de quarantaine sont Ă©galement stockĂ©es dans une base de donnĂ©es centrale gĂ©rĂ©e par LaunchServices dans ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2, ce qui permet Ă  l'interface graphique d'obtenir des donnĂ©es sur les origines des fichiers. De plus, cela peut ĂȘtre Ă©crasĂ© par des applications qui pourraient ĂȘtre intĂ©ressĂ©es Ă  cacher leurs origines. De plus, cela peut ĂȘtre fait Ă  partir des API de LaunchServices.

libquarantine.dylb

Cette bibliothĂšque exporte plusieurs fonctions qui permettent de manipuler les champs d'attributs Ă©tendus.

Les API qtn_file_* traitent des politiques de quarantaine des fichiers, les API qtn_proc_* s'appliquent aux processus (fichiers créés par le processus). Les fonctions non exportées __qtn_syscall_quarantine* sont celles qui appliquent les politiques qui appellent mac_syscall avec "Quarantine" comme premier argument, ce qui envoie les demandes à Quarantine.kext.

Quarantine.kext

L'extension du noyau n'est disponible que via le cache du noyau sur le systÚme ; cependant, vous pouvez télécharger le Kernel Debug Kit depuis https://developer.apple.com/, qui contiendra une version symbolique de l'extension.

Ce Kext interceptera via MACF plusieurs appels afin de capturer tous les Ă©vĂ©nements du cycle de vie des fichiers : CrĂ©ation, ouverture, renommage, liaison dure... mĂȘme setxattr pour l'empĂȘcher de dĂ©finir l'attribut Ă©tendu com.apple.quarantine.

Il utilise Ă©galement quelques MIBs :

  • security.mac.qtn.sandbox_enforce : Appliquer la quarantaine avec le Sandbox
  • security.mac.qtn.user_approved_exec : Les processus en quarantaine ne peuvent exĂ©cuter que des fichiers approuvĂ©s

XProtect

XProtect est une fonctionnalitĂ© anti-malware intĂ©grĂ©e dans macOS. XProtect vĂ©rifie toute application lorsqu'elle est lancĂ©e pour la premiĂšre fois ou modifiĂ©e par rapport Ă  sa base de donnĂ©es de logiciels malveillants connus et de types de fichiers non sĂ©curisĂ©s. Lorsque vous tĂ©lĂ©chargez un fichier via certaines applications, telles que Safari, Mail ou Messages, XProtect analyse automatiquement le fichier. S'il correspond Ă  un logiciel malveillant connu dans sa base de donnĂ©es, XProtect empĂȘchera le fichier de s'exĂ©cuter et vous alertera sur la menace.

La base de données XProtect est mise à jour réguliÚrement par Apple avec de nouvelles définitions de logiciels malveillants, et ces mises à jour sont automatiquement téléchargées et installées sur votre Mac. Cela garantit que XProtect est toujours à jour avec les derniÚres menaces connues.

Cependant, il convient de noter que XProtect n'est pas une solution antivirus complÚte. Il ne vérifie qu'une liste spécifique de menaces connues et ne réalise pas de scan à l'accÚs comme la plupart des logiciels antivirus.

Vous pouvez obtenir des informations sur la derniÚre mise à jour de XProtect en exécutant :

bash
system_profiler SPInstallHistoryDataType 2>/dev/null | grep -A 4 "XProtectPlistConfigData" | tail -n 5

XProtect est situé dans un emplacement protégé par SIP à /Library/Apple/System/Library/CoreServices/XProtect.bundle et à l'intérieur du bundle, vous pouvez trouver des informations que XProtect utilise :

  • XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist : Permet au code avec ces cdhashes d'utiliser des droits hĂ©ritĂ©s.
  • XProtect.bundle/Contents/Resources/XProtect.meta.plist : Liste des plugins et extensions qui ne sont pas autorisĂ©s Ă  se charger via BundleID et TeamID ou indiquant une version minimale.
  • XProtect.bundle/Contents/Resources/XProtect.yara : RĂšgles Yara pour dĂ©tecter les logiciels malveillants.
  • XProtect.bundle/Contents/Resources/gk.db : Base de donnĂ©es SQLite3 avec des hachages d'applications bloquĂ©es et TeamIDs.

Notez qu'il y a une autre application dans /Library/Apple/System/Library/CoreServices/XProtect.app liée à XProtect qui n'est pas impliquée dans le processus de Gatekeeper.

Pas Gatekeeper

caution

Notez que Gatekeeper n'est pas exécuté à chaque fois que vous exécutez une application, seul AppleMobileFileIntegrity (AMFI) vérifie les signatures de code exécutable lorsque vous exécutez une application qui a déjà été exécutée et vérifiée par Gatekeeper.

Par conséquent, auparavant, il était possible d'exécuter une application pour la mettre en cache avec Gatekeeper, puis modifier des fichiers non exécutables de l'application (comme les fichiers Electron asar ou NIB) et si aucune autre protection n'était en place, l'application était exécutée avec les ajouts malveillants.

Cependant, cela n'est plus possible car macOS empĂȘche la modification des fichiers Ă  l'intĂ©rieur des bundles d'applications. Donc, si vous essayez l'attaque Dirty NIB, vous constaterez qu'il n'est plus possible de l'exploiter car aprĂšs avoir exĂ©cutĂ© l'application pour la mettre en cache avec Gatekeeper, vous ne pourrez pas modifier le bundle. Et si vous changez par exemple le nom du rĂ©pertoire Contents en NotCon (comme indiquĂ© dans l'exploit), puis exĂ©cutez le binaire principal de l'application pour le mettre en cache avec Gatekeeper, cela dĂ©clenchera une erreur et ne s'exĂ©cutera pas.

Contournements de Gatekeeper

Tout moyen de contourner Gatekeeper (réussir à faire télécharger quelque chose par l'utilisateur et à l'exécuter lorsque Gatekeeper devrait l'interdire) est considéré comme une vulnérabilité dans macOS. Voici quelques CVE attribués à des techniques qui ont permis de contourner Gatekeeper dans le passé :

CVE-2021-1810

Il a été observé que si l'Archive Utility est utilisé pour l'extraction, les fichiers avec des chemins dépassant 886 caractÚres ne reçoivent pas l'attribut étendu com.apple.quarantine. Cette situation permet involontairement à ces fichiers de contourner les vérifications de sécurité de Gatekeeper.

Consultez le rapport original pour plus d'informations.

CVE-2021-30990

Lorsqu'une application est créée avec Automator, les informations sur ce dont elle a besoin pour s'exécuter se trouvent dans application.app/Contents/document.wflow et non dans l'exécutable. L'exécutable est juste un binaire Automator générique appelé Automator Application Stub.

Par conséquent, vous pourriez faire en sorte que application.app/Contents/MacOS/Automator\ Application\ Stub pointe avec un lien symbolique vers un autre Automator Application Stub à l'intérieur du systÚme et il exécutera ce qui se trouve dans document.wflow (votre script) sans déclencher Gatekeeper car l'exécutable réel n'a pas l'attribut xattr de quarantaine.

Exemple d'emplacement attendu : /System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub

Consultez le rapport original pour plus d'informations.

CVE-2022-22616

Dans ce contournement, un fichier zip a été créé avec une application commençant à se compresser à partir de application.app/Contents au lieu de application.app. Par conséquent, l'attribut de quarantaine a été appliqué à tous les fichiers de application.app/Contents mais pas à application.app, ce qui était ce que Gatekeeper vérifiait, donc Gatekeeper a été contourné car lorsque application.app a été déclenché, il n'avait pas l'attribut de quarantaine.

bash
zip -r test.app/Contents test.zip

VĂ©rifiez le rapport original pour plus d'informations.

CVE-2022-32910

MĂȘme si les composants sont diffĂ©rents, l'exploitation de cette vulnĂ©rabilitĂ© est trĂšs similaire Ă  la prĂ©cĂ©dente. Dans ce cas, nous allons gĂ©nĂ©rer une archive Apple Ă  partir de application.app/Contents afin que application.app ne reçoive pas l'attribut de quarantaine lorsqu'il est dĂ©compressĂ© par Archive Utility.

bash
aa archive -d test.app/Contents -o test.app.aar

VĂ©rifiez le rapport original pour plus d'informations.

CVE-2022-42821

L'ACL writeextattr peut ĂȘtre utilisĂ©e pour empĂȘcher quiconque d'Ă©crire un attribut dans un fichier :

bash
touch /tmp/no-attr chmod +a "everyone deny writeextattr" /tmp/no-attr xattr -w attrname vale /tmp/no-attr xattr: [Errno 13] Permission denied: '/tmp/no-attr'

De plus, le format de fichier AppleDouble copie un fichier y compris ses ACE.

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Ă©. Donc, si vous avez compressĂ© une application dans un fichier zip avec le format de fichier AppleDouble avec une ACL qui empĂȘche d'autres xattrs d'y ĂȘtre Ă©crits... l'xattr de quarantaine n'a pas Ă©tĂ© dĂ©fini dans l'application :

bash
chmod +a "everyone deny write,writeattr,writeextattr" /tmp/test ditto -c -k test test.zip python3 -m http.server # Download the zip from the browser and decompress it, the file should be without a quarantine xattr

Consultez le rapport original pour plus d'informations.

Notez que cela pourrait Ă©galement ĂȘtre exploitĂ© avec AppleArchives :

bash
mkdir app touch app/test chmod +a "everyone deny write,writeattr,writeextattr" app/test aa archive -d app -o test.aar

CVE-2023-27943

Il a été découvert que Google Chrome ne définissait pas l'attribut de quarantaine pour les fichiers téléchargés en raison de certains problÚmes internes de macOS.

CVE-2023-27951

Les formats de fichiers AppleDouble stockent les attributs d'un fichier dans un fichier séparé commençant par ._, ce qui aide à copier les attributs de fichier entre les machines macOS. Cependant, il a été remarqué qu'aprÚs la décompression d'un fichier AppleDouble, le fichier commençant par ._ n'était pas doté de l'attribut de quarantaine.

bash
mkdir test echo a > test/a echo b > test/b echo ._a > test/._a aa archive -d test/ -o test.aar # If you downloaded the resulting test.aar and decompress it, the file test/._a won't have a quarantitne attribute

Être capable de crĂ©er un fichier qui n'aura pas l'attribut de quarantaine a permis de contourner Gatekeeper. L'astuce consistait Ă  crĂ©er une application de fichier DMG en utilisant la convention de nom AppleDouble (commencer par ._) et Ă  crĂ©er un fichier visible en tant que lien symbolique vers ce fichier cachĂ© sans l'attribut de quarantaine.
Lorsque le fichier dmg est exécuté, comme il n'a pas d'attribut de quarantaine, il contournera Gatekeeper.

bash
# Create an app bundle with the backdoor an call it app.app echo "[+] creating disk image with app" hdiutil create -srcfolder app.app app.dmg echo "[+] creating directory and files" mkdir mkdir -p s/app cp app.dmg s/app/._app.dmg ln -s ._app.dmg s/app/app.dmg echo "[+] compressing files" aa archive -d s/ -o app.aar

uchg (à partir de cette présentation)

  • CrĂ©ez un rĂ©pertoire contenant une application.
  • Ajoutez uchg Ă  l'application.
  • Compressez l'application dans un fichier tar.gz.
  • Envoyez le fichier tar.gz Ă  une victime.
  • La victime ouvre le fichier tar.gz et exĂ©cute l'application.
  • Gatekeeper ne vĂ©rifie pas l'application.

Prévenir le xattr de Quarantine

Dans un bundle ".app", si le xattr de quarantine n'est pas ajouté, lors de son exécution Gatekeeper ne sera pas déclenché.

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Soutenir HackTricks