Como os atacantes contornam a nova identificação de dois factores e como proteger os seus utilizadores

Preparar o ataque

Para executar o ataque, vamos usar uma combinação de duas ferramentas, Muraena e Necrobrowser. Muraena é um
proxy reverso
que irá executar a nossa página de phishing. A página de phishing será a página original com a qual a vítima irá interagir. Depois de a vítima se autenticar na sessão, o Muraena entrega a sessão ao Necrobrowser, permitindo que o atacante assuma o controlo da sessão ou automatize os passos seguintes do ataque. Como a Muraena actua como um proxy reverso, não haverá qualquer diferença entre o nosso site malicioso e o site original, para além do URL. A Muraena pode ser configurada para utilizar SSL com certificados obtidos através de, por exemplo, LetsEncrypt. Do ponto de vista da vítima, toda a experiência parecerá legítima, uma vez que simula a interação com a página original. Passarão pelo processo de autenticação normal, incluindo 2FA. Se a 2FA consistir numa palavra-passe de uso único (OTP) normal enviada por SMS, token de hardware ou software, a vítima introduzi-la-á como habitualmente. No entanto, mesmo os métodos modernos, como uma notificação automática para um dispositivo móvel ou a leitura de um código QR no ecrã, serão ignorados por este ataque.

O utilizador visita a página de phishing, que tem o SSL ativado.
O proxy reverso (Muraena) procura a página bancária legítima e entrega uma cópia à vítima.
A vítima tenta iniciar sessão na página e é-lhe solicitada a autenticação de dois factores.
Depois de a vítima ter completado o processo de autenticação, o proxy reverso (Muraena) entrega a sessão ao atacante (Necrobrowser) para assumir o controlo, cortando o acesso à vítima.

Na imagem abaixo pode ver-se Muraena a alojar o Google no domínio phish.anti. Para efeitos de demonstração, será configurado um DNS local para resolver isto na sua máquina de teste e também emitir certificados utilizando a sua própria CA, na qual o browser confia. No entanto, é exatamente este o aspeto que teria da perspetiva da vítima se fosse implementado no seu próprio domínio utilizando certificados válidos.

Proteção contra ataques

Agora que entendemos como o ataque funciona, podemos identificar quais os passos necessários para identificar ou proteger contra este tipo de ataque.

A ligação dinâmica proporciona uma boa primeira camada de defesa contra uma variedade de ataques. A ligação dinâmica é uma autenticação de dois factores realizada no momento da transação, que incorpora os detalhes da transação no processo de assinatura; frequentemente referida como O que se vê é o que se assinaporque o utilizador 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, tornando mais difícil ao atacante contorná-la. Normalmente, a ligação dinâmica é implementada através de tokens de hardware, tokens de software ou integrada como parte de uma aplicação bancária. Aqui estão dois exemplos de ligações dinâmicas, o primeiro para um pagamento legítimo e o segundo quando um atacante tenta modificar o pagamento.

O utilizador cria uma transação no banco online.
O utilizador submete a transação.
O banco envia os detalhes da transação para o telemóvel do utilizador.
O utilizador verifica os dados da transferência e autoriza o pagamento com dados biométricos (ou outro segundo fator).
A aplicação móvel gera uma palavra-passe de uso único (OTP) utilizando os dados da transação e a chave do token na aplicação móvel.

O utilizador tenta efetuar um pagamento na banca online.
O atacante modifica o pagamento para ter uma nova conta e/ou montante de dinheiro.
O banco envia os detalhes da transação para o telemóvel do utilizador.
O utilizador recebe a informação de pagamento modificada e rejeita o pagamento.

Os exemplos acima ilustram também a importância de utilizar a encriptação de extremo a extremo ao implementar a ligação dinâmica. Além disso, mostra que a própria aplicação móvel deve ser protegida, uma vez que o atacante pode tentar atacar a aplicação para ocultar os dados de pagamento modificados do utilizador.

Outra forma eficaz de reconhecer e defender-se contra uma grande variedade de ataques é implementar uma monitorização contínua nas suas plataformas digitais. Ao monitorizar a sessão desde o momento do início de sessão até ao fim da mesma, podemos contextualizar melhor as acções dos utilizadores e os dispositivos ou contas a que estão associados. A monitorização contínua combina perfeitamente com outras camadas, como a 2FA ou as ligações dinâmicas, uma vez que também permitem que o banco se contextualize a partir destes dispositivos de autenticação.

O banco pode então monitorizar indicadores típicos de ataques conhecidos, tais como novos dispositivos, localizações, presença de proxy ou outros. Esta informação pode ser correlacionada com a sua base de utilizadores para compreender melhor o risco destes elementos. Podemos também ter em conta as operações que o utilizador efectua durante toda a sessão e compará-las com o seu comportamento habitual. Esta abordagem estabelece um perfil de risco contínuo para a sessão que pode mudar com cada ação tomada pelo utilizador final. Isto não só permite que o banco tome medidas automatizadas em tempo real quando são detectadas anomalias, como também permite que o banco reduza o atrito das sessões legítimas, reduzindo o número de autenticações necessárias para sessões reais.

Conclusão

Embora o ataque neste artigo fale de tecnologia e conceitos que existem há séculos, vemos que a sua aplicação correcta ainda pode conduzir a um grande sucesso e lutar contra vários métodos de autenticação implementados atualmente. É importante que os bancos utilizem uma abordagem por camadas, uma vez que a maioria das camadas individuais pode ser atacada ou dinamizada. Ao implementar ligações dinâmicas, os bancos devem garantir que estabelecem uma linha de comunicação segura com o utilizador final. Por exemplo, confiar nos SMS já não é fiável, uma vez que as mensagens podem ser roubadas, falsificadas ou interceptadas pelo atacante. No entanto, ao implementar aplicações móveis, os bancos devem também estar conscientes de que estas aplicações se tornam um alvo e devem proteger as suas aplicações móveis de ataques externos. O objetivo deste artigo é principalmente demonstrar que os ataques de phishing podem ser modernizados para derrotar a autenticação de dois factores no início de sessão e que a implementação da 2FA por si só não oferece uma proteção completa contra o phishing. Por último, mencionámos algumas camadas que os bancos podem implementar para proporcionar uma maior proteção aos seus utilizadores finais, bem como as armadilhas a evitar ao fazê-lo. Em suma:

Implementa ligações dinâmicas com encriptação de ponta a ponta.
Implementa a análise do lado do servidor para monitorizar as sessões do utilizador final, os dispositivos e o comportamento de ataque.
Proteja as suas aplicações móveis contra malware e outras ameaças externas.