Links para todas as partes:Parte 1. Acesso Inicial a um Dispositivo Móvel (Acesso Inicial)Parte 2. Persistência e EscaladaParte 3. Obtendo acesso à credencial (acesso à credencial)Parte 4. Evasão de DefesaParte 5. Descoberta e movimento lateralOs métodos para contornar as ferramentas de proteção são usados pelos criminosos cibernéticos para evitar a detecção de suas atividades maliciosas ou em conjunto com outras técnicas de ataque para atingir determinados objetivos táticos como resultado de minar a proteção específica. Assim, a evasão de defesa pode ser considerada como um conjunto de técnicas usadas pelo inimigo em todas as etapas do ataque.
O autor não é responsável pelas possíveis consequências da aplicação das informações contidas no artigo e também se desculpa por possíveis imprecisões feitas em algumas formulações e termos. As informações publicadas são uma recontagem gratuita do conteúdo de ATT @ CK Mobile Matrices: Device Access .Plataforma: Android, iOS
Descrição: os invasores podem tentar identificar todos os aplicativos instalados no dispositivo para identificar a disponibilidade de medidas de segurança que podem aumentar o risco de detecção ou vice-versa - determinar os aplicativos que serão alvo de um novo ataque.
Os aplicativos Android podem usar o método de classe PackageManager para listar outros aplicativos ou outro objeto de linha de comando para usar o comando pm. Os aplicativos para iOS podem usar chamadas de API privadas para obter uma lista dos aplicativos instalados no dispositivo. No entanto, é provável que a distribuição de um aplicativo usando chamadas de API privadas pela AppStore seja impossível.
Recomendações de proteção: Os métodos para verificar aplicativos Android devem incluir meios para detectar o uso da classe PackageManager por aplicativos para listar outros aplicativos com o objetivo de realizar análises adicionais. No entanto, essa abordagem pode ser impraticável porque muitos aplicativos podem chamar os métodos da classe PackageManager como parte de seu trabalho regular. No iOS, os métodos de validação podem procurar chamadas de API privadas da mesma forma, no entanto, é importante observar que um aplicativo que usa chamadas de API privadas provavelmente não será aceito na AppStore.
Plataforma: Android, iOS
Descrição: um adversário pode usar o conhecimento dos algoritmos de segurança para evitar a detecção. Por exemplo, algumas ferramentas de segurança de dispositivos móveis detectam um comprometimento identificando artefatos específicos, como o binário instalado, mas você pode contornar isso nomeando o binário de maneira diferente. Um adversário pode usar um código polimórfico para evitar a detecção por análise de assinatura.
Plataforma: Android, iOS
Descrição: para evitar a detecção de código malicioso durante as verificações em um ambiente corporativo ou loja de aplicativos usando métodos estáticos de análise de código (possivelmente dinâmico), um aplicativo mal-intencionado pode baixar e executar o código dinâmico (não incluído no pacote do aplicativo) após a instalação.
No Android, o código dinâmico pode incluir código nativo, código Dalvik ou código JavaScript que usa a função JavascriptInterface Android WebView. O IOS também possui métodos para executar o código dinâmico carregado após a instalação do aplicativo.
Recomendações de proteção: As tecnologias de verificação de aplicativos (análise estática e dinâmica) podem detectar sinais de que o aplicativo está carregando novo código em tempo de execução (por exemplo, no Android, ele está usando o DexClassLoader, System.load ou WebView JavaScryptInterface, no iOS, o JSPatch ou recursos semelhantes). Infelizmente, esse é apenas um método parcial de mitigação de riscos, porque os aplicativos identificados exigirão verificação adicional devido ao fato de que esses métodos são frequentemente usados por desenvolvedores sem intenção maliciosa e também porque os aplicativos podem usar outros métodos, como ocultar Usando métodos de carregamento de código em tempo de execução.
Plataforma: Android, iOS
Descrição: um adversário pode tentar instalar uma configuração insegura ou maliciosa em um dispositivo móvel usando um email de phishing ou uma mensagem de texto contendo um arquivo de configuração como anexo ou um link da Web para os parâmetros de configuração. Ao definir parâmetros de configuração, o usuário pode ser enganado usando métodos de engenharia social. Por exemplo, ao definir uma configuração, um certificado indesejado de uma autoridade de certificação (CA) pode ser colocado no armazenamento de certificados confiáveis do dispositivo, o que aumentará a suscetibilidade do dispositivo a ataques de pessoas da meia-idade.
No iOS, os perfis de configuração maliciosa podem conter certificados de Autoridade de Certificação (CA) indesejados ou outras configurações inseguras, como o endereço de um proxy ou servidor VPN indesejado para rotear o tráfego do dispositivo através de um sistema invasor ou registrar o dispositivo de destino no MDM (sistema de gerenciamento de dispositivo móvel) inimigo.
Recomendações de proteção: No iOS 10.3 e superior, é adicionada uma etapa adicional que exige que o usuário execute determinadas ações para instalar novos certificados de CA confiáveis. Aplicativos Android compatíveis com Android 7 e superior (API nível 24), por padrão, confiam apenas nos certificados de CA que são entregues com o sistema operacional e não adicionados pelo usuário ou administrador, o que reduz sua suscetibilidade a ataques intermediários.
Em geral, as configurações inseguras ou mal-intencionadas não são definidas sem o consentimento do usuário. Os usuários não devem definir parâmetros de configuração inesperados (certificados de CA, perfis de configuração do iOS, conexões MDM).
No Android, um usuário pode exibir certificados de CA confiáveis por meio das configurações do dispositivo para identificar certificados suspeitos. Da mesma forma, as proteções de dispositivos móveis podem verificar anomalias nos armazenamentos de certificados. No iOS, um usuário pode visualizar os perfis de configuração instalados por meio das configurações do dispositivo e identificar perfis suspeitos. Da mesma forma, os sistemas MDM podem usar a API MDM do iOS para verificar listas de perfis instalados quanto a anomalias.
Plataforma: Android, iOS
Descrição: como uma oportunidade para aumentar privilégios, um adversário pode tentar colocar código malicioso no kernel do sistema operacional ou nos componentes da partição de inicialização, onde o código não pode ser detectado, será salvo após a reinicialização do dispositivo e não poderá ser excluído pelo usuário. Em alguns casos (por exemplo, Samsung Knox), um ataque pode ser detectado, mas levará à transferência do dispositivo para o modo de funcionalidade limitada.
Muitos dispositivos Android oferecem a capacidade de desbloquear o carregador de inicialização para fins de desenvolvimento, mas essa funcionalidade oferece a capacidade de atualizar maliciosamente o kernel ou outro código de partição de inicialização. Se o carregador de inicialização ainda não estiver desbloqueado, ainda existe a possibilidade potencial de usar vulnerabilidades para atualizar o código do kernel.
Recomendações de proteção: em um ambiente corporativo, organize a instalação de atualizações de segurança, a introdução da certificação remota de dispositivos móveis (Android SafetyNet, Samsung KNOX TIMA) e também impeça que dispositivos que não passaram na certificação acessem os recursos corporativos. Verifique o status de bloqueio do carregador de inicialização em dispositivos que oferecem a capacidade de desbloquear o carregador de inicialização (permitindo que qualquer código do SO seja gravado no dispositivo).
A API do Android SafetyNet Attestation pode ser usada para identificar e responder remotamente a dispositivos comprometidos. O Samsung KNOX fornece recursos de certificação remota em dispositivos Samsung Android suportados. Os dispositivos Samsung KNOX incluem um fusível irreversível que funcionará se um kernel não-KNOX for carregado no dispositivo. Quando acionado, os serviços corporativos de contêiner KNOX não estarão disponíveis no dispositivo.
Conforme descrito no Guia de segurança do iOS, os dispositivos iOS não podem inicializar ou permitir a ativação do dispositivo se forem detectadas alterações não autorizadas. Muitos aplicativos corporativos realizam suas próprias verificações para detectar e responder a dispositivos comprometidos. Tais verificações não são um meio confiável, mas podem detectar os principais sinais de comprometimento.
Plataforma: Android, iOS
Descrição: se o adversário aumentar os privilégios, ele poderá usá-los para colocar código malicioso na seção do sistema do dispositivo, onde o código será salvo após a reinicialização do sistema operacional e não será facilmente acessível para remoção pelo usuário. Muitos dispositivos Android permitem desbloquear o gerenciador de inicialização para fins de desenvolvimento. Esse recurso também pode ser usado por um adversário para modificar uma partição do sistema.
Recomendações de proteção: dispositivos Android com suporte a Inicialização verificada realizam verificação criptográfica da integridade da partição do sistema. A API Android SafetyNet pode ser usada para identificar dispositivos comprometidos. O Samsung KNOX também fornece recursos de controle remoto em dispositivos suportados. Os dispositivos IOS não inicializam ou não permitem a ativação de um dispositivo no qual alterações não autorizadas são detectadas.
Plataforma: Android
Descrição: com privilégios apropriados, um invasor pode tentar colocar código malicioso em um tempo de execução confiável (TEE) ou outro tempo de execução isolado semelhante, em que o código não é detectável, será salvo após a reinicialização do dispositivo e não poderá ser excluído pelo usuário. A execução de código no TEE fornecerá ao adversário a capacidade de controlar ou falsificar a operação do dispositivo.
Dicas de segurança: Os dispositivos devem executar verificações de integridade no código executado no TEE no momento da inicialização. O iOS não inicializará se o código executado no Secure Enclave falhar na verificação da assinatura digital.
Plataforma: Android, iOS
Descrição: um desenvolvedor de aplicativo mal-intencionado pode usar métodos de ofuscação ou criptografia de código que é ocultado e descriptografado durante a execução do aplicativo no dispositivo de destino.
Recomendações de proteção: As ferramentas de verificação de aplicativos podem alertar sobre a presença de código ofuscado ou criptografado nos aplicativos. Infelizmente, essas verificações são ineficazes, pois muitos aplicativos usam ofuscação e criptografia para se proteger contra técnicas de modificação, como reembalar o aplicativo. A análise dinâmica, em alguns casos, pode identificar o código ofuscado ou criptografado, detectando-o em tempo de execução em texto não criptografado. Algumas ferramentas de verificação de aplicativos usam a análise de reputação do desenvolvedor e podem avisar sobre aplicativos potencialmente perigosos sem realmente analisar o código.