Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-28 07:31:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/ios-pentesting/ios-basics.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

15 KiB
Raw Blame History

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Separação de privilégios e sandbox

Os aplicativos aos quais o usuário pode acessar são executados como usuário mobile, enquanto os processos críticos do sistema são executados como root.
No entanto, o sandbox permite um melhor controle sobre as ações que os processos e aplicativos podem executar.

Por exemplo, mesmo que dois processos sejam executados como o mesmo usuário (mobile), eles não têm permissão para acessar ou modificar os dados um do outro.

Cada aplicativo é instalado em private/var/mobile/Applications/{ID aleatório}
Uma vez instalados, os aplicativos têm acesso limitado de leitura a algumas áreas e funções do sistema (SMS, chamada telefônica...). Se um aplicativo quiser acessar uma área protegida, aparecerá uma janela pop-up solicitando permissão.

Proteção de dados

Os desenvolvedores de aplicativos podem aproveitar as APIs de Proteção de Dados do iOS para implementar controle de acesso refinado para os dados do usuário armazenados na memória flash. As APIs são construídas em cima do Processador de Enclave Seguro (SEP). O SEP é um coprocessador que fornece operações criptográficas para proteção de dados e gerenciamento de chaves. Uma chave de hardware específica do dispositivo - o UID do dispositivo (ID exclusivo) - é incorporada no enclave seguro, garantindo a integridade da proteção de dados mesmo quando o kernel do sistema operacional é comprometido.

Quando um arquivo é criado no disco, uma nova chave AES de 256 bits é gerada com a ajuda do gerador de números aleatórios baseado em hardware do enclave seguro. O conteúdo do arquivo é então criptografado com a chave gerada. E então, esta chave é salva criptografada com uma chave de classe juntamente com o ID da classe, com ambos os dados criptografados pela chave do sistema, dentro dos metadados do arquivo.

Para descriptografar o arquivo, os metadados são descriptografados usando a chave do sistema. Em seguida, usando o ID da classe, a chave da classe é recuperada para descriptografar a chave por arquivo e descriptografar o arquivo.

Os arquivos podem ser atribuídos a uma das quatro classes de proteção diferentes, que são explicadas com mais detalhes no Guia de Segurança da Plataforma Apple:

  • Proteção Completa (NSFileProtectionComplete): Uma chave derivada do código de acesso do usuário e do UID do dispositivo protege esta chave de classe. A chave derivada é apagada da memória pouco depois que o dispositivo é bloqueado, tornando os dados inacessíveis até que o usuário desbloqueie o dispositivo.
  • Protegido a menos que aberto (NSFileProtectionCompleteUnlessOpen): Esta classe de proteção é semelhante à Proteção Completa, mas, se o arquivo for aberto quando desbloqueado, o aplicativo pode continuar a acessar o arquivo mesmo se o usuário bloquear o dispositivo
let userDefaults = UserDefaults.standard

if userDefaults.bool(forKey: "hasRunBefore") == false {
    // Remove Keychain items here

    // Update the flag indicator
    userDefaults.set(true, forKey: "hasRunBefore")
    userDefaults.synchronize() // Forces the app to update UserDefaults
}
  • Ao desenvolver a funcionalidade de logout para um aplicativo iOS, certifique-se de que os dados do Keychain sejam apagados como parte do logout da conta. Isso permitirá que os usuários limpem suas contas antes de desinstalar um aplicativo.

Capacidades do aplicativo

Cada aplicativo tem um diretório inicial exclusivo e é isolado, de modo que não pode acessar recursos do sistema protegidos ou arquivos armazenados pelo sistema ou por outros aplicativos. Essas restrições são implementadas por meio de políticas de sandbox (também conhecidas como perfis), que são aplicadas pelo Trusted BSD (MAC) Mandatory Access Control Framework por meio de uma extensão do kernel.

Algumas capacidades/ permissões podem ser configuradas pelos desenvolvedores do aplicativo (por exemplo, Proteção de Dados ou Compartilhamento de Keychain) e terão efeito direto após a instalação. No entanto, para outras, o usuário será explicitamente solicitado na primeira vez que o aplicativo tentar acessar um recurso protegido.

As strings de propósito ou strings de descrição de uso são textos personalizados que são oferecidos aos usuários no alerta de solicitação de permissão do sistema ao solicitar permissão para acessar dados ou recursos protegidos.

Se tiver o código-fonte original, você pode verificar as permissões incluídas no arquivo Info.plist:

  • Abra o projeto com o Xcode.
  • Encontre e abra o arquivo Info.plist no editor padrão e procure as chaves que começam com "Privacy -".

Você pode alternar a exibição para exibir os valores brutos clicando com o botão direito e selecionando "Mostrar chaves/valores brutos" (desta forma, por exemplo, "Privacy - Location When In Use Usage Description" se transformará em NSLocationWhenInUseUsageDescription).

Se tiver apenas o IPA:

  • Descompacte o IPA.

  • O arquivo Info.plist está localizado em Payload/<nome_do_aplicativo>.app/Info.plist.

  • Converta-o, se necessário (por exemplo, plutil -convert xml1 Info.plist) conforme explicado no capítulo "Teste de segurança básico do iOS", seção "O arquivo Info.plist".

  • Inspeccione todas as chaves strings de propósito Info.plist, geralmente terminando com UsageDescription:

      <plist version="1.0">
  <dict>
      <key>NSLocationWhenInUseUsageDescription</key>
      <string>Sua localização é usada para fornecer instruções de navegação para o seu destino.</string>

Capacidades do dispositivo

As capacidades do dispositivo são usadas pela App Store para garantir que apenas dispositivos compatíveis sejam listados e, portanto, possam baixar o aplicativo. Elas são especificadas no arquivo Info.plist do aplicativo sob a chave UIRequiredDeviceCapabilities.

<key>UIRequiredDeviceCapabilities</key>
<array>
    <string>armv7</string>
</array>

Normalmente, você encontrará a capacidade armv7, o que significa que o aplicativo é compilado apenas para o conjunto de instruções armv7, ou se for um aplicativo universal de 32/64 bits.

Por exemplo, um aplicativo pode depender completamente do NFC para funcionar (por exemplo, um aplicativo "Leitor de Tag NFC"). De acordo com a Referência de Compatibilidade de Dispositivos iOS arquivada, o NFC só está disponível a partir do iPhone 7 (e iOS 11). Um desenvolvedor pode querer excluir todos os dispositivos incompatíveis definindo a capacidade do dispositivo nfc.

Direitos

Os direitos são pares de chave-valor que são assinados em um aplicativo e permitem autenticação além de fatores de tempo de execução, como o ID de usuário UNIX. Como os direitos são assinados digitalmente, eles não podem ser alterados. Os direitos são usados extensivamente por aplicativos e daemons do sistema para realizar operações privilegiadas específicas que, de outra forma, exigiriam que o processo fosse executado como root. Isso reduz enormemente o potencial de escalonamento de privilégios por um aplicativo ou daemon do sistema comprometido.

Por exemplo, se você deseja definir a capacidade "Proteção de Dados Padrão", precisará ir para a guia Capacidades no Xcode e habilitar Proteção de Dados. Isso é escrito diretamente pelo Xcode no arquivo <nomedoaplicativo>.entitlements como o direito com.apple.developer.default-data-protection com o valor padrão NSFileProtectionComplete. No IPA, podemos encontrar isso em embedded.mobileprovision como:

<key>Entitlements</key>
<dict>
    ...
    <key>com.apple.developer.default-data-protection</key>
    <string>NSFileProtectionComplete</string>
</dict>

Para outras capacidades, como HealthKit, o usuário deve ser solicitado a permissão, portanto, não é suficiente adicionar as permissões, chaves especiais e strings devem ser adicionadas ao arquivo Info.plist do aplicativo.

Conceitos Básicos de Objective-C e Swift

O Objective-C possui um tempo de execução dinâmico, portanto, quando um programa Objective-C é executado no iOS, ele chama bibliotecas cujos endereços são resolvidos em tempo de execução comparando o nome da função enviada na mensagem com uma lista de todos os nomes de função disponíveis.

No início, apenas os aplicativos criados pela Apple eram executados nos iPhones, então eles tinham acesso a tudo porque eram confiáveis. No entanto, quando a Apple permitiu aplicativos de terceiros, a Apple simplesmente removeu os arquivos de cabeçalho das funções poderosas para "escondê-las" dos desenvolvedores. No entanto, os desenvolvedores descobriram que as funções "seguras" precisavam de algumas dessas funções não documentadas e, criando um arquivo de cabeçalho personalizado com os nomes das funções não documentadas, era possível invocar essas funções ocultas poderosas. Na verdade, a Apple, antes de permitir que um aplicativo seja publicado, verifica se o aplicativo chama alguma dessas funções proibidas.

Então, surgiu o Swift. Como o Swift é vinculado estaticamente (não resolve o endereço das funções em tempo de execução como o Objective-C), é possível verificar mais facilmente as chamadas que um programa Swift fará por meio da análise de código estático.

Gerenciamento de Dispositivos

A partir da versão 6 do iOS, há suporte integrado para gerenciamento de dispositivos com controles de granularidade fina que permitem que uma organização controle os dispositivos Apple corporativos.
A inscrição pode ser iniciada pelo usuário instalando um agente para acessar os aplicativos corporativos. Nesse caso, o dispositivo geralmente pertence ao usuário.
Ou a empresa pode indicar os números de série dos dispositivos comprados ou o ID do pedido de compra e especificar o perfil MDM a ser instalado nesses dispositivos. Observe que a Apple não permite inscrever um dispositivo específico dessa maneira duas vezes. Depois que o primeiro perfil é excluído, o usuário precisa dar consentimento para instalar outro.

O usuário pode ver as políticas instaladas em Configurações --> Geral --> Perfil e Gerenciamento de Dispositivos

Como essas políticas MDM estão verificando e limitando outras aplicações, elas estão executando com mais privilégios.
Uma política MDM pode forçar usuários a ter um código de acesso definido com uma complexidade de senha mínima.
Os perfis estão vinculados ao ID do dispositivo, assinados e criptografados pelo servidor MDM e à prova de violação. Eles não podem ser removidos sem perder todos os dados corporativos.
Os perfis MDM permitem apagar todos os dados se houver X tentativas de senha falhadas. Além disso, o administrador pode apagar o iPhone remotamente sempre que quiser via interface MDM.

Os agentes MDM também verificarão possíveis jailbreaks do dispositivo, pois esse é um estado muito perigoso para um iPhone.

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥