StrandHogg 2.0 é uma nova vulnerabilidade perigosa do Android. Veja como isso pode afetar os usuários e como os desenvolvedores podem proteger seus aplicativos contra isso.
São 22h. Você sabe onde estão suas atividades? Há uma nova vulnerabilidade que pode ser explorada em milhões de dispositivos Android, e também é bastante desagradável. Resumindo, essa falha de design permite que um invasor apresente sua própria atividade (página) sobre a de outro aplicativo, potencialmente confundindo o usuário e levando-o a fornecer seus dados privados. A vulnerabilidade foi apelidada de StrandHogg 2.0 e foi recentemente divulgada por Promon, uma empresa de segurança norueguesa.
A vulnerabilidade StrandHogg 2.0 afeta teoricamente todos os dispositivos Android que executam versões do Android tão antigas quanto Honeycomb (3.0) e até Android 9 Pie (9.0). Com base no estatísticas de distribuição da versão mais recente do Android, isso significa que aproximadamente 91,8% de todos os dispositivos Android são vulneráveis ao StrandHogg 2.0
. A vulnerabilidade foi atribuída CVE-2020-0096 e foi dado um nível de gravidade de "crítico". Não requer nenhuma permissão especial para funcionar e pode funcionar quase inteiramente sem interação do usuário. Tudo o que o usuário precisa fazer é abrir um aplicativo com código malicioso oculto e então ele estará vulnerável à exploração.A Promon teve a gentileza de nos enviar seu aplicativo de prova de conceito e seu código-fonte para que pudéssemos melhor explicar como funciona a exploração, por que ela é importante para os usuários e como os desenvolvedores podem proteger seus aplicativos contra isso.
Como funciona
Digamos que você esteja usando o Gmail e clique em um link da web. Se você acessar a tela de aplicativos recentes, poderá notar que a página da web parece estar “dentro” do Gmail. A visualização mostra o site, mas o ícone e o nome do aplicativo ainda são do Gmail. Isso é algo que acontece quando um aplicativo/atividade inicia outro aplicativo/atividade na mesma tarefa. Agora imagine que você não abriu esse link propositalmente. Para você, parece que é apenas parte do aplicativo Gmail. Este é o comportamento que o StrandHogg 2.0 explora.
Teremos que deixar alguns detalhes de fora aqui, mas aqui está mais ou menos como essa exploração funciona. A seguir, vamos supor que o invasor queira obter o login do usuário no Gmail.
- O usuário baixa um aplicativo malicioso (é claro, sem saber que é malicioso) e o abre.
- Em segundo plano, o aplicativo abre o Gmail, coloca uma atividade de login semelhante em cima dele e, em seguida, inicia outra atividade.
- O usuário abre o Gmail e vê o que parece ser a tela de login do Gmail, mas na verdade é a atividade de phishing do invasor.
A Atividade final lançada no passo 2 pode ser qualquer coisa que evite suspeitas. O aplicativo pode fingir uma falha e voltar para a tela inicial ou simplesmente abrir sua atividade principal como se nada tivesse acontecido. A única coisa suspeita que o usuário pode ver é um monte de animações de abertura quando todas as atividades são iniciadas. A pior parte: nem vai parecer que o Gmail foi aberto.
É claro que um invasor pode fazer mais do que apenas mostrar uma tela de login falsa. Em vez disso, um aplicativo malicioso pode apresentar um prompt de permissões, induzindo o usuário a conceder permissões indesejadas. Embora solicitar permissões especiais, como acessibilidade, possa deixar o usuário desconfiado, é possível causar muitos danos com algo como acesso ao armazenamento.
As partes técnicas
A próxima seção é uma visão geral de alto nível de como o StrandHogg 2.0 funciona. A Promon não divulgará todos os detalhes nos próximos meses, portanto não podemos compartilhar exatamente como essa exploração é implementada. Existem alguns detalhes técnicos sobre os quais podemos conversar.
Resumindo, StrandHogg 2.0 sequestra Android Context.startActivities() Método API, usando três Intents.
- O primeiro Intent é aquele que lança, no caso do nosso exemplo, o Gmail. Está sinalizado com
Intent.FLAG_ACTIVITY_NEW_TASK. - A segunda intenção é a maliciosa. Em nosso exemplo, é para a atividade de login semelhante. Esta intenção não possui sinalizadores.
- A terceira Intenção é a distração. Isso garante que o usuário não suspeite que o Gmail esteja abrindo aleatoriamente, em vez do aplicativo em que ele tocou (ou seja, aquele que iniciou o ataque). Está sinalizado com
Intent.FLAG_ACTIVITY_NEW_TASK.
Todos esses Intents são então passados em um array para o startActivities() método.
A falta de sinalizadores do segundo Intent é a chave aqui. Ao fazer isso, basicamente replicamos o exemplo do Gmail acima. A tarefa é tecnicamente do Gmail, mas a atividade principal é do invasor. Quando o usuário clica no ícone da tela inicial do Gmail, a atividade do invasor é exibida em vez da do Gmail.
Prova de conceito
Com as informações que a Promon nos enviou, conseguimos replicar sua prova de conceito. Aqui está uma gravação de tela de um Samsung Galaxy Note8 rodando Android 9 Pie mostrando-o em ação.
Técnicas e problemas de mitigação
Agora, simplesmente replicar o código acima não funcionará. Não é um exemplo completo e há algumas outras coisas que um invasor precisa fazer para que funcione, que não podemos compartilhar. Mas eles não são particularmente difíceis de adivinhar por conta própria, e isso é parte do que torna esse ataque tão perigoso. StrandHogg 2.0 é uma exploração relativamente fácil de implementar e difícil de mitigar.
A mitigação não pode envolver apenas colocar na lista negra todos os aplicativos que usam startActivities(), uma vez que existem muitos usos legítimos para ele. Também é muito difícil automatizar um algoritmo de detecção para isso. Desenvolvedores maliciosos podem empregar todos os tipos de truques para tornar a implementação do StrandHogg 2.0 efetivamente invisível para serviços como o Google Play Protect. O StrandHogg 1.0 exigia que o invasor adicionasse um atributo no AndroidManifest.xml do aplicativo malicioso, que era relativamente fácil de detectar. O StrandHogg 2.0, por outro lado, funciona inteiramente em Java/Kotlin.
Levando em consideração a ofuscação, a reflexão e até mesmo estilos de codificação diferentes, parece impraticável detectar automaticamente e adequadamente um aplicativo que faz uso dessa exploração. Além do mais, se um usuário for alvo de um ataque do StrandHogg 2.0, ele pode nem saber. Se você abrir o Gmail e vir a tela de login, você pode pensar que sua sessão expirou e inserir seus dados de login sem pensar duas vezes.
Quando contatamos o Google para obter uma resposta, um porta-voz fez a seguinte declaração:
“Agradecemos o trabalho dos pesquisadores e lançamos uma correção para o problema identificado. Além disso, o Google Play Protect detecta e bloqueia aplicativos maliciosos, incluindo aqueles que usam esta técnica."
Isso parece bom e espero que tenha pelo menos algum efeito contra os ataques do StrandHogg 2.0. É importante notar, porém, que o Google Play Protect nao fiz detectar nosso aplicativo de prova de conceito como malicioso, mesmo depois de realizar uma verificação manual.
Promon diz que eles "não observei nenhum malware na vida real utilizando a vulnerabilidade StrandHogg 2.0," mas não há garantia de que esta seja a primeira vez que a exploração foi descoberta. Por esse motivo, a Promon recomenda que os desenvolvedores sigam em frente e protejam seus aplicativos configurando as atividades do seu launcher launchMode sinalizar para qualquer um singleTask ou singleInstance. Qualquer um desses sinalizadores impedirá a injeção de tarefas, que é o que o StrandHogg 2.0 depende. No entanto, fazer com que sua atividade use um desses sinalizadores pode causar problemas com determinados fluxos de aplicativos, por isso nem sempre é desejável.
A Promon também está promovendo seu próprio produto “In-App Protection by Promon SHIELD”, que parece uma biblioteca que os desenvolvedores de aplicativos podem implementar para monitorar as tarefas no processo do seu aplicativo para verificar se há irregularidades inserções. Como não existe uma estratégia de mitigação verdadeiramente eficaz para desenvolvedores ou usuários, é muito importante que os fabricantes implementem o patch para corrigir isso o mais rápido possível.
Felizmente, a Promon seguiu as diretrizes de divulgação responsável antes de tornar esta exploração pública (e ainda não é totalmente público – a Promon está esperando 90 dias antes de divulgar totalmente como o StrandHogg 2.0 funciona). Desde então, o Google fez backport de patches para esta exploração para Android 8.0 Oreo, Android 8.1 Oreo e Android 9 Pie com o Nível de patch de segurança do Android (SPL) de maio de 2020. Os usuários do Android 10 e superior não são vulneráveis, embora não tenhamos certeza do motivo. Provavelmente tem algo a ver com as novas restrições do Android 10 em relação ao lançamento de atividades e como o Google integrou isso à pilha de tarefas. Promon diz que “no Android 10 o ataque é totalmente ineficaz e as atividades são divididas em tarefas diferentes e em pilhas de tarefas separadas de acordo com adb shell dumpsys activity activities."
Se o fabricante do seu dispositivo ainda fornece atualizações de segurança (você pode ler mais sobre como funciona o processo de patch de segurança aqui), você deve importuná-los para obter uma atualização o mais rápido possível. Caso contrário, você só precisará ter cuidado com quais aplicativos você baixa e executa (embora você deva fazer isso de qualquer maneira).
Para mais detalhes e casos de uso do StrandHogg 2.0, confira o anúncio oficial no site da Promon. Para desenvolvedores de ROM customizados, você pode encontrar os commits AOSP relevantes para prevenir ataques StrandHogg 2.0 aqui e aqui.
Cronograma de divulgação
Aqui está o cronograma de divulgação que a Promon compartilhou em seu documento StandHogg 2.0:
- 4 de dezembro de 2019 – Problema relatado ao Google
- 4 de dezembro de 2019 – Compartilhou um “aplicativo malicioso” PoC e um vídeo com o Google
- 4 de dezembro de 2019 – Google confirmou o recebimento do relatório
- 9 de dezembro de 2019 – O Google definiu a gravidade da descoberta como «Crítica»
- 9 de dezembro de 2019 – O Google confirma que é capaz de reproduzir o problema
- 14 de fevereiro de 2020 – Informamos ao Google que a divulgação de 90 dias está se aproximando no início de março e pedimos status da parte deles
- 14 de fevereiro de 2020 – O Google responde que abril é o mais rápido possível para lançar uma correção
- 14 de fevereiro de 2020 – Informamos ao Google que estamos trabalhando em mitigações
- 14 de fevereiro de 2020 – Google responde. Eles estão trabalhando em soluções e perguntam se podemos compartilhar quais mitigações recomendamos
- 17 de fevereiro de 2020 – Informamos ao Google que podemos adiar a divulgação até abril. Solicitamos o número CVE
- 17 de fevereiro de 2020 – Compartilhamos nossas estratégias de mitigação, bem como imaginamos uma mitigação de plataforma
- 23 de março de 2020 – Google responde com o CVE ID (CVE-2020-0096)
- 23 de março de 2020 – Google responde que a disponibilidade geral da correção para Android estará disponível em maio
- 23 de março de 2020 – Google pergunta se consideraremos adiar a divulgação para maio
- 27 de março de 2020 – Respondemos que adiaremos a divulgação até maio
- 22 de abril de 2020 – O Google nos informa que o Boletim de Segurança de maio está programado para conter um patch para a vulnerabilidade