C'est comme le LD_PRELOAD sur Linux. Il permet d'indiquer à un processus qu'il va exécuter pour charger une bibliothèque spécifique à partir d'un chemin (si la variable d'environnement est activée)
Cette technique peut également être utilisée comme une technique ASEP car chaque application installée a un fichier plist appelé "Info.plist" qui permet de d'assigner des variables d'environnement en utilisant une clé appelée LSEnvironmental.
Depuis 2012, Apple a considérablement réduit le pouvoir du DYLD_INSERT_LIBRARIES.
Allez dans le code et vérifiez src/dyld.cpp. Dans la fonction pruneEnvironmentVariables, vous pouvez voir que les variables DYLD_* sont supprimées.
Dans la fonction processRestricted, la raison de la restriction est définie. En vérifiant ce code, vous pouvez voir que les raisons sont :
Le binaire est setuid/setgid
Existence de la section __RESTRICT/__restrict dans le binaire macho.
Vérifiez les autorisations d'un binaire avec : codesign -dv --entitlements :- </chemin/vers/bin>
Dans les versions plus récentes, vous pouvez trouver cette logique dans la deuxième partie de la fonction configureProcessRestrictions. Cependant, ce qui est exécuté dans les versions plus récentes est le début des vérifications de la fonction (vous pouvez supprimer les ifs liés à iOS ou à la simulation car ils ne seront pas utilisés dans macOS.
Validation de bibliothèque
Même si le binaire permet d'utiliser la variable d'environnement DYLD_INSERT_LIBRARIES, si le binaire vérifie la signature de la bibliothèque pour la charger, il ne chargera pas une bibliothèque personnalisée.
Pour charger une bibliothèque personnalisée, le binaire doit avoir une des autorisations suivantes :
ou le binaire ne doit pas avoir le drapeau de runtime renforcé ou le drapeau de validation de bibliothèque.
Vous pouvez vérifier si un binaire a le runtime renforcé avec codesign --display --verbose <binaire> en vérifiant le drapeau runtime dans CodeDirectory comme : CodeDirectory v=20500 size=767 flags=0x10000(runtime) hashes=13+7 location=embedded
Vous pouvez également charger une bibliothèque si elle est signée avec le même certificat que le binaire.
Trouvez un exemple sur la façon de (ab)user de cela et vérifiez les restrictions dans :
Rappelez-vous que les restrictions de validation de bibliothèque précédentes s'appliquent également pour effectuer des attaques de détournement de dylib.
Comme sous Windows, sous MacOS, vous pouvez également détourner des dylibs pour faire exécuter du code arbitraire aux applications (en fait, en tant qu'utilisateur régulier, cela pourrait ne pas être possible car vous pourriez avoir besoin d'une autorisation TCC pour écrire à l'intérieur d'un bundle .app et détourner une bibliothèque).
Cependant, la façon dont les applications MacOS chargent les bibliothèques est plus restreinte que sous Windows. Cela implique que les développeurs de logiciels malveillants peuvent toujours utiliser cette technique pour la discrétion, mais la probabilité de pouvoir abuser de cela pour escalader les privilèges est beaucoup plus faible.
Tout d'abord, il est plus courant de constater que les binaires MacOS indiquent le chemin complet des bibliothèques à charger. Deuxièmement, MacOS ne recherche jamais dans les dossiers du $PATH pour les bibliothèques.
La partie principale du code liée à cette fonctionnalité se trouve dans ImageLoader::recursiveLoadLibraries dans ImageLoader.cpp.
Il existe 4 commandes d'en-tête différentes qu'un binaire macho peut utiliser pour charger des bibliothèques :
La commande LC_LOAD_DYLIB est la commande courante pour charger une dylib.
La commande LC_LOAD_WEAK_DYLIB fonctionne comme la précédente, mais si la dylib n'est pas trouvée, l'exécution se poursuit sans aucune erreur.
La commande LC_REEXPORT_DYLIB elle proxy (ou réexporte) les symboles d'une bibliothèque différente.
La commande LC_LOAD_UPWARD_DYLIB est utilisée lorsque deux bibliothèques dépendent l'une de l'autre (c'est ce qu'on appelle une dépendance ascendante).
Cependant, il existe 2 types de détournement de dylib :
Bibliothèques liées faibles manquantes : Cela signifie que l'application tentera de charger une bibliothèque qui n'existe pas configurée avec LC_LOAD_WEAK_DYLIB. Ensuite, si un attaquant place une dylib là où elle est attendue, elle sera chargée.
Le fait que le lien soit "faible" signifie que l'application continuera de s'exécuter même si la bibliothèque n'est pas trouvée.
Le code lié à cela se trouve dans la fonction ImageLoaderMachO::doGetDependentLibraries de ImageLoaderMachO.cpp où lib->requiredest seulementfalselorsqueLC_LOAD_WEAK_DYLIB` est vrai.
Trouvez des bibliothèques liées faibles dans les binaires avec (vous avez ensuite un exemple sur la création de bibliothèques de détournement) :
otool -l </chemin/vers/bin> | grep LC_LOAD_WEAK_DYLIB -A 5 cmd LC_LOAD_WEAK_DYLIB cmdsize 56 name /var/tmp/lib/libUtl.1.dylib (offset 24) time stamp 2 Wed Jun 21 12:23:31 1969 current version 1.0.0 compatibility version 1.0.0
- **Configuré avec @rpath** : Les binaires Mach-O peuvent avoir les commandes **`LC_RPATH`** et **`LC_LOAD_DYLIB`**. En fonction des **valeurs** de ces commandes, les **bibliothèques** vont être **chargées** à partir de **différents répertoires**.
- **`LC_RPATH`** contient les chemins de certains dossiers utilisés pour charger les bibliothèques par le binaire.
- **`LC_LOAD_DYLIB`** contient le chemin des bibliothèques spécifiques à charger. Ces chemins peuvent contenir **`@rpath`**, qui sera **remplacé** par les valeurs dans **`LC_RPATH`**. S'il y a plusieurs chemins dans **`LC_RPATH`**, chacun sera utilisé pour rechercher la bibliothèque à charger. Exemple :
- Si **`LC_LOAD_DYLIB`** contient `@rpath/library.dylib` et **`LC_RPATH`** contient `/application/app.app/Contents/Framework/v1/` et `/application/app.app/Contents/Framework/v2/`. Les deux dossiers seront utilisés pour charger `library.dylib`**.** Si la bibliothèque n'existe pas dans `[...]/v1/` et que l'attaquant pourrait la placer là pour détourner le chargement de la bibliothèque dans `[...]/v2/` car l'ordre des chemins dans **`LC_LOAD_DYLIB`** est suivi.
- **Trouvez les chemins rpath et les bibliothèques** dans les binaires avec : `otool -l </chemin/vers/binaire> | grep -E "LC_RPATH|LC_LOAD_DYLIB" -A 5`
<div data-gb-custom-block data-tag="hint" data-style='info'>
**`@executable_path`** : Est le **chemin** vers le répertoire contenant le **fichier exécutable principal**.
**`@loader_path`** : Est le **chemin** vers le **répertoire** contenant le **binaire Mach-O** qui contient la commande de chargement.
- Lorsqu'il est utilisé dans un exécutable, **`@loader_path`** est effectivement le **même** que **`@executable_path`**.
- Lorsqu'il est utilisé dans une **dylib**, **`@loader_path`** donne le **chemin** vers la **dylib**.
</div>
La façon d'**escalader les privilèges** en abusant de cette fonctionnalité serait dans le cas rare où une **application** exécutée **par** **root** recherche une **bibliothèque dans un dossier où l'attaquant a des permissions d'écriture.**
<div data-gb-custom-block data-tag="hint" data-style='success'>
Un **scanner** pratique pour trouver des **bibliothèques manquantes** dans les applications est [**Dylib Hijack Scanner**](https://objective-see.com/products/dhs.html) ou une [**version CLI**](https://github.com/pandazheng/DylibHijack).\
Un **rapport avec des détails techniques** sur cette technique peut être trouvé [**ici**](https://www.virusbulletin.com/virusbulletin/2015/03/dylib-hijacking-os-x).
</div>
**Exemple**
<div data-gb-custom-block data-tag="content-ref" data-url='../../macos-dyld-hijacking-and-dyld_insert_libraries.md'>
[macos-dyld-hijacking-and-dyld\_insert\_libraries.md](../../macos-dyld-hijacking-and-dyld\_insert\_libraries.md)
</div>
## Dlopen Hijacking
<div data-gb-custom-block data-tag="hint" data-style='danger'>
Rappelez-vous que les **restrictions de validation de bibliothèque précédentes s'appliquent également** pour effectuer des attaques de détournement de Dlopen.
</div>
Depuis **`man dlopen`** :
- Lorsque le chemin **ne contient pas de caractère slash** (c'est-à-dire qu'il s'agit simplement d'un nom de feuille), **dlopen() effectuera une recherche**. Si **`$DYLD_LIBRARY_PATH`** était défini au lancement, dyld cherchera d'abord dans ce répertoire. Ensuite, si le fichier mach-o appelant ou l'exécutable principal spécifie un **`LC_RPATH`**, alors dyld cherchera dans ces répertoires. Ensuite, si le processus est **non restreint**, dyld recherchera dans le **répertoire de travail actuel**. Enfin, pour les anciens binaires, dyld essaiera quelques solutions de repli. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** était défini au lancement, dyld recherchera dans **ces répertoires**, sinon, dyld cherchera dans **`/usr/local/lib/`** (si le processus est non restreint), puis dans **`/usr/lib/`** (ces informations ont été prises de **`man dlopen`**).
1. `$DYLD_LIBRARY_PATH`
2. `LC_RPATH`
3. `CWD`(si non restreint)
4. `$DYLD_FALLBACK_LIBRARY_PATH`
5. `/usr/local/lib/` (si non restreint)
6. `/usr/lib/`
<div data-gb-custom-block data-tag="hint" data-style='danger'>
S'il n'y a pas de barres obliques dans le nom, il y aurait 2 façons de faire un détournement :
- Si un **`LC_RPATH`** est **modifiable** (mais la signature est vérifiée, donc pour cela, vous avez également besoin que le binaire soit non restreint)
- Si le binaire est **non restreint** et qu'il est alors possible de charger quelque chose à partir du CWD (ou en abusant de l'une des variables d'environnement mentionnées)
</div>
- Lorsque le chemin **ressemble à un chemin de framework** (par exemple `/stuff/foo.framework/foo`), si **`$DYLD_FRAMEWORK_PATH`** était défini au lancement, dyld cherchera d'abord dans ce répertoire pour le **chemin partiel du framework** (par exemple `foo.framework/foo`). Ensuite, dyld essaiera le **chemin fourni tel quel** (en utilisant le répertoire de travail actuel pour les chemins relatifs). Enfin, pour les anciens binaires, dyld essaiera quelques solutions de repli. Si **`$DYLD_FALLBACK_FRAMEWORK_PATH`** était défini au lancement, dyld recherchera dans ces répertoires. Sinon, il recherchera dans **`/Library/Frameworks`** (sur macOS si le processus est non restreint), puis dans **`/System/Library/Frameworks`**.
1. `$DYLD_FRAMEWORK_PATH`
2. chemin fourni (en utilisant le répertoire de travail actuel pour les chemins relatifs si non restreint)
3. `$DYLD_FALLBACK_FRAMEWORK_PATH`
4. `/Library/Frameworks` (si non restreint)
5. `/System/Library/Frameworks`
<div data-gb-custom-block data-tag="hint" data-style='danger'>
Si un chemin de framework, la façon de le détourner serait :
- Si le processus est **non restreint**, en abusant du **chemin relatif à partir de CWD** des variables d'environnement mentionnées (même si cela n'est pas dit dans la documentation si le processus est restreint, les variables d'environnement DYLD\_\* sont supprimées)
</div>
- Lorsque le chemin **contient une barre oblique mais n'est pas un chemin de framework** (c'est-à-dire un chemin complet ou un chemin partiel vers une dylib), dlopen() regarde d'abord (si défini) dans **`$DYLD_LIBRARY_PATH`** (avec la partie feuille du chemin). Ensuite, dyld **essaie le chemin fourni** (en utilisant le répertoire de travail actuel pour les chemins relatifs (mais uniquement pour les processus non restreints)). Enfin, pour les anciens binaires, dyld essaiera des solutions de repli. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** était défin
```c
// gcc dlopentest.c -o dlopentest -Wl,-rpath,/tmp/test
#include <dlfcn.h>
#include <stdio.h>
int main(void)
{
void* handle;
fprintf("--- No slash ---\n");
handle = dlopen("just_name_dlopentest.dylib",1);
if (!handle) {
fprintf(stderr, "Error loading: %s\n\n\n", dlerror());
}
fprintf("--- Relative framework ---\n");
handle = dlopen("a/framework/rel_framework_dlopentest.dylib",1);
if (!handle) {
fprintf(stderr, "Error loading: %s\n\n\n", dlerror());
}
fprintf("--- Abs framework ---\n");
handle = dlopen("/a/abs/framework/abs_framework_dlopentest.dylib",1);
if (!handle) {
fprintf(stderr, "Error loading: %s\n\n\n", dlerror());
}
fprintf("--- Relative Path ---\n");
handle = dlopen("a/folder/rel_folder_dlopentest.dylib",1);
if (!handle) {
fprintf(stderr, "Error loading: %s\n\n\n", dlerror());
}
fprintf("--- Abs Path ---\n");
handle = dlopen("/a/abs/folder/abs_folder_dlopentest.dylib",1);
if (!handle) {
fprintf(stderr, "Error loading: %s\n\n\n", dlerror());
}
return 0;
}
Si vous le compilez et l'exécutez, vous pouvez voir où chaque bibliothèque a été recherchée sans succès. De plus, vous pourriez filtrer les journaux du système de fichiers:
sudofs_usage|grep"dlopentest"
Détournement de chemin relatif
Si un binaire/application privilégié (comme un SUID ou un binaire avec des autorisations puissantes) charge une bibliothèque avec un chemin relatif (par exemple en utilisant @executable_path ou @loader_path) et que la Validation de bibliothèque est désactivée, il pourrait être possible de déplacer le binaire vers un emplacement où l'attaquant pourrait modifier la bibliothèque chargée avec un chemin relatif, et l'utiliser pour injecter du code dans le processus.
Élaguer les variables d'environnement DYLD_* et LD_LIBRARY_PATH
Dans le fichier dyld-dyld-832.7.1/src/dyld2.cpp, il est possible de trouver la fonction pruneEnvironmentVariables, qui supprimera toute variable d'environnement qui commence par DYLD_ et LD_LIBRARY_PATH=.
Il définira également spécifiquement les variables d'environnement DYLD_FALLBACK_FRAMEWORK_PATH et DYLD_FALLBACK_LIBRARY_PATH sur null pour les binaires suid et sgid.
Cette fonction est appelée depuis la fonction _main du même fichier lors du ciblage de macOS de cette manière :
et ces indicateurs booléens sont définis dans le même fichier dans le code :
#ifTARGET_OS_OSX// support chrooting from old kernelbool isRestricted =false;bool libraryValidation =false;// any processes with setuid or setgid bit set or with __RESTRICT segment is restrictedif ( issetugid() ||hasRestrictedSegment(mainExecutableMH) ) {isRestricted =true;}bool usingSIP = (csr_check(CSR_ALLOW_TASK_FOR_PID) !=0);uint32_t flags;if ( csops(0, CS_OPS_STATUS,&flags,sizeof(flags)) !=-1 ) {// On OS X CS_RESTRICT means the program was signed with entitlementsif ( ((flags & CS_RESTRICT) == CS_RESTRICT) && usingSIP ) {isRestricted =true;}// Library Validation loosens searching but requires everything to be code signedif ( flags & CS_REQUIRE_LV ) {isRestricted =false;libraryValidation =true;}}gLinkContext.allowAtPaths =!isRestricted;gLinkContext.allowEnvVarsPrint =!isRestricted;gLinkContext.allowEnvVarsPath =!isRestricted;gLinkContext.allowEnvVarsSharedCache =!libraryValidation ||!usingSIP;gLinkContext.allowClassicFallbackPaths =!isRestricted;gLinkContext.allowInsertFailures =false;gLinkContext.allowInterposing =true;
Ce qui signifie essentiellement que si le binaire est suid ou sgid, ou a un segment RESTRICT dans les en-têtes ou s'il a été signé avec le drapeau CS_RESTRICT, alors !gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache est vrai et les variables d'environnement sont élaguées.
Notez que si CS_REQUIRE_LV est vrai, alors les variables ne seront pas élaguées mais la validation de la bibliothèque vérifiera qu'elles utilisent le même certificat que le binaire d'origine.
Vérifier les Restrictions
SUID & SGID
# Make it owned by root and suidsudochownroothellosudochmod+shello# Insert the libraryDYLD_INSERT_LIBRARIES=inject.dylib./hello# Remove suidsudochmod-shello
Créez un nouveau certificat dans le trousseau et utilisez-le pour signer le binaire :
# Apply runtime proetctioncodesign-s<cert-name>--option=runtime./helloDYLD_INSERT_LIBRARIES=inject.dylib./hello#Library won't be injected# Apply library validationcodesign-f-s<cert-name>--option=library./helloDYLD_INSERT_LIBRARIES=inject.dylib./hello-signed#Will throw an error because signature of binary and library aren't signed by same cert (signs must be from a valid Apple-signed developer certificate)# Sign it## If the signature is from an unverified developer the injection will still work## If it's from a verified developer, it won'tcodesign-f-s<cert-name>inject.dylibDYLD_INSERT_LIBRARIES=inject.dylib./hello-signed# Apply CS_RESTRICT protectioncodesign-f-s<cert-name>--option=restricthello-signedDYLD_INSERT_LIBRARIES=inject.dylib./hello-signed# Won't work
Notez que même s'il y a des binaires signés avec des indicateurs 0x0(none), ils peuvent obtenir dynamiquement l'indicateur CS_RESTRICT lors de leur exécution et donc cette technique ne fonctionnera pas sur eux.
Vous pouvez vérifier si un processus a cet indicateur avec (obtenez csops ici):
csops-status<pid>
et vérifiez ensuite si le drapeau 0x800 est activé.
