<summary><strong>Aprende a hackear AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
El código de **dyld es de código abierto** y se puede encontrar en [https://opensource.apple.com/source/dyld/](https://opensource.apple.com/source/dyld/) y se puede descargar un tar usando una **URL como** [https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz](https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz)
Esto es similar al [**LD\_PRELOAD en Linux**](../../../../linux-hardening/privilege-escalation#ld\_preload). Permite indicar a un proceso que se va a ejecutar para cargar una biblioteca específica desde una ruta (si la variable de entorno está habilitada).
Esta técnica también puede ser **utilizada como técnica ASEP** ya que cada aplicación instalada tiene un archivo plist llamado "Info.plist" que permite la **asignación de variables de entorno** utilizando una clave llamada `LSEnvironmental`.
* El software tiene entitlements (tiempo de ejecución endurecido) sin el entitlement [`com.apple.security.cs.allow-dyld-environment-variables`](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_allow-dyld-environment-variables)
* Verifica los **entitlements** de un binario con: `codesign -dv --entitlements :- </ruta/al/bin>`
En versiones más actualizadas puedes encontrar esta lógica en la segunda parte de la función **`configureProcessRestrictions`.** Sin embargo, lo que se ejecuta en versiones más nuevas son las **verificaciones iniciales de la función** (puedes eliminar los ifs relacionados con iOS o simulación ya que no se usarán en macOS.
Incluso si el binario permite el uso de la variable de entorno **`DYLD_INSERT_LIBRARIES`**, si el binario verifica la firma de la biblioteca para cargarla, no cargará una personalizada.
Puedes verificar si un binario tiene **tiempo de ejecución endurecido** con `codesign --display --verbose <bin>` verificando la bandera de tiempo de ejecución en **`CodeDirectory`** como: **`CodeDirectory v=20500 size=767 flags=0x10000(runtime) hashes=13+7 location=embedded`**
Al igual que en Windows, en MacOS también puedes **secuestrar dylibs** para hacer que las **aplicaciones ejecuten****código arbitrario** (bueno, en realidad desde un usuario regular esto podría no ser posible ya que es posible que necesites un permiso TCC para escribir dentro de un paquete `.app` y secuestrar una biblioteca).\
Sin embargo, la forma en que las aplicaciones de **MacOS** cargan las bibliotecas es **más restringida** que en Windows. Esto implica que los desarrolladores de **malware** aún pueden usar esta técnica para **sigilo**, pero la probabilidad de poder **abusar de esto para escalar privilegios es mucho menor**.
En primer lugar, es **más común** encontrar que los **binarios de MacOS indican la ruta completa** de las bibliotecas a cargar. Y en segundo lugar, **MacOS nunca busca** en las carpetas de la **$PATH** para bibliotecas.
* **Bibliotecas débilmente vinculadas faltantes**: Esto significa que la aplicación intentará cargar una biblioteca que no existe configurada con **LC\_LOAD\_WEAK\_DYLIB**. Luego, **si un atacante coloca una dylib donde se espera, será cargada**.
* El hecho de que el enlace sea "débil" significa que la aplicación seguirá ejecutándose incluso si la biblioteca no se encuentra.
* El **código relacionado** con esto está en la función `ImageLoaderMachO::doGetDependentLibraries` de `ImageLoaderMachO.cpp donde `lib->required` es `false` solo cuando `LC_LOAD_WEAK_DYLIB` es verdadero.
* **Encuentra bibliotecas débilmente vinculadas** en binarios con (más adelante tienes un ejemplo de cómo crear bibliotecas de secuestro):
* **Configurado con @rpath**: Los binarios Mach-O pueden tener los comandos **`LC_RPATH`** y **`LC_LOAD_DYLIB`**. Basándose en los **valores** de esos comandos, las **bibliotecas** se cargarán desde **diferentes directorios**.
* **`LC_LOAD_DYLIB`** contiene la ruta a bibliotecas específicas para cargar. Estas rutas pueden contener **`@rpath`**, que será **reemplazado** por los valores en **`LC_RPATH`**. Si hay varias rutas en **`LC_RPATH`** todas se usarán para buscar la biblioteca a cargar. Ejemplo:
* Si **`LC_LOAD_DYLIB`** contiene `@rpath/library.dylib` y **`LC_RPATH`** contiene `/application/app.app/Contents/Framework/v1/` y `/application/app.app/Contents/Framework/v2/`. Ambas carpetas se utilizarán para cargar `library.dylib`**.** Si la biblioteca no existe en `[...]/v1/` y el atacante podría colocarla allí para secuestrar la carga de la biblioteca en `[...]/v2/` ya que se sigue el orden de las rutas en **`LC_LOAD_DYLIB`**.
* **Encuentra rutas y bibliotecas rpath** en binarios con: `otool -l </ruta/al/binario> | grep -E "LC_RPATH|LC_LOAD_DYLIB" -A 5`
La forma de **escalar privilegios** abusando de esta funcionalidad sería en el caso raro de que una **aplicación** ejecutada **por****root** esté **buscando** alguna **biblioteca en alguna carpeta donde el atacante tenga permisos de escritura.**
Un buen **escáner** para encontrar **bibliotecas faltantes** en aplicaciones es [**Dylib Hijack Scanner**](https://objective-see.com/products/dhs.html) o una [**versión CLI**](https://github.com/pandazheng/DylibHijack).\
Un buen **informe con detalles técnicos** sobre esta técnica se puede encontrar [**aquí**](https://www.virusbulletin.com/virusbulletin/2015/03/dylib-hijacking-os-x).
* Cuando la ruta **no contiene un carácter de barra inclinada** (es decir, es solo un nombre de hoja), **dlopen() buscará**. Si **`$DYLD_LIBRARY_PATH`** estaba configurado al inicio, dyld buscará primero en ese directorio. Luego, si el archivo mach-o que llama o el ejecutable principal especifican un **`LC_RPATH`**, entonces dyld buscará en esos directorios. Luego, si el proceso es **sin restricciones**, dyld buscará en el **directorio de trabajo actual**. Por último, para binarios antiguos, dyld intentará algunos fallbacks. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** estaba configurado al inicio, dyld buscará en **esos directorios**, de lo contrario, dyld buscará en **`/usr/local/lib/`** (si el proceso es sin restricciones), y luego en **`/usr/lib/`** (esta información se tomó de **`man dlopen`**).
* Cuando la ruta **parece una ruta de framework** (por ejemplo, `/stuff/foo.framework/foo`), si **`$DYLD_FRAMEWORK_PATH`** estaba configurado al inicio, dyld buscará primero en ese directorio para la **ruta parcial del framework** (por ejemplo, `foo.framework/foo`). Luego, dyld intentará la **ruta suministrada tal cual** (usando el directorio de trabajo actual para rutas relativas). Por último, para binarios antiguos, dyld intentará algunos fallbacks. Si **`$DYLD_FALLBACK_FRAMEWORK_PATH`** estaba configurado al inicio, dyld buscará en esos directorios. De lo contrario, buscará en **`/Library/Frameworks`** (en macOS si el proceso es sin restricciones), luego en **`/System/Library/Frameworks`**.
* Si el proceso es **sin restricciones**, abusando de la **ruta relativa desde CWD** de las variables de entorno mencionadas (aunque no se menciona en la documentación si el proceso está restringido, las variables de entorno DYLD\* se eliminan)
* Cuando la ruta **contiene una barra inclinada pero no es una ruta de framework** (es decir, una ruta completa o una ruta parcial a una dylib), dlopen() primero buscará (si está configurado) en **`$DYLD_LIBRARY_PATH`** (con la parte de hoja de la ruta). Luego, dyld **probará la ruta suministrada** (usando el directorio de trabajo actual para rutas relativas (pero solo para procesos sin restricciones)). Por último, para binarios antiguos, dyld intentará fallbacks. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** estaba configurado al inicio, dyld buscará en esos directorios, de lo contrario, dyld buscará en **`/usr/local/lib/`** (si el proceso es sin restricciones), y luego en **`/usr/lib/`**.
* Si el binario es **sin restricciones** y luego es posible cargar algo desde el CWD o `/usr/local/lib` (o abusando de una de las variables de entorno mencionadas)
Si lo compilas y lo ejecutas, puedes ver **dónde se buscó sin éxito cada biblioteca**. Además, podrías **filtrar los registros del sistema de archivos**:
Si un **binario/aplicación privilegiado** (como un SUID o algún binario con permisos poderosos) está **cargando una biblioteca de ruta relativa** (por ejemplo, usando `@executable_path` o `@loader_path`) y tiene la **Validación de Biblioteca deshabilitada**, podría ser posible mover el binario a una ubicación donde el atacante pudiera **modificar la biblioteca cargada de ruta relativa**, y abusar de ella para inyectar código en el proceso.
En el archivo `dyld-dyld-832.7.1/src/dyld2.cpp` es posible encontrar la función **`pruneEnvironmentVariables`**, que eliminará cualquier variable de entorno que **empiece con `DYLD_`** y **`LD_LIBRARY_PATH=`**.
También establecerá específicamente las variables de entorno **`DYLD_FALLBACK_FRAMEWORK_PATH`** y **`DYLD_FALLBACK_LIBRARY_PATH`** en **nulo** para binarios **suid** y **sgid**.
Lo que básicamente significa es que si el binario es **suid** o **sgid**, o tiene un segmento **RESTRICT** en los encabezados o fue firmado con la bandera **CS\_RESTRICT**, entonces **`!gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache`** es verdadero y las variables de entorno son eliminadas.
Ten en cuenta que si CS\_REQUIRE\_LV es verdadero, entonces las variables no serán eliminadas, pero la validación de la biblioteca verificará que estén utilizando el mismo certificado que el binario original.
DYLD_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
Ten en cuenta que incluso si hay binarios firmados con banderas **`0x0(none)`**, pueden obtener la bandera **`CS_RESTRICT`** dinámicamente al ejecutarse y, por lo tanto, esta técnica no funcionará en ellos.
<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
