A Cloudflare diz que foi alvo de um ataque semelhante ao feito na empresa de comunicações Twilio na semana passada, mas neste caso foi frustrado por chaves de segurança de hardware que são necessárias para acessar aplicativos e serviços.
Twilio relatou uma violação depois que os funcionários receberam mensagens de texto de phishing alegando ser do departamento de TI da empresa. Eles os enganaram para fazer login em uma página da Web falsa projetada para se parecer com a página de login do próprio Twilio, usando pretextos como alegando que precisavam alterar suas senhas. Os invasores puderam então usar as credenciais fornecidas pelas vítimas para fazer login no site real.
De acordo com a Cloudflare, ela registrou um incidente muito semelhante no final do mês passado, o que pode sugerir que os dois ataques podem ter originado do mesmo invasor ou grupo.
Detalhando o incidente em seu blog, a rede de entrega de conteúdo alegou que nenhum sistema Cloudflare foi comprometido, mas disse que era “um ataque sofisticado visando funcionários e sistemas em tais uma maneira que acreditamos que a maioria das organizações provavelmente seria violada.”
No caso da Cloudflare, sua equipe de segurança começou a receber relatórios em 20 de julho de que os funcionários receberam mensagens de texto contendo um link para o que parecia ser uma página de login da Cloudflare Okta (a Cloudflare usa os serviços de gerenciamento de identidade e acesso da Okta internamente). e treinou seus funcionários para repo rt qualquer coisa que pareça suspeita para a SIRT investigar. A grande maioria dos relatórios são falsos alarmes, mas neste caso parece que pelo menos 76 funcionários da empresa receberam as mensagens de phishing no espaço de um minuto.
A sofisticação do ataque pode ser medido pelo fato de que o URL nas mensagens de texto vinculadas a um domínio (cloudflare-okta.com) parecia ser legítimo e não havia sido detectado pelos sistemas de monitoramento da empresa. A Cloudflare possui sistemas para observar domínios registrados com seu nome e desligá-los, mas neste caso o domínio foi registrado menos de 40 minutos antes do envio das mensagens de phishing e, portanto, ainda não havia sido detectado.
Assim como no incidente do Twilio, a página de login falsa do Cloudflare Okta solicitava a qualquer funcionário que a visitasse seu nome de usuário e senha. Alertado por seus funcionários entrando em contato com a SIRT, a Cloudflare conseguiu analisar a carga útil do ataque de phishing com base na mensagem recebida pelos funcionários, bem como no que foi postado em serviços como o VirusTotal por outras empresas que foram vítimas de ataques semelhantes.
Parece que, se uma vítima digitasse suas credenciais, elas eram imediatamente retransmitidas ao invasor por meio do serviço de mensagens Telegram. A razão para fazer isso foi porque a página de phishing também solicitaria um código de senha de uso único com base no tempo (TOTP), de acordo com a Cloudflare, e seria necessário que o invasor tentasse fazer login usando o código antes que ele expirasse.
A maneira como deveria funcionar é que o invasor receberia as credenciais da vítima e as inseriria na página de login real, onde o site geraria um código e normalmente o enviaria para a vítima por mensagem de texto novamente. Uma vez inserido, isso também seria retransmitido para o invasor, que poderia usá-lo para se autenticar e obter acesso.
Esse método anularia a maioria das implementações de autenticação de dois fatores, de acordo com a Cloudflare, mas a empresa foi salva porque não usa códigos TOTP, mas usa um sistema diferente que exige que cada funcionário tenha uma chave de segurança compatível com FIDO2 (a Cloudflare menciona YubiKey) que implementa a vinculação de origem.
O este último refere-se a um token de autenticação sendo criptograficamente vinculado a um site específico por meio da camada TLS, o que significa que um ataque man-in-the-middle como este falhará. Isso significa que, embora a Cloudflare tenha descoberto que três de seus funcionários caíram na mensagem de phishing e digitaram suas credenciais, o invasor não conseguiu obter acesso.
Isso foi uma sorte, pois a Cloudflare diz que sua análise mostra que se uma vítima passasse por essas etapas, a página falsa iniciaria o download do software de acesso remoto que permitiria que um invasor controlasse a máquina da vítima remotamente.
O Cloudflare detalha as etapas realizadas respondendo em seu blog para que outras organizações possam aprender com o incidente. A empresa disse que já está fazendo ajustes em sua postura de segurança a partir do que aprendeu, incluindo ajustar o Cloudflare Gateway para restringir ou sandbox o acesso a sites executados em domínios registrados nas últimas 24 horas.
