☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 - ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa 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 [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección de exclusivos [**NFTs**](https://opensea.io/collection/the-peass-family) - Obtén el [**oficial PEASS & HackTricks swag**](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** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.** - **Comparte tus trucos de hacking enviando PR al [repositorio de hacktricks](https://github.com/carlospolop/hacktricks) y al [repositorio de hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
# Separación de privilegios y sandbox Las aplicaciones a las que el usuario puede acceder se ejecutan como el usuario **mobile**, mientras que los procesos críticos del sistema se ejecutan como **root**.\ Sin embargo, el sandbox permite un mejor control sobre las acciones que los procesos y aplicaciones pueden realizar. Por ejemplo, incluso si dos procesos se ejecutan como el mismo usuario (mobile), **no se les permite acceder o modificar los datos del otro**. Cada aplicación se instala en **`private/var/mobile/Applications/{ID aleatorio}`**\ Una vez instaladas, las aplicaciones tienen acceso de lectura limitado a algunas áreas y funciones del sistema (SMS, llamadas telefónicas...). Si una aplicación quiere acceder a un **área protegida**, aparece una **ventana emergente que solicita permiso**. # Protección de datos Los desarrolladores de aplicaciones pueden aprovechar las API de _Data Protection_ de iOS para implementar un **control de acceso detallado** para los datos del usuario almacenados en la memoria flash. Las API se basan en el **procesador Secure Enclave** (SEP). El SEP es un coprocesador que proporciona **operaciones criptográficas para la protección de datos y la gestión de claves**. Una clave de hardware específica del dispositivo, el **UID del dispositivo** (ID único), está **incrustada en el enclave seguro**, asegurando la integridad de la protección de datos incluso cuando el kernel del sistema operativo está comprometido. Cuando se crea un **archivo** en el disco, se genera una nueva **clave AES de 256 bits** con la ayuda del generador de números aleatorios basado en hardware del enclave seguro. El **contenido del archivo se cifra con la clave generada**. Y luego, esta **clave se guarda cifrada con una clave de clase** junto con **el ID de clase**, con **ambos datos cifrados por la clave del sistema**, dentro de los **metadatos** del archivo. ![](<../../.gitbook/assets/image (473).png>) Para descifrar el archivo, se **descifran los metadatos usando la clave del sistema**. Luego, utilizando el **ID de clase**, se **recupera la clave de clase** **para descifrar la clave por archivo y descifrar el archivo.** Los archivos se pueden asignar a una de **cuatro** **clases de protección** diferentes, que se explican con más detalle en la [Guía de seguridad de la plataforma Apple](https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf): * **Protección completa (NSFileProtectionComplete)**: Una clave derivada del código de acceso del usuario y el UID del dispositivo protege esta clave de clase. La clave derivada se borra de la memoria poco después de que el dispositivo se bloquee, lo que hace que los datos sean inaccesibles hasta que el usuario desbloquee el dispositivo. * **Protegido a menos que se abra (NSFileProtectionCompleteUnlessOpen)**: Esta clase de protección es similar a la protección completa, pero, si el archivo se abre cuando está desbloqueado, la aplicación puede seguir accediendo al archivo incluso si el usuario bloquea el dispositivo. Esta clase de protección se utiliza cuando, por ejemplo, se está descargando un archivo adjunto de correo electrónico en segundo plano. * **Protegido hasta la primera autenticación del usuario ( ```objectivec let userDefaults = UserDefaults.standard if userDefaults.bool(forKey: "hasRunBefore") == false { // Remove Keychain items here // Update the flag indicator userDefaults.set(true, forKey: "hasRunBefore") userDefaults.synchronize() // Forces the app to update UserDefaults } ``` * Al desarrollar la funcionalidad de cierre de sesión para una aplicación iOS, asegúrese de que los datos de Keychain se borren como parte del cierre de sesión de la cuenta. Esto permitirá a los usuarios eliminar sus cuentas antes de desinstalar una aplicación. # **Capacidades de la aplicación** **Cada aplicación tiene un directorio de inicio único y está aislada**, por lo que no pueden acceder a recursos del sistema protegidos o archivos almacenados por el sistema o por otras aplicaciones. Estas restricciones se implementan mediante políticas de aislamiento (también conocidas como _perfiles_), que son aplicadas por el [Marco de Control de Acceso Obligatorio de BSD de Confianza (MAC)](http://www.trustedbsd.org/mac.html) a través de una extensión del kernel. Algunas [**capacidades/permisos**](https://help.apple.com/developer-account/#/dev21218dfd6) pueden ser configuradas por los desarrolladores de la aplicación (por ejemplo, Protección de Datos o Compartir Keychain) y tendrán efecto directo después de la instalación. Sin embargo, para otros, **se le pedirá explícitamente al usuario la primera vez que la aplicación intente acceder a un recurso protegido**. Las [_cadenas de propósito_](https://developer.apple.com/documentation/uikit/core\_app/protecting\_the\_user\_s\_privacy/accessing\_protected\_resources?language=objc#3037322) o _cadenas de descripción de uso_ son textos personalizados que se ofrecen a los usuarios en la alerta de solicitud de permiso del sistema al solicitar permiso para acceder a datos o recursos protegidos. ![](https://gblobscdn.gitbook.com/assets%2F-LH00RC4WVf3-6Ou4e0l%2F-Lf1APQHyCHdAvoJSvc\_%2F-Lf1AQw8W2q7BB5-il7r%2Fpermission\_request\_alert.png?alt=media) Si se tiene el código fuente original, se pueden verificar los permisos incluidos en el archivo `Info.plist`: * Abra el proyecto con Xcode. * Encuentre y abra el archivo `Info.plist` en el editor predeterminado y busque las claves que comienzan con `"Privacidad -"`. Puede cambiar la vista para mostrar los valores en bruto haciendo clic con el botón derecho y seleccionando "Mostrar claves/valores en bruto" (de esta manera, por ejemplo, `"Privacidad - Descripción de uso de ubicación cuando se usa"` se convertirá en `NSLocationWhenInUseUsageDescription`). Si solo se tiene el IPA: * Descomprima el IPA. * El archivo `Info.plist` se encuentra en `Payload/.app/Info.plist`. * Conviértalo si es necesario (por ejemplo, `plutil -convert xml1 Info.plist`) como se explica en el capítulo "Pruebas básicas de seguridad de iOS", sección "El archivo Info.plist". * Inspeccione todas las claves de _cadenas de propósito en el archivo Info.plist_, que generalmente terminan con `UsageDescription`: ```markup NSLocationWhenInUseUsageDescription Se utiliza su ubicación para proporcionar indicaciones de giro a su destino. ``` ## Capacidades del dispositivo Las capacidades del dispositivo se utilizan por la App Store para garantizar que solo se enumeren dispositivos compatibles y, por lo tanto, se les permita descargar la aplicación. Se especifican en el archivo `Info.plist` de la aplicación bajo la clave [`UIRequiredDeviceCapabilities`](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple\_ref/doc/plist/info/UIRequiredDeviceCapabilities). ```markup UIRequiredDeviceCapabilities armv7 ``` > Por lo general, encontrará la capacidad `armv7`, lo que significa que la aplicación está compilada solo para el conjunto de instrucciones armv7, o si es una aplicación universal de 32/64 bits. Por ejemplo, una aplicación puede depender completamente de NFC para funcionar (por ejemplo, una aplicación "Lector de etiquetas NFC"). Según la [Referencia de compatibilidad de dispositivos iOS archivada](https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html), NFC solo está disponible a partir del iPhone 7 (y iOS 11). Un desarrollador podría querer excluir todos los dispositivos incompatibles estableciendo la capacidad del dispositivo `nfc`. ## Derechos > Los derechos son pares de clave-valor que se firman en una aplicación y permiten la autenticación más allá de los factores de tiempo de ejecución, como el ID de usuario de UNIX. Dado que los derechos están firmados digitalmente, no se pueden cambiar. Los derechos se utilizan ampliamente por las aplicaciones y demonios del sistema para **realizar operaciones privilegiadas específicas que de lo contrario requerirían que el proceso se ejecutara como root**. Esto reduce en gran medida el potencial de escalada de privilegios por parte de una aplicación o demonio del sistema comprometido. Por ejemplo, si desea establecer la capacidad "Protección de datos predeterminada", deberá ir a la pestaña **Capacidades** en Xcode y habilitar **Protección de datos**. Esto se escribe directamente por Xcode en el archivo `.entitlements` como el derecho `com.apple.developer.default-data-protection` con el valor predeterminado `NSFileProtectionComplete`. En el IPA, podemos encontrar esto en `embedded.mobileprovision` como: ```markup Entitlements ... com.apple.developer.default-data-protection NSFileProtectionComplete ``` Para otras capacidades como HealthKit, se debe pedir permiso al usuario, por lo tanto, no es suficiente agregar los entitlements, se deben agregar claves y cadenas especiales al archivo `Info.plist` de la aplicación. # Conceptos básicos de Objective-C y Swift **Objective-C** tiene un **tiempo de ejecución dinámico**, por lo que cuando se ejecuta un programa Objective-C en iOS, llama a bibliotecas cuyas **direcciones se resuelven en tiempo de ejecución** comparando el nombre de la función enviada en el mensaje con una lista de todos los nombres de función disponibles. Al principio, solo las aplicaciones creadas por Apple se ejecutaban en los iPhones, por lo que tenían **acceso a todo** ya que eran **confiables**. Sin embargo, cuando Apple **permitió** **aplicaciones de terceros**, Apple simplemente eliminó los archivos de encabezado de las funciones poderosas para "ocultarlas" a los desarrolladores. Sin embargo, los desarrolladores descubrieron que las funciones "seguras" necesitaban algunas de estas funciones no documentadas y simplemente creando un **archivo de encabezado personalizado con los nombres de las funciones no documentadas, era posible invocar estas poderosas funciones ocultas**. En realidad, Apple, antes de permitir que una aplicación se publique, verifica si la aplicación llama a alguna de estas funciones prohibidas. Luego apareció Swift. Como **Swift está vinculado estáticamente** (no resuelve la dirección de las funciones en tiempo de ejecución como Objective-C), se pueden verificar más fácilmente las llamadas que un programa Swift va a hacer mediante análisis de código estático. # Gestión de dispositivos A partir de la versión 6 de iOS, hay **soporte incorporado para la capacidad de gestión de dispositivos** con controles de granularidad fina que permiten a una organización controlar los dispositivos corporativos de Apple.\ La inscripción puede ser **iniciada por el usuario instalando un agente** para acceder a las aplicaciones corporativas. En este caso, el dispositivo generalmente pertenece al usuario.\ O la **empresa puede indicar los números de serie** de los dispositivos comprados o el ID del pedido de compra y especificar el perfil MDM para instalar en esos dispositivos. Tenga en cuenta que Apple **no permite inscribir un dispositivo en particular de esta manera dos veces**. Una vez que se elimina el primer perfil, el usuario debe dar su consentimiento para instalar otro. El usuario puede ver las políticas instaladas en _**Configuración**_ --> _**General**_ --> _**Perfiles y gestión de dispositivos**_ Como estas políticas MDM están verificando y limitando otras aplicaciones, se están **ejecutando con más privilegios**.\ Una política MDM puede **obligar** a los **usuarios** a tener un **código de acceso** establecido con una **complejidad de contraseña mínima**.\ Los perfiles están vinculados al ID de dispositivo, **firmados** y **encriptados** por el servidor MDM y **a prueba de manipulaciones**. No se pueden eliminar sin **perder** todos los **datos corporativos**.\ Los perfiles MDM permiten **borrar** todos los **datos** si hay X **intentos fallidos** de **contraseña**. Además, el **administrador** puede **borrar** el iPhone de forma remota en cualquier momento a través de la interfaz MDM. Los agentes MDM también **verificarán** posibles **jailbreaks del dispositivo**, ya que este es un estado muy peligroso para un iPhone.