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;

}

</details>

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 :

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 à la GUI d’obtenir des données sur l’origine des fichiers. De plus, cela peut être écrasé par des applications qui pourraient être intéressées à masquer leur origine. De plus, cela peut être fait depuis les LaunchServices APIS.

libquarantine.dylib

Cette bibliothèque exporte plusieurs fonctions qui permettent de manipuler les champs d’attributs étendus.

Les APIs qtn_file_* gèrent les politiques de quarantaine des fichiers, les APIs 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 : elles appellent mac_syscall avec “Quarantine” comme premier argument, ce qui envoie les requêtes à Quarantine.kext.

Quarantine.kext

L’extension kernel n’est disponible que via le kernel cache sur le système ; toutefois, vous pouvez télécharger le Kernel Debug Kit depuis https://developer.apple.com/, qui contiendra une version symboliquée de l’extension.

Ce Kext interceptera via MACF plusieurs appels afin de piéger tous les événements du cycle de vie des fichiers : création, ouverture, renommage, création de hard-links… 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: Enforce quarantine along Sandbox
• security.mac.qtn.user_approved_exec: Querantined procs can only execute approved files

Provenance xattr (Ventura and later)

macOS 13 Ventura a introduit un mécanisme de provenance distinct qui est rempli la première fois qu’une app en quarantaine est autorisée à s’exécuter. Deux artefacts sont créés :

• The com.apple.provenance xattr on the .app bundle directory (fixed-size binary value containing a primary key and flags).
• A row in the provenance_tracking table inside the ExecPolicy database at /var/db/SystemPolicyConfiguration/ExecPolicy/ storing the app’s cdhash and metadata.

Practical usage:

# Inspect provenance xattr (if present)
xattr -p com.apple.provenance /Applications/Some.app | hexdump -C

# Observe Gatekeeper/provenance events in real time
log stream --style syslog --predicate 'process == "syspolicyd"'

# Retrieve historical Gatekeeper decisions for a specific bundle
log show --last 2d --style syslog --predicate 'process == "syspolicyd" && eventMessage CONTAINS[cd] "GK scan"'

XProtect

XProtect est une fonctionnalité intégrée de anti-malware 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 malware connus et de types de fichiers dangereux. Lorsque vous téléchargez un fichier via certaines apps, telles que Safari, Mail ou Messages, XProtect scanne automatiquement le fichier. Si celui-ci correspond à un malware connu dans sa base de données, XProtect empêchera l’exécution du fichier et vous avertira de la menace.

La base de données XProtect est mise à jour régulièrement par Apple avec de nouvelles définitions de malware, 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 n’effectue pas de on-access scanning comme la plupart des antivirus.

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

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

XProtect is located on. SIP protected location at /Library/Apple/System/Library/CoreServices/XProtect.bundle and inside the bundle you can find information XProtect uses:

• XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist: Allows code with those cdhashes to use legacy entitlements.
• XProtect.bundle/Contents/Resources/XProtect.meta.plist: List of plugins and extensions that are disallowed to load via BundleID and TeamID or indicating a minimum version.
• XProtect.bundle/Contents/Resources/XProtect.yara: Yara rules to detect malware.
• XProtect.bundle/Contents/Resources/gk.db: SQLite3 database with hashes of blocked applications and TeamIDs.

Note that there is another App in /Library/Apple/System/Library/CoreServices/XProtect.app related to XProtect that isn’t involved with the Gatekeeper process.

XProtect Remediator: On modern macOS, Apple ships on-demand scanners (XProtect Remediator) that run periodically via launchd to detect and remediate families of malware. You can observe these scans in unified logs:

log show --last 2h --predicate 'subsystem == "com.apple.XProtectFramework" || category CONTAINS "XProtect"' --style syslog

Ce n’est pas Gatekeeper

Caution

Notez que Gatekeeper n’est pas exécuté à chaque fois que vous lancez une application : seule AppleMobileFileIntegrity (AMFI) vérifie les signatures du code exécutable lorsque vous exécutez une app 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 via Gatekeeper, puis de modifier des fichiers non exécutables de l’application (comme les asar d’Electron ou les fichiers NIB) et si aucune autre protection n’était en place, l’application était exécutée avec les ajouts malveillants.

Cependant, maintenant ce n’est plus possible car macOS empêche la modification des fichiers à l’intérieur des bundles d’applications. Ainsi, si vous essayez l’attaque Dirty NIB, vous constaterez qu’il n’est plus possible d’en abuser car après avoir exécuté l’app pour la mettre en cache via 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 la mettre en cache via Gatekeeper, cela déclenchera une erreur et ne s’exécutera pas.

Contournements de Gatekeeper

Toute méthode permettant de contourner Gatekeeper (réussir à faire télécharger quelque chose à l’utilisateur et l’exécuter alors que Gatekeeper devrait l’interdire) est considérée comme une vulnérabilité dans macOS. Voici quelques CVE attribuées à des techniques ayant permis de contourner Gatekeeper par 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 contrôles 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 n’est qu’un binaire Automator générique appelé Automator Application Stub.

Par conséquent, vous pouviez faire en sorte que application.app/Contents/MacOS/Automator\ Application\ Stub pointe avec un lien symbolique vers un autre Automator Application Stub dans le système et il exécutera ce qui est dans document.wflow (votre script) sans déclencher Gatekeeper parce que l’exécutable réel n’a pas l’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éé en commençant la compression à 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, qui est ce que Gatekeeper vérifiait, si bien que Gatekeeper était contourné parce que lorsque application.app était lancé il n’avait pas l’attribut de quarantaine.

zip -r test.app/Contents test.zip

Consultez 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, on va générer un Apple Archive à partir de application.app/Contents, donc application.app won’t get the quarantine attr lorsqu’il est décompressé par Archive Utility.

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

Consultez le original report 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 :

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 en incluant ses ACEs.

Dans le source code on peut voir que la représentation texte de l’ACL stockée dans l’xattr appelé com.apple.acl.text sera appliquée comme ACL dans le fichier décompressé. Donc, si vous avez compressé une application dans un fichier zip avec le format AppleDouble et avec une ACL qui empêche l’écriture d’autres xattrs… le quarantine xattr n’a pas été défini dans l’application :

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:

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

CVE-2023-27943

On a découvert que Google Chrome n’ajoutait pas l’attribut de quarantaine aux fichiers téléchargés en raison de problèmes internes à macOS.

CVE-2023-27951

Les formats AppleDouble stockent les attributs d’un fichier dans un fichier séparé commençant par ._, ce qui permet de copier les attributs de fichier entre des machines macOS. Cependant, on a constaté qu’après la décompression d’un fichier AppleDouble, le fichier commençant par ._ n’obtenait pas l’attribut de quarantaine.

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

En étant capable de créer un fichier qui n’aura pas le quarantine attribute défini, il était possible de bypass Gatekeeper. Le truc consistait à créer une application DMG en utilisant la convention de nommage AppleDouble (start it with ._) et à créer un fichier visible comme un sym link vers ce fichier caché sans le quarantine attribute.
Lorsque le dmg file est exécuté, comme il n’a pas de quarantine attribute il va bypass Gatekeeper.

# 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

[CVE-2023-41067]

Un contournement de Gatekeeper corrigé dans macOS Sonoma 14.0 permettait à des apps spécialement conçues de s’exécuter sans demande de confirmation. Les détails ont été rendus publics après le patch et le problème a été activement exploité dans la nature avant la correction. Assurez-vous que Sonoma 14.0 ou une version ultérieure est installée.

[CVE-2024-27853]

Un contournement de Gatekeeper dans macOS 14.4 (publié en mars 2024) dû au comportement de libarchive face à des ZIP malveillants permettait à des apps d’échapper à l’évaluation. Mettez à jour vers 14.4 ou une version ultérieure où Apple a corrigé le problème.

CVE-2024-44128

Un Automator Quick Action workflow intégré dans une app téléchargée pouvait se déclencher sans l’évaluation de Gatekeeper, car les workflows étaient traités comme des données et exécutés par le helper Automator en dehors du chemin normal de l’invite de notarisation. Une .app spécialement conçue emballant une Quick Action qui exécute un script shell (par ex. dans Contents/PlugIns/*.workflow/Contents/document.wflow) pouvait donc s’exécuter immédiatement au lancement. Apple a ajouté une boîte de dialogue de consentement supplémentaire et corrigé le chemin d’évaluation dans Ventura 13.7, Sonoma 14.7, et Sequoia 15.

Third‑party unarchivers mis‑propagating quarantine (2023–2024)

Plusieurs vulnérabilités dans des outils d’extraction populaires (p.ex. The Unarchiver) faisaient que les fichiers extraits d’archives n’avaient pas l’xattr com.apple.quarantine, permettant des opportunités de contournement de Gatekeeper. Utilisez toujours macOS Archive Utility ou des outils patchés lors des tests, et validez les xattrs après extraction.

uchg (from this talk)

• Créez un répertoire contenant une app.
• Ajoutez uchg à l’app.
• Compressez l’app en un fichier tar.gz.
• Envoyez le fichier tar.gz à une victime.
• La victime ouvre le tar.gz et exécute l’app.
• Gatekeeper ne vérifie pas l’app.

Prevent Quarantine xattr

Dans un bundle “.app”, si l’xattr de quarantine n’est pas ajouté, lors de son exécution Gatekeeper ne sera pas déclenché.

References

• Apple Platform Security: À propos du contenu de sécurité de macOS Sonoma 14.4 (inclut CVE-2024-27853) – https://support.apple.com/en-us/HT214084
• Eclectic Light: Comment macOS suit maintenant la provenance des apps – https://eclecticlight.co/2023/05/10/how-macos-now-tracks-the-provenance-of-apps/
• Apple: À propos du contenu de sécurité de macOS Sonoma 14.7 / Ventura 13.7 (CVE-2024-44128) – https://support.apple.com/en-us/121234
• MacRumors: macOS 15 Sequoia supprime le contournement Gatekeeper via le Control‑click “Open” – https://www.macrumors.com/2024/06/11/macos-sequoia-removes-open-anyway/

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) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.