Como agressores contornam a moderna autenticação de dois fatores e como proteger os usuários

Ben Balthazar, 4 de Fevereiro de 2020
How Attackers Bypass Modern Two-factor Authentication and How to Protect Your Users

Neste artigo, veremos um exemplo de ferramentas e técnicas que os atacantes podem usar para ignorar a maioria dos autenticação de dois fatores (2FA), do SMS OTP a notificações push criptografadas em um aplicativo móvel. O método de ataque pode ser muito eficaz contra a maioria dos tipos de 2FA implantados hoje, incluindo autenticação fora de banda. Também discutiremos que tipo de contramedidas podem ser implementadas pelos bancos para reduzir o risco de tais ataques e proteger seus clientes.

Configurando o ataque

Para executar este ataque, usaremos uma combinação de duas ferramentas, Muraena e Necrobrowser. Muraena é uma proxy reverso que executará nossa página de phishing. A página de phishing procurará a página original com a qual a vítima irá interagir. Depois que a vítima se autenticar, Muraena entregará a sessão ao Necrobrowser, o que permite que o atacante assuma o controle da sessão ou automatize as próximas etapas do ataque. Como o Muraena age como um proxy reverso, não haverá diferença entre nosso site malicioso e o site original, além do URL. O Muraena pode ser configurado para usar SSL com certificados obtidos por exemplo, por LetsEncrypt. Do ponto de vista da vítima, toda a experiência parecerá legítima, pois parece que eles estão interagindo com a página original. Eles passarão pelo processo de autenticação regular, incluindo o 2FA. Se o 2FA consistir em uma senha descartável comum entregue por SMS, hardware ou software, a vítima a digitará normalmente. No entanto, mesmo métodos modernos, como uma notificação por push em um dispositivo móvel ou a digitalização de um código QR na tela, serão ignorados por esse ataque.

Ilustração do ataque de phishing de proxy reverso.

  1. O usuário visita a página de phishing, que possui o SSL ativado.
  2. O Proxy Reverso (Muraena) busca a página bancária legítima e serve uma cópia para a vítima.
  3. A vítima tenta fazer login na página e é solicitada a autenticação de dois fatores
  4. Após a vítima concluir o processo de autenticação, o Proxy Reverso (Muraena) entrega a sessão ao invasor (Necrobrowser) para assumir o controle, cortando a vítima.

Na imagem abaixo, você pode ver Muraena hospedando o Google no domínio phish.anti. Para fins de demonstração, configurei um DNS local para resolver isso em minha máquina de teste e também emiti certificados usando minha própria CA, que é confiável pelo navegador. No entanto, é exatamente assim que seria da perspectiva da vítima se isso fosse implantado em seu próprio domínio usando certificados válidos.

Captura de tela do Muraena que copia o google.com para phish.anti usando SSL.

Protegendo contra o ataque

Agora que entendemos como o ataque funciona, podemos identificar quais etapas seriam bem-sucedidas na identificação ou proteção contra esse tipo de ataque.

Ligação dinâmica fornece uma boa primeira camada de defesa contra uma variedade de ataques. O vínculo dinâmico consiste em uma autenticação de dois fatores feita no momento da transação, que incorpora os detalhes da transação no processo de assinatura. Geralmente chamado de O que você vê é o que você assina, porque o usuário final deve receber os detalhes da transação antes de concluir o processo de assinatura. Uma vez assinada, a assinatura deve ser válida apenas para esta transação específica, dificultando assim o desvio do invasor. Normalmente, o vínculo dinâmico é implementado por meio de tokens de hardware, tokens de software ou integrados como parte de um aplicativo bancário. Abaixo, temos dois exemplos de vínculo dinâmico, primeiro para um pagamento legítimo e o segundo para um invasor tentar modificar o pagamento.

Ilustração de vinculação dinâmica em um pagamento legítimo.

  1. O usuário cria uma transação no banco online.
  2. O usuário envia a transação.
  3. O banco envia os detalhes da transação para o celular do usuário.
  4. O usuário verifica os detalhes da transferência e autoriza o pagamento com uma biometria (ou outro segundo fator).
  5. O aplicativo móvel gera uma senha de uso único usando os detalhes da transação e a chave do token dentro do aplicativo móvel.

Ilustração da vinculação dinâmica em que um invasor tenta modificar o pagamento.

  1. O usuário tenta criar um pagamento no banco online.
  2. O atacante modifica o pagamento para ter uma nova conta e / ou valor de beneficiário.
  3. O banco envia os detalhes da transação para o celular do usuário.
  4. O usuário recebe as informações de pagamento modificadas e rejeita o pagamento.

Os exemplos acima também ilustram a importância do uso de criptografia de ponta a ponta ao implementar o vínculo dinâmico. Além disso, mostra que o próprio aplicativo móvel deve ser protegido, pois o invasor pode tentar atacá-lo para ocultar os detalhes de pagamento modificados do usuário.

Outra maneira eficaz de reconhecer e se defender contra uma grande variedade de ataques é implementar monitoramento contínuo em suas plataformas digitais. Ao monitorar a sessão desde o momento da iniciação até o final da sessão, podemos trazer mais contexto por meio das ações dos usuários e dos dispositivos ou contas com os quais eles se associam. O monitoramento contínuo combina perfeitamente com outras camadas, como 2FA ou vínculo dinâmico, pois permite que o banco traga contexto também desses dispositivos de autenticação.

Exemplo de monitoramento contínuo para entender cada tentativa de operação, autenticação e resultado.

O banco pode então monitorar indicadores típicos de ataques conhecidos, como novos dispositivos, locais, presença de proxy ou outros. Essas informações podem ser correlacionadas em toda a base de usuários para entender melhor o risco desses elementos. Em seguida, também podemos levar em consideração as operações que o usuário está realizando durante toda a sessão e analisar o perfil com relação ao comportamento usual. Essa abordagem estabelece um perfil de risco contínuo para a sessão, que pode ser alterado a cada ação realizada pelo usuário final. Isso não apenas permite ao banco executar ações automatizadas em tempo real quando são detectadas anomalias, como também reduz o atrito por sessões legítimas, reduzindo a quantidade de autenticações necessárias para sessões genuínas.

Conclusão

Embora o ataque neste artigo use tecnologia e conceitos que existem há muito tempo, vemos que aplicá-los corretamente ainda pode levar a um grande sucesso e derrotar vários métodos de autenticação implantados hoje. É importante que os bancos usem uma abordagem em camadas, pois a maioria das camadas individuais ainda pode ser atacada ou explorada. Ao implementar a vinculação dinâmica, os bancos precisam garantir uma linha de comunicação segura com o usuário final. Confiar no SMS, por exemplo, já provou não ser confiável, pois as mensagens podem ser roubadas, falsificadas ou interceptadas pelo invasor. No entanto, ao implementar aplicativos móveis, os bancos também devem estar cientes de que esses aplicativos se tornam um alvo e devem proteger seus aplicativos móveis contra ataques externos. O objetivo deste artigo é principalmente demonstrar que os ataques de phishing podem ser modernizados para anular a autenticação de dois fatores no login e a implementação do 2FA por si só não oferece proteção completa contra phishing. Por fim, mencionamos algumas camadas que os bancos podem implementar para fornecer proteção adicional a seus usuários finais, bem como quais armadilhas devem ser evitadas ao fazê-lo. Para resumir:

  • Implemento ligação dinâmica com criptografia de ponta a ponta.
  • Implemente análises do lado do servidor para monitor sessões de usuário final, dispositivos e comportamento para possíveis ataques.
  • Proteger seu celular apps de malware e outras ameaças externas.
capa do ebook
eBook

Fraude de sequestro de conta: como proteger seu negócio e seus clientes

Como prevenir a fraude de sequestro de conta e proteger os clientes em cada estágio de sua jornada digital.

Baixar Agora

 

Ben Balthazar é consultor de fraude da OneSpan, ajudando instituições financeiras da Europa, Oriente Médio e Ásia a se defenderem contra o cibercrime financeiro. Ben iniciou sua carreira na OneSpan em 2014 e mudou-se da Bélgica para Dubai em 2016.