Saqueando o CACHE.DB do Aplicativo iOS. Informações confidenciais não devem ser armazenadas em texto não criptografado nos arquivos locais de um aplicativo.
As avaliações de aplicativos móveis divergem um pouco das avaliações normais de aplicativos da Web, pois há um aplicativo cliente instalado em um dispositivo local para acompanhar o servidor de back-end. Os aplicativos móveis geralmente funcionam off-line e, portanto, possuem um armazenamento local de dados. Isso geralmente ocorre na forma de bancos de dados SQLite armazenados na “caixa de proteção” do sistema de arquivos do aplicativo.
Como parte de uma avaliação de aplicativo móvel, o TrustedSec revisa como os dados são armazenados e armazenados em cache nesses arquivos locais. Informações confidenciais não devem ser armazenadas em texto não criptografado nos arquivos locais de um aplicativo. Tanto o Android quanto o iOS fornecem métodos seguros de armazenamento de dados confidenciais, usando o Android Keystore e o iOS Keychain.
Essas ferramentas de armazenamento seguro são perfeitas para armazenar tokens de sessão, cookies, senhas e chaves de criptografia. Embora você não queira armazenar uma grande quantidade de dados no Keychain ou Keystore, você pode facilmente criptografar um banco de dados SQLite usando ferramentas como SQLCipher e manter a chave de criptografia no Keychain ou Keystore.
Você pensaria que tais ferramentas levariam a uma abundância de bancos de dados criptografados no desenvolvimento de aplicativos móveis. Infelizmente, raramente vemos bancos de dados SQLite criptografados no armazenamento de arquivos local.
Mas os desenvolvedores de aplicativos não são os únicos culpados aqui. O iOS fornece um sistema de carregamento de URL para facilitar o desenvolvimento de aplicativos. As classes NSURLSession ajudam os desenvolvedores a obter a comunicação entre seu aplicativo e o servidor de back-end em funcionamento.
Por padrão, essa biblioteca armazenará em cache o tráfego de rede, nos arquivos locais do aplicativo, em um arquivo não criptografado chamado Cache.db . Este é um banco de dados SQLite que vemos em quase todas as avaliações de aplicativos iOS.
Então, o que encontramos em Cache.db ? Mais de 90% das vezes, encontramos cookies e tokens de sessão. Isso não é bom, pois essas informações podem levar ao comprometimento da conta. Também encontramos dados contidos nas respostas do servidor armazenados em cache neste banco de dados, potencialmente revelando essas informações também.
E com bastante frequência, encontraremos as credenciais completas de texto não criptografado do usuário.
Fig.3 – Isso é um loot gostoso
Fig.3 – Isso é um loot gostosoAntes de abordarmos como você recuperaria essas informações do arquivo Cache.db, quero abordar como um invasor pode colocar as mãos nesse arquivo. Dispositivos iOS e Android atualizados fornecem fortes controles de segurança. Arquivos como Cache.db são armazenados na caixa de proteção do aplicativo, tornando o acesso a esses arquivos um desafio para invasores.
O caminho de ataque mais óbvio para adquirir os dados locais é obter acesso ao dispositivo desbloqueado, o que não é uma tarefa fácil.
Um caminho mais provável para acessar esses arquivos é a partir de um backup do dispositivo. Especificamente para um dispositivo iOS, isso pode ocorrer comprometendo uma conta do iCloud ou obtendo acesso ao computador desktop que contém um backup local do dispositivo. Os desenvolvedores de aplicativos precisam desabilitar especificamente os backups de seus aplicativos ou dados. Frequentemente recupero arquivos Cache.db de um backup do iOS.
Fig.4 – Fazendo backup do iPhone
Você pode encontrar esses arquivos de backup no computador local nos seguintes locais:
macOS: ~/Library/Application Support/MobileSync/Backup Windows: %APPDATA%\Apple Computer\MobileSync\Backup
Para o backup do iOS, todos os nomes de pastas e arquivos serão substituídos por hashes. Isso torna bastante difícil usar o backup diretamente, mas a ferramenta iExplorer pode tornar isso significativamente mais fácil. O iExplorer pode extrair os arquivos de dados locais para o aplicativo e pode até mesmo descriptografar o backup se você tiver acesso à senha usada para criar o backup.
Fig.5 – Dados do aplicativo local no iExplorer
Depois de extrair as pastas de dados locais do iExplorer, você pode começar a procurar dados confidenciais. A pasta Cache.db está localizada por padrão em /Library/Caches/APPBUNDLEID/Cache.db .
Vejamos como você extrai dados potencialmente confidenciais desse banco de dados. Sou um grande fã de revisar bancos de dados usando o DB Browser for SQLite .
Você deve revisar todas as entradas no banco de dados, mas frequentemente com Cache.db você encontrará “blobs” no banco de dados que são listas de propriedades binárias (PLISTs).
Fig.6 – Blobs PLIST binários no banco de dados
Uma grande dica de que o blob que você está vendo no banco de dados é um PLIST binário é a string bplist no topo do blob.
Fig.7 – string bplist
Você pode exportar individualmente esses PLISTs binários e convertê-los para revisão, mas há uma maneira mais rápida de fazer esse tipo de análise. Primeiro, vamos extrair todos os PLISTs binários e despejá-los em arquivos.
Em seguida, extrairemos quaisquer PLISTs incorporados. PLISTs podem ter PLISTs adicionais embutidos neles, e usaremos um script para extrair esses PLISTs binários adicionais e salvá-los em um arquivo.
Por fim, converteremos os PLISTs binários em ASCII, para que possamos revisá-los em busca de dados confidenciais em um editor de texto.
No diretório onde você tem o arquivo Cache.db recuperado , crie um subdiretório dataDump . Este é o diretório onde nossos comandos irão salvar os PLISTs binários extraídos.
O comando a seguir despejará o banco de dados Cache.db , procurará PLISTs binários e salvará cada um em um arquivo em nosso diretório dataDump .
CONTADOR=1; para i em `sqlite3 Cache.db .dump | grep ",X'\|,x'" | egrep -o "X\'[A-z0-9]*'" | awk -F"'" '{print $2}'`; faça eco $i | xxd -r -p > dataDump/$((CONTADOR)).dump.plist; CONTADOR=$((CONTADOR+1)); feitoAgora queremos extrair quaisquer PLISTs incorporados. Usaremos o plistsubtractor para fazer isso. Esta ferramenta incrível de Joshua Wright extrai de um PLIST binário quaisquer PLISTs incorporados encontrados nele e os salva em outro arquivo. Você pode encontrar a ferramenta python2 original aqui , ou uma versão ligeiramente modificada do python3 aqui .
Vá para o diretório dataDump e execute o seguinte comando, atualizando para onde quer que seu script plistsubtractor esteja localizado.
para i em `ls *.dump.plist`; faça python3 plistsubtractor3.py $i; feitoAgora você deseja converter os PLISTs binários em ASCII para revisão. Eu uso plutil no macOS para executar esta tarefa.
Você pode converter um PLIST binário para ASCII usando o comando:
plutil -convert xml1 plist.filePodemos percorrer os arquivos no diretório dataDump procurando por arquivos de lista de propriedades binárias da Apple e convertê-los todos de uma vez:
para plist em `arquivo * | grep 'Lista de propriedades binárias da Apple' | awk -F':' '{print $1}'`; faça plutil -convert xml1 $plist; feitoEm seguida, abra todos os arquivos PLIST em seu editor e comece a procurar tokens de sessão, respostas confidenciais do servidor e credenciais. Você ficará surpreso com a quantidade de informações confidenciais que poderá encontrar. Certifique-se de decodificar todas as strings base64 encontradas nos PLISTs extraídos.
Lembre-se de que há muito mais arquivos no armazenamento local do aplicativo que podem armazenar inadvertidamente dados confidenciais além do arquivo Cache.db . Todos os arquivos devem ser revisados, no entanto, bancos de dados SQLite e arquivos PLIST em particular tendem a ser os candidatos mais prováveis para dados confidenciais.
Cache.db quase sempre contém dados confidenciais, é criado por padrão e também parece ter backup por padrão. Acho essa uma escolha de design estranha da Apple, que poderia facilmente manter o arquivo Cache.db fora dos backups por padrão ou até mesmo criptografar o banco de dados e aproveitar o iOS Keychain para armazenamento seguro de chaves.
Os desenvolvedores que desejam atenuar essa vulnerabilidade podem desabilitar os backups do diretório Caches ou desabilitar completamente o cache. Existem ideias sobre como atenuar esse problema listadas nas referências abaixo.
Se você tiver problemas ou ideias sobre como isso pode ser melhorado, ou melhores métodos de mitigação, meus DMs estão sempre abertos @hoodoer ou no Mastodon em @ hoodoer@infosec.exchange .
- https://developer.android.com/training/articles/keystore (Android Keystore)
- https://developer.apple.com/documentation/security/keychain_services (iOS Keychain)
- https://www.zetetic.net/sqlcipher (SQL Cipher)
- https://macroplant.com/iexplorer (iExplorer)
- https://sqlitebrowser.org (Navegador de banco de dados para SQLite)
- https://github.com/joswr1ght/plistsubtractor (python2 original plistsubtractor)
- https://github.com/hoodoer/plistsubstractor3 (versão Python3 do plistsubstractor)
- https://kunalgupta1508.medium.com/data-leakage-with-cache-db-2d311582cf23 (blog de vazamento de dados)
- https://books.nowsecure.com/secure-mobile-development/en/ios/avoid-caching-https-requests-responses.html (etapas de mitigação)
- https://developer.apple.com/documentation/foundation/optimizing_your_app_s_data_for_icloud_backup (Desativando backups)
Por Drew Kirkpatrick originalmente publicado em TrustedSec
Veja também:
- Momento certo para investir em cibersegurança é agora
- O uso da tecnologia como estratégia na capacitação do profissional da geração Z
- Cuidado com o seu português
- Aplicação da LGPD aos organizadores de eventos
- Setor Farmacêutico e LGPD
- Para onde foram todos os especialistas?
- CISA alerta sobre falha de desvio de ASLR da Samsung explorada em ataques
- BrutePrint força smartphones a ignorar autenticação digital
- Estressado com o trabalho? Seis dicas para os CISOs melhorarem o ambiente profissional
- Requerimentos para implementação de DevSecOps no SDLC
- Sites falsos que se passam pelo ChatGPT representam alto risco
- Sua empresa está preparada para migrar para a nuvem?
Be the first to comment