Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
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**:
É recomendado usar a ferramenta [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) para realizar uma Análise Estática automática no arquivo IPA.
***PIE (Executable Posicionamento Independente)**: 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.
***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.
Confira a análise dinâmica que o [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-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.
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 ativos 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`**](https://developer.apple.com/documentation/coredata): É usado para salvar os dados permanentes do seu aplicativo para uso offline, para armazenar dados temporários em cache 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`**](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): O arquivo `PkgInfo` é uma maneira alternativa de especificar os códigos de tipo e criador do 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áveis (`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.
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**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc).
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:
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`:
No ambiente iOS, os diretórios são designados especificamente para **aplicativos do sistema** e **aplicativos instalados pelo usuário**. Os aplicativos do sistema residem no diretório `/Applications`, enquanto os aplicativos instalados pelo usuário são colocados em `/private/var/containers/`. Esses aplicativos 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 de diretório.
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:
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:
* Este é o Pacote de Aplicativo, 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**.
* 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).
* 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.
* 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 Aplicativo (.app) do iGoat-Swift dentro do diretório do Pacote (`/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app`):
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`**:
No entanto, as melhores opções para desmontar o binário são: [**Hopper**](https://www.hopperapp.com/download.html?) e [**IDA**](https://www.hex-rays.com/products/ida/support/download_freeware/).
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
Os seguintes locais para armazenar informações devem ser verificados **imediatamente 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.
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`](https://developer.apple.com/documentation/foundation/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 de aplicativos. Esta classe armazena **dados** em um **arquivo plist**, mas é destinada a ser usada com pequenas quantidades de dados.
[`Core Data`](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/nsfetchedresultscontroller.html#//apple_ref/doc/uid/TP40001075-CH8-SW1) é um framework para gerenciar a camada de modelo de objetos em sua aplicação. [Core Data pode usar o SQLite como seu armazenamento persistente](https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/), 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](https://github.com/project-imas/encrypted-core-data) 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`
É 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}`)
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 no formato JSON, os dados são sincronizados em tempo real para todos os clientes conectados.
[Realm Objective-C](https://realm.io/docs/objc/latest/) e [Realm Swift](https://realm.io/docs/swift/latest/) 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:
O [Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) é 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.
O iOS armazena os cookies dos aplicativos no **`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**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) ou usar o **`ios cookies get`** do objection.\
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:
1. É recomendado remover as respostas em cache após o logout. Isso pode ser feito com o método fornecido pela Apple chamado [`removeAllCachedResponses`](https://developer.apple.com/documentation/foundation/urlcache/1417802-removeallcachedresponses). Você pode chamar este método da seguinte forma:
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 a propriedade de configuração [.ephemeral](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral) do URLSession, que desativará o salvamento de cookies e caches.
`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](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). Isso desativará o armazenamento de cache de qualquer maneira, seja na memória ou no disco.
Sempre que você pressiona o botão home, o iOS **tira uma captura de tela da tela atual** para poder fazer a transição para o aplicativo de uma maneira muito 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**). Essas são as capturas de tela às 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, a última captura de tela é armazenada 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 a captura de tela usando a função `ApplicationDidEnterBackground()`.
Este código define a imagem de fundo como `overlayImage.png` sempre que a aplicação é colocada em segundo plano. Isso previne vazamentos de dados sensíveis, pois `overlayImage.png` sempre substituirá a visualização atual.
Para acessar e gerenciar o keychain do iOS, ferramentas como [**Keychain-Dumper**](https://github.com/ptoomey3/Keychain-Dumper) estão disponíveis, adequadas para dispositivos com jailbreak. Além disso, o [**Objection**](https://github.com/sensepost/objection) fornece o comando `ios keychain dump` para fins semelhantes.
A classe **NSURLCredential** é ideal para salvar informações sensíveis diretamente no keychain, contornando a necessidade de NSUserDefaults ou outros invólucros. Para armazenar credenciais após o login, o seguinte código Swift é utilizado:
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.
- É aconselhável desativar os teclados de terceiros para segurança aprimorada.
- Esteja ciente das funcionalidades de autocorreção e 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.
O [protocolo UITextInputTraits](https://developer.apple.com/reference/uikit/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:
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`.
Depurar código frequentemente envolve 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.
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**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
Recursos de **auto-backup** estão integrados 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.
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.
Arquivos em `Documents/` e `Library/Application Support/` são automaticamente incluídos nos backups. 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.
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](https://support.apple.com/en-us/HT204215). 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](https://imazing.com). Para backups criptografados, a presença de criptografia pode ser confirmada verificando a chave "IsEncrypted" no arquivo "Manifest.plist" na raiz do backup.
Para lidar com backups criptografados, scripts Python disponíveis no [repositório GitHub da DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), 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**](https://pypi.org/project/iOSbackup/) é outra opção para acessar arquivos em backups protegidos por senha.
Um exemplo de alteração do 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.
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.
Para dispositivos com e sem jailbreak, ferramentas como [objection](https://github.com/sensepost/objection) e [Fridump](https://github.com/Nightbringer21/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.
**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 pesquisa diretamente na memória do aplicativo em execução:
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.
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** forem usados para armazenar senhas, por exemplo, hashes resistentes a **ataques de força bruta** devem ser usados com sal.
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**.
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](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography)
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](https://developer.apple.com/documentation/localauthentication)** e o **[keychain](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html)** 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 [wrappers de código aberto](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id) tornam o acesso ao chaveiro mais simples.
No entanto, tanto o `LocalAuthentication.framework` quanto o `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](https://www.youtube.com/watch?v=XhXIHVGCFFM)).
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.
Implementar a **autenticação local** em aplicativos iOS envolve o uso de **APIs de chaveiro** para armazenar de forma segura 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.
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 iOS
Existem várias ferramentas disponíveis para pentesting de aplicativos iOS. Algumas das ferramentas populares incluem:
- **Cycript**: Uma ferramenta de injeção de código que permite a análise e manipulação dinâmica de aplicativos iOS.
- **Clutch**: Uma ferramenta para decodificar aplicativos iOS.
- **Frida**: Uma estrutura poderosa para instrumentação dinâmica de aplicativos iOS.
- **MobSF**: Uma estrutura de segurança móvel automatizada que suporta a análise estática e dinâmica de aplicativos iOS.
## Técnicas de Pentesting iOS
Ao realizar pentesting em aplicativos iOS, algumas técnicas comuns incluem:
- **Análise de código**: Examinar o código-fonte do aplicativo em busca de vulnerabilidades.
- **Teste de segurança**: Realizar testes de segurança para identificar possíveis vulnerabilidades.
- **Análise de tráfego**: Monitorar e analisar o tráfego de rede gerado pelo aplicativo.
- **Teste de autenticação**: Testar a segurança da autenticação do aplicativo.
- **Teste de autorização**: Verificar se as autorizações do aplicativo estão configuradas corretamente.
## Conclusão
O pentesting de aplicativos iOS é essencial para garantir a segurança e proteção dos dados dos usuários. Com as ferramentas e técnicas certas, é possível identificar e corrigir vulnerabilidades em aplicativos iOS, garantindo uma experiência segura para os usuários.
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.
O iOS é um sistema operacional móvel desenvolvido pela Apple para seus dispositivos, como iPhones e iPads. Durante um teste de penetração em um aplicativo iOS, é importante entender como o aplicativo foi desenvolvido e como ele lida com dados sensíveis e comunicações de rede.
## Ferramentas de Teste de Penetração
Existem várias ferramentas disponíveis para testar a segurança de aplicativos iOS. Algumas das ferramentjson mais populares incluem:
- **Cycript**: Uma ferramenta de injeção de código que permite a inspeção e manipulação de aplicativos em tempo de execução.
- **Clutch**: Uma ferramenta para dumping de aplicativos iOS.
- **Frida**: Uma ferramenta de injeção de código que permite a execução de scripts JavaScript nos aplicativos.
- **Hopper**: Um descompilador para aplicativos iOS.
- **MobSF**: Uma estrutura de teste de segurança móvel automatizada.
## Análise Estática
Durante a análise estática de um aplicativo iOS, é possível examinar o código fonte do aplicativo em busca de vulnerabilidades de segurança. Isso pode incluir a identificação de chamadas inseguras de API, armazenamento inadequado de dados sensíveis e outras práticas inseguras de programação.
## Análise Dinâmica
Na análise dinâmica de um aplicativo iOS, o aplicativo é executado em um ambiente controlado para observar seu comportamento. Isso pode ajudar a identificar possíveis vulnerabilidades, como comunicações inseguras de rede, manipulação inadequada de dados de entrada e saída, entre outros.
## Conclusão
Ao realizar testes de penetração em aplicativos iOS, é essencial combinar técnicas de análise estática e dinâmica para identificar e explorar vulnerabilidades de segurança. O conhecimento das ferramentas disponíveis e das práticas recomendadas de segurança é fundamental para garantir a eficácia dos testes.
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`:
Se o `LocalAuthentication.framework` for usado em um aplicativo, a saída conterá ambas as seguintes linhas (lembre-se de que o `LocalAuthentication.framework` usa o `Security.framework` internamente):
Através do **Objection Biometrics Bypass**, localizado nesta [página do GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), uma técnica está disponível para contornar o mecanismo de **LocalAuthentication**. O cerne dessa abordagem envolve a alavancagem 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.
Este comando inicia uma sequência onde o Objection registra uma tarefa que altera efetivamente o resultado da verificação `evaluatePolicy` para `True`.
[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.
É importante verificar se não há comunicação ocorrendo **sem criptografia** e também se o aplicativo está corretamente **validando o certificado TLS** do servidor.\
Para verificar esse tipo de problema, você pode usar um proxy como o **Burp**:
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 o aplicativo ainda funcionar, então algo está vulnerável.
Se um aplicativo estiver usando corretamente a Pinagem SSL, então o aplicativo só funcionará se o certificado for o esperado. Ao testar um aplicativo **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**](https://github.com/nabla-c0d3/ssl-kill-switch2) ou instalar [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)
* Dentro da pasta de uma aplicação instalada (**`/User/Applications/<IDDOAPP>/`**) 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.
Os desenvolvedores podem **corrigir remotamente todas as instalações de seu aplicativo instantaneamente** sem precisar reenviar o aplicativo para a App Store e esperar até que seja aprovado.\
Para esse fim, geralmente é usado o [**JSPatch**](https://github.com/bang590/JSPatch)**.** Mas existem outras opções também, como [Siren](https://github.com/ArtSabintsev/Siren) e [react-native-appstore-version-checker](https://www.npmjs.com/package/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.
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 um aplicativo utiliza, o comando **`otool`** pode ser empregado. Esta ferramenta deve ser executada contra o aplicativo e cada biblioteca compartilhada que ele utiliza para descobrir bibliotecas adicionais.
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente com as **ferramentas comunitárias mais avançadas do mundo**.\
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).