hacktricks/mobile-pentesting/ios-pentesting/ios-basics.md

☁️ 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!

• Descubre The PEASS Family, nuestra colección de exclusivos NFTs

• Obtén el oficial PEASS & HackTricks swag

• Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.

• Comparte tus trucos de hacking enviando PR al repositorio de hacktricks y al repositorio de 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.

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:

• 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 (

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) a través de una extensión del kernel.

Algunas capacidades/permisos 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 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.

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/<nombre de la aplicación>.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:

    <plist version="1.0">
    <dict>
        <key>NSLocationWhenInUseUsageDescription</key>
        <string>Se utiliza su ubicación para proporcionar indicaciones de giro a su destino.</string>
  

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.

<key>UIRequiredDeviceCapabilities</key>
<array>
    <string>armv7</string>
</array>

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, 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 <nombre de la aplicación>.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:

<key>Entitlements</key>
<dict>
    ...
    <key>com.apple.developer.default-data-protection</key>
    <string>NSFileProtectionComplete</string>
</dict>

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.