Utilice [**Trickest**](https://trickest.io/) para construir y **automatizar flujos de trabajo** con las herramientas de la comunidad más avanzadas del mundo.\
Durante la prueba se sugerirán **varias operaciones** (conectar al dispositivo, leer/escribir/subir/bajar archivos, usar algunas herramientas...). Por lo tanto, si no sabe cómo realizar alguna de estas acciones, **comience leyendo la página**:
Para los siguientes pasos, **la aplicación debe estar instalada** en el dispositivo y ya se debe haber obtenido el **archivo IPA** de la aplicación.\
Lea la página [Operaciones básicas de prueba de iOS](basic-ios-testing-operations.md) para aprender cómo hacer esto.
{% endhint %}
### Análisis estático básico
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.
Identificación de **protecciones presentes en el binario**:
***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 dificulta predecir su dirección de memoria inicial.
```
otool -hv <app-binary> | grep PIE # Debería incluir la bandera PIE
***Canarios de pila**: Para validar la integridad de la pila, se coloca un valor de "canario" en la pila antes de llamar a una función y se valida nuevamente una vez que la función termina.
***Binario cifrado**: El binario debe estar cifrado
```
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT # El cryptid debería ser 1
```
**Identificación de funciones sensibles/inseguras**
***Algoritmos de hash débiles**
```
# En el dispositivo iOS
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"
# En linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"
```
***Funciones aleatorias inseguras**
```
# En el dispositivo iOS
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"
# En linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"
```
***Función 'Malloc' insegura**
```
# En el dispositivo iOS
otool -Iv <app> | grep -w "_malloc"
# En linux
grep -iER "_malloc"
```
***Funciones inseguras y vulnerables**
```
# En el dispositivo iOS
otool -Iv <app> | grep -w "_gets"
otool -Iv <app> | grep -w "_memcpy"
otool -Iv <app> | grep -w "_strncpy"
otool -Iv <app> | grep -w "_strlen"
otool -Iv <app> | grep -w "_vsnprintf"
otool -Iv <app> | grep -w "_sscanf"
otool -Iv <app> | grep -w "_strtok"
otool -Iv <app> | grep -w "_alloca"
otool -Iv <app> | grep -w "_sprintf"
otool -Iv <app> | grep -w "_printf"
otool -Iv <app> | grep -w "_vsprintf"
# En linux
grep -R "_gets"
grep -iER "_memcpy"
grep -iER "_strncpy"
grep -iER "_strlen"
grep -iER "_vsnprintf"
grep -iER "_sscanf"
grep -iER "_strtok"
grep -iER "_alloca"
grep -iER "_sprintf"
grep -iER "_printf"
grep -iER "_vsprintf"
```
### Análisis dinámico básico
Consulte el análisis dinámico que realiza [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF). Tendrá que navegar por las diferentes vistas e interactuar con ellas, pero se enganchará en varias clases al hacer otras cosas y preparará un informe una vez que haya terminado.
Cuando se apuntan aplicaciones que están instaladas en el dispositivo, primero debe averiguar el identificador de paquete correcto de la aplicación que desea analizar. Puede usar `frida-ps -Uai` para obtener todas las aplicaciones (`-a`) actualmente instaladas (`-i`) en el dispositivo USB conectado (`-U`):
Los archivos `.ipa` son **paquetes comprimidos**, por lo que puedes cambiar la extensión a `.zip` y **descomprimirlos**. Una aplicación **empaquetada** completa lista para ser instalada se conoce comúnmente como un **Bundle**.\
Después de descomprimirlos, deberías ver `<NOMBRE>.app`, un archivo comprimido que contiene el resto de los recursos.
*`Info.plist`: Un archivo que contiene algunas de las configuraciones específicas de la aplicación.
*`_CodeSignature/` contiene un archivo plist con una firma sobre todos los archivos en el bundle.
*`Assets.car`: Otro archivo comprimido que contiene recursos (iconos).
*`Frameworks/` contiene las bibliotecas nativas de la aplicación como archivos .dylib o .framework.
*`PlugIns/` puede contener extensiones de aplicaciones como archivos .appex (no presentes en el ejemplo).
* [`Core Data`](https://developer.apple.com/documentation/coredata): Se utiliza para guardar los datos permanentes de la aplicación para su uso sin conexión, para almacenar en caché los 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 bundle.
* **en.lproj, fr.proj, Base.lproj**: Son los paquetes de idiomas que contienen recursos para esos idiomas específicos y un recurso predeterminado en caso de que un idioma no sea compatible.
La lista de propiedades de información o `Info.plist` es la principal fuente de información para una aplicación iOS. Consiste en un archivo estructurado que contiene pares de **clave-valor** que describen información de configuración esencial sobre la aplicación. En realidad, se espera que todos los ejecutables empaquetados (extensiones de aplicaciones, frameworks y aplicaciones) tengan un archivo `Info.plist`. Puedes encontrar todas las claves posibles en la [**Documentación de Desarrolladores de Apple**](https://developer.apple.com/documentation/bundleresources/information\_property\_list?language=objc).
El archivo puede estar formateado en **XML o binario (bplist)**. Puedes **convertirlo a formato XML** con un simple comando:
* En macOS con `plutil`, que es una herramienta que viene de forma nativa con macOS 10.2 y versiones superiores (actualmente no hay documentación oficial en línea disponible):
```bash
$ plutil -convert xml1 Info.plist
```
* En Linux:
```bash
$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist
```
Aquí hay una lista no exhaustiva de algunas informaciones y las palabras clave correspondientes que puedes buscar fácilmente en el archivo `Info.plist` simplemente inspeccionando el archivo o usando `grep -i <palabra clave> Info.plist`:
* Cadenas de propósito de permisos de la aplicación: `UsageDescription`
* Esquemas de URL personalizados: `CFBundleURLTypes`
* Tipos de documentos personalizados exportados/importados: `UTExportedTypeDeclarations` / `UTImportedTypeDeclarations`
* Configuración de Seguridad de Transporte de la Aplicación (ATS): `NSAppTransportSecurity`
Por favor, consulta los capítulos mencionados para aprender más sobre cómo probar cada uno de estos puntos.
En iOS, las **aplicaciones del sistema se pueden encontrar en el directorio `/Applications`** mientras que las aplicaciones **instaladas por el usuario** están disponibles en **`/private/var/containers/`**. Sin embargo, encontrar la carpeta correcta navegando por el sistema de archivos no es una tarea trivial ya que **cada aplicación recibe un UUID (Identificador Único Universal) de 128 bits aleatorio** asignado para sus nombres de directorio.
Para obtener fácilmente la información del directorio de instalación de las aplicaciones instaladas por el usuario, puedes usar el comando **`env`** de Objection que también te mostrará toda la información del directorio de la aplicación:
Como se puede ver, las aplicaciones tienen dos ubicaciones principales:
* El **directorio Bundle** (`/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/`).
* El **directorio de datos** (`/var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/`).
Estas carpetas contienen información que debe ser examinada detenidamente durante las evaluaciones de seguridad de la aplicación (por ejemplo, al analizar los datos almacenados en busca de datos sensibles).
**Directorio Bundle:**
* **AppName.app**
* Este es el paquete de la aplicación como se vio antes en el IPA, contiene datos esenciales de la aplicación, contenido estático y el binario compilado de la aplicación.
* Este directorio es visible para los usuarios, pero **los usuarios no pueden escribir en él**.
* El contenido de este directorio **no se respalda**.
* El contenido de esta carpeta se utiliza para **validar la firma del código**.
**Directorio de datos:**
* **Documents/**
* Contiene todos los datos generados por el usuario. El usuario final de la aplicación inicia la creación de estos datos.
* Visible para los usuarios y **los usuarios pueden escribir en él**.
* El contenido de este directorio **se respalda**.
* La aplicación puede deshabilitar las rutas estableciendo `NSURLIsExcludedFromBackupKey`.
* **Library/**
* Contiene todos los **archivos que no son específicos del usuario**, como **cachés**, **preferencias**, **cookies** y archivos de configuración de lista de propiedades (plist).
* Las aplicaciones de iOS suelen utilizar los subdirectorios `Application Support` y `Caches`, pero la aplicación puede crear subdirectorios personalizados.
* **Library/Caches/**
* Contiene archivos en caché **semipermanentes**.
* Invisible para los usuarios y **los usuarios no pueden escribir en él**.
* El contenido de este directorio **no se respalda**.
* 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 bajo.
* 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 bajo.
Echemos un vistazo más de cerca al directorio de paquetes de la aplicación (.app) de iGoat-Swift dentro del directorio Bundle (`/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`**:
Para imprimir el **segmento Objective-C** de la aplicación de ejemplo se puede utilizar:
```bash
otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa 0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache 0x0 __objc_empty_cache
vtable 0x0
data 0x1003de748
flags 0x80
instanceStart 8
```
Para obtener un código Objective-C más compacto, puedes usar [**class-dump**](http://stevenygard.com/projects/class-dump/):
```bash
class-dump some-app
//
// Generated by class-dump 3.5 (64 bit).
//
// class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//
#pragma mark Named Structures
struct CGPoint {
double _field1;
double _field2;
};
struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};
struct CGSize {
double _field1;
double _field2;
};
```
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/).
Utilice [**Trickest**](https://trickest.io/) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas de la comunidad **más avanzadas del mundo**.\
Los siguientes lugares para almacenar información deben ser revisados **justo después de instalar la aplicación**, **después de verificar todas las funcionalidades** de la aplicación e incluso después de **cerrar sesión de un usuario e iniciar sesión en otro**.\
El objetivo es encontrar **información sensible no protegida** de la aplicación (contraseñas, tokens), del usuario actual y de los usuarios que iniciaron sesión anteriormente.
Los archivos **plist** son archivos XML estructurados que **contienen pares clave-valor**. Es una forma de almacenar datos persistentes, por lo que a veces puede 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 escribe 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 predeterminado. El sistema predeterminado permite que una aplicación personalice su comportamiento de acuerdo con las **preferencias del usuario**. Los datos guardados por `NSUserDefaults` se pueden ver 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.
Estos datos ya no se pueden acceder directamente a través de una computadora confiable, pero se pueden acceder realizando una **copia de seguridad**.
Para encontrar todos los archivos plist utilizados por la aplicación, puede acceder a `/private/var/mobile/Containers/Data/Application/{APPID}` y ejecutar:
* En macOS con `plutil`, que es una herramienta que viene de forma nativa con macOS 10.2 y versiones superiores (actualmente no hay documentación oficial en línea disponible):
[`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 administrar 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 por defecto. 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 Core Data de una aplicación en la ruta `/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support`
**Si puedes abrir el SQLite y acceder a información sensible, entonces encontraste una mala configuración.**
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 guarda los datos (`/private/var/mobile/Containers/Data/Application/{APPID}`)
Los desarrolladores de aplicaciones pueden aprovecharlas para **almacenar y sincronizar datos con una base de datos NoSQL alojada en la nube**. Los datos se almacenan como JSON y se sincronizan en tiempo real con cada cliente conectado y también permanecen disponibles incluso cuando la aplicación está sin conexión.
Puede encontrar cómo verificar las bases de datos de Firebase mal configuradas aquí:
[Realm Objective-C](https://realm.io/docs/objc/latest/) y [Realm Swift](https://realm.io/docs/swift/latest/) no son suministrados por Apple, pero aún así vale la pena mencionarlos. **Almacenan todo sin cifrar, a menos que la configuración tenga habilitado el cifrado**.
Puedes utilizar la herramienta [**Realm Studio**](https://github.com/realm/realm-studio) para abrir estos archivos de base de datos.
El siguiente ejemplo demuestra cómo utilizar el cifrado con una base de datos de Realm:
```swift
// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}
```
### Bases de datos de Couchbase Lite
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) es un motor de base de datos ligero, integrado y orientado a documentos (NoSQL) que se puede sincronizar. Se compila nativamente para iOS y macOS.
Verifique posibles bases de datos de Couchbase en `/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/`
iOS almacena las cookies de las aplicaciones en **`Library/Cookies/cookies.binarycookies`** dentro de la carpeta de cada aplicación. Sin embargo, los desarrolladores a veces deciden guardarlas en el **llavero** ya que el mencionado **archivo de cookies puede ser accedido en las copias de seguridad**.
Para inspeccionar el archivo de cookies, puede usar [**este script de Python**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) o usar **`ios cookies get`** de objection.\
**También puede usar objection para** convertir estos archivos a un formato JSON\*\* e inspeccionar los datos.
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 o cualquier otra información sensible que se haya almacenado en caché. Para encontrar la información almacenada en caché, abra el directorio de datos de la aplicación (`/var/mobile/Containers/Data/Application/<UUID>`) y vaya 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 desactivar 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 almacenadas 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). Puede llamar a este método de la siguiente manera:
`URLCache.shared.removeAllCachedResponses()`
Este método eliminará todas las solicitudes y respuestas almacenadas en caché del archivo Cache.db.
2. Si no necesita utilizar las ventajas de las cookies, se recomienda utilizar la propiedad de configuración [.ephemeral](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral) de URLSession, que desactivará el almacenamiento de cookies y cachés.
[Documentación de Apple](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral):
`Un objeto de configuración de sesión efímera es similar a una configuración de sesión predeterminada (consulte default), 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 el 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 el disco es cuando le indica que escriba el contenido de una URL en un archivo.`
3. La caché también se puede desactivar estableciendo la política de caché en [.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). Esto desactivará el almacenamiento de caché de cualquier manera, ya sea en memoria o en disco.
Cada vez que presiona el botón de inicio, iOS **toma una captura de pantalla de la pantalla actual** para poder hacer la transición a la aplicación de una manera más suave. Sin embargo, si hay **datos sensibles** presentes en la pantalla actual, se **guardarán** en la **imagen** (que **persiste****a través****de****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 la carpeta `Library/Caches/Snapshots/` o `Library/SplashBoard/Snapshots` (los ordenadores de confianza no pueden acceder al sistema de archivos desde iOX 7.0).
Una forma de evitar 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()`.
A continuación se muestra un método de remediación de ejemplo que establecerá una captura de pantalla predeterminada.
Objective-C es un lenguaje de programación utilizado para desarrollar aplicaciones iOS y macOS. Es un lenguaje orientado a objetos que se basa en C y agrega características adicionales para trabajar con objetos y clases. Objective-C es el lenguaje principal utilizado para desarrollar aplicaciones iOS antes de la introducción de Swift en 2014.
Esto establece la imagen de fondo en `overlayImage.png` cada vez que la aplicación se minimiza. Esto evita la filtración de datos sensibles porque `overlayImage.png` siempre sobrescribirá la vista actual.
Herramientas como [**Keychain-Dumper**](https://github.com/ptoomey3/Keychain-Dumper) se pueden utilizar para volcar el keychain (el dispositivo debe estar con jailbreak).\
También se puede utilizar `ios keychain dump` de [**Objection**](https://github.com/sensepost/objection)**.**
**NSURLCredential**
**NSURLCredential** es la clase perfecta para **almacenar el nombre de usuario y la contraseña en el keychain**. No es necesario preocuparse por NSUserDefaults ni por ningún wrapper de keychain.\
Desde iOS 8.0, Apple permite instalar extensiones personalizadas para iOS, como teclados personalizados.\
Los teclados instalados se pueden gestionar a través de **Ajustes** > **General** > **Teclado** > **Teclados**.\
Los teclados personalizados se pueden utilizar para **interceptar** las **pulsaciones de teclas** y enviarlas al servidor del atacante. Sin embargo, ten en cuenta que **los teclados personalizados que requieren conectividad de red se notificarán al usuario.**\
Además, el **usuario puede cambiar a un teclado diferente** (más confiable) **para introducir las credenciales.**
Además, **las aplicaciones pueden impedir que sus usuarios usen teclados personalizados** dentro de la aplicación (o al menos para partes sensibles de la aplicación).
{% hint style="warning" %}
Se recomienda no permitir teclados de terceros si consideras que los usuarios no los necesitarán.
{% endhint %}
Ten en cuenta que debido a la corrección automática y las sugerencias automáticas, el teclado predeterminado de iOS capturará y almacenará cada palabra no estándar en un archivo de caché si el atributo **securetTextEntry** no está establecido en **true** o si **autoCorrectionType** no está establecido en **UITextAutoCorrectionTypeNo.**
Por defecto, los teclados **almacenan esta caché** dentro del sandbox de las aplicaciones en el archivo `Library/Keyboard/{locale}-dynamic-text.dat` o en `/private/var/mobile/Library/Keyboard/dynamic-text.dat`. Sin embargo, podría estar guardando los datos en otro lugar.\
Es posible restablecer la caché en _**Ajustes**_ > _**General**_ > _**Restablecer**_ > _**Restablecer diccionario de teclado**_
{% hint style="info" %}
Por lo tanto, **siempre revisa estos archivos** y busca posibles **informaciones sensibles**.\
**Interceptar el tráfico de red** es otra forma de comprobar si el teclado personalizado está enviando pulsaciones de teclas a un servidor remoto.
{% endhint %}
El protocolo [UITextInputTraits](https://developer.apple.com/reference/uikit/uitextinputtraits) se utiliza para la caché del teclado. Las clases UITextField, UITextView y UISearchBar admiten automáticamente este protocolo y ofrece las siguientes propiedades:
*`var autocorrectionType: UITextAutocorrectionType` determina si la corrección automática está habilitada durante la escritura. Cuando la corrección automática está habilitada, el objeto de texto realiza un seguimiento de las palabras desconocidas y sugiere reemplazos adecuados, reemplazando automáticamente el texto escrito a menos que el usuario anule el reemplazo. El valor predeterminado de esta propiedad es `UITextAutocorrectionTypeDefault`, que para la mayoría de los métodos de entrada habilita la corrección automática.
*`var secureTextEntry: BOOL` determina si se desactiva la copia de texto y la caché de texto y oculta el texto que se está introduciendo para `UITextField`. El valor predeterminado de esta propiedad es `NO`.
* Abra los archivos xib y storyboard en el `Interface Builder` de Xcode y verifique los estados de `Secure Text Entry` y `Correction` en el `Attributes Inspector` para el objeto correspondiente.
La aplicación debe evitar el almacenamiento en caché de información sensible ingresada en los campos de texto. Puede evitar el almacenamiento en caché deshabilitándolo programáticamente, utilizando la directiva `textObject.autocorrectionType = UITextAutocorrectionTypeNo` en los UITextFields, UITextViews y UISearchBars deseados. Para los datos que deben enmascararse, como los PIN y las contraseñas, establezca `textObject.secureTextEntry` en `YES`.
En iOS versión 6 y anteriores, los registros eran legibles por todo el mundo (una aplicación maliciosa podía leer registros de otras aplicaciones y extraer información sensible de allí). **Hoy en día, las aplicaciones solo pueden acceder a sus propios registros**.
Sin embargo, un **atacante** con **acceso físico** a un dispositivo **desbloqueado** puede conectarlo a una computadora y **leer los registros** (tenga en cuenta que los registros escritos en disco por una aplicación no se eliminan si la aplicación se desinstala).
Se recomienda **navegar por todas las pantallas** de la aplicación e **interactuar** con **cada** elemento de la interfaz de usuario y **funcionalidad** y proporcionar texto de entrada en todos los campos de texto y **revisar los registros** en busca de **información****sensible** expuesta.
Use las siguientes palabras clave para verificar el código fuente de la aplicación en busca de declaraciones de registro predefinidas y personalizadas:
Muchas aplicaciones registran mensajes informativos (y potencialmente sensibles) en el registro de la consola. El registro también contiene informes de fallas y otra información útil.
Puede utilizar estas herramientas:
```bash
idevice_id --list # To find the device ID
idevicesyslog -u <id> (| grep <app>) # To get the device logs
3. Elija **Ventana** -> **Dispositivos y simuladores**.
4. Haga clic en su dispositivo iOS conectado en la sección izquierda de la ventana Dispositivos.
5. Reproduzca el problema.
6. Haga clic en el botón **Abrir consola** ubicado en el área superior derecha de la ventana Dispositivos para ver los registros de la consola en una ventana separada.
También puede conectarse a la shell del dispositivo como se explica en Acceso a la shell del dispositivo, instalar **socat** a través de **apt-get** y ejecutar el siguiente comando:
Utilice [**Trickest**](https://trickest.io/) para construir y automatizar fácilmente flujos de trabajo con las herramientas de la comunidad más avanzadas del mundo.\
iOS incluye funciones de copia de seguridad automática que crean copias de los datos almacenados en el dispositivo. Puede **hacer copias de seguridad de iOS** desde su computadora host utilizando iTunes (hasta macOS Catalina) o Finder (desde macOS Catalina en adelante), o a través de la función de copia de seguridad de iCloud. En ambos casos, la copia de seguridad incluye casi todos los datos almacenados en el dispositivo iOS, excepto datos altamente sensibles como la información de Apple Pay y la configuración de Touch ID.
Dado que iOS realiza copias de seguridad de las aplicaciones instaladas y sus datos, una preocupación obvia es si los **datos sensibles del usuario** almacenados por la aplicación podrían **filtrarse accidentalmente a través de la copia de seguridad**. Otra preocupación, aunque menos obvia, es si **la configuración de configuración sensible utilizada para proteger datos o restringir la funcionalidad de la aplicación podría ser manipulada para cambiar el comportamiento de la aplicación después de restaurar una copia de seguridad modificada**. Ambas preocupaciones son válidas y estas vulnerabilidades han demostrado existir en una gran cantidad de aplicaciones hoy en día.
Una copia de seguridad de un dispositivo en el que se ha instalado una aplicación móvil incluirá todos los subdirectorios (excepto `Library/Caches/`) y archivos en el [directorio privado de la aplicación](https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple\_ref/doc/uid/TP40010672-CH2-SW12).\
Por lo tanto, **evite almacenar datos sensibles en texto plano dentro de cualquiera de los archivos o carpetas que se encuentran en el directorio privado o subdirectorios de la aplicación**.
Aunque todos los archivos en `Documents/` y `Library/Application Support/` siempre se respaldan por defecto, puede [excluir archivos de la copia de seguridad](https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple\_ref/doc/uid/TP40010672-CH2-SW28) llamando a `NSURL setResourceValue:forKey:error:` con la clave `NSURLIsExcludedFromBackupKey`.\
Puede utilizar las propiedades del sistema de archivos [NSURLIsExcludedFromBackupKey](https://developer.apple.com/reference/foundation/nsurl#//apple\_ref/c/data/NSURLIsExcludedFromBackupKey) y [CFURLIsExcludedFromBackupKey](https://developer.apple.com/reference/corefoundation/cfurl-rd7#//apple\_ref/c/data/kCFURLIsExcludedFromBackupKey) para excluir archivos y directorios de las copias de seguridad.
{% hint style="warning" %}
Por lo tanto, al verificar la copia de seguridad de una aplicación, debe verificar si **se puede acceder a alguna información sensible** y si puede **modificar algún comportamiento sensible** de la aplicación mediante **la modificación de alguna configuración de la copia de seguridad** y la restauración de la copia de seguridad.
Comience por **crear una copia de seguridad del dispositivo** (puede hacerlo usando Finder) y encontrar dónde se almacena la copia de seguridad. La documentación oficial de Apple lo ayudará a [ubicar las copias de seguridad de su iPhone, iPad y iPod touch](https://support.apple.com/en-us/HT204215).
Una vez que haya encontrado la copia de seguridad del dispositivo (`/Users/carlos.martin/Library/Application Support/MobileSync/Backup/{deviceID}`), puede comenzar a buscar información sensible utilizando grep, por ejemplo, o utilizando herramientas como [iMazing](https://imazing.com)).
Para identificar si una copia de seguridad está cifrada, puede verificar la clave llamada "IsEncrypted" del archivo "Manifest.plist", ubicado en la raíz del directorio de copia de seguridad. El siguiente ejemplo muestra una configuración que indica que la copia de seguridad está cifrada:
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plistversion="1.0">
...
<key>Date</key>
<date>2021-03-12T17:43:33Z</date>
<key>IsEncrypted</key>
<true/>
...
</plist>
```
En caso de que necesite trabajar con una copia de seguridad cifrada, hay algunos scripts de Python 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**, que servirán como un buen punto de partida. Sin embargo, tenga en cuenta que es posible que no funcionen con las últimas versiones de iTunes/Finder y que deban ajustarse.
También puede utilizar la herramienta [**iOSbackup**](https://pypi.org/project/iOSbackup/) para leer y extraer fácilmente archivos de una copia de seguridad de iOS cifrada con contraseña.
**Cómo modificar el comportamiento**
En la aplicación de billetera de Bitcoin de código abierto, [Bither](https://github.com/bither/bither-ios), verá que es posible configurar un PIN para bloquear la interfaz de usuario. Este PIN se almacena en el archivo `net.bither.plist` dentro de la **clave****pin_code**. Si borra esta clave de ese plist en la copia de seguridad y restaura la copia de seguridad, podrá acceder a la billetera.
## Pruebas de memoria para datos sensibles
En algún momento, la información confidencial se almacenará en la memoria. El objetivo es asegurarse de que esta información se exponga el menor tiempo posible.
Para investigar la memoria de una aplicación, primero cree un **volcado de memoria**. Alternativamente, puede **analizar la memoria en tiempo real** con, por ejemplo, un depurador. Independientemente del método que utilice, este es un proceso propenso a errores porque los volcados proporcionan los datos dejados por las funciones ejecutadas y es posible que se pierdan pasos críticos. Además, pasar por alto datos durante el análisis es bastante fácil de hacer a menos que conozca la huella de los datos que está buscando (ya sea su valor exacto o su formato). Por ejemplo, si la aplicación cifra según una clave simétrica generada aleatoriamente, es muy poco probable que detecte la clave en la memoria a menos que encuentre su valor por otros medios.
**Recuperación y análisis de un volcado de memoria**
Ya sea que esté utilizando un dispositivo con jailbreak o sin jailbreak, puede volcar la memoria del proceso de la aplicación con [objection](https://github.com/sensepost/objection) y [Fridump](https://github.com/Nightbringer21/fridump).
Después de que se haya volcado la memoria (por ejemplo, en un archivo llamado "memory"), dependiendo de la naturaleza de los datos que está buscando, necesitará un conjunto de herramientas diferentes para procesar y analizar ese volcado de memoria. Por ejemplo, si se centra en cadenas, puede ser suficiente para usted ejecutar el comando `strings` o `rabin2 -zz` para extraer esas cadenas.
```bash
# using strings
$ strings memory > strings.txt
# using rabin2
$ rabin2 -ZZ memory > strings.txt
```
Abre `strings.txt` en tu editor favorito y busca información sensible.
Sin embargo, si deseas inspeccionar otro tipo de datos, es mejor que uses radare2 y sus capacidades de búsqueda. Consulta la ayuda de radare2 sobre el comando de búsqueda (`/?`) para obtener más información y una lista de opciones. Lo siguiente muestra solo un subconjunto de ellas:
```bash
$ r2 <name_of_your_dump_file>
[0x00000000]> /?
Usage: /[!bf] [arg] Search stuff (see 'e??search' for options)
|Use io.va for searching in non virtual addressing spaces
| / foo\x00 search for string 'foo\0'
| /c[ar] search for crypto materials
| /e /E.F/i match regular expression
| /i foo search for string 'foo' ignoring case
| /m[?][ebm] magicfile search for magic, filesystems or binary headers
| /v[1248] value look for an `cfg.bigendian` 32bit value
Usando [**r2frida**](https://github.com/nowsecure/r2frida) puedes analizar e inspeccionar la memoria de la aplicación mientras se ejecuta sin necesidad de volcarla. Por ejemplo, puedes ejecutar los comandos de búsqueda anteriores desde r2frida y buscar en la memoria una cadena, valores hexadecimales, etc. Al hacerlo, recuerda agregar una barra diagonal invertida `\` antes del comando de búsqueda (y cualquier otro comando específico de r2frida) después de iniciar la sesión con `r2 frida://usb//<nombre_de_tu_aplicación>`.
## Criptografía rota
### Malos procesos de gestión de claves
Algunos desarrolladores guardan datos sensibles en el almacenamiento local y los cifran con una clave codificada/predeterminada en el código. Esto no debería hacerse ya que algunos procesos de reversión podrían permitir a los atacantes extraer la información confidencial.
### Uso de algoritmos inseguros y/o obsoletos
Los desarrolladores no deberían usar **algoritmos obsoletos** para realizar **comprobaciones** de autorización, **almacenar** o **enviar** datos. Algunos de estos algoritmos son: RC4, MD4, MD5, SHA1... Si se usan **hashes** para almacenar contraseñas, por ejemplo, se deben usar hashes resistentes a la fuerza bruta con sal.
### Comprobación
Las principales comprobaciones a realizar son encontrar si se pueden 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**.
Es interesante saber que puedes **monitorizar** algunas **bibliotecas** de **criptografía** automáticamente usando **objection** con:
```swift
ios monitor crypt
```
Para **más información** sobre las APIs y bibliotecas criptográficas de iOS, acceda 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)
El probador debe ser consciente de que **la autenticación local siempre debe ser obligatoria en un punto final remoto** o basada en un primitivo criptográfico. Los atacantes pueden evitar fácilmente la autenticación local si no se devuelve ningún dato del proceso de autenticación.
El [**marco de autenticación local**](https://developer.apple.com/documentation/localauthentication) \_\*\*\_proporciona un conjunto de APIs para que los desarrolladores extiendan un diálogo de autenticación a un usuario. En el contexto de la conexión a un servicio remoto, es posible (y recomendado) aprovechar el [llavero](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) para implementar la autenticación local.
El sensor de **identificación de huellas dactilares** es operado por el [coprocesador de seguridad SecureEnclave](https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf) y no expone los datos de huellas dactilares a ninguna otra parte del sistema. Junto con Touch ID, Apple introdujo _Face ID_: que permite la autenticación basada en el reconocimiento facial.
Los desarrolladores tienen dos opciones para incorporar la autenticación Touch ID/Face ID:
*`LocalAuthentication.framework` es una API de alto nivel que se puede utilizar para **autenticar al usuario a través de Touch ID**. La aplicación no puede acceder a ningún dato asociado con la huella dactilar inscrita y solo se le notifica si la autenticación fue exitosa.
*`Security.framework` es una API de nivel inferior para acceder a los [servicios del llavero](https://developer.apple.com/documentation/security/keychain\_services). Esta es una opción segura si su aplicación necesita **proteger algunos datos secretos con autenticación biométrica**, ya que el control de acceso se gestiona a nivel del sistema y no se puede evitar fácilmente. `Security.framework` tiene una API de C, pero hay varios [envoltorios de código abierto disponibles](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id), lo que hace que el acceso al llavero sea tan simple como a NSUserDefaults.
Tenga en cuenta que el uso de `LocalAuthentication.framework` o `Security.framework` será un control que puede ser evitado por un atacante, ya que solo devuelve un booleano y no hay datos para continuar. Consulte [Don't touch me that way, de David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM) para obtener más detalles.
Los desarrolladores pueden mostrar un **cuadro de diálogo de autenticación** utilizando la función **`evaluatePolicy`** de la clase **`LAContext`**. Dos políticas disponibles definen formas aceptables de autenticación:
*`deviceOwnerAuthentication`(Swift) o `LAPolicyDeviceOwnerAuthentication`(Objective-C): Cuando está disponible, se le solicita al usuario que realice la autenticación de Touch ID. Si Touch ID no está activado, se solicita el código de acceso del dispositivo. Si el código de acceso del dispositivo no está habilitado, la evaluación de la política falla.
*`deviceOwnerAuthenticationWithBiometrics` (Swift) o `LAPolicyDeviceOwnerAuthenticationWithBiometrics`(Objective-C): La autenticación se restringe a la biometría donde se le solicita al usuario que utilice Touch ID.
La **función `evaluatePolicy` devuelve un valor booleano** que indica si el usuario se ha autenticado correctamente. Lo que significa que puede ser fácilmente evitado (ver abajo)
### Autenticación Local utilizando el Llavero
Las **APIs del llavero de iOS pueden (y deben) ser utilizadas para implementar la autenticación local**. Durante este proceso, la aplicación almacena un token de autenticación secreto u otro dato secreto que identifica al usuario en el llavero. Para autenticarse en un servicio remoto, el usuario debe desbloquear el llavero utilizando su contraseña o huella dactilar para obtener los datos secretos.
El llavero permite guardar elementos con el atributo especial `SecAccessControl`, que permitirá el acceso al elemento desde el llavero solo después de que el usuario haya pasado la autenticación de Touch ID (o el código de acceso, si se permite una alternativa por los parámetros de atributo).
En el siguiente ejemplo, guardaremos la cadena "test\_strong\_password" en el llavero. La cadena solo se puede acceder en el dispositivo actual mientras se establezca el código de acceso (`kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` parámetro) y después de la autenticación de Touch ID para los dedos inscritos actualmente (`SecAccessControlCreateFlags.biometryCurrentSet` parámetro):
{% tabs %}
{% tab title="Swift" %}
```swift
// 1. create AccessControl object that will represent authentication settings
var error: Unmanaged<CFError>?
guard let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
SecAccessControlCreateFlags.biometryCurrentSet,
&error) else {
// failed to create AccessControl object
return
}
// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
var query: [String: Any] = [:]
query[kSecClass as String] = kSecClassGenericPassword
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecAttrAccount as String] = "OWASP Account" as CFString
query[kSecValueData as String] = "test_strong_password".data(using: .utf8)! as CFData
query[kSecAttrAccessControl as String] = accessControl
// 3. save item
let status = SecItemAdd(query as CFDictionary, nil)
This document describes the techniques used to pentest iOS apps. It covers the following topics:
- Setting up a pentesting environment for iOS apps
- Reverse engineering iOS apps
- Analyzing network traffic
- Analyzing file system
- Analyzing keychain
- Analyzing SQLite databases
- Analyzing binaries
- Bypassing jailbreak detection
- Bypassing SSL pinning
- Bypassing Touch ID and Face ID
- Exploiting vulnerabilities
## Setting up a Pentesting Environment for iOS Apps
To pentest iOS apps, you need a jailbroken iOS device or a non-jailbroken device with a developer certificate. You also need a Mac with Xcode and other tools installed.
### Jailbreaking an iOS Device
Jailbreaking an iOS device allows you to install apps and tweaks that are not available on the App Store. It also allows you to access the file system and perform other actions that are not possible on a non-jailbroken device.
There are several tools available to jailbreak an iOS device. Some of the popular ones are:
- [unc0ver](https://unc0ver.dev/)
- [checkra1n](https://checkra.in/)
- [Electra](https://coolstar.org/electra/)
- [Chimera](https://chimera.sh/)
### Setting up a Non-Jailbroken Device with a Developer Certificate
If you don't want to jailbreak your device, you can set up a non-jailbroken device with a developer certificate. This allows you to install apps on your device without going through the App Store.
To set up a non-jailbroken device with a developer certificate, you need to:
1. Create an Apple Developer account
2. Create a new App ID
3. Create a new provisioning profile
4. Install the provisioning profile on your device
5. Sign the app with the provisioning profile
6. Install the app on your device
### Installing Xcode and Other Tools
To pentest iOS apps, you need to install Xcode and other tools on your Mac. Xcode is available on the App Store. Other tools can be installed using [Homebrew](https://brew.sh/).
To install Xcode using Homebrew, run the following command:
```bash
brew install --cask xcode
```
To install other tools using Homebrew, run the following command:
```bash
brew install [tool-name]
```
## Reverse Engineering iOS Apps
Reverse engineering iOS apps allows you to understand how they work and identify vulnerabilities. There are several tools available to reverse engineer iOS apps. Some of the popular ones are:
Analyzing network traffic allows you to identify how an app communicates with its server and identify vulnerabilities. There are several tools available to analyze network traffic. Some of the popular ones are:
- [Wireshark](https://www.wireshark.org/)
- [Charles Proxy](https://www.charlesproxy.com/)
- [mitmproxy](https://mitmproxy.org/)
## Analyzing File System
Analyzing the file system allows you to identify sensitive information stored on the device and identify vulnerabilities. There are several tools available to analyze the file system. Some of the popular ones are:
Analyzing the keychain allows you to identify sensitive information stored on the device and identify vulnerabilities. There are several tools available to analyze the keychain. Some of the popular ones are:
Analyzing SQLite databases allows you to identify sensitive information stored on the device and identify vulnerabilities. There are several tools available to analyze SQLite databases. Some of the popular ones are:
- [DB Browser for SQLite](https://sqlitebrowser.org/)
## Analyzing Binaries
Analyzing binaries allows you to identify vulnerabilities in the app's code. There are several tools available to analyze binaries. Some of the popular ones are:
Exploiting vulnerabilities allows you to gain access to sensitive information or perform actions that are not authorized. There are several techniques to exploit vulnerabilities. Some of the popular ones are:
- Buffer overflow
- SQL injection
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF)
- Man-in-the-middle (MITM) attack
## Conclusion
Pentesting iOS apps requires a combination of technical skills and tools. By following the techniques described in this document, you can identify vulnerabilities and exploit them to gain access to sensitive information or perform unauthorized actions.
Ahora podemos solicitar el elemento guardado del llavero. Los servicios del llavero presentarán el cuadro de diálogo de autenticación al usuario y devolverán datos o nulos dependiendo de si se proporcionó o no una huella digital adecuada.
```swift
// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString
// 2. get item
var queryResult: AnyObject?
let status = withUnsafeMutablePointer(to: &queryResult) {
SecItemCopyMatching(query as CFDictionary, UnsafeMutablePointer($0))
}
if status == noErr {
let password = String(data: queryResult as! Data, encoding: .utf8)!
Este documento describe cómo realizar pruebas de penetración en aplicaciones iOS escritas en Objective-C. Se asume que el lector tiene conocimientos básicos de Objective-C y iOS.
# Configuración del entorno
Para realizar pruebas de penetración en aplicaciones iOS, necesitará un dispositivo iOS con jailbreak o un simulador de iOS. También necesitará un entorno de desarrollo de iOS, como Xcode, y un conjunto de herramientas de prueba de penetración, como Frida, Cycript y Objection.
# Pruebas de penetración
Las pruebas de penetración en aplicaciones iOS escritas en Objective-C pueden incluir la identificación de vulnerabilidades de seguridad, como la inyección de código, la inyección de SQL, la inyección de JavaScript y la inyección de HTML. También puede realizar pruebas de penetración en la autenticación, la autorización, la criptografía y la gestión de sesiones.
# Conclusión
Las pruebas de penetración en aplicaciones iOS escritas en Objective-C son esenciales para garantizar la seguridad de las aplicaciones móviles. Al seguir los pasos descritos en este documento, puede identificar y corregir vulnerabilidades de seguridad en sus aplicaciones iOS.
El uso de frameworks en una aplicación también puede ser detectado mediante el análisis de 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 líneas siguientes (recuerda que `LocalAuthentication.framework` utiliza `Security.framework` bajo el capó):
\*\*\*\*[**Objection Biometrics Bypass**](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass) \*\*\*\* se puede utilizar para evitar la autenticación local. Objection **utiliza Frida para instrumentar la función `evaluatePolicy` para que devuelva `True`** incluso si la autenticación no se realizó correctamente. Utilice el comando `ios ui biometrics_bypass` para evitar la autenticación biométrica insegura. Objection registrará un trabajo que reemplazará el resultado de `evaluatePolicy`. Funcionará tanto en implementaciones Swift como Objective-C.
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
Para saltarse la Autenticación Local, tenemos que escribir un script de Frida que **salte** la verificación mencionada de _**evaluatePolicy**. Como se puede ver en el fragmento de código anterior, **evaluatePolicy** utiliza un **callback** que determina el **resultado**. Por lo tanto, la forma más fácil de lograr el hackeo es interceptar ese callback y asegurarse de que siempre devuelva **success=1**.
Es importante verificar que no se esté produciendo **ninguna comunicación sin cifrado** y que la aplicación esté validando correctamente el **certificado TLS** del servidor.\
Para comprobar este tipo de problemas, se puede utilizar un proxy como **Burp**:
Un problema común al validar el certificado TLS es comprobar que el certificado fue firmado por una **CA de confianza**, pero **no comprobar** si **el nombre de host** del certificado es el nombre de host al que se está accediendo.\
Para comprobar este problema utilizando Burp, después de confiar en la CA de Burp en el iPhone, se puede **crear un nuevo certificado con Burp para un nombre de host diferente** y utilizarlo. Si la aplicación sigue funcionando, entonces algo es vulnerable.
### Pinning de Certificado
Si una aplicación está utilizando correctamente el Pinning de SSL, entonces la aplicación solo funcionará si el certificado es el que se espera. 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, se puede 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/tools/mobile-assistant/installing)\\**](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing\)/)\*
* **`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 la caché. En **`/Library/Cache/Snapshots/*`** se pueden encontrar las instantáneas realizadas a la aplicación antes de enviarla al fondo.
### Parcheo en Caliente/Actualización Forzada
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, se utiliza generalmente [**JSPatch**](https://github.com/bang590/JSPatch)**.** Pero también hay 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 lo hay) y probarlo.** Se podría intentar descargar una versión anterior de la aplicación para este propósito.
Un problema de los SDK de terceros es que no hay **control granular sobre las características ofrecidas por el SDK**. Se podría utilizar el SDK y tener todas las características (incluyendo fugas de diagnóstico y conexiones HTTP inseguras), o no utilizarlo. Además, por lo general, no es posible para los desarrolladores de aplicaciones **parchear una vulnerabilidad** en el SDK.\
Además, algunos SDK comienzan a **contener malware una vez que son muy confiables** por la comunidad.
Además, las características que estos servicios proporcionan pueden implicar servicios de **seguimiento para monitorear el comportamiento del usuario** mientras utiliza la aplicación, vender anuncios de banner o mejorar la experiencia del usuario. El inconveniente de los servicios de terceros es que los desarrolladores no conocen los detalles del código ejecutado a través de las bibliotecas de terceros. En consecuencia, no se debe enviar a un servicio más información de la necesaria y no se debe divulgar información confidencial.
El inconveniente es que un **desarrollador no conoce en detalle qué código se ejecuta a través de las bibliotecas de terceros** y, por lo tanto, renuncia a la visibilidad. En consecuencia, se debe asegurar que no se envíe más
