Segurança Móvel - Vetores de Ataque

Por definição, um Attack Vector é um método ou técnica que um hacker usa para obter acesso a outro dispositivo de computação ou rede, a fim de injetar um "código ruim", muitas vezes chamado payload. Este vetor ajuda os hackers a explorar vulnerabilidades do sistema. Muitos desses vetores de ataque tiram vantagem do elemento humano, pois é o ponto mais fraco deste sistema. A seguir está a representação esquemática do processo dos vetores de ataque, que podem ser vários ao mesmo tempo usados por um hacker.

Alguns dos vetores de ataque móvel são -

Malware
- Vírus e Rootkit
- Modificação de aplicativo
- Modificação do sistema operacional
Exfiltração de dados
- Os dados saem da organização
- Captura de tela
- Cópia para USB e perda de backup
Adulteração de dados
- Modificação por outro aplicativo
- Tentativas de violação não detectadas
- Dispositivos arrombados
Perda de dados
- Perda de dispositivo
- Acesso não autorizado a dispositivo
- Vulnerabilidades de aplicativos

Consequências dos vetores de ataque

Os vetores de ataque são o processo de hacking conforme explicado e é bem-sucedido, seguindo-se o impacto em seus dispositivos móveis.

Losing your data - Se o seu dispositivo móvel foi hackeado ou um vírus introduzido, todos os seus dados armazenados são perdidos e levados pelo invasor.
Bad use of your mobile resources- O que significa que sua rede ou dispositivo móvel pode ficar sobrecarregado e você não pode acessar seus serviços originais. Em cenários piores, para ser usado pelo hacker para conectar outra máquina ou rede.
Reputation loss- No caso de sua conta do Facebook ou conta de email comercial ser hackeada, o hacker pode enviar mensagens falsas para seus amigos, parceiros de negócios e outros contatos. Isso pode prejudicar sua reputação.
Identity theft - Pode haver caso de roubo de identidade como foto, nome, endereço, cartão de crédito, etc. e o mesmo pode ser utilizado para crime.

Anatomia de um ataque móvel

A seguir está uma representação esquemática da anatomia de um ataque móvel. Começa com a fase de infecção, que inclui vetores de ataque.

Infectando o dispositivo

A infecção do dispositivo com spyware móvel é realizada de forma diferente para dispositivos Android e iOS.

Android- Os usuários são enganados para baixar um aplicativo do mercado ou de um aplicativo de terceiros, geralmente usando um ataque de engenharia social. A infecção remota também pode ser realizada por meio de um ataque Man-in-the-Middle (MitM), em que um adversário ativo intercepta as comunicações móveis do usuário para injetar o malware.

iOS- A infecção iOS requer acesso físico ao celular. A infecção do dispositivo também pode ocorrer através da exploração de um dia zero, como o exploit JailbreakME.

Instalando um backdoor

A instalação de um backdoor requer privilégios de administrador, fazendo o root em dispositivos Android e desbloqueando dispositivos Apple. Apesar dos fabricantes de dispositivos colocarem mecanismos de detecção de root / desbloqueio, o spyware móvel os contorna facilmente -

Android - Os mecanismos de detecção de root não se aplicam ao root intencional.

iOS - A “comunidade” jailbreaking é vociferante e motivada.

Ignorando mecanismos de criptografia e exfiltrando informações

O spyware envia conteúdo móvel, como e-mails e mensagens criptografadas para os servidores do invasor em texto simples. O spyware não ataca diretamente o contêiner seguro. Ele pega os dados no ponto em que o usuário puxa os dados do contêiner seguro para lê-los. Nesse estágio, quando o conteúdo é descriptografado para uso do usuário, o spyware assume o controle do conteúdo e o envia.

Como um hacker pode lucrar com um celular comprometido com sucesso?

Na maioria dos casos, a maioria de nós pensa no que podemos perder caso nosso celular seja hackeado. A resposta é simples - perderemos nossa privacidade. Nosso dispositivo se tornará um sistema de vigilância para o hacker nos observar. Outras atividades lucrativas para o hacker é pegar nossos dados confidenciais, fazer pagamentos, realizar atividades ilegais comoDDoS attacks. A seguir está uma representação esquemática.

OWASP Mobile 10 principais riscos

Ao falar sobre segurança móvel, baseamos os tipos de vulnerabilidade no OWASP, que é uma organização de caridade sem fins lucrativos nos Estados Unidos, estabelecida em 21 de abril. OWASP é uma organização internacional e a Fundação OWASP apóia os esforços do OWASP em todo o mundo.

Para dispositivos móveis, OWASP tem 10 vulnerability classifications.

M1-Uso impróprio da plataforma

Esta categoria cobre o uso indevido de um recurso da plataforma ou a falha no uso dos controles de segurança da plataforma. Pode incluir intenções do Android, permissões de plataforma, uso indevido de TouchID, o Keychain ou algum outro controle de segurança que faça parte do sistema operacional móvel. Existem várias maneiras pelas quais os aplicativos móveis podem enfrentar esse risco.

M2-Dados Inseguros

Esta nova categoria é uma combinação de M2 e M4 do Mobile Top Ten 2014. Isso cobre armazenamento de dados inseguros e vazamento de dados não intencional.

M3-Comunicação Insegura

Isso cobre comunicação de baixa qualidade, versões incorretas de SSL, negociação fraca, comunicação de texto claro de ativos confidenciais, etc.

Autenticação M4-Insegura

Esta categoria captura as noções de autenticação do usuário final ou gerenciamento de sessão ruim. Isso inclui -

Deixar de identificar o usuário quando isso deveria ser necessário
Falha em manter a identidade do usuário quando necessário
Fraquezas no gerenciamento de sessão

M5-Insuficient Cryptography

O código aplica criptografia a um ativo de informações confidenciais. No entanto, a criptografia é insuficiente de alguma forma. Observe que tudo e qualquer coisa relacionada a TLS ou SSL vai no M3. Além disso, se o aplicativo deixar de usar criptografia quando deveria, isso provavelmente pertence ao M2. Esta categoria é para problemas em que a criptografia foi tentada, mas não foi feita corretamente.

M6-Autorização Insegura

Esta é uma categoria para capturar quaisquer falhas na autorização (por exemplo, decisões de autorização no lado do cliente, navegação forçada, etc.) É diferente de problemas de autenticação (por exemplo, inscrição de dispositivo, identificação do usuário, etc.)

Se o aplicativo não autentica os usuários em uma situação em que deveria (por exemplo, conceder acesso anônimo a algum recurso ou serviço quando o acesso autenticado e autorizado é necessário), isso é uma falha de autenticação, não uma falha de autorização.

Qualidade do código M7-Client

Tratava-se das "Decisões de segurança por meio de entradas não confiáveis", uma de nossas categorias menos utilizadas. Essa seria a solução geral para problemas de implementação em nível de código no cliente móvel. Isso é diferente dos erros de codificação do lado do servidor. Isso capturaria coisas como estouros de buffer, vulnerabilidades de string de formato e vários outros erros de nível de código em que a solução é reescrever algum código que está sendo executado no dispositivo móvel.

Adulteração de código M8

Esta categoria cobre patching binário, modificação de recurso local, hooking de método, swizzling de método e modificação de memória dinâmica.

Depois que o aplicativo é entregue ao dispositivo móvel, o código e os recursos de dados residem nele. Um invasor pode modificar diretamente o código, alterar o conteúdo da memória dinamicamente, alterar ou substituir as APIs do sistema que o aplicativo usa ou modificar os dados e recursos do aplicativo. Isso pode fornecer ao invasor um método direto de subverter o uso pretendido do software para ganho pessoal ou monetário.

M9-Engenharia Reversa

Esta categoria inclui a análise do binário principal final para determinar seu código-fonte, bibliotecas, algoritmos e outros ativos. Softwares como IDA Pro, Hopper, otool e outras ferramentas de inspeção binárias fornecem ao invasor uma visão do funcionamento interno do aplicativo. Isso pode ser usado para explorar outras vulnerabilidades nascentes no aplicativo, bem como revelar informações sobre servidores back-end, constantes criptográficas e cifras e propriedade intelectual.

M10-Funcionalidade estranha

Freqüentemente, os desenvolvedores incluem funcionalidades ocultas de backdoor ou outros controles internos de segurança de desenvolvimento que não devem ser lançados em um ambiente de produção. Por exemplo, um desenvolvedor pode incluir acidentalmente uma senha como um comentário em um aplicativo híbrido. Outro exemplo inclui a desativação da autenticação de dois fatores durante o teste.