yo-yo-yo-jbo/macos_app_structurePlongée pédagogique en profondeur dans les bundles d'applications macOS, les fichiers plist et le comportement des processus launchd, avec des notes de sécurité offensive sur l'empaquetage de payloads sous forme de fichiers .app et le contournement de la surveillance de l'arborescence des processus.
Passer de Linux ou Windows à macOS peut donner l'impression de débarquer dans un nouveau monde inconnu. Linux étant open-source et Windows étant bien documenté et très populaire (et macOS n'étant ni l'un ni l'autre, exactement), macOS peut être parfois difficile à appréhender. Dans cet article, j'ai l'intention d'aborder certaines des premières choses que vous pourriez remarquer sur macOS - des Apps, des Apps partout !
Venant d'un environnement Windows ou Linux, le concept d'Apps peut sembler étrange. Nous savons tous que les threads sont des « unités d'exécution » et que les processus sont des conteneurs de threads avec leur propre espace d'adressage -- quoi de plus à comprendre ? Eh bien, les processus sont rarement déployés dans un seul fichier. Sur Windows comme sur Linux, le code peut avoir besoin de nombreuses choses pour fonctionner, parmi lesquelles :
.dll, .so). Par exemple, la bibliothèque d'exécution C (msvcr<version>.dll sur Windows, libc-<version>.so) ainsi que d'autres dépendances.PE, qui possède des répertoires - l'un d'eux est le répertoire de ressources (même partiellement documenté ici) qui peut contenir des ressources (images, chaînes de caractères, etc.). Les ressources peuvent également être chargées dynamiquement depuis le disque, bien évidemment.PE lui-même (lisez ici) ou dans des fichiers de catalogue (c'est-à-dire, en externe).xml, ini, json) et la base de registre Windows.Eh bien, macOS met fortement l'accent sur les Application Bundles. L'idée est d'empaqueter (presque) tout ce qui est nécessaire au fonctionnement du programme dans une structure de répertoires - y compris les ressources, les informations de localisation, etc. Bien sûr, tout ne peut pas être joliment empaqueté (comme la bibliothèque d'exécution C, par exemple) - mais cela signifie tout de même que les éléments sont regroupés proprement - pas besoin de naviguer dans une énorme base de registre ni de lire des pages de manuel pour trouver des emplacements de fichiers de configuration obscurs. Les application bundles sont simplement des répertoires se terminant par .app - même si l'interface utilisateur masque l'extension .app (et le fait qu'il s'agisse d'un répertoire).
Du point de vue d'un attaquant, c'est intéressant - puisqu'une Application Bundle peut avoir des icônes arbitraires et masque l'extension .app - la livraison de malware pourrait être réalisée en trompant un utilisateur peu méfiant pour qu'il clique sur une telle app. Par exemple, pensez à un fichier Resume.app avec une icône de PDF.
La structure de répertoires d'une Application Bundle peut être facilement examinée, évidemment avec l'application Calculator intégrée :
jbo@McJbo ~ % cd /System/Applications/Calculator.app
jbo@McJbo Calculator.app % ll
total 0
drwxr-xr-x 3 root wheel 96 Mar 17 21:34 .
drwxr-xr-x 43 root wheel 1376 Mar 17 21:34 ..
drwxr-xr-x 9 root wheel 288 Mar 17 21:34 Contents
jbo@McJbo Calculator.app % cd Contents
jbo@McJbo Contents % ll
total 16
drwxr-xr-x 9 root wheel 288 Mar 17 21:34 .
drwxr-xr-x 3 root wheel 96 Mar 17 21:34 ..
-rw-r--r-- 1 root wheel 2147 Mar 17 21:34 Info.plist
drwxr-xr-x 3 root wheel 96 Mar 17 21:34 MacOS
-rw-r--r-- 204 root wheel 8 Mar 17 21:34 PkgInfo
drwxr-xr-x 4 root wheel 128 Mar 17 21:34 PlugIns
drwxr-xr-x 54 root wheel 1728 Mar 17 21:34 Resources
drwxr-xr-x 3 root wheel 96 Mar 17 21:34 _CodeSignature
-rw-r--r-- 1 root wheel 461 Mar 17 21:34 version.plist
jbo@McJbo Contents % cd MacOS
jbo@McJbo MacOS % ll
total 344
drwxr-xr-x 3 root wheel 96 Mar 17 21:34 .
drwxr-xr-x 9 root wheel 288 Mar 17 21:34 ..
-rwxr-xr-x 1 root wheel 540912 Mar 17 21:34 Calculator
jbo@McJbo MacOS %
Comme vous pouvez le voir, Calculator.app est un répertoire. Sous celui-ci se trouve un seul élément - un autre répertoire appelé Contents.
Sous Contents se trouvent plusieurs éléments :
Info.plist - contient les métadonnées de l'App. Plus de détails à ce sujet plus loin.MacOS - contient l'exécutable principal de l'App (comme on peut le voir dans la 3ème liste de répertoires).PkgInfo - non obligatoire. Un fichier binaire contenant des informations sur le paquet.PlugIns - non obligatoire. Un répertoire pouvant contenir des plugins pour l'App. Calculator en a deux - un pour « Basic and Scientific » et un pour « Hexadecimal » (je ne sais vraiment pas pourquoi ils ont fait cette séparation, et je m'en fiche).Resources - non obligatoire. Comme son nom l'indique, contient des ressources. On peut y trouver plusieurs éléments, notamment un fichier .icns contenant les icônes, ainsi que des répertoires avec le suffixe .lprroj liés à la localisation._CodeSignature - non obligatoire. Comme son nom l'indique - contient les informations de signature de code.version.plist - non obligatoire, contient des informations de version.Remarquez qu'il y a très peu d'éléments officiellement requis. En fait, nous pouvons créer notre propre première App sans même compiler quoi que ce soit !
Mais il faut d'abord aborder ce fichier Info.plist.
Plus vous regardez macOS, plus vous trouverez ces fichiers étranges. Ce ne sont rien de plus que des fichiers de configuration améliorés.
Ils ont toujours une extension .plist, qui n'est qu'un raccourci pour leur nom formel : les fichiers Property list.
Malheureusement, il existe 3 formats plist différents maintenus par Apple :
xml, lisible par les humains.json, peu utilisé.bplist comme signature magique.Heureusement, il existe un utilitaire appelé plutil qui prend en charge tous les formats. Pour afficher un fichier plist, utilisez simplement plutil -p. Par exemple :
jbo@McJbo Contents % plutil -p Info.plist | head -n 20
{
"BuildMachineOSBuild" => "22A380007"
"CFBundleDevelopmentRegion" => "English"
"CFBundleExecutable" => "Calculator"
"CFBundleGetInfoString" => "10.14, Copyright © 2000-2018, Apple Inc."
"CFBundleHelpBookFolder" => "Calculator.help"
"CFBundleHelpBookName" => "com.apple.Calculator.help"
"CFBundleIconFile" => "AppIcon"
"CFBundleIconName" => "AppIcon"
"CFBundleIdentifier" => "com.apple.calculator"
"CFBundleInfoDictionaryVersion" => "6.0"
"CFBundleName" => "Calculator"
"CFBundlePackageType" => "APPL"
"CFBundleShortVersionString" => "10.16"
"CFBundleSignature" => "????"
"CFBundleSupportedPlatforms" => [
0 => "MacOSX"
]
"CFBundleVersion" => "223"
"CTIgnoreUserFonts" => 1
jbo@McJbo Contents %
Il existe également des fonctionnalités de conversion intégrées à plutil - nous ne les démontrerons pas pour le moment.
Apple documente plusieurs exigences dans le Info.plist d'une App, mais il y a très peu de champs réellement obligatoires. Voici quelques champs intéressants :
CFBundleExecutable - le nom de l'exécutable principal, censé se trouver dans le répertoire MacOS.CFBundleIconFile - le nom du fichier d'icône. Non obligatoire.CFBundleIdentifier - un identifiant pour l'Application Bundle. Apple recommande d'utiliser une notation DNS inversée (par exemple com.apple.calculator).CFBundleName - le nom du bundle.Avec cela à l'esprit, nous pouvons créer notre première application géniale, sans même coder ! Regardez :
#!/bin/zsh
# Create Bundle structure
mkdir -p ./MyApp.app/Contents/MacOS
# Create main executable file - a shell script in our case
cat <<EOF > ./MyApp.app/Contents/MacOS/MyApp
#!/bin/zsh
osascript -e 'tell app "Finder" to display dialog "Hello from MyApp!"'
EOF
chmod +x ./MyApp.app/Contents/MacOS/MyApp
# Create the Info.plist file
cat <<EOF > ./MyApp.app/Contents/Info.plist
<?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>MyApp</string>
<key>CFBundleIdentifier</key>
<string>com.myapp</string>
<key>CFBundleName</key>
<string>MyApp</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
</dict>
</plist>
EOF
Cela créera une nouvelle app appelée MyApp - cliquer dessus exécutera simplement le script zsh (appelé MyApp).
Notez qu'il utilise osascript, qui est un interpréteur AppleScript et tout un sac de nœuds, mais il affichera juste une boîte de dialogue disant Hello from MyApp!. Vous pourriez écrire du code arbitraire dans ce fichier shell zsh, évidemment. Les versions récentes de macOS peuvent afficher une invite demandant l'autorisation à zsh d'appeler osascript - nous verrons pourquoi cela se produit dans un futur article, mais notez qu'elle ne sera pas redemandée après une première approbation.
Lancer une App signifie qu'un processus est toujours créé - évidemment celui désigné par CFBundleExecutable. Sous quel processus s'exécute-t-il ? Voyons :
jbo@McJbo ~ % open -a Calculator
jbo@McJbo ~ % ps -A -j | grep Calculator | grep -v grep
jbo 12067 1 12067 0 1 S ?? 0:00.41 /System/Applications/Calculator.app/Contents/MacOS/Calculator
jbo@McJbo ~ %
La commande open équivaut à un double-clic sur l'App Calculator - c'est assez fascinant et nous en parlerons bientôt.
Maintenant que Calculator est en cours d'exécution, nous utilisons ps pour afficher les processus actifs. Comme prévu, /System/Applications/Calculator.app/Contents/MacOS/Calculator est le processus qui s'exécute, et il a un PID de 12067. Cependant, son processus parent a l'ID 1 !
Le processus ID 1 sur macOS est /sbin/launchd. C'est le « gestionnaire de démons/agents à l'échelle du système et par utilisateur ». Vous pouvez l'imaginer comme services.exe (si vous venez d'un environnement Windows) ou systemd (si vous êtes familier avec Linux). En plus de gérer les services (appelés Launch Agents et Launch Daemons sur macOS), il est également le parent de toutes les Applications, ce qui est l'une des raisons pour lesquelles obtenir un arbre de processus significatif sur macOS est difficile.
Fait intéressant, vous pouvez toujours exécuter l'App Calculator comme un simple processus en invoquant directement /System/Applications/Calculator.app/Contents/MacOS/Calculator, mais elle ne sera alors pas un enfant de launchd :
jbo@McJbo ~ % /System/Applications/Calculator.app/Contents/MacOS/Calculator &
[1] 12502
jbo@McJbo ~ % 2023-04-04 15:54:22.987 Calculator[12502:1297087] XType: XTFontStaticRegistry is enabled by Info.plist.
jbo@McJbo ~ % ps -A -j | grep Calculator | grep -v grep
jbo 12502 951 12502 0 1 SN s000 0:00.31 /System/Applications/Calculator.app/Contents/MacOS/Calculator
jbo@McJbo ~ % echo $$
951
jbo@McJbo ~ %
En effet, Calculator fonctionne parfaitement, mais est maintenant un processus enfant de notre terminal.
Une chose à noter dans le comportement que nous avons observé est que les attaquants pourraient l'utiliser à différentes fins. Par exemple, les attaquants peuvent facilement sortir de l'arbre des processus pour échapper aux outils de sécurité, ainsi qu'abuser de vulnérabilités logiques (lisez mon writeup sur la vulnérabilité d'évasion du sandbox macOS si vous avez le temps).
Il y a d'autres responsabilités intéressantes pour launchd (lisez à propos des LaunchAgents et LaunchDaemons) mais nous n'en discuterons pas pour le moment.
Ici, je vous ai montré un type de bundle, mais il en existe bien d'autres (liste non exhaustive) :
.app - nous avons vu celui-ci, ce sont des Application Bundles qui servent de conteneurs pour les Apps..framework - contient des Frameworks, qui sont des bundles chargeables. Oui, sur macOS, vous pouvez appeler dlopen sur un fichier chargeable (.dylib) ou charger un bundle de framework entier (avec ressources, code, etc.)..kext - contient des extensions de noyau, qui sont des bundles chargeables mais destinés au noyau macOS. Dans les versions récentes du système d'exploitation, Apple s'efforce vraiment de réduire le nombre d'extensions de noyau..plugin - comme son nom l'indique, un conteneur pour des plugins.Ceci est le premier d'une série de courts articles visant à aider les gens à effectuer la transition vers la recherche sur macOS.
La première chose que j'ai remarquée, du point de vue de la sécurité offensive, est à quel point il est facile d'empaqueter des charges utiles dans une belle structure d'app.
Les choses ne sont cependant pas si simples - dans les prochains articles, nous découvrirons que l'obtention d'une exécution de code n'est pas si triviale en raison des nombreuses fonctionnalités de sécurité de macOS.
Restez à l'écoute !
Jonathan Bar Or (https://jonathanbaror.com)