mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-25 14:10:41 +00:00
Translated ['macos-hardening/macos-security-and-privilege-escalation/mac
This commit is contained in:
Translator
parent
30929f101f
commit
b13b663bc3
3 changed files with 72 additions and 44 deletions
|
|
@ -18,7 +18,7 @@ El código de **dyld es de código abierto** y se puede encontrar en [https://op
|
|||
|
||||
## **DYLD\_INSERT\_LIBRARIES**
|
||||
|
||||
> Esta es una lista separada por dos puntos de **bibliotecas dinámicas** para cargar antes de las especificadas en el programa. Esto te permite probar nuevos módulos de bibliotecas compartidas dinámicas existentes que se utilizan en imágenes de espacio de nombres plano cargando una biblioteca compartida dinámica temporal con solo los nuevos módulos. Ten en cuenta que esto no tiene ningún efecto en imágenes construidas con un espacio de nombres de dos niveles utilizando una biblioteca compartida dinámica a menos que también se utilice DYLD\_FORCE\_FLAT\_NAMESPACE.
|
||||
> Esta es una lista separada por dos puntos de **bibliotecas dinámicas** para cargar antes de las especificadas en el programa. Esto te permite probar nuevos módulos de bibliotecas compartidas dinámicas existentes que se utilizan en imágenes de espacio de nombres plano cargando una biblioteca compartida dinámica temporal con solo los nuevos módulos. Ten en cuenta que esto no tiene efecto en imágenes construidas con un espacio de nombres de dos niveles utilizando una biblioteca compartida dinámica a menos que también se utilice DYLD\_FORCE\_FLAT\_NAMESPACE.
|
||||
|
||||
Esto es similar a **LD\_PRELOAD en Linux**.
|
||||
|
||||
|
|
@ -32,34 +32,42 @@ Ve al código y **verifica `src/dyld.cpp`**. En la función **`pruneEnvironmentV
|
|||
En la función **`processRestricted`** se establece la razón de la restricción. Al verificar ese código, puedes ver que las razones son:
|
||||
|
||||
* El binario es `setuid/setgid`
|
||||
* Existencia de la sección `__RESTRICT/__restrict` en el binario macho.
|
||||
* El software tiene permisos (tiempo de ejecución endurecido) sin el permiso [`com.apple.security.cs.allow-dyld-environment-variables`](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_allow-dyld-environment-variables) o [`com.apple.security.cs.disable-library-validation`](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_disable-library-validation)`/` [`com.apple.private.security.clear-library-validation`](https://theevilbit.github.io/posts/com.apple.private.security.clear-library-validation/).
|
||||
* Verifica los **permisos** de un binario con: `codesign -dv --entitlements :- </path/to/bin>`
|
||||
* Si la biblioteca está firmada con un certificado diferente al del binario
|
||||
* Si la biblioteca y el binario están firmados con el mismo certificado, esto evitará las restricciones anteriores
|
||||
* Los programas con los permisos **`system.install.apple-software`** y **`system.install.apple-software.standar-user`** pueden **instalar software** firmado por Apple sin solicitar una contraseña (escalada de privilegios)
|
||||
* Existe la sección `__RESTRICT/__restrict` en el binario macho.
|
||||
* El software tiene permisos (tiempo de ejecución endurecido) sin el permiso [`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 **permisos** de un binario con: `codesign -dv --entitlements :- </ruta/al/binario>`
|
||||
|
||||
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 **comprobaciones iniciales de la función** (puedes eliminar los ifs relacionados con iOS o simulación, ya que no se utilizarán en macOS).
|
||||
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 utilizarán en macOS).
|
||||
{% endhint %}
|
||||
|
||||
### Validación de Bibliotecas
|
||||
|
||||
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 biblioteca personalizada.
|
||||
|
||||
Para cargar una biblioteca personalizada, el binario debe tener **uno de los siguientes permisos**:
|
||||
|
||||
*  [`com.apple.security.cs.disable-library-validation`](../../macos-security-protections/macos-dangerous-entitlements.md#com.apple.security.cs.disable-library-validation)
|
||||
* [`com.apple.private.security.clear-library-validation`](../../macos-security-protections/macos-dangerous-entitlements.md#com.apple.private.security.clear-library-validation)
|
||||
|
||||
o el binario **no debe tener** la **bandera de tiempo de ejecución endurecido** o la **bandera de validación de biblioteca**.
|
||||
|
||||
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`**
|
||||
|
||||
También puedes cargar una biblioteca si está **firmada con el mismo certificado que el binario**.
|
||||
|
||||
Encuentra un ejemplo de cómo (ab)usar esto y verificar las restricciones en:
|
||||
|
||||
{% content-ref 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)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Secuestro de Dylib
|
||||
|
||||
{% hint style="danger" %}
|
||||
Recuerda que **las restricciones anteriores también se aplican** para realizar ataques de secuestro de Dylib.
|
||||
Recuerda que también se aplican las restricciones de **Validación de Bibliotecas anteriores** para realizar ataques de secuestro de Dylib.
|
||||
{% endhint %}
|
||||
|
||||
Al igual que en Windows, en MacOS también puedes **secuestrar dylibs** para hacer que las **aplicaciones ejecuten** **código arbitrario**.\
|
||||
Sin embargo, la forma en que las aplicaciones de **MacOS** cargan bibliotecas es **más restrictiva** que en Windows. Esto implica que los desarrolladores de **malware** aún pueden usar esta técnica para **ocultarse**, pero la probabilidad de poder **abusar de esto para escalar privilegios es mucho menor**.
|
||||
Al igual que en Windows, en MacOS también puedes **secuestrar dylibs** para hacer que las **aplicaciones** ejecuten **código arbitrario**. Sin embargo, la forma en que las aplicaciones de **MacOS** cargan bibliotecas es **más restrictiva** que en Windows. Esto implica que los desarrolladores de malware aún pueden usar esta técnica para **ocultarse**, 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 **$PATH** las bibliotecas.
|
||||
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 **$PATH** las bibliotecas.
|
||||
|
||||
La **parte principal** del **código** relacionado con esta funcionalidad se encuentra en **`ImageLoader::recursiveLoadLibraries`** en `ImageLoader.cpp`.
|
||||
|
||||
|
|
@ -67,14 +75,15 @@ Hay **4 comandos diferentes de encabezado** que un binario macho puede usar para
|
|||
|
||||
* El comando **`LC_LOAD_DYLIB`** es el comando común para cargar una dylib.
|
||||
* El comando **`LC_LOAD_WEAK_DYLIB`** funciona como el anterior, pero si no se encuentra la dylib, la ejecución continúa sin ningún error.
|
||||
* El comando **`LC_REEXPORT_DYLIB`** actúa como un proxy (o reexporta) los símbolos de una biblioteca diferente.
|
||||
* El comando **`LC_REEXPORT_DYLIB`** se utiliza para hacer de intermediario (o reexportar) los símbolos de una biblioteca diferente.
|
||||
* El comando **`LC_LOAD_UPWARD_DYLIB`** se utiliza cuando dos bibliotecas dependen una de la otra (esto se llama una _dependencia ascendente_).
|
||||
|
||||
Sin embargo, hay **2 tipos de secuestro de dylib**:
|
||||
* **Bibliotecas vinculadas débilmente 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 que se cargue**.
|
||||
|
||||
* **Bibliotecas débilmente vinculadas que faltan**: Esto significa que la aplicación intentará cargar una biblioteca que no existe configurada con **LC\_LOAD\_WEAK\_DYLIB**. Entonces, **si un atacante coloca una dylib donde se espera que se cargue**.
|
||||
* El hecho de que el enlace sea "débil" significa que la aplicación seguirá funcionando incluso si no se encuentra la biblioteca.
|
||||
* El **código relacionado** con esto se encuentra en la función `ImageLoaderMachO::doGetDependentLibraries` de `ImageLoaderMachO.cpp`, donde `lib->required` es `false` solo cuando `LC_LOAD_WEAK_DYLIB` es verdadero.
|
||||
* **Encontrar bibliotecas vinculadas débilmente** en binarios con (más adelante tienes un ejemplo de cómo crear bibliotecas de secuestro):
|
||||
* **Encontrar bibliotecas débilmente vinculadas** en binarios con (más adelante tienes un ejemplo de cómo crear bibliotecas de secuestro):
|
||||
* ```bash
|
||||
otool -l </ruta/al/binario> | grep LC_LOAD_WEAK_DYLIB -A 5 cmd LC_LOAD_WEAK_DYLIB
|
||||
cmdsize 56
|
||||
|
|
@ -83,7 +92,7 @@ time stamp 2 Wed Jun 21 12:23:31 1969
|
|||
current version 1.0.0
|
||||
compatibility version 1.0.0
|
||||
```
|
||||
* **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, se van a **cargar bibliotecas** desde **directorios diferentes**.
|
||||
* **Configurado con @rpath**: Los binarios Mach-O pueden tener los comandos **`LC_RPATH`** y **`LC_LOAD_DYLIB`**. Según los **valores** de esos comandos, las **bibliotecas** se cargarán desde **directorios diferentes**.
|
||||
* **`LC_RPATH`** contiene las rutas de algunas carpetas utilizadas para cargar bibliotecas por el binario.
|
||||
* **`LC_LOAD_DYLIB`** contiene la ruta de 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`**, se utilizarán todas 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`**.
|
||||
|
|
@ -98,10 +107,10 @@ compatibility version 1.0.0
|
|||
* Cuando se usa en una **dylib**, **`@loader_path`** proporciona la **ruta** a la **dylib**.
|
||||
{% endhint %}
|
||||
|
||||
La forma de **elevar privilegios** abusando de esta funcionalidad sería en el caso raro de que una **aplicación** que se está ejecutando **por** **root** esté **buscando** alguna **biblioteca en alguna carpeta donde el atacante tenga permisos de escritura**.
|
||||
La forma de **escalar privilegios** abusando de esta funcionalidad sería en el caso raro de que una **aplicación** que se ejecuta **como** **root** esté **buscando** alguna **biblioteca en alguna carpeta donde el atacante tenga permisos de escritura**.
|
||||
|
||||
{% hint style="success" %}
|
||||
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 de línea de comandos**](https://github.com/pandazheng/DylibHijack).\
|
||||
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).
|
||||
{% endhint %}
|
||||
|
||||
|
|
@ -113,9 +122,13 @@ Un buen **informe con detalles técnicos** sobre esta técnica se puede encontra
|
|||
|
||||
## Secuestro de Dlopen
|
||||
|
||||
{% hint style="danger" %}
|
||||
Recuerda que también se aplican las restricciones de **Validación de Bibliotecas anteriores** para realizar ataques de secuestro de Dlopen.
|
||||
{% endhint %}
|
||||
|
||||
De **`man dlopen`**:
|
||||
|
||||
* Cuando la ruta **no contiene un carácter de barra diagonal** (es decir, es solo un nombre de archivo), **dlopen() buscará**. Si **`$DYLD_LIBRARY_PATH`** se estableció 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. A continuación, si el proceso no tiene restricciones, dyld buscará en el **directorio de trabajo actual**. Por último, para binarios antiguos, dyld intentará algunas alternativas. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** se estableció al inicio, dyld buscará en esos directorios. De lo contrario, buscará en **`/usr/local/lib/`** (si el proceso no tiene restricciones) y luego en **`/usr/lib/`** (esta información se tomó de **`man dlopen`**).
|
||||
* Cuando la ruta **no contiene el carácter de barra diagonal** (es decir, es solo un nombre de archivo), **dlopen() buscará**. Si **`$DYLD_LIBRARY_PATH`** se estableció al inicio, dyld buscará primero en ese directorio. A continuación, si el archivo mach-o que llama o el ejecutable principal especifican un **`LC_RPATH`**, entonces dyld buscará en esos directorios. A continuación, si el proceso no tiene restricciones, dyld buscará en el **directorio de trabajo actual**. Por último, para los binarios antiguos, dyld intentará algunas alternativas. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** se estableció al inicio, dyld buscará en **esos directorios**, de lo contrario, dyld buscará en **`/usr/local/lib/`** (si el proceso no tiene restricciones), y luego en **`/usr/lib/`** (esta información se obtuvo de **`man dlopen`**).
|
||||
1. `$DYLD_LIBRARY_PATH`
|
||||
2. `LC_RPATH`
|
||||
3. `CWD` (si no tiene restricciones)
|
||||
|
|
@ -126,26 +139,25 @@ De **`man dlopen`**:
|
|||
{% hint style="danger" %}
|
||||
Si no hay barras diagonales en el nombre, habría 2 formas de hacer un secuestro:
|
||||
|
||||
* Si algún **`LC_RPATH`** es **editable** (pero se verifica la firma, por lo que también se necesita que el binario no tenga restricciones)
|
||||
* Si algún **`LC_RPATH`** es **editable** (pero se verifica la firma, por lo que también necesitas que el binario no tenga restricciones)
|
||||
* Si el binario no tiene restricciones y luego es posible cargar algo desde el CWD (o abusando de una de las variables de entorno mencionadas)
|
||||
{% endhint %}
|
||||
|
||||
* Cuando la ruta **se parece a una ruta de framework** (por ejemplo, `/stuff/foo.framework/foo`), si **`$DYLD_FRAMEWORK_PATH`** se estableció al inicio, dyld buscará primero en ese directorio la **ruta parcial del framework** (por ejemplo, `foo.framework/foo`). A continuación, dyld intentará la **ruta suministrada tal cual** (usando el directorio de trabajo actual para rutas relativas). Por último, para binarios antiguos, dyld intentará algunas alternativas. Si **`$DYLD_FALLBACK_FRAMEWORK_PATH`** se estableció al inicio, dyld buscará en esos directorios. De lo contrario, buscará en **`/Library/Frameworks`** (en macOS si el proceso no tiene restricciones), luego en **`/System/Library/Frameworks`**.
|
||||
* Cuando la ruta **se parece a una ruta de framework** (por ejemplo, `/stuff/foo.framework/foo`), si **`$DYLD_FRAMEWORK_PATH`** se estableció al inicio, dyld buscará primero en ese directorio la **ruta parcial del framework** (por ejemplo, `foo.framework/foo`). A continuación, dyld intentará la **ruta proporcionada tal cual** (usando el directorio de trabajo actual para rutas relativas). Por último, para binarios antiguos, dyld intentará algunas alternativas. Si **`$DYLD_FALLBACK_FRAMEWORK_PATH`** se estableció al inicio, dyld buscará en esos directorios. De lo contrario, buscará en **`/Library/Frameworks`** (en macOS si el proceso no tiene restricciones), luego en **`/System/Library/Frameworks`**.
|
||||
1. `$DYLD_FRAMEWORK_PATH`
|
||||
2. ruta suministrada (usando el directorio de trabajo actual para rutas relativas si no tiene restricciones)
|
||||
2. ruta proporcionada (usando el directorio de trabajo actual para rutas relativas si no hay restricciones)
|
||||
3. `$DYLD_FALLBACK_FRAMEWORK_PATH`
|
||||
4. `/Library/Frameworks` (si no tiene restricciones)
|
||||
4. `/Library/Frameworks` (si no hay restricciones)
|
||||
5. `/System/Library/Frameworks`
|
||||
|
||||
{% hint style="danger" %}
|
||||
Si es una ruta de framework, la forma de secuestrarla sería:
|
||||
|
||||
* Si el proceso no tiene restricciones, abusando de la **ruta relativa desde el CWD** y 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)
|
||||
* Si el proceso no tiene restricciones, abusando de la **ruta relativa desde el directorio de trabajo actual** y las variables de entorno mencionadas (aunque no se menciona en la documentación si el proceso tiene restricciones, las variables de entorno DYLD\_\* se eliminan)
|
||||
{% endhint %}
|
||||
|
||||
* Cuando la ruta **contiene una barra diagonal pero no es una ruta de framework** (es decir, una ruta completa o una ruta parcial a una dylib), dlopen() primero busca (si está configurado) en **`$DYLD_LIBRARY_PATH`** (con la parte final de la ruta). A continuación, dyld **prueba 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á alternativas. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** se estableció al inicio, dyld buscará en esos directorios, de lo contrario, dyld buscará en **`/usr/local/lib/`** (si el proceso no tiene restricciones) y luego en **`/usr/lib/`**.
|
||||
* Cuando la ruta **contiene una barra pero no es una ruta de framework** (es decir, una ruta completa o una ruta parcial a un dylib), dlopen() primero busca (si está configurado) en **`$DYLD_LIBRARY_PATH`** (con la parte final de la ruta). A continuación, dyld **intenta la ruta proporcionada** (usando el directorio de trabajo actual para rutas relativas, pero solo para procesos sin restricciones). Por último, para binarios antiguos, dyld intentará alternativas. Si **`$DYLD_FALLBACK_LIBRARY_PATH`** se estableció al inicio, dyld buscará en esos directorios, de lo contrario, dyld buscará en **`/usr/local/lib/`** (si el proceso no tiene restricciones), y luego en **`/usr/lib/`**.
|
||||
1. `$DYLD_LIBRARY_PATH`
|
||||
2. ruta suministrada (usando el directorio de trabajo actual para rutas relativas si no hay restricciones)
|
||||
2. ruta proporcionada (usando el directorio de trabajo actual para rutas relativas si no hay restricciones)
|
||||
3. `$DYLD_FALLBACK_LIBRARY_PATH`
|
||||
4. `/usr/local/lib/` (si no hay restricciones)
|
||||
5. `/usr/lib/`
|
||||
|
|
@ -153,22 +165,22 @@ Si es una ruta de framework, la forma de secuestrarla sería:
|
|||
{% hint style="danger" %}
|
||||
Si hay barras en el nombre y no es un framework, la forma de secuestrarlo sería:
|
||||
|
||||
* Si el binario está **sin restricciones**, entonces es posible cargar algo desde el CWD o `/usr/local/lib` (o abusando de una de las variables de entorno mencionadas)
|
||||
* Si el binario no tiene restricciones y luego es posible cargar algo desde el directorio de trabajo actual o `/usr/local/lib` (o abusando de una de las variables de entorno mencionadas)
|
||||
{% endhint %}
|
||||
|
||||
{% hint style="info" %}
|
||||
Nota: No hay archivos de configuración para controlar la búsqueda de `dlopen`.
|
||||
Nota: No hay archivos de configuración para **controlar la búsqueda de dlopen**.
|
||||
|
||||
Nota: Si el ejecutable principal es un binario **set\[ug]id o firmado con entitlements**, entonces **se ignoran todas las variables de entorno**, y solo se puede usar una ruta completa (consultar las restricciones de `DYLD_INSERT_LIBRARIES` para obtener información más detallada).
|
||||
Nota: Si el ejecutable principal es un binario **set\[ug]id o firmado con entitlements**, entonces **se ignoran todas las variables de entorno**, y solo se puede usar una ruta completa (consulte las restricciones de DYLD\_INSERT\_LIBRARIES para obtener información más detallada).
|
||||
|
||||
Nota: Las plataformas de Apple utilizan archivos "universales" para combinar bibliotecas de 32 y 64 bits. Esto significa que **no hay rutas de búsqueda separadas para 32 y 64 bits**.
|
||||
Nota: Las plataformas de Apple utilizan archivos "universales" para combinar bibliotecas de 32 bits y 64 bits. Esto significa que no hay **rutas de búsqueda separadas para 32 bits y 64 bits**.
|
||||
|
||||
Nota: En las plataformas de Apple, la mayoría de las bibliotecas del sistema operativo se **combinan en la caché de dyld** y no existen en el disco. Por lo tanto, llamar a **`stat()`** para verificar si una biblioteca del sistema operativo existe **no funcionará**. Sin embargo, **`dlopen_preflight()`** utiliza los mismos pasos que **`dlopen()`** para encontrar un archivo mach-o compatible.
|
||||
{% endhint %}
|
||||
|
||||
**Verificar rutas**
|
||||
|
||||
Verifiquemos todas las opciones con el siguiente código:
|
||||
Veamos todas las opciones con el siguiente código:
|
||||
```c
|
||||
// gcc dlopentest.c -o dlopentest -Wl,-rpath,/tmp/test
|
||||
#include <dlfcn.h>
|
||||
|
|
@ -279,11 +291,17 @@ sudo chmod -s hello
|
|||
|
||||
The `__RESTRICT` section is a segment in macOS that is used to restrict the execution of certain processes. This section is designed to prevent unauthorized access and privilege escalation by limiting the actions that can be performed by a process.
|
||||
|
||||
The `__restrict` segment is responsible for enforcing these restrictions. It contains code that checks the permissions and privileges of a process before allowing it to execute certain actions. This segment ensures that only authorized processes can perform privileged operations, such as accessing sensitive data or modifying system settings.
|
||||
When a process is placed in the `__RESTRICT` section, it is restricted from executing certain operations, such as loading dynamic libraries or injecting code into other processes. This helps to protect the integrity and security of the system.
|
||||
|
||||
By leveraging the `__RESTRICT` section and the `__restrict` segment, macOS provides an additional layer of security to prevent process abuse and privilege escalation attacks. It helps to ensure that only trusted processes can access and modify critical system resources.
|
||||
By leveraging the `__RESTRICT` section, an attacker can bypass these restrictions and inject malicious code into a process. This technique is known as library injection and can be used to escalate privileges and gain unauthorized access to sensitive information.
|
||||
|
||||
It is important to note that modifying or bypassing the `__RESTRICT` section and the `__restrict` segment can lead to serious security vulnerabilities. Therefore, it is crucial to understand and respect these restrictions to maintain the integrity and security of the macOS system.
|
||||
To perform library injection, the attacker needs to identify a vulnerable process and find a way to inject their malicious code into it. This can be done by exploiting vulnerabilities in the target process or by using techniques such as code injection or DLL hijacking.
|
||||
|
||||
Once the malicious code is injected into the target process, the attacker can execute arbitrary commands, access sensitive data, or perform other malicious activities. This can lead to a complete compromise of the system and the leakage of sensitive information.
|
||||
|
||||
To protect against library injection attacks, it is important to implement proper security measures, such as keeping the system and applications up to date with the latest patches, using strong authentication mechanisms, and implementing access controls to limit the privileges of processes.
|
||||
|
||||
By understanding the `__RESTRICT` section and the risks associated with library injection, system administrators and security professionals can take proactive steps to secure their macOS systems and prevent unauthorized access and privilege escalation.
|
||||
```bash
|
||||
gcc -sectcreate __RESTRICT __restrict /dev/null hello.c -o hello-restrict
|
||||
DYLD_INSERT_LIBRARIES=inject.dylib ./hello-restrict
|
||||
|
|
|
|||
|
|
@ -44,18 +44,22 @@ Este entitlement permite **cargar frameworks, complementos o bibliotecas sin est
|
|||
|
||||
### `com.apple.private.security.clear-library-validation`
|
||||
|
||||
Este entitlement es muy similar a **`com.apple.security.cs.disable-library-validation`** pero en lugar de **desactivar directamente** la validación de la biblioteca, permite que el proceso **llame a una llamada de sistema `csops` para desactivarla**.\
|
||||
Este entitlement es muy similar a **`com.apple.security.cs.disable-library-validation`** pero en lugar de **desactivar directamente** la validación de la biblioteca, permite al proceso **llamar a una llamada de sistema `csops` para desactivarla**.\
|
||||
Consulta [**esto para más información**](https://theevilbit.github.io/posts/com.apple.private.security.clear-library-validation/).
|
||||
|
||||
### `com.apple.security.cs.allow-dyld-environment-variables`
|
||||
|
||||
Este entitlement permite **usar variables de entorno DYLD** que podrían ser utilizadas para inyectar bibliotecas y código. Consulta [**esto para más información**](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_allow-dyld-environment-variables).
|
||||
Este entitlement permite **usar variables de entorno DYLD** que podrían usarse para inyectar bibliotecas y código. Consulta [**esto para más información**](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_allow-dyld-environment-variables).
|
||||
|
||||
### `com.apple.private.tcc.manager` y `com.apple.rootless.storage`.`TCC`
|
||||
|
||||
[**Según este blog**](https://objective-see.org/blog/blog\_0x4C.html), estos entitlements permiten **modificar** la **base de datos TCC**.
|
||||
|
||||
### com.apple.private.security.kext-management
|
||||
### **`system.install.apple-software`** y **`system.install.apple-software.standar-user`**
|
||||
|
||||
Estos entitlements permiten **instalar software sin solicitar permisos** al usuario, lo cual puede ser útil para una **escalada de privilegios**.
|
||||
|
||||
### `com.apple.private.security.kext-management`
|
||||
|
||||
Entitlement necesario para solicitar al **kernel que cargue una extensión de kernel**.
|
||||
|
||||
|
|
@ -65,14 +69,14 @@ TODO: No sé qué permite hacer esto
|
|||
|
||||
### `com.apple.private.apfs.revert-to-snapshot`
|
||||
|
||||
TODO: En [**este informe**](https://jhftss.github.io/The-Nightmare-of-Apple-OTA-Update/) **se menciona que esto podría usarse para** actualizar los contenidos protegidos por SSV después de un reinicio. Si sabes cómo hacerlo, envía un PR por favor!
|
||||
|
||||
TODO: En [**este informe**](https://jhftss.github.io/The-Nightmare-of-Apple-OTA-Update/) **se menciona que esto podría usarse para** actualizar los contenidos protegidos por SSV después de un reinicio. ¡Si sabes cómo hacerlo, envía un PR por favor!
|
||||
### `com.apple.private.apfs.create-sealed-snapshot`
|
||||
|
||||
TODO: En [**este informe**](https://jhftss.github.io/The-Nightmare-of-Apple-OTA-Update/) **se menciona que esto podría usarse para** actualizar los contenidos protegidos por SSV después de un reinicio. Si sabes cómo hacerlo, envía un PR por favor!
|
||||
TODO: En [**este informe**](https://jhftss.github.io/The-Nightmare-of-Apple-OTA-Update/) **se menciona que esto podría ser utilizado para** actualizar el contenido protegido por SSV después de un reinicio. Si sabes cómo hacerlo, por favor envía un PR.
|
||||
|
||||
### `keychain-access-groups`
|
||||
|
||||
Esta lista de permisos **keychain** agrupa a las aplicaciones a las que se les permite acceder:
|
||||
Esta lista de permisos **keychain** agrupa a las aplicaciones que tienen acceso a:
|
||||
```xml
|
||||
<key>keychain-access-groups</key>
|
||||
<array>
|
||||
|
|
@ -109,7 +113,7 @@ Este permiso permite **crear memoria que es escribible y ejecutable** al pasar l
|
|||
|
||||
### `com.apple.security.cs.allow-unsigned-executable-memory`
|
||||
|
||||
Este permiso permite **anular o parchear código C**, utilizar el marco de **`NSCreateObjectFileImageFromMemory`** (que es fundamentalmente inseguro) o utilizar el marco **DVDPlayback**. Consulta [**esto para obtener más información**](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_allow-unsigned-executable-memory).
|
||||
Este permiso permite **anular o parchear código C**, utilizar el marco **`NSCreateObjectFileImageFromMemory`** (que es fundamentalmente inseguro) o utilizar el marco **DVDPlayback**. Consulta [**esto para obtener más información**](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_allow-unsigned-executable-memory).
|
||||
|
||||
{% hint style="danger" %}
|
||||
Incluir este permiso expone tu aplicación a vulnerabilidades comunes en lenguajes de código no seguro en memoria. Considera cuidadosamente si tu aplicación necesita esta excepción.
|
||||
|
|
|
|||
|
|
@ -182,6 +182,12 @@ Sin embargo, hay algunos archivos cuya firma no se verificará, estos tienen la
|
|||
...
|
||||
</dict>
|
||||
```
|
||||
Es posible calcular la firma de un recurso desde la línea de comandos con:
|
||||
|
||||
{% code overflow="wrap" %}
|
||||
```bash
|
||||
openssl dgst -binary -sha1 /System/Cryptexes/App/System/Applications/Safari.app/Contents/Resources/AppIcon.icns | openssl base64
|
||||
```
|
||||
## Montar archivos DMG
|
||||
|
||||
Un usuario puede montar un archivo DMG personalizado incluso encima de algunas carpetas existentes. Así es como puedes crear un paquete DMG personalizado con contenido personalizado:
|
||||
|
|
|
|||
Loading…
Reference in a new issue