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>

En **verwyder** daardie attribuut met:
```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

En vind al die gekwarantineerde lêers met:

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

Karantyninligting word ook gestoor in ’n sentrale databasis wat deur LaunchServices bestuur word in ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2, wat die GUI in staat stel om data oor die lêerherkoms te kry. Verder kan dit oorskryf word deur toepassings wat moontlik belangstel om hul herkoms te verberg. Dit kan ook vanaf die LaunchServices APIS gedoen word.

libquarantine.dylib

Hierdie biblioteek exporteer verskeie funksies wat toelaat om die uitgebreide attribuutvelde te manipuleer.

Die qtn_file_* APIs hanteer lêerkarantynbeleid, die qtn_proc_* APIs word op prosesse toegepas (lêers wat deur die proses geskep is). Die nie-eksporteerde __qtn_syscall_quarantine* funksies is diegene wat die beleide toepas en mac_syscall aanroep met “Quarantine” as eerste argument wat die versoeke na Quarantine.kext stuur.

Quarantine.kext

Die kerneluitbreiding is slegs beskikbaar deur die kernel cache op die stelsel; jy kan egter die Kernel Debug Kit vanaf https://developer.apple.com/ aflaai, wat ’n gesimbooliseerde weergawe van die uitbreiding sal bevat.

Hierdie Kext koppel via MACF aan verskeie oproepe om alle lêer-lewenstydsgebeurtenisse te vang: skepping, opening, hernoeming, hard-linking… selfs setxattr om te verhoed dat dit die com.apple.quarantine uitgebreide attribuut stel.

Dit gebruik ook ’n paar MIBs:

• security.mac.qtn.sandbox_enforce: Handhaaf karantyn saam met Sandbox
• security.mac.qtn.user_approved_exec: Gekarantyneerde prosesse kan slegs goedgekeurde lêers uitvoer

Provenance xattr (Ventura and later)

macOS 13 Ventura het ’n afsonderlike provenance-meganisme ingestel wat gevul word die eerste keer dat ’n gekarantyneerde app toegelaat word om te loop. Twee artefakte word geskep:

• Die com.apple.provenance xattr op die .app bundle directory (vaste-grootte binêre waarde wat ’n primêre sleutel en vlae bevat).
• ’n Ry in die provenance_tracking tabel in die ExecPolicy-databasis by /var/db/SystemPolicyConfiguration/ExecPolicy/ wat die app se cdhash en metadata stoor.

Praktiese gebruik:

# 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 is a built-in anti-malware feature in macOS. XProtect kontroleer enige toepassing wanneer dit vir die eerste keer begin of gewysig word teen sy databasis van bekende malware en onveilige lêertipes. Wanneer jy ’n lêer aflaai deur sekere apps, soos Safari, Mail, of Messages, skandeer XProtect die lêer outomaties. As dit ooreenstem met enige bekende malware in sy databasis, sal XProtect voorkom dat die lêer uitgevoer word en jou oor die bedreiging waarsku.

Die XProtect-databasis word deur Apple gereeld opgedateer met nuwe malware-definisies, en hierdie opdaterings word outomaties op jou Mac afgelaai en geïnstalleer. Dit verseker dat XProtect altyd op datum is met die nuutste bekende bedreigings.

Dit is egter die moeite werd om te noem dat XProtect nie ’n volledige antivirus-oplossing is nie. Dit kyk slegs na ’n spesifieke lys bekende bedreigings en voer nie on-access scanning uit soos die meeste antivirus-sagteware nie.

Jy kan inligting oor die nuutste XProtect-opdatering kry deur die volgende te laat loop:

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: Laat kode met daardie cdhashes toe om legacy entitlements te gebruik.
• XProtect.bundle/Contents/Resources/XProtect.meta.plist: Lys van plugins en uitbreidings wat nie toegelaat word om te laai nie via BundleID en TeamID of wat `n minimumweergawe aandui.
• XProtect.bundle/Contents/Resources/XProtect.yara: Yara reëls om malware te ontdek.
• XProtect.bundle/Contents/Resources/gk.db: SQLite3-databasis met hashes van geblokkeerde toepassings en 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

Nie Gatekeeper nie

Caution

Let wel dat Gatekeeper nie elke keer uitgevoer word nie wanneer jy ’n toepassing uitvoer; slegs AppleMobileFileIntegrity (AMFI) sal slegs uitvoerbare kodehandtekeninge verifieer wanneer jy ’n app uitvoer wat reeds deur Gatekeeper uitgevoer en geverifieer is.

Daarom was dit voorheen moontlik om ’n app uit te voer om dit deur Gatekeeper te cache, en dan nie-uitvoerbare lêers van die toepassing te wysig (soos Electron asar of NIB-lêers) en as daar geen ander beskermings in plek was nie, sou die toepassing met die kwaadaardige toevoegings uitgevoer word.

Tans is dit egter nie moontlik nie omdat macOS voorkom dat lêers binne toepassingsbundels gewysig word. Dus, as jy die Dirty NIB aanval probeer, sal jy vind dat dit nie meer moontlik is om dit te misbruik nie omdat nadat die app uitgevoer is om dit met Gatekeeper te cache, jy nie die bundel kan wysig nie. En as jy byvoorbeeld die naam van die Contents-gids verander na NotCon (soos in die exploit aangedui), en dan die hoof-binary van die app uitvoer om dit met Gatekeeper te cache, sal dit ’n fout veroorsaak en nie uitgevoer word nie.

Gatekeeper Bypasses

Enige manier om Gatekeeper te omseil (daardie dit jou gelukte om die gebruiker iets af te laai en dit uit te voer wanneer Gatekeeper dit sou verhoed) word as ’n kwesbaarheid in macOS beskou. Hier is ’n paar CVE’s wat toegewys is aan tegnieke wat in die verlede toegelaat het om Gatekeeper te omseil:

CVE-2021-1810

Daar is waargeneem dat as die Archive Utility gebruik word vir uitpak, lêers met paaie wat 886 karakters oorskry nie die com.apple.quarantine uitgebreide attribuut ontvang nie. Hierdie situasie laat daardie lêers onbedoeld toe om Gatekeeper se veiligheidskontroles te omseil.

Check the original report for more information.

CVE-2021-30990

Wanneer ’n toepassing met Automator geskep word, is die inligting oor wat dit benodig om uit te voer binne application.app/Contents/document.wflow en nie in die uitvoerbare binêre nie. Die uitvoerbare is net ’n generiese Automator-binarie genoem Automator Application Stub.

Dus kon jy application.app/Contents/MacOS/Automator\ Application\ Stub na ’n simboliese skakel laat wys na ’n ander Automator Application Stub binne die stelsel en dit sal uitvoer wat binne document.wflow is (jou script) sonder om Gatekeeper te aktiveer omdat die werklike uitvoerbare nie die quarantine xattr het nie.

Example os expected location: /System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub

Check the original report for more information.

CVE-2022-22616

In hierdie omseiling is ’n zip-lêer geskep waar ’n toepassing begin saamgepers is vanaf application.app/Contents in plaas van application.app. Dus is die quarantine attr toegepas op al die lêers uit application.app/Contents maar nie op application.app nie, wat Gatekeeper kontroleer, so Gatekeeper is omseil omdat wanneer application.app geaktiveer is, dit nie die quarantine-attribuut gehad het nie.

zip -r test.app/Contents test.zip

Kyk na die original report vir meer inligting.

CVE-2022-32910

Selfs al is die komponente verskillend, is die benutting van hierdie kwesbaarheid baie soortgelyk aan die vorige een. In hierdie geval sal ’n Apple Archive gegenereer word vanaf application.app/Contents sodat application.app won’t get the quarantine attr wanneer dit deur Archive Utility uitgepak word.

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

Kyk na die original report vir meer inligting.

CVE-2022-42821

Die ACL writeextattr kan gebruik word om te verhoed dat enigiemand ’n attribuut in ’n lêer skryf:

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'

Verder kopieer die AppleDouble lêerformaat ’n lêer, insluitend sy ACEs.

In die source code is dit moontlik om te sien dat die ACL-teksvoorstelling wat in die xattr met die naam com.apple.acl.text gestoor is, as ACL in die gedekomprimeerde lêer gestel gaan word. Dus, as jy ’n toepassing in ’n zip-lêer saamgepak het met die AppleDouble lêerformaat en met ’n ACL wat verhoed dat ander xattrs daarna geskryf word… is die quarantine xattr nie in die toepassing gestel nie:

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

Kyk na die original report vir meer inligting.

Let daarop dat dit ook met AppleArchives uitgebuit kan word:

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

CVE-2023-27943

Dit is ontdek dat Google Chrome die quarantine-attribuut nie by afgelaaide lêers gestel het nie as gevolg van sekere interne macOS-probleme.

CVE-2023-27951

AppleDouble-lêerformate stoor die attributte van ’n lêer in ’n aparte lêer wat begin met ._; dit help om lêerattribuutte oor macOS-masjiene te kopieer. Dit is egter opgemerk dat nadat ’n AppleDouble-lêer gedekomprimeer is, die lêer wat met ._ begin nie die quarantine-attribuut ontvang het nie.

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

Deur ’n lêer te kan skep wat nie die kwarantynattribuut het nie, was dit moontlik om Gatekeeper te omseil. Die truuk was om ’n DMG file application te skep deur die AppleDouble naamkonvensie te gebruik (begin dit met ._) en ’n sigbare lêer as ’n sym link na hierdie verborge lêer te skep sonder die kwarantynattribuut.
Wanneer die dmg file uitgevoer word, aangesien dit nie ’n kwarantynattribuut het nie, sal dit Gatekeeper omseil.

# 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]

’n Gatekeeper-omseiling wat in macOS Sonoma 14.0 herstel is, het toegelaat dat gemanipuleerde apps sonder ’n bevestiging uitgevoer kon word. Details is publiek bekendgemaak ná die pleister, en die probleem is aktief in die veld uitgebuit voordat dit reggestel is. Maak seker macOS Sonoma 14.0 of later is geïnstalleer.

[CVE-2024-27853]

’n Gatekeeper-omseiling in macOS 14.4 (vrygestel Maart 2024) wat voortgekom het uit die hantering deur libarchive van kwaadwillige ZIPs het toegelaat dat apps assessering kon ontduik. Werk op na 14.4 of later waarin Apple die probleem aangespreek het.

CVE-2024-44128

An Automator Quick Action workflow ingebed in ’n afgelaaide app kon sonder Gatekeeper-assessering aktiveer, omdat workflows as data behandel is en deur die Automator-hulp buite die normale notarization-prompt-pad uitgevoer is. ’n Gemanipuleerde .app wat ’n Quick Action bundel wat ’n shell script uitvoer (bv. binne Contents/PlugIns/*.workflow/Contents/document.wflow) kon dus onmiddellik by opstart uitgevoer word. Apple het ’n ekstra toestemmingsdialoog bygevoeg en die assesseringspad reggemaak in Ventura 13.7, Sonoma 14.7, en Sequoia 15.

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

Verskeie kwesbaarhede in populêre uitpakgereedskap (bv. The Unarchiver) het veroorsaak dat lêers wat uit argiewe uitgepak is die com.apple.quarantine xattr mis, wat Gatekeeper-omseilings moontlik gemaak het. Vertrou altyd op macOS Archive Utility of gepatchte gereedskap wanneer jy toets, en valideer xattrs na uitpak.

uchg (from this talk)

• Skep ’n gids wat ’n app bevat.
• Voeg uchg by die app.
• Pak die app saam in ’n tar.gz-lêer.
• Stuur die tar.gz-lêer na ’n slagoffer.
• Die slagoffer maak die tar.gz-lêer oop en voer die app uit.
• Gatekeeper kontroleer die app nie.

Prevent Quarantine xattr

In ’n “.app” bundel, as die quarantine xattr nie bygevoeg is nie, sal Gatekeeper nie getrigger word wanneer dit uitgevoer word nie.

Verwysings

• Apple Platform Security: Oor die veiligheidsinhoud van macOS Sonoma 14.4 (sluit CVE-2024-27853 in) – https://support.apple.com/en-us/HT214084
• Eclectic Light: How macOS now tracks the provenance of apps – https://eclecticlight.co/2023/05/10/how-macos-now-tracks-the-provenance-of-apps/
• Apple: About the security content of macOS Sonoma 14.7 / Ventura 13.7 (CVE-2024-44128) – https://support.apple.com/en-us/121234
• MacRumors: macOS 15 Sequoia removes the Control‑click “Open” Gatekeeper bypass – https://www.macrumors.com/2024/06/11/macos-sequoia-removes-open-anyway/

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!
• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.