Utilice [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias más avanzadas del mundo.\
<summary><strong>Aprenda hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si desea ver su **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulte los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtenga [**artículos oficiales de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únase al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síganos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparta sus 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.
Durante la prueba **se sugerirán varias operaciones** (conectar al dispositivo, leer/escribir/subir/descargar archivos, usar algunas herramientas...). Por lo tanto, si no sabes cómo realizar alguna de estas acciones, por favor, **comienza leyendo la página**:
Se recomienda utilizar la herramienta [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) para realizar un Análisis Estático automático del archivo IPA.
***PIE (Ejecutable Independiente de la Posición)**: Cuando está habilitado, la aplicación se carga en una dirección de memoria aleatoria cada vez que se inicia, lo que hace más difícil predecir su dirección de memoria inicial.
***Canarios de Pila**: Para validar la integridad de la pila, se coloca un valor 'canario' en la pila antes de llamar a una función y se valida nuevamente una vez que la función termina.
Revisa el análisis dinámico que realiza [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF). Necesitarás navegar por las diferentes vistas e interactuar con ellas, pero estará enganchando varias clases y realizando otras acciones, y preparará un informe una vez que hayas terminado.
La estructura de un archivo **IPA** es esencialmente la de un **paquete comprimido**. Al cambiar su extensión a `.zip`, se puede **descomprimir** para revelar su contenido. Dentro de esta estructura, un **Bundle** representa una aplicación completamente empaquetada lista para la instalación. Dentro, encontrarás un directorio llamado `<NOMBRE>.app`, que encapsula los recursos de la aplicación.
* **`Info.plist`**: Este archivo contiene detalles de configuración específicos de la aplicación.
* **`_CodeSignature/`**: Este directorio incluye un archivo plist que contiene una firma, asegurando la integridad de todos los archivos en el paquete.
* [**`Core Data`**](https://developer.apple.com/documentation/coredata): Se utiliza para guardar los datos permanentes de tu aplicación para uso sin conexión, para almacenar datos temporales y para agregar funcionalidad de deshacer a tu aplicación en un solo dispositivo. Para sincronizar datos en varios dispositivos en una sola cuenta de iCloud, Core Data refleja automáticamente tu esquema en un contenedor de CloudKit.
* [**`PkgInfo`**](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): El archivo `PkgInfo` es una forma alternativa de especificar los códigos de tipo y creador de tu aplicación o paquete.
* **en.lproj, fr.proj, Base.lproj**: Son los paquetes de idioma que contienen recursos para esos idiomas específicos, y un recurso predeterminado en caso de que un idioma no sea compatible.
* **Seguridad**: El directorio `_CodeSignature/` juega un papel crítico en la seguridad de la aplicación al verificar la integridad de todos los archivos empaquetados a través de firmas digitales.
* **Gestión de Activos**: El archivo `Assets.car` utiliza compresión para gestionar eficientemente activos gráficos, crucial para optimizar el rendimiento de la aplicación y reducir su tamaño total.
* **Frameworks y PlugIns**: Estos directorios subrayan la modularidad de las aplicaciones de iOS, permitiendo a los desarrolladores incluir bibliotecas de código reutilizables (`Frameworks/`) y extender la funcionalidad de la aplicación (`PlugIns/`).
* **Localización**: La estructura admite múltiples idiomas, facilitando el alcance global de la aplicación al incluir recursos para paquetes de idiomas específicos.
El **Info.plist** sirve como piedra angular para las aplicaciones de iOS, encapsulando datos de configuración clave en forma de pares de **clave-valor**. Este archivo es un requisito no solo para aplicaciones, sino también para extensiones de aplicaciones y frameworks empaquetados dentro de él. Está estructurado en XML o en un formato binario y contiene información crítica que va desde permisos de la aplicación hasta configuraciones de seguridad. Para una exploración detallada de las claves disponibles, se puede consultar la [**Documentación para Desarrolladores de Apple**](https://developer.apple.com/documentation/bundleresources/information\_property\_list?language=objc).
Para aquellos que deseen trabajar con este archivo en un formato más accesible, la conversión a XML se puede lograr fácilmente mediante el uso de `plutil` en macOS (disponible nativamente en las versiones 10.2 y posteriores) o `plistutil` en Linux. Los comandos para la conversión son los siguientes:
Entre la gran cantidad de información que el archivo **Info.plist** puede divulgar, las entradas destacadas incluyen cadenas de permisos de la aplicación (`UsageDescription`), esquemas de URL personalizados (`CFBundleURLTypes`), y configuraciones para la Seguridad del Transporte de la Aplicación (`NSAppTransportSecurity`). Estas entradas, junto con otras como tipos de documentos personalizados exportados/importados (`UTExportedTypeDeclarations` / `UTImportedTypeDeclarations`), pueden ser fácilmente localizadas inspeccionando el archivo o empleando un simple comando `grep`:
En el entorno de iOS, los directorios están designados específicamente para las **aplicaciones del sistema** y las **aplicaciones instaladas por el usuario**. Las aplicaciones del sistema residen en el directorio `/Applications`, mientras que las aplicaciones instaladas por el usuario se colocan en `/var/mobile/containers/Data/Application/`. Estas aplicaciones se les asigna un identificador único conocido como un **UUID de 128 bits**, lo que hace que la tarea de localizar manualmente la carpeta de una aplicación sea desafiante debido a la aleatoriedad de los nombres de directorio.
Como las aplicaciones en iOS deben estar en un sandbox, cada aplicación también tendrá una carpeta dentro de **`$HOME/Library/Containers`** con el **`CFBundleIdentifier`** de la aplicación como nombre de carpeta.
Sin embargo, ambas carpetas (de datos y de contenedores) tienen el archivo **`.com.apple.mobile_container_manager.metadata.plist`** que enlaza ambos archivos en la clave `MCMetadataIdentifier`).
Para facilitar el descubrimiento del directorio de instalación de una aplicación instalada por el usuario, la herramienta **objection** proporciona un comando útil, `env`. Este comando revela información detallada del directorio para la aplicación en cuestión. A continuación se muestra un ejemplo de cómo usar este comando:
Los comandos como `ps` y `lsof` también se pueden utilizar para identificar el proceso de la aplicación y listar archivos abiertos, respectivamente, proporcionando información sobre las rutas de directorio activas de la aplicación:
* Este es el Paquete de la Aplicación como se veía antes en el IPA, contiene datos esenciales de la aplicación, contenido estático, así como el binario compilado de la aplicación.
* Contiene todos los **archivos que no son específicos del usuario**, como **cachés**, **preferencias**, **cookies** y archivos de configuración de listas de propiedades (plist).
* Las aplicaciones de iOS suelen utilizar los subdirectorios `Application Support` y `Caches`, pero la aplicación puede crear subdirectorios personalizados.
* El sistema operativo puede eliminar automáticamente los archivos de este directorio cuando la aplicación no se está ejecutando y el espacio de almacenamiento es escaso.
* El sistema operativo puede eliminar automáticamente los archivos de este directorio cuando la aplicación no se está ejecutando y el espacio de almacenamiento es escaso.
Echemos un vistazo más de cerca al directorio del Paquete de Aplicación (.app) de iGoat-Swift dentro del directorio del Paquete (`/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app`):
Dentro de la carpeta `<nombre-de-la-aplicación>.app` encontrarás un archivo binario llamado `<nombre-de-la-aplicación>`. Este es el archivo que se **ejecutará**. Puedes realizar una inspección básica del binario con la herramienta **`otool`**:
Sin embargo, las mejores opciones para desensamblar el binario son: [**Hopper**](https://www.hopperapp.com/download.html?) y [**IDA**](https://www.hex-rays.com/products/ida/support/download_freeware/).
Utiliza [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir fácilmente y **automatizar flujos de trabajo** impulsados por las herramientas comunitarias más avanzadas del mundo.\
Los siguientes lugares para almacenar información deben ser verificados **justo después de instalar la aplicación**, **después de revisar todas las funcionalidades** de la aplicación e incluso después de **cerrar sesión de un usuario e iniciar sesión con otro**.\
El objetivo es encontrar **información sensible no protegida** de la aplicación (contraseñas, tokens), del usuario actual y de usuarios previamente conectados.
Los archivos **plist** son archivos XML estructurados que **contienen pares clave-valor**. Es una forma de almacenar datos de forma persistente, por lo que a veces puedes encontrar **información sensible en estos archivos**. Se recomienda revisar estos archivos después de instalar la aplicación y después de usarla intensivamente para ver si se ha escrito nueva información.
La forma más común de persistir datos en archivos plist es a través del uso de **NSUserDefaults**. Este archivo plist se guarda dentro del sandbox de la aplicación en **`Library/Preferences/<appBundleID>.plist`**
La clase [`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults) proporciona una interfaz programática para interactuar con el sistema de preferencias predeterminado. El sistema predeterminado permite a una aplicación personalizar su comportamiento de acuerdo a las **preferencias del usuario**. Los datos guardados por `NSUserDefaults` pueden ser vistos en el paquete de la aplicación. Esta clase almacena **datos** en un **archivo plist**, pero está destinada a ser utilizada con pequeñas cantidades de datos.
[`Core Data`](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/nsfetchedresultscontroller.html#//apple_ref/doc/uid/TP40001075-CH8-SW1) es un marco para gestionar la capa de modelo de objetos en tu aplicación. [Core Data puede usar SQLite como su almacenamiento persistente](https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/), pero el marco en sí no es una base de datos. CoreData no cifra sus datos de forma predeterminada. Sin embargo, se puede agregar una capa de cifrado adicional a CoreData. Consulta el [Repositorio de GitHub](https://github.com/project-imas/encrypted-core-data) para obtener más detalles.
Puedes encontrar la información de SQLite de Core Data de una aplicación en la ruta `/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support`
Es común que las aplicaciones creen su propia base de datos sqlite. Pueden estar almacenando datos sensibles en ellas y dejándolos sin cifrar. Por lo tanto, siempre es interesante revisar cada base de datos dentro del directorio de aplicaciones. Por lo tanto, ve al directorio de la aplicación donde se guardan los datos (`/private/var/mobile/Containers/Data/Application/{APPID}`)
Los desarrolladores pueden **almacenar y sincronizar datos** en una **base de datos alojada en la nube NoSQL** a través de las bases de datos en tiempo real de Firebase. Almacenados en formato JSON, los datos se sincronizan en tiempo real con todos los clientes conectados.
[Realm Objective-C](https://realm.io/docs/objc/latest/) y [Realm Swift](https://realm.io/docs/swift/latest/) ofrecen una alternativa potente para el almacenamiento de datos, no proporcionada por Apple. Por defecto, **almacenan datos sin cifrar**, con la posibilidad de habilitar el cifrado a través de una configuración específica.
Las bases de datos se encuentran en: `/private/var/mobile/Containers/Data/Application/{APPID}`. Para explorar estos archivos, se pueden utilizar comandos como:
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) se describe como un motor de base de datos **ligero** y **incorporado** que sigue el enfoque **orientado a documentos** (NoSQL). Diseñado para ser nativo de **iOS** y **macOS**, ofrece la capacidad de sincronizar datos de forma transparente.
iOS almacena las cookies de las aplicaciones en el **`Library/Cookies/cookies.binarycookies`** dentro de la carpeta de cada aplicación. Sin embargo, a veces los desarrolladores deciden guardarlas en el **llavero** ya que el **archivo de cookies mencionado puede ser accedido en las copias de seguridad**.
Para inspeccionar el archivo de cookies puedes usar [**este script de Python**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) o utilizar **`ios cookies get`** de objection.\
Por defecto, NSURLSession almacena datos, como **solicitudes y respuestas HTTP en la base de datos Cache.db**. Esta base de datos puede contener **datos sensibles**, como tokens, nombres de usuario u otra información sensible que haya sido almacenada en caché. Para encontrar la información en caché, abre el directorio de datos de la aplicación (`/var/mobile/Containers/Data/Application/<UUID>`) y ve a `/Library/Caches/<Bundle Identifier>`. La **caché de WebKit también se almacena en el archivo Cache.db**. **Objection** puede abrir e interactuar con la base de datos con el comando `sqlite connect Cache.db`, ya que es una **base de datos SQLite normal**.
Se **recomienda deshabilitar el almacenamiento en caché de estos datos**, ya que pueden contener información sensible en la solicitud o respuesta. La siguiente lista muestra diferentes formas de lograr esto:
1. Se recomienda eliminar las respuestas en caché después de cerrar sesión. Esto se puede hacer con el método proporcionado por Apple llamado [`removeAllCachedResponses`](https://developer.apple.com/documentation/foundation/urlcache/1417802-removeallcachedresponses). Puedes llamar a este método de la siguiente manera:
2. Si no necesitas utilizar las ventajas de las cookies, se recomienda simplemente usar la propiedad de configuración [.ephemeral](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral) de URLSession, que deshabilitará el almacenamiento de cookies y cachés.
`Un objeto de configuración de sesión efímera es similar a una configuración de sesión predeterminada (ver predeterminada), excepto que el objeto de sesión correspondiente no almacena cachés, almacenes de credenciales ni ningún dato relacionado con la sesión en disco. En su lugar, los datos relacionados con la sesión se almacenan en RAM. La única vez que una sesión efímera escribe datos en disco es cuando le indicas que escriba el contenido de una URL en un archivo.`
3. La caché también se puede deshabilitar configurando la Política de Caché en [.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). Esto deshabilitará el almacenamiento de caché de cualquier forma, ya sea en memoria o en disco.
Cada vez que presionas el botón de inicio, iOS **toma una captura de pantalla de la pantalla actual** para poder realizar la transición a la aplicación de una manera más suave. Sin embargo, si hay **datos sensibles** en la pantalla actual, se **guardarán** en la **imagen** (que **persiste****a través** de los **reinicios**). Estas son las capturas de pantalla a las que también se puede acceder al hacer doble clic en la pantalla de inicio para cambiar entre aplicaciones.
A menos que el iPhone esté con jailbreak, el **atacante** necesita tener **acceso** al **dispositivo****desbloqueado** para ver estas capturas de pantalla. Por defecto, la última captura de pantalla se almacena en el sandbox de la aplicación en `Library/Caches/Snapshots/` o en la carpeta `Library/SplashBoard/Snapshots` (las computadoras de confianza no pueden acceder al sistema de archivos desde iOS 7.0).
Una forma de prevenir este comportamiento no deseado es poner una pantalla en blanco o eliminar los datos sensibles antes de tomar la captura de pantalla utilizando la función `ApplicationDidEnterBackground()`.
Esto establece la imagen de fondo en `overlayImage.png` cada vez que la aplicación pasa a segundo plano. Esto evita fugas de datos sensibles porque `overlayImage.png` siempre sobrescribirá la vista actual.
Para acceder y gestionar el llavero de iOS, herramientas como [**Keychain-Dumper**](https://github.com/ptoomey3/Keychain-Dumper) están disponibles, adecuadas para dispositivos con jailbreak. Además, [**Objection**](https://github.com/sensepost/objection) proporciona el comando `ios keychain dump` con propósitos similares.
La clase **NSURLCredential** es ideal para guardar información sensible directamente en el llavero, evitando la necesidad de NSUserDefaults u otros envoltorios. Para almacenar credenciales después del inicio de sesión, se utiliza el siguiente código Swift:
A partir de iOS 8.0, los usuarios pueden instalar extensiones de teclado personalizadas, que se pueden gestionar en **Configuración > General > Teclado > Teclados**. Si bien estos teclados ofrecen funcionalidades extendidas, representan un riesgo de registro de pulsaciones de teclas y de envío de datos a servidores externos, aunque los usuarios son notificados sobre los teclados que requieren acceso a la red. Las aplicaciones pueden y deben restringir el uso de teclados personalizados para la introducción de información sensible.
* Tener en cuenta las funciones de autocorrección y sugerencias automáticas del teclado iOS predeterminado, que podrían almacenar información sensible en archivos de caché ubicados en `Library/Keyboard/{locale}-dynamic-text.dat` o `/private/var/mobile/Library/Keyboard/dynamic-text.dat`. Estos archivos de caché deben ser revisados regularmente en busca de datos sensibles. Se recomienda restablecer el diccionario del teclado a través de **Configuración > General > Restablecer > Restablecer diccionario del teclado** para limpiar los datos en caché.
El [protocolo UITextInputTraits](https://developer.apple.com/reference/uikit/uitextinputtraits) ofrece propiedades para gestionar la autocorrección y la entrada de texto segura, esenciales para prevenir el almacenamiento de información sensible. Por ejemplo, deshabilitar la autocorrección y habilitar la entrada de texto segura se puede lograr con:
Además, los desarrolladores deben asegurarse de que los campos de texto, especialmente aquellos para ingresar información sensible como contraseñas y PIN, deshabiliten el almacenamiento en caché configurando `autocorrectionType` en `UITextAutocorrectionTypeNo` y `secureTextEntry` en `YES`.
Depurar código a menudo implica el uso de **registros**. Existe un riesgo ya que los **registros pueden contener información sensible**. Anteriormente, en iOS 6 y versiones anteriores, los registros eran accesibles para todas las aplicaciones, lo que suponía un riesgo de fuga de datos sensibles. **Ahora, las aplicaciones están restringidas a acceder solo a sus propios registros**.
A pesar de estas restricciones, un **atacante con acceso físico** a un dispositivo desbloqueado aún puede explotar esto conectando el dispositivo a una computadora y **leyendo los registros**. Es importante tener en cuenta que los registros permanecen en el disco incluso después de desinstalar la aplicación.
Para mitigar riesgos, se recomienda **interactuar minuciosamente con la aplicación**, explorando todas sus funcionalidades y entradas para asegurarse de que no se esté registrando información sensible involuntariamente.
Al revisar el código fuente de la aplicación en busca de posibles fugas, busque tanto **declaraciones de registro predefinidas** como **personalizadas** utilizando palabras clave como `NSLog`, `NSAssert`, `NSCAssert`, `fprintf` para funciones integradas, y cualquier mención de `Logging` o `Logfile` para implementaciones personalizadas.
Seguido por comandos para observar las actividades de registro, que pueden ser invaluables para diagnosticar problemas o identificar posibles fugas de datos en los registros.
Utilice [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias más avanzadas del mundo.\
Las funciones de **autorespaldo** están integradas en iOS, facilitando la creación de copias de datos del dispositivo a través de iTunes (hasta macOS Catalina), Finder (desde macOS Catalina en adelante) o iCloud. Estas copias de seguridad abarcan casi todos los datos del dispositivo, excluyendo elementos altamente sensibles como detalles de Apple Pay y configuraciones de Touch ID.
La inclusión de **aplicaciones instaladas y sus datos** en las copias de seguridad plantea el problema de posibles **fugas de datos** y el riesgo de que las **modificaciones de la copia de seguridad puedan alterar la funcionalidad de la aplicación**. Se recomienda **no almacenar información sensible en texto plano** dentro del directorio de ninguna aplicación o sus subdirectorios para mitigar estos riesgos.
Los archivos en `Documents/` y `Library/Application Support/` se respaldan de forma predeterminada. Los desarrolladores pueden excluir archivos o directorios específicos de las copias de seguridad utilizando `NSURL setResourceValue:forKey:error:` con la clave `NSURLIsExcludedFromBackupKey`. Esta práctica es crucial para proteger los datos sensibles de ser incluidos en las copias de seguridad.
Para evaluar la seguridad de la copia de seguridad de una aplicación, comience por **crear una copia de seguridad** utilizando Finder, luego localícela siguiendo la guía de la [documentación oficial de Apple](https://support.apple.com/en-us/HT204215). Analice la copia de seguridad en busca de datos sensibles o configuraciones que podrían ser alteradas para afectar el comportamiento de la aplicación.
La información sensible se puede buscar utilizando herramientas de línea de comandos o aplicaciones como [iMazing](https://imazing.com). Para copias de seguridad encriptadas, la presencia de encriptación se puede confirmar verificando la clave "IsEncrypted" en el archivo "Manifest.plist" en la raíz de la copia de seguridad.
Para lidiar con copias de seguridad encriptadas, los scripts de Python disponibles en el [repositorio de GitHub de DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python\_scripts), como **backup\_tool.py** y **backup\_passwd.py**, pueden ser útiles, aunque potencialmente requieran ajustes para ser compatibles con las últimas versiones de iTunes/Finder. La herramienta [**iOSbackup**](https://pypi.org/project/iOSbackup/) es otra opción para acceder a archivos dentro de copias de seguridad protegidas con contraseña.
Un ejemplo de alterar el comportamiento de una aplicación a través de modificaciones en la copia de seguridad se muestra en la aplicación de billetera de bitcoins Bither (https://github.com/bither/bither-ios), donde el PIN de bloqueo de la interfaz de usuario se almacena dentro de `net.bither.plist` bajo la clave **pin\_code**. Eliminar esta clave del plist y restaurar la copia de seguridad elimina el requisito del PIN, proporcionando acceso sin restricciones.
Al tratar con información sensible almacenada en la memoria de una aplicación, es crucial limitar el tiempo de exposición de estos datos. Hay dos enfoques principales para investigar el contenido de la memoria: **crear un volcado de memoria** y **analizar la memoria en tiempo real**. Ambos métodos tienen sus desafíos, incluida la posibilidad de perder datos críticos durante el proceso de volcado o análisis.
Tanto en dispositivos con jailbreak como sin jailbreak, herramientas como [objection](https://github.com/sensepost/objection) y [Fridump](https://github.com/Nightbringer21/fridump) permiten el volcado de la memoria del proceso de una aplicación. Una vez volcado, analizar estos datos requiere diversas herramientas, dependiendo de la naturaleza de la información que estás buscando.
**r2frida** proporciona una alternativa poderosa para inspeccionar la memoria de una aplicación en tiempo real, sin necesidad de un volcado de memoria. Esta herramienta permite la ejecución de comandos de búsqueda directamente en la memoria de la aplicación en ejecución:
Algunos desarrolladores guardan datos sensibles en el almacenamiento local y los cifran con una clave codificada/predecible en el código. Esto no debería hacerse, ya que un proceso de reversión podría permitir a los atacantes extraer la información confidencial.
Los desarrolladores no deberían utilizar algoritmos obsoletos para realizar comprobaciones de autorización, almacenar o enviar datos. Algunos de estos algoritmos son: RC4, MD4, MD5, SHA1... Si se utilizan hashes para almacenar contraseñas, por ejemplo, se deben utilizar hashes resistentes a ataques de fuerza bruta con sal.
Las principales verificaciones a realizar son encontrar contraseñas/secretos codificados en el código, o si estos son predecibles, y si el código está utilizando algún tipo de algoritmos de criptografía débiles.
Para **más información** sobre las API y bibliotecas criptográficas de iOS, accede a [https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography)
La **autenticación local** juega un papel crucial, especialmente cuando se trata de salvaguardar el acceso en un punto final remoto a través de métodos criptográficos. La esencia aquí es que sin una implementación adecuada, los mecanismos de autenticación local pueden ser eludidos.
El [**framework de Autenticación Local de Apple**](https://developer.apple.com/documentation/localauthentication) y el [**llavero**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) proporcionan API sólidas para que los desarrolladores faciliten diálogos de autenticación de usuarios y manejen de forma segura datos secretos, respectivamente. El Secure Enclave asegura la identificación de huellas dactilares para Touch ID, mientras que Face ID se basa en el reconocimiento facial sin comprometer datos biométricos.
* **`LocalAuthentication.framework`** para autenticación de usuario de alto nivel sin acceso a datos biométricos.
* **`Security.framework`** para acceso a servicios de llavero de nivel inferior, asegurando datos secretos con autenticación biométrica. Varios [envoltorios de código abierto](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id) hacen que el acceso al llavero sea más sencillo.
Sin embargo, tanto `LocalAuthentication.framework` como `Security.framework` presentan vulnerabilidades, ya que principalmente devuelven valores booleanos sin transmitir datos para procesos de autenticación, lo que los hace susceptibles a eludir (consultar [Don't touch me that way, de David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM)).
Para solicitar a los usuarios autenticación, los desarrolladores deben utilizar el método **`evaluatePolicy`** dentro de la clase **`LAContext`**, eligiendo entre:
Implementar la **autenticación local** en aplicaciones de iOS implica el uso de **APIs de llavero** para almacenar de forma segura datos secretos como tokens de autenticación. Este proceso garantiza que los datos solo puedan ser accedidos por el usuario, utilizando su código de acceso del dispositivo o autenticación biométrica como Touch ID.
El llavero ofrece la capacidad de establecer elementos con el atributo `SecAccessControl`, que restringe el acceso al elemento hasta que el usuario se autentique con éxito a través de Touch ID o código de acceso del dispositivo. Esta característica es crucial para mejorar la seguridad.
A continuación se muestran ejemplos de código en Swift y Objective-C que demuestran cómo guardar y recuperar una cadena en/desde el llavero, aprovechando estas características de seguridad. Los ejemplos muestran específicamente cómo configurar el control de acceso para requerir autenticación con Touch ID y asegurar que los datos solo sean accesibles en el dispositivo en el que se configuraron, bajo la condición de que se haya configurado un código de acceso del dispositivo.
El lenguaje de programación Objective-C es ampliamente utilizado en el desarrollo de aplicaciones iOS. Es importante comprender sus conceptos y características al realizar pruebas de penetración en aplicaciones iOS. Aquí se presentan algunas técnicas comunes de pentesting específicas de Objective-C:
Ahora podemos solicitar el elemento guardado del llavero. Los servicios del llavero presentarán el cuadro de autenticación al usuario y devolverán datos o nil dependiendo de si se proporcionó una huella digital adecuada o no.
El lenguaje de programación Objective-C es ampliamente utilizado en el desarrollo de aplicaciones iOS. Es importante comprender sus conceptos y características para realizar pruebas de penetración efectivas en aplicaciones iOS escritas en Objective-C.
Es fundamental tener en cuenta estas vulnerabilidades al realizar pruebas de penetración en aplicaciones iOS escritas en Objective-C para garantizar la seguridad de la aplicación.
El uso de frameworks en una aplicación también se puede detectar analizando la lista de bibliotecas dinámicas compartidas del binario de la aplicación. Esto se puede hacer utilizando `otool`:
Si se utiliza `LocalAuthentication.framework` en una aplicación, la salida contendrá ambas de las siguientes líneas (recuerda que `LocalAuthentication.framework` utiliza `Security.framework` internamente):
A través del **Bypass Biométrico de Objection**, ubicado en [esta página de GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), está disponible una técnica para superar el mecanismo de **LocalAuthentication**. El núcleo de este enfoque implica aprovechar **Frida** para manipular la función `evaluatePolicy`, asegurando que produzca consistentemente un resultado `True`, independientemente del éxito real de la autenticación. Esto es particularmente útil para eludir procesos de autenticación biométrica defectuosos.
Este comando inicia una secuencia donde Objection registra una tarea que altera efectivamente el resultado de la verificación de `evaluatePolicy` a `True`.
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
Para lograr el **bypass** de la Autenticación Local, se escribe un script de Frida. Este script apunta a la verificación de **evaluatePolicy**, interceptando su devolución de llamada para asegurar que devuelva **success=1**. Al alterar el comportamiento de la devolución de llamada, se logra eludir efectivamente la verificación de autenticación.
El siguiente script se inyecta para modificar el resultado del método **evaluatePolicy**. Cambia el resultado de la devolución de llamada para indicar siempre éxito.
Es importante verificar que no se esté produciendo ninguna comunicación **sin cifrado** y también que la aplicación esté validando correctamente el **certificado TLS** del servidor.\
Para verificar este tipo de problemas, puedes utilizar un proxy como **Burp**:
Un problema común al validar el certificado TLS es verificar que el certificado fue firmado por una **CA de confianza**, pero **no verificar** si **el nombre de host** del certificado es el nombre de host al que se accede.\
Para verificar este problema usando Burp, después de confiar en la CA de Burp en el iPhone, puedes **crear un nuevo certificado con Burp para un nombre de host diferente** y usarlo. Si la aplicación sigue funcionando, entonces algo es vulnerable.
Si una aplicación está utilizando correctamente el Pinning SSL, entonces la aplicación solo funcionará si el certificado es el esperado. Al probar una aplicación, **esto puede ser un problema ya que Burp servirá su propio certificado.**\
Para evitar esta protección dentro de un dispositivo con jailbreak, puedes instalar la aplicación [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) o instalar [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)
* **`iTunesArtwork`**: El icono utilizado por la aplicación
* **`iTunesMetadata.plist`**: Información de la aplicación utilizada en la App Store
* **`/Library/*`**: Contiene las preferencias y caché. En **`/Library/Cache/Snapshots/*`** puedes encontrar la instantánea realizada a la aplicación antes de enviarla al segundo plano.
Los desarrolladores pueden **parchear remotamente todas las instalaciones de su aplicación al instante** sin tener que volver a enviar la aplicación a la App Store y esperar a que sea aprobada.\
Para este propósito, generalmente se utiliza [**JSPatch**](https://github.com/bang590/JSPatch)**.** Pero también existen otras opciones como [Siren](https://github.com/ArtSabintsev/Siren) y [react-native-appstore-version-checker](https://www.npmjs.com/package/react-native-appstore-version-checker).\
**Este es un mecanismo peligroso que podría ser abusado por SDK de terceros maliciosos, por lo tanto se recomienda verificar qué método se utiliza para la actualización automática (si la hay) y probarlo.** Podrías intentar descargar una versión anterior de la aplicación con este propósito.
Un desafío significativo con **SDK de terceros** es la **falta de control granular** sobre sus funcionalidades. Los desarrolladores se enfrentan a una elección: integrar el SDK y aceptar todas sus características, incluidas posibles vulnerabilidades de seguridad y preocupaciones de privacidad, o renunciar por completo a sus beneficios. A menudo, los desarrolladores no pueden parchear las vulnerabilidades dentro de estos SDK por sí mismos. Además, a medida que los SDK ganan confianza dentro de la comunidad, algunos pueden empezar a contener malware.
Los servicios proporcionados por los SDK de terceros pueden incluir seguimiento del comportamiento del usuario, visualización de anuncios o mejoras en la experiencia del usuario. Sin embargo, esto introduce un riesgo ya que los desarrolladores pueden no estar completamente al tanto del código ejecutado por estas bibliotecas, lo que conlleva posibles riesgos de privacidad y seguridad. Es crucial limitar la información compartida con los servicios de terceros a lo necesario y asegurarse de que no se expongan datos sensibles.
La implementación de servicios de terceros suele venir en dos formas: una biblioteca independiente o un SDK completo. Para proteger la privacidad del usuario, cualquier dato compartido con estos servicios debe estar **anonimizado** para evitar la divulgación de Información de Identificación Personal (PII).
Para identificar las bibliotecas que utiliza una aplicación, se puede emplear el comando **`otool`**. Este comando debe ejecutarse contra la aplicación y cada biblioteca compartida que utiliza para descubrir bibliotecas adicionales.
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias más avanzadas del mundo.\
<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)!
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **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).
