* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres que tu **empresa sea anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén la [**ropa oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**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/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud)
Las restricciones de inicio en macOS se introdujeron para mejorar la seguridad al **regular cómo, quién y desde dónde puede iniciarse un proceso**. Introducidas en macOS Ventura, proporcionan un marco que categoriza **cada binario del sistema en categorías de restricciones distintas**, definidas dentro de la **caché de confianza**, una lista que contiene binarios del sistema y sus respectivos hashes. Estas restricciones se extienden a cada binario ejecutable dentro del sistema, implicando un conjunto de **reglas** que delinean los requisitos para **iniciar un binario en particular**. Las reglas abarcan restricciones propias que un binario debe cumplir, restricciones parentales que deben cumplir su proceso padre y restricciones responsables que deben cumplir otras entidades relevantes.
El mecanismo se extiende a aplicaciones de terceros a través de **Restricciones de Ambiente**, comenzando desde macOS Sonoma, lo que permite a los desarrolladores proteger sus aplicaciones especificando un **conjunto de claves y valores para las restricciones de ambiente**.
Defines **restricciones de inicio y biblioteca de ambiente** en diccionarios de restricciones que guardas en **archivos de lista de propiedades de `launchd`**, o en **archivos de lista de propiedades separados** que utilizas en la firma de código.
Por lo tanto, cuando un proceso intenta iniciar otro proceso —llamando a `execve(_:_:_:)` o `posix_spawn(_:_:_:_:_:_:)`—, el sistema operativo verifica que el **archivo ejecutable** cumpla su **propia restricción**, que el **proceso padre** del proceso cumpla la **restricción del padre del ejecutable**, y que el **proceso responsable** del proceso cumpla la **restricción del proceso responsable del ejecutable**. Si alguna de estas restricciones de inicio no se cumple, el sistema operativo no ejecuta el programa.
Los [**hechos que un LC puede usar están documentados**](https://developer.apple.com/documentation/security/defining\_launch\_environment\_and\_library\_constraints). Por ejemplo:
*`on-authorized-authapfs-volume:` Un valor booleano que indica si el sistema operativo cargó el ejecutable desde un volumen APFS autorizado y autenticado.
*`on-authorized-authapfs-volume`: Un valor booleano que indica si el sistema operativo cargó el ejecutable desde un volumen APFS autorizado y autenticado.
* Volumen Cryptexes
*`on-system-volume:` Un valor booleano que indica si el sistema operativo cargó el ejecutable desde el volumen del sistema actualmente arrancado.
* Dentro de /System...
* ...
Cuando un binario de Apple está firmado, se **asigna a una categoría de LC** dentro de la **caché de confianza**.
* Las **16 categorías de LC de iOS** fueron [**invertidas y documentadas aquí**](https://gist.github.com/LinusHenze/4cd5d7ef057a144cda7234e2c247c056).
* Las actuales **categorías de LC (macOS 14** - Somona) han sido invertidas y sus [**descripciones se pueden encontrar aquí**](https://gist.github.com/theevilbit/a6fef1e0397425a334d064f7b6e1be53).
Tienes más información [**sobre esto aquí**](https://theevilbit.github.io/posts/launch\_constraints\_deep\_dive/#reversing-constraints), pero básicamente, están definidos en **AMFI (AppleMobileFileIntegrity)**, por lo que necesitas descargar el Kit de Desarrollo del Kernel para obtener el **KEXT**. Los símbolos que comienzan con **`kConstraintCategory`** son los **interesantes**. Al extraerlos, obtendrás un flujo codificado DER (ASN.1) que necesitarás decodificar con [ASN.1 Decoder](https://holtstrom.com/michael/tools/asn1decoder.php) o la biblioteca python-asn1 y su script `dump.py`, [andrivet/python-asn1](https://github.com/andrivet/python-asn1/tree/master) que te dará una cadena más comprensible.
Estas son las Restricciones de Lanzamiento configuradas en **aplicaciones de terceros**. El desarrollador puede seleccionar los **hechos** y **operandos lógicos a utilizar** en su aplicación para restringir el acceso a la misma.
En macOS que se ejecuta en dispositivos con Apple Silicon, si un binario firmado por Apple no está en el caché de confianza, AMFI se negará a cargarlo.
(Otra opción podría ser usar la herramienta [**img4tool**](https://github.com/tihmstar/img4tool), la cual funcionará incluso en M1 aunque la versión sea antigua y para x86\_64 si la instalas en las ubicaciones adecuadas).
Luego, podrías usar un script como [**este**](https://gist.github.com/xpn/66dc3597acd48a4c31f5f77c3cc62f30) para extraer datos.
A partir de esos datos, puedes verificar las aplicaciones con un valor de **restricciones de inicio de `0`**, que son las que no están restringidas ([**ver aquí**](https://gist.github.com/LinusHenze/4cd5d7ef057a144cda7234e2c247c056) para ver qué representa cada valor).
## Mitigaciones de Ataque
Las Restricciones de Inicio habrían mitigado varios ataques antiguos al **asegurarse de que el proceso no se ejecute en condiciones inesperadas:** Por ejemplo, desde ubicaciones inesperadas o ser invocado por un proceso padre inesperado (si solo launchd debería iniciarlo).
Sin embargo, **no mitigan abusos comunes de XPC**, inyecciones de código de **Electron** o inyecciones de **dylib** sin validación de biblioteca (a menos que se conozcan los IDs de equipo que pueden cargar bibliotecas).
En la versión Sonoma, un punto notable es la **configuración de responsabilidad** del servicio XPC del demonio. El servicio XPC es responsable de sí mismo, a diferencia de que el cliente conectado sea responsable. Esto está documentado en el informe de retroalimentación FB13206884. Esta configuración puede parecer defectuosa, ya que permite ciertas interacciones con el servicio XPC:
- **Iniciar el Servicio XPC**: Si se asume que es un error, esta configuración no permite iniciar el servicio XPC a través de código malicioso.
- **Conectar a un Servicio Activo**: Si el servicio XPC ya está en ejecución (posiblemente activado por su aplicación original), no hay barreras para conectarse a él.
Si bien implementar restricciones en el servicio XPC podría ser beneficioso al **reducir la ventana para posibles ataques**, no aborda la preocupación principal. Asegurar la seguridad del servicio XPC requiere fundamentalmente **validar efectivamente al cliente conectado**. Este sigue siendo el único método para fortalecer la seguridad del servicio. Además, cabe destacar que la configuración de responsabilidad mencionada está actualmente operativa, lo que puede no estar alineado con el diseño previsto.
Incluso si es necesario que la aplicación se **abra mediante LaunchService** (en las restricciones de los padres). Esto se puede lograr utilizando **`open`** (que puede establecer variables de entorno) o utilizando la **API de Launch Services** (donde se pueden indicar variables de entorno).
