Entendendo os 10 principais riscos do OWASP Mobile com casos do mundo real

Possuir um histórico de desenvolvimento de aplicativos 100% à prova de hacks vem com uma responsabilidade e uma garantia básica de que nenhuma das soluções digitais desenvolvidas sob nosso nome enfrentaria violação de segurança.

Como forma de conseguir isso, a equipe de Garantia de Qualidade da Appinventiv está familiarizada com todos os possíveis riscos de segurança que um aplicativo pode enfrentar. Conhecer os riscos facilita ignorar armadilhas e escrever aplicativos seguros.

Ajudar-nos a estar no topo do jogo quando se trata de garantir a segurança é ter um conhecimento completo das práticas de codificação segura OWASP (Open Web Application Security Project). É uma comunidade online de especialistas em segurança que desenvolveram documentação gratuita, materiais de aprendizagem e ferramentas para construir aplicativos móveis e web seguros.

Além de outras coisas, eles também compilaram uma lista das 10 principais ameaças de segurança do OWASP Mobile em aplicativos móveis.

Embora o documento de práticas de segurança do OWASP seja bastante claro, às vezes pode ser difícil para as empresas conectá-lo a partir de casos do mundo real.

Neste artigo, forneceremos uma visão geral básica dos 10 principais riscos de segurança móvel e daremos exemplos das vulnerabilidades divulgadas no mundo real para cada um deles. Ele lhe dará uma visão sobre o que nos preparamos na Appinventiv quando trabalhamos em sua inscrição.

Antes de olhar para os riscos, vamos olhar para as estatísticas.

A NowSecure analisou os aplicativos na Google Play Store e a App Store identificou que mais de 85% dos aplicativos violam um dos riscos.

Desses aplicativos, 50% tiveram armazenamento de dados inseguro e, em algum lugar, o mesmo número de aplicativos estava trabalhando com risco de comunicação insegura . Aqui está um gráfico que mostra a porcentagem de ocorrência dos 10 principais riscos do OWASP Mobile

Lista das 10 ameaças mais comuns aos aplicativos móveis e as melhores práticas para evitá-las

M1: uso inadequado da plataforma

A categoria de teste de segurança OWASP consiste no uso indevido de uma funcionalidade do dispositivo ou na ocorrência de falha ao utilizar os controles de segurança da plataforma. Pode incluir permissões de plataforma, intenções do Android, uso indevido do TouchID, Keychain, etc.

Caso do mundo real:

Três aplicativos iOS : “Aplicativo Fitness Balance”, “Heart Rate Monitor” e “Aplicativo Calories Tracker” vieram à tona por ignorar o Touch ID da Apple. Eles estavam pedindo aos usuários que usassem sua impressão digital para obter informações de condicionamento físico, enquanto a usavam para cobrar dinheiro da App Store.

Melhor prática a evitar:

• O desenvolvedor não deve permitir criptografias do Keychain por meio da rota do servidor e manter as chaves em apenas um dispositivo, para que seja impossível ser explorado em outros servidores ou dispositivos.
• O desenvolvedor deve proteger o aplicativo por meio do Keychain para armazenar o segredo do aplicativo que possui uma lista de controle de acesso dedicada.
• O desenvolvedor deve obter permissão para limitar quais aplicativos têm permissão para se comunicar com seu aplicativo.
• O desenvolvedor deve controlar o primeiro da lista OWASP Mobile Top 10, definindo as intenções explícitas e, assim, bloqueando todos os outros componentes para acessar as informações presentes na intenção.

M2: armazenamento de dados inseguro

OWASP considera uma ameaça quando alguém obtém acesso a um dispositivo móvel perdido/roubado ou quando um malware ou outro aplicativo reempacotado começa a agir em nome do adversário e executa a ação no dispositivo móvel.

Uma vulnerabilidade de armazenamento de dados inseguro geralmente leva a estes riscos:

• Fraude
• Roubo de identidade
• Perda de Materiais.
• Danos à reputação
• Violação de política externa (PCI)

Caso do mundo real :

Aplicativos de namoro como Tinder, OKCupid e Bumble foram repetidamente examinados por suas práticas inseguras de armazenamento de dados. As falhas de segurança presentes nesses aplicativos variam de acordo com a viabilidade e gravidade e viabilidade, podem expor o nome dos usuários, detalhes de login, histórico de mensagens e até localização, além de outras atividades da conta pessoal.

Práticas recomendadas para evitar:

• Para iOS, as práticas de segurança da OWASP recomendam o uso de aplicativos vulneráveis ​​criados propositalmente, como o iGoat, para modelar ameaças à estrutura e aos aplicativos de desenvolvimento. Isso ajudará os desenvolvedores de aplicativos ios a entender como as APIs lidam com os processos do aplicativo e os ativos de informações.
• Os desenvolvedores de aplicativos Android podem usar o shell do Android Debug Bridge para verificar as permissões de arquivo do aplicativo de destino e do DBMS para verificar a criptografia do banco de dados. Eles também devem usar a ferramenta de análise de memória e o Android Device Monitor para garantir que a memória do dispositivo não tenha dados indesejados.

M3: Comunicação Insegura

Ao conceber um aplicativo móvel, os dados são trocados no modelo cliente-servidor. Assim, quando os dados são transmitidos, eles devem primeiro percorrer a rede da operadora do dispositivo e a internet. Os agentes de ameaças podem explorar vulnerabilidades e interceptar dados confidenciais enquanto viajam pela rede. Aqui estão os diferentes agentes de ameaças que existem:

• Adversário que compartilha sua rede local – um Wi-Fi comprometido
• Dispositivos de rede ou operadora – torres de celular, proxy, roteadores, etc.
• Malware no dispositivo móvel.

A interceptação de dados sensíveis via canal de comunicação resultaria em violação de privacidade, o que pode levar a:

• Roubo de identidade
• Fraude
• Dano reputacional.

Caso do mundo real:

A empresa de segurança Rapid7 divulgou várias vulnerabilidades associadas a smartwatches infantis. Esses relógios foram comercializados como os usados ​​pelos pais para rastrear seus filhos e enviar mensagens ou fazer chamadas em seu smartwatch.

Os relógios deveriam ser contatados por números de contato aprovados por meio de uma lista branca, mas a empresa descobriu que os filtros nem estavam funcionando. Os relógios até aceitavam comandos de configuração via mensagens de texto. Isso significava que um hacker poderia alterar as configurações do relógio e colocar as crianças em risco.

“Você pode identificar onde está o telefone ou a criança, pode obter acesso ao áudio ou fazer chamadas telefônicas para crianças”, disse Deral Heiland, líder de pesquisa de IoT da Rapid7.

Práticas recomendadas para evitar:

• Os desenvolvedores não devem apenas procurar vazamentos no tráfego comunicado entre o aplicativo e o servidor, mas também o dispositivo que contém o aplicativo e outro dispositivo ou rede local.

• A aplicação de TLS/SSL para o transporte de canais também é uma das melhores práticas de segurança de aplicativos móveis a serem consideradas quando se trata de transmitir informações confidenciais e outros dados confidenciais.

• Use certificados fornecidos por verificações de cadeia SSL confiáveis.
• Não envie dados confidenciais por canais alternativos, como MMS, SMS ou notificações push.
• Aplique uma camada de criptografia separada a dados confidenciais antes de fornecer ao canal SSL.

M4: Autenticação insegura

Os agentes de ameaças que exploram vulnerabilidades de autenticação o fazem por meio de ataques automatizados que usam ferramentas personalizadas ou disponíveis.

O impacto comercial do M4 pode ser:

• Roubo de informações
• Danos à reputação
• Acesso não autorizado a dados.

Caso do mundo real :

Em 2019, um banco dos EUA foi invadido por um invasor cibernético que aproveitou a falha do site do banco e contornou a autenticação de dois fatores que foi implementada para proteger as contas.

O invasor fez login no sistema por meio de credenciais roubadas da vítima e, ao chegar à página em que o PIN ou a resposta de segurança precisava ser inserido, o invasor usou uma string manipulada na URL da Web, que definiu o computador como reconhecido. Isso permitiu que ele cruzasse o palco e iniciasse as transferências eletrônicas.

Práticas recomendadas para evitar:

• A equipe de segurança do aplicativo deve estudar a autenticação do aplicativo e testá-la por meio de ataques binários no modo offline para determinar se ela pode ser explorada.
• Os protocolos de segurança de teste de aplicativos da Web OWASP devem corresponder aos de aplicativos móveis.
• Use métodos de autenticação online tanto quanto possível, assim como no caso do navegador da web.
• Não habilite o carregamento de dados do aplicativo até que o servidor tenha autenticado as sessões do usuário.
• Os locais onde os dados locais são eventuais, garantem que sejam criptografados por meio de chave criptografada derivada das credenciais de login dos usuários.
• A solicitação de autenticação persistente também deve ser armazenada no servidor.
• A equipe de segurança deve ter cuidado com os tokens de autorização centrados no dispositivo no aplicativo, pois se o dispositivo for roubado, o aplicativo poderá ficar vulnerável.
• Como o acesso físico não autorizado de dispositivos é comum, a equipe de segurança deve impor a autenticação regular de credenciais de usuário do lado do servidor.

M5: Riscos de Criptografia Insuficientes

Os agentes de ameaças neste caso são aqueles que têm acesso físico aos dados que foram criptografados incorretamente. Ou onde um malware está agindo em nome do adversário.

A criptografia quebrada geralmente resulta nestes casos:

• Roubo de informações
• Roubo de propriedade intelectual
• Roubo de código
• Violações de privacidade
• Dano reputacional.

Caso do mundo real :

Às vezes, um alerta da equipe de resposta a emergências cibernéticas da DHS Industrial Control Systems e o aviso da Philips alertavam os usuários sobre uma possível vulnerabilidade no aplicativo Philips HealthSuite Health para Android .

O problema que foi rastreado até a força de criptografia inadequada abriu o aplicativo para hackers que poderiam ter acesso à atividade da frequência cardíaca, pressão arterial, estado de sono, análise de peso e composição corporal dos usuários, etc.

Práticas recomendadas para evitar:

• Para resolver esse um dos 10 principais riscos móveis mais comuns do OWASP , os desenvolvedores devem escolher algoritmos de criptografia modernos para criptografar seus aplicativos. A escolha do algoritmo cuida da vulnerabilidade em grande medida.
• Se o desenvolvedor não for especialista em segurança, ele deve abster-se de criar códigos de criptografia próprios.

M6: Riscos de autorização insegura

Nesse caso, os agentes de ameaças podem acessar o aplicativo de outra pessoa normalmente por meio de ataques automatizados que usam ferramentas personalizadas ou disponíveis.

Pode levar aos seguintes problemas:

• Roubo de informações
• Danos à reputação
• Fraude

Caso do mundo real :

Os especialistas em segurança da informação da Pen Test Partners hackearam o Pandora , um sistema de alarme de carro inteligente. Em teoria, o aplicativo é usado para rastrear um carro, desligar o motor em caso de roubo e trancá-lo até a chegada da polícia.

Do outro lado da moeda, um hacker pode sequestrar a conta e obter acesso a todos os dados e às funcionalidades de alarme inteligente. Além disso, eles poderiam:

• Acompanhe os movimentos do veículo
• Ativar e desativar o sistema de alarme
• Tranque e destrave as portas do carro
• Corte o motor
• No caso do Pandora, os hackers tiveram acesso a tudo o que foi falado dentro do carro pelo microfone do sistema antifurto.

Práticas recomendadas para evitar:

• A equipe de controle de qualidade deve testar regularmente os privilégios do usuário executando tokens de sessão com poucos privilégios para os comandos confidenciais.
• O desenvolvedor deve observar que os esquemas de autorização do usuário dão errado no modo offline.
• A melhor maneira de evitar esse risco é executar verificações de autorização para permissões e funções de um usuário autenticado no servidor, em vez do dispositivo móvel.

M7: Riscos de má qualidade do código

Nesses casos, entradas não confiáveis ​​são passadas por entidades para chamadas de método feitas no código móvel. Um efeito disso pode ser problemas técnicos que podem levar à degradação do desempenho, uso pesado de memória e arquitetura de front-end de trabalho ruim.

Caso do mundo real :

O WhatsApp corrigiu no ano passado uma vulnerabilidade que os hackers estavam aproveitando para instalar um malware de vigilância chamado Pegasus Spyware em smartphones. Tudo o que eles precisavam fazer era fazer uma chamada de áudio do WhatsApp nos números de telefone visados.

Em poucos passos simples, os hackers conseguiram entrar nos dispositivos dos usuários e acessá-los remotamente.

Práticas recomendadas para evitar:

• De acordo com as práticas de codificação segura do OWASP , o código deve ser reescrito no dispositivo móvel em vez de corrigi-lo no lado do servidor. Os desenvolvedores devem observar que a codificação ruim no lado do servidor é muito diferente da codificação ruim no nível do cliente. Ou seja, os controles fracos do lado do servidor e os controles do lado do cliente devem receber atenção separada.
• O desenvolvedor deve usar ferramentas de terceiros para análise estática para identificar estouros de buffer e vazamentos de memória.
• A equipe deve criar uma lista de bibliotecas de terceiros e verificar periodicamente as versões mais recentes.
• Os desenvolvedores devem ver todas as entradas do cliente como não confiáveis ​​e validá-las, independentemente de serem provenientes de usuários ou do aplicativo.

M8: Riscos de adulteração de código

Normalmente, nesse caso, um invasor explora a modificação de código por meio de formas maliciosas dos aplicativos hospedados nas lojas de aplicativos de terceiros. Eles também podem induzir os usuários a instalar um aplicativo por meio de ataques de phishing.

Práticas recomendadas para evitar:

• Os desenvolvedores devem certificar-se de que o aplicativo seja capaz de detectar alterações de código em tempo de execução.
• O arquivo build.prop deve ser verificado quanto à presença de ROM não oficial no Android e para descobrir se o dispositivo está enraizado.
• O desenvolvedor deve usar somas de verificação e avaliar as assinaturas digitais para ver se houve adulteração de arquivos.
• O codificador pode garantir que as chaves, o código e os dados do aplicativo sejam removidos assim que a violação for encontrada.

M9: Risco de Engenharia Reversa

Um invasor normalmente baixa o aplicativo de destino da loja de aplicativos e o analisa dentro de seu ambiente local com um conjunto de ferramentas diferentes. Depois disso, eles podem alterar o código e tornar a função do aplicativo diferente.

Caso do mundo real :

O Pokémon Go enfrentou recentemente os olhares de violação de segurança quando foi descoberto que os usuários fizeram engenharia reversa do aplicativo para conhecer a vizinhança dos Pokémons e pegá-los em minutos.

Práticas recomendadas para evitar:

• A melhor maneira de proteger um aplicativo contra o risco, de acordo com a segurança móvel da OWASP , é usar as mesmas ferramentas que os hackers usariam para engenharia reversa.
• O desenvolvedor também deve ofuscar o código-fonte para que fique difícil de ler e, em seguida, fazer engenharia reversa.

M10: Risco de Funcionalidade Estranha

Normalmente, um hacker analisa as funcionalidades estranhas dentro de um aplicativo móvel para descobrir as funcionalidades ocultas nos sistemas de back-end. O invasor exploraria funcionalidades estranhas de seus próprios sistemas sem qualquer envolvimento dos usuários finais.

Caso do mundo real :

A ideia do aplicativo Wifi File Transfer era abrir a porta no Android e permitir conexões do computador. O problema ? Uma ausência de autenticação, como senhas, ou seja, qualquer pessoa pode se conectar a um dispositivo e obter acesso total.

Práticas recomendadas para evitar:

• Certifique-se de que não haja código de teste na compilação final
• Certifique-se de que não haja nenhum switch oculto nas definições de configuração
• Os logs não devem conter nenhuma descrição do processo do servidor de back-end
• Certifique-se de que os logs completos do sistema não sejam expostos a aplicativos pelos OEMs
• Os endpoints da API devem ser bem documentados.