MFA seguro contra proxies de phishing com F5 BIG-IP APM e defesa de bot de nuvem distribuída

Um ataque de proxy de phishing em tempo real começa com uma mensagem de phishing enviada por texto, e-mail ou página da web. A mensagem de phishing contém um link que leva o usuário a um domínio controlado pelo invasor, projetado para encaminhar todas as solicitações para o application de destino. Da perspectiva do usuário, tudo parece legítimo, exceto o nome de domínio, que geralmente é escolhido para se assemelhar ao real. 

Enganado pelo proxy de phishing, o usuário insere suas credenciais. No caso de autenticação de fator único, essa entrada de credenciais é suficiente para que o invasor obtenha acesso à conta. No caso de 2FA, o proxy de phishing em tempo real envia as credenciais para o application legítimo, acionando a solicitação 2FA. Infelizmente, o usuário, ainda acreditando que está interagindo com o application legítimo, provavelmente aceitará o 2FA, concordando com qualquer solicitação feita. 

Proxies de phishing reverso podem comprometer quase todas as formas de 2FA:

• 2FA baseado em serviço de mensagens curtas (SMS). Em um SMS 2FA, o sistema de autenticação dispara uma mensagem de texto para o usuário com uma senha de uso único (OTP), que o usuário digita no aplicativo. Durante um ataque de proxy de phishing, o usuário digita a senha diretamente no aplicativo malicioso, que então a envia por proxy para o aplicativo legítimo, concedendo assim o acesso criminoso. A mesma lógica se aplica à 2FA quando o OTP é enviado por e-mail. Se o mecanismo envolver o usuário digitando o OTP em um aplicativo, um ataque de proxy de phishing em tempo real pode obter acesso a esse OTP.
• Token de hardware 2FA. Os tokens de hardware, que são dispositivos físicos que geram chaves em intervalos de tempo fixos seguindo um algoritmo criptográfico, têm a mesma finalidade que os OTPs na autenticação de dois fatores baseada em SMS. Olhando para o dispositivo, o usuário digita a chave no application. Quando enganado por um proxy de phishing em tempo real para digitar essa chave em um application malicioso, o invasor obtém acesso à conta. De certa forma, entregar o token via SMS, e-mail ou hardware não faz diferença para o proxy de phishing em tempo real. (Por outro lado, as chaves de hardware FIDO2/U2F não são passíveis de phish porque o navegador colabora com a chave de hardware na vinculação de origem.)
• 2FA baseado em aplicativo. Aplicativos autenticadores móveis, como o Google Authenticator e o Duo Mobile, geram tokens da mesma forma que dispositivos de hardware. Novamente, espera-se que os usuários digitem o token no aplicativo. Se o usuário for enganado para digitar o token em um aplicativo malicioso, o invasor obtém acesso ao application real.
• 2FA baseado em push. Certamente, qualquer mecanismo 2FA que envolva o usuário digitando um OTP em um application pode ser quebrado enganando o usuário e fazendo-o digitar o OTP em um application malicioso. Mas o que dizer do 2FA baseado em push, que não exige que o usuário digite um OTP em um application? Em vez disso, em um sistema baseado em push, o application, ao receber uma solicitação de login, aciona uma solicitação para um sistema de notificação push que faz com que o usuário receba uma notificação em seu dispositivo móvel. O usuário só precisa clicar uma vez para aceitar a solicitação. Quando isso ocorre, o sistema de notificação push faz uma chamada de API de volta para o application , indicando que a autenticação push foi bem-sucedida, e o application conclui o processo de autenticação, concedendo acesso ao usuário. Nesse cenário, o proxy de phishing nunca recebe o token porque ele é passado diretamente para o application. No entanto, o criminoso ainda obtém acesso à conta porque o application eventualmente entregará o token de sessão autenticado ao application por meio do proxy, o que permite que o invasor o capture e o use para acessar o application usando a identidade da vítima.

Devemos esperar que os ataques de proxy de phishing em tempo real aumentem porque os proxies de phishing como serviço (PhaaS) — como EvilGinx, Muraena e Modlishka — tornam isso notavelmente fácil para os criminosos, fornecendo tudo o que eles precisam para lançar esses ataques:

• Modelos de e-mail de phishing que enganam os usuários e os fazem visitar sites maliciosos
• Servidores web hospedados que imitam aplicativos de destino
• Bancos de dados para armazenar credenciais roubadas
• Monitoramento em tempo real
• Mecanismos defensivos para frustrar pesquisadores de segurança
• Documentação e atendimento ao cliente

O tráfego que passa por um proxy de phishing tem características distintas: O nome de domínio não corresponderá ao do site real, o HTML e o JavaScript podem ser alterados para acomodar a mudança do nome de domínio, e o tempo e as assinaturas TLS podem ser alterados. Usando muitos dos mesmos sinais de rede e do lado do cliente usados para distinguir bots de humanos, o Distributed Cloud Bot Defense pode detectar as anomalias que distinguem proxies de phishing em tempo real e, assim, resolver uma das ameaças mais comuns contra MFA.

O BIG-IP APM é uma solução de gerenciamento de acesso flexível e de alto desempenho para aplicativos e APIs. Ele fornece serviços de autenticação para applications conectando serviços de identidade empresarial , como Active Directory, provedores LDAP e RADIUS, a protocolos de autenticação modernos, como SSO, federação de acesso, OAuth 2.0, SAML e OIDC. 

O BIG-IP APM inclui suporte para autenticação por etapas , fornecendo OTP 2FA baseado em SMS pronto para uso. Além disso, o BIG-IP APM integra-se à maioria das principais soluções MFA, incluindo as da Cisco Duo, Okta, Azure AD e outras. 

Devido ao papel central que o BIG-IP APM desempenha no processo de autenticação de muitas empresas, ele é um local ideal para implementar o Distributed Cloud Bot Defense para proteger os usuários de ataques de proxy de phishing em tempo real que usam automação para ignorar as proteções MFA.