Como combater a invasão de contas: por que a MFA é apenas o primeiro passo
Introdução
A autenticação multifator (MFA) não elimina a ameaça de invasão de contas. Ela cria obstáculos, é verdade, mas invasores determinados descobriram maneiras engenhosas de contornar todos os fatores de autenticação disponíveis. Em vez de considerar a autenticação um problema resolvido, devemos entender que a MFA amplia a superfície de ataque: cada fator introduz um novo sistema de dependências, novas fontes de bugs e vulnerabilidades e novas oportunidades de engenharia social. Infelizmente, muitas organizações de segurança veem a MFA da mesma forma como víamos o perímetro da rede: como uma barreira capaz de impedir uma ampla variedade de ataques. A falácia do perímetro seguro, exposta pelos defensores da segurança de confiança zero permitiu que invasores explorassem vulnerabilidades dentro das redes para se movimentar lateralmente e elevar seus privilégios. Da mesma forma, a falácia de que a MFA elimina o risco de invasão de contas impede que as organizações de segurança reconheçam as fragilidades da MFA e as muitas vulnerabilidades de sistema ainda existentes que expõem as contas dos usuários a invasões criminosas. Ao analisar como os invasores contornam a MFA, este white paper demonstra que ela torna outras medidas de segurança ainda mais importantes, especialmente a mitigação de bots, as proteções da cadeia de suprimentos de JavaScript e o monitoramento de riscos contextuais — técnicas que reforçam as vantagens de segurança da MFA e, ao mesmo tempo, reduzem o atrito que ela impõe aos usuários.
Os fatores que impulsionam a MFA
Apesar de suas vulnerabilidades, a MFA veio para ficar, e por um bom motivo: a autenticação baseada apenas em senha claramente fracassou.
Nós, seres humanos, simplesmente não conseguimos memorizar longas sequências aleatórias de caracteres. Por isso, recorremos a atalhos: escolhemos senhas previsíveis e fáceis de lembrar, reutilizamos senhas em diferentes aplicativos e anotamos senhas em post-its. Embora as empresas reduzam esse risco impondo requisitos de tamanho e complexidade das senhas, a memória humana tem limites. Mesmo diante desses requisitos, encontramos maneiras de manter padrões previsíveis: usamos letra maiúscula apenas no início, substituímos caracteres alfanuméricos por caracteres especiais visualmente semelhantes ($ no lugar de S) e acrescentamos ao final da senha sequências fáceis de adivinhar, como 123. (Consulte os resultados da pesquisa sobre previsibilidade de senhas.)
Nós, seres humanos, também compartilhamos falhas que nos tornam vulneráveis à engenharia social. Entregamos nossas senhas quando os invasores exploram nossa confiança, nosso desejo de nos adequar, nosso respeito pela autoridade e nossa disposição para ajudar. Acontece que, às vezes, basta pedir para que as pessoas revelem suas senhas, como você pode conferir neste vídeo divertido do Jimmy Kimmel Live.
Diante dessas fragilidades da autenticação baseada em senhas, órgãos governamentais e associações do setor estão impulsionando a adoção da MFA. Em maio de 2021, o presidente Biden emitiu uma ordem executiva exigindo que os órgãos federais adotassem a MFA no prazo de 180 dias, e a Agência de Segurança Cibernética e de Infraestrutura (CISA) está promovendo a MFA entre empresas privadas. O Conselho de Padrões de Segurança do Setor de Cartões de Pagamento está determinando, por meio de seu Padrão de Segurança de Dados v4.0, que as organizações implementem a MFA para todo acesso aos dados de titulares de cartões de crédito até 31 de março de 2025.
Com as claras vantagens da MFA em relação à autenticação baseada apenas em senha impulsionando sua adoção, os profissionais de segurança precisam prestar cada vez mais atenção às desvantagens da MFA, à forma como ela amplia a superfície de ataque e cria novas vulnerabilidades que permitem aos invasores contornar os controles de autenticação.
A superfície de ataque ampliada da MFA
A MFA é definida como a aplicação de dois ou mais fatores no processo de autenticação. Por fator, entende-se uma forma de comprovar que você é quem diz ser por meio de:
- Conhecimento: algo que você sabe, como uma senha ou um Número de Identificação Pessoal (PIN)
- Posse: algo que você possui, como um dispositivo móvel, cartão inteligente, token de hardware ou unidade USB
- Inerência: algo que você é, conforme determinado por dados biométricos, como impressões digitais, reconhecimento facial e padrões da íris
Há inúmeras maneiras de implementar a autenticação multifator (MFA), e muitas delas criam novas superfícies de ataque ou deixam os aplicativos expostos às mesmas vulnerabilidades que caracterizam a autenticação baseada apenas em senha.
MFA baseada em SMS
Há inúmeras maneiras de implementar a MFA, e muitas delas criam novas superfícies de ataque ou deixam os aplicativos expostos às mesmas vulnerabilidades que caracterizam a autenticação baseada apenas em senha.
A implementação mais difundida de MFA utiliza SMS para enviar aos usuários uma senha de uso único (OTP), que, em princípio, comprova a posse de um smartphone. Geralmente, o usuário inicia o login com um nome de usuário e uma senha, fazendo com que o aplicativo envie a mensagem de texto. Em seguida, o usuário visualiza a OTP e a insere no aplicativo, concluindo a autenticação e gerando um token de sessão que será válido por um período determinado.
Vulnerabilidades remanescentes da autenticação baseada em SMS
A implementação do fator de posse via SMS não elimina várias vulnerabilidades importantes. Como o usuário insere a OTP e a senha no aplicativo, e o aplicativo envia a OTP de volta ao servidor pelo mesmo canal de comunicação utilizado por ele, um invasor que tenha comprometido o aplicativo, o dispositivo ou a rede poderá acessar a senha, a OTP e o token de sessão.
Atacando o endpoint
Usando diversas técnicas bem estabelecidas e ainda predominantes, os invasores assumem o controle de dispositivos infectando-os com malware, o que resulta em um ataque man-in-the-browser (MitB). A execução de código no navegador permite que os invasores obtenham a senha e a OTP para se autenticarem em nome do usuário. Como alternativa, o invasor pode permitir que a autenticação seja concluída e, em seguida, roubar o identificador da sessão, que pode ser usado para contornar a autenticação e acessar a conta do usuário. (Para conhecer as tendências recentes de malware que infecta endpoints, consulte o relatório da F5 Labs sobre o BlackGuard Infostealer.)
Comprometimento do aplicativo
Ao infectar um aplicativo, os invasores podem assumir o controle das contas dos usuários em massa. Além de comprometer a infraestrutura de uma empresa por meio de malware, os criminosos podem obter acesso aos dados do aplicativo comprometendo qualquer uma das bibliotecas de código que o compõem, uma tática conhecida como ataque à cadeia de suprimentos.
Em um ataque à cadeia de suprimentos de software, o invasor geralmente tem como alvo um fornecedor terceirizado confiável ou um repositório de código aberto que fornece componentes de software (bibliotecas, frameworks, serviços) à organização visada. O invasor insere um malware no componente, que é então integrado ao aplicativo. Esse ataque pode ser eficaz porque nem todos os fornecedores e equipes de código aberto têm as habilidades e os recursos necessários para aplicar práticas de codificação segura.
Aplicações web e móveis são particularmente vulneráveis a ataques à cadeia de suprimentos porque normalmente incluem dezenas de scripts de terceiros, muitos deles adicionados dinamicamente às páginas por gerenciadores de tags. Esses scripts, que mudam com frequência e sem aviso prévio, não passam pelas verificações de segurança de código da organização. Se um invasor conseguir comprometer qualquer um desses scripts, ele obterá controle total sobre a aplicação, podendo ler as informações inseridas pelo usuário, acessar dados na memória do navegador ou sequestrar a jornada do usuário para redirecioná-lo a uma aplicação maliciosa sem aviso prévio.
Esses ataques à cadeia de suprimentos, como o Magecart, causaram violações de segurança que comprometeram centenas de milhares de credenciais. Assim como os ataques MitB, esses ataques à cadeia de suprimentos são eficazes contra qualquer solução de MFA na qual o token que comprova a posse seja inserido no aplicativo, como ocorre normalmente na maioria das implementações que usam OTPs. Como o código malicioso lê os dados inseridos pelo usuário, ele pode roubar tanto a senha estática quanto a OTP, além de quaisquer outras informações pessoais ou financeiras coletadas pelo aplicativo.
Escuta na rede
Como, na autenticação baseada em SMS, a senha, o OTP e o token de sessão trafegam pela mesma conexão de rede, essa forma de MFA continua vulnerável a ataques do tipo man-in-the-middle (MitM), que utilizam vetores de ataque comuns, como envenenamento de DNS, envenenamento de ARP e pontos de acesso sem fio maliciosos.
Engenharia social
Um dos ataques mais comuns e bem-sucedidos contra a MFA baseada em SMS usa engenharia social para realizar um ataque MitM por meio de proxies de phishing em tempo real (RTPP).
Nesse ataque, o fraudador usa e-mails de phishing para induzir o usuário a acessar um site controlado pelo invasor, no qual o usuário insere suas credenciais. Até esse ponto, a tática é idêntica à de um ataque de phishing para roubo de credenciais, mas contornar a MFA exige uma etapa adicional. Quando o usuário insere seu nome de usuário e senha no aplicativo, o invasor encaminha essas credenciais ao aplicativo-alvo, que então envia ao usuário uma solicitação de segundo fator. É muito provável que o usuário aprove a solicitação, pois acredita estar se autenticando em um aplicativo confiável; ele clica no botão de aprovação ou insere o token no aplicativo conforme solicitado. Em ambos os casos, o invasor obtém acesso ao aplicativo. (Para ver uma demonstração do ataque, assista a este vídeo de Kevin Mitnick.)
Com a automação e a propensão dos usuários a cair em golpes de phishing, os ataques de RTPP podem ser bem-sucedidos em larga escala. (Para mais dados sobre o crescimento dos proxies de phishing em tempo real, consulte o Relatório de Phishing e Fraude da F5 Labs.)
Novas vulnerabilidades da autenticação por SMS
Além de não corrigir muitas das vulnerabilidades existentes na autenticação baseada apenas em senha, o uso de SMS como segundo fator expõe um aplicativo a outros vetores de ataque.
Roubo do dispositivo físico
Talvez o ataque mais óbvio contra a autenticação baseada em posse seja o roubo de um dispositivo físico. Um criminoso que rouba um celular pode obter acesso a uma senha de uso único (OTP) exibida em uma notificação, mesmo com o aparelho bloqueado. Muitas vítimas de roubo de celular acabaram perdendo o dinheiro de suas contas bancárias.
Troca de SIM (Módulo de Identidade do Assinante)
Os criminosos não precisam estar fisicamente de posse de um telefone para acessar OTPs enviados por mensagem de texto. A troca de SIM (https://www.darkreading.com/edge/sim-swapping-attacks-what-they-are-how-to-stop-them), também conhecida como sequestro ou portabilidade de SIM, permite que invasores contornem a autenticação baseada em SMS, a forma de MFA mais utilizada em aplicativos voltados para clientes. Em um ataque de troca de SIM, o fraudador explora a possibilidade oferecida pelas operadoras de telecomunicações de transferir um número de telefone para outro dispositivo, um recurso útil quando um telefone é perdido ou roubado.
O fraudador começa coletando informações pessoais sobre a vítima por meio de pesquisas online, phishing ou engenharia social. Com essas informações, o invasor convence a operadora de telefonia a transferir o número de telefone da vítima para o cartão SIM do fraudador. Outra possibilidade é o invasor acessar indevidamente a conta do usuário junto à operadora usando preenchimento de credenciais, tentativas de força bruta ou um ataque de dicionário.
Ao assumir o controle do serviço de telefonia da vítima, o fraudador receberá todas as mensagens SMS e chamadas de voz destinadas a ela. Isso permite que o fraudador intercepte quaisquer tokens de segurança enviados por mensagem de texto.
Dispositivos de token de hardware
Os tokens de hardware são dispositivos especializados, geralmente bem pequenos, que exibem uma senha de uso único (OTP), a qual o usuário insere em um aplicativo para se autenticar. Esses dispositivos permitem comprovar a posse sem exigir que o aplicativo se comunique com o usuário, eliminando uma das principais vulnerabilidades da autenticação baseada em SMS.
Em vez de depender do envio de uma OTP ao usuário a cada login, o dispositivo gera uma sequência de OTPs com base em um valor de semente inicial e em um algoritmo. O próprio valor de semente é compartilhado entre o dispositivo e o serviço de autenticação durante a configuração. Ao valor de semente é acrescentado um contador, que é incrementado por um evento, como uma solicitação de login, ou após um intervalo de tempo, como 60 segundos. Esses métodos são chamados, respectivamente, de OTP baseada em evento (EOTP) e OTP baseada em tempo (TOTP). EOTP e TOTP são tipos de OTP baseada em hash (HOTP), pois o contador e a semente são processados juntos por uma função hash que gera uma sequência de dígitos aparentemente aleatória e que, quando implementada corretamente, não revela um padrão previsível.
Ao eliminar a necessidade de enviar a OTP por mensagem de texto, os tokens de hardware impedem que ela seja interceptada antes de chegar ao usuário por meios como a troca de SIM. No entanto, como o usuário precisa inserir a OTP no aplicativo, que a transmite ao serviço de autenticação pelo mesmo canal de comunicação usado para a senha, a maioria das outras vulnerabilidades da autenticação baseada em SMS permanece. O invasor pode obter acesso à senha e à OTP comprometendo o dispositivo, a rede ou o aplicativo das mesmas formas que faria com OTPs enviadas por mensagem de texto.
O ataque mais comum contra a autenticação baseada em SMS, que utiliza proxies de phishing em tempo real, funciona igualmente bem com OTPs geradas em dispositivos de hardware, pois o usuário é induzido a digitar a OTP no site falso, independentemente de ela ser exibida em um telefone ou em um dispositivo especializado.
Embora os dispositivos de hardware eliminem a possibilidade de invasores capturarem a OTP durante a transmissão ao usuário, esses dispositivos dependem de valores de semente que podem ser comprometidos. Os invasores podem acessar o valor de semente obtendo acesso físico aos dispositivos (veja a menção a um ataque com microscópio eletrônico em Mais de 12 maneiras de hackear a MFA), comprometendo o banco de dados usado pelo serviço de autenticação ou interceptando o processo de configuração no qual o valor de semente é acordado entre o dispositivo e o serviço de autenticação.
Aplicativos autenticadores
Os aplicativos autenticadores podem funcionar de forma muito semelhante aos tokens de hardware, gerando uma sequência de OTPs com base em uma semente inicial e em um algoritmo, o que elimina a necessidade de transmitir a semente por um canal vulnerável. No entanto, eles também podem ir além, utilizando um canal alternativo para transmitir a OTP. Nesse cenário, após a verificação bem-sucedida do nome de usuário e da senha, o serviço de autenticação envia uma notificação push ao aplicativo autenticador, solicitando que o usuário aprove a solicitação. Após a aprovação, o aplicativo autenticador envia a OTP diretamente ao serviço de autenticação, sem exigir que o usuário a digite no aplicativo. A comunicação entre o aplicativo autenticador e o serviço de autenticação ocorre por meio de uma conexão distinta.
O uso de um canal de comunicação alternativo impede que um invasor acesse a OTP ao comprometer o aplicativo, pois a OTP nunca é inserida nele. Também é mais difícil obter tanto a senha quanto a OTP comprometendo a conexão de rede, porque elas são transmitidas por canais seguros distintos. No entanto, comprometer o dispositivo poderia permitir que um invasor acessasse tanto a senha quanto a OTP caso o aplicativo e o aplicativo autenticador estivessem sendo executados no mesmo dispositivo. (Consulte o relatório sobre malware do F5 Labs que compromete o Google Authenticator.)
Infelizmente, os aplicativos autenticadores não impedem o uso de proxies de phishing em tempo real. O usuário ainda é induzido, por meio de uma mensagem de texto de phishing, a inserir seu nome de usuário e sua senha em um site falso. Ao inserir suas credenciais, o aplicativo acionará uma solicitação no aplicativo autenticador. Como o usuário acredita estar fazendo login em um aplicativo confiável, é provável que aprove a solicitação, concluindo assim a autenticação. Embora o invasor nunca veja a OTP, seu proxy passará a controlar uma sessão autenticada, dando-lhe acesso à conta do usuário. (Para saber mais sobre RTPP e autenticação por notificação push, consulte este artigo sobre plataformas de phishing no Hacker News.)
Além disso, a facilidade de uso dos aplicativos autenticadores criou outra forma de os invasores contornarem a MFA por meio de engenharia social. Em ataques de bombardeio de MFA ou de fadiga de MFA, o invasor engana o alvo para que forneça seu código de autenticação, enviando várias solicitações fraudulentas do código. Normalmente, o invasor usa ferramentas automatizadas para gerar um grande número de solicitações, sobrecarregando a vítima com uma quantidade excessiva de notificações ou mensagens que pedem que ela insira seu código de autenticação.
Embora o bombardeio de MFA possa induzir um usuário a inserir uma OTP recebida por SMS ou gerada por um dispositivo de hardware, ele é particularmente eficaz contra aplicativos autenticadores, pois o usuário pode interromper facilmente a enxurrada de solicitações com o simples toque de um botão.
Autenticação biométrica
Há ainda mais maneiras de implementar a autenticação biométrica do que a autenticação baseada em posse. Além de existirem diversos métodos para acionar a solicitação de autenticação e transmitir esses dados de volta ao serviço de autenticação, há muitas formas de biometria, desde impressões digitais até o escaneamento da íris. O hardware necessário para realizar a leitura pode estar integrado ao dispositivo que executa o aplicativo, como uma câmera com leitor de impressões digitais em um notebook, ou pode exigir um equipamento separado. O leitor biométrico pode ser controlado pelo sistema operacional ou por um aplicativo especializado. Dadas essas variações de implementação, é difícil modelar todas as vulnerabilidades. No entanto, é importante entender que, apesar da reputação da autenticação biométrica de oferecer maior segurança, ela ainda apresenta vulnerabilidades bastante evidentes.
De fato, um dos métodos mais comuns para contornar o fator de posse, o uso de proxies de phishing em tempo real, também pode ser usado para contornar a autenticação biométrica. Quando o usuário acessa um aplicativo controlado por um invasor acreditando que se trata de um aplicativo confiável, esse aplicativo usa as credenciais para acessar o aplicativo legítimo em nome do usuário, acionando a solicitação de autenticação biométrica. Enquanto o usuário acreditar que está se autenticando no aplicativo verdadeiro, provavelmente prosseguirá com a autenticação biométrica, dando ao invasor acesso à conta. (O padrão FIDO2 WebAuthn, criado pelo W3C, inclui proteção contra phishing, embora ainda não seja amplamente adotado por aplicativos web.)
A possibilidade de burlar a autenticação biométrica por meio do comprometimento do endpoint, da aplicação ou da rede depende da implementação específica. Se o sistema de autenticação biométrica for executado no mesmo dispositivo que a aplicação, o comprometimento do endpoint poderá invalidar a autenticação. Se a aplicação gerenciar o processo de autenticação biométrica, o comprometimento dela poderá invalidar a autenticação. E, se a autenticação biométrica for enviada pelo mesmo canal de comunicação usado pela aplicação, o comprometimento da rede poderá invalidar a autenticação. Em suma, a autenticação biométrica exige uma modelagem de ameaças detalhada e específica para a implementação.
A autenticação biométrica apresenta uma vulnerabilidade específica à cópia e à falsificação. Considere as impressões digitais. Nós as deixamos por toda parte, em praticamente todas as superfícies lisas que tocamos. Nós as deixamos em maçanetas, em restaurantes e no lixo. Coletar impressões digitais dessas superfícies é trivial; todos nós já vimos isso ser feito inúmeras vezes em séries policiais. Reproduzir impressões digitais também é trivial, usando desde uma impressora 3D até balas de goma.
Para outras formas de biometria, há uma disputa contínua entre pesquisadores de segurança que revelam como a biometria pode ser falsificada e fornecedores que desenvolvem tecnologias antifalsificação. Máscaras 3D já enganaram leitores faciais em aeroportos, embora essas máscaras possam ser detectadas por meio de verificações de vivacidade e outros métodos. Da mesma forma, invasores têm usado gravações de voz com síntese de voz por deepfake para burlar sistemas de reconhecimento de voz, embora talvez seja possível detectar essas falsificações por meio das distorções sutis introduzidas pelos dispositivos de gravação. Até mesmo imagens da íris podem ser reproduzidas e falsificadas com o uso de lentes de contato cosméticas ou de um olho artificial, embora várias técnicas antifalsificação — incluindo a identificação de diferenças na iluminação entre tecidos humanos e materiais sintéticos — possam detectar a fraude. Em suma, a segurança dos leitores biométricos dependerá do estado atual das tecnologias de falsificação e antifalsificação.
Mesmo que vivêssemos como eremitas e evitássemos tocar fisicamente em superfícies, invasores poderiam roubar nossos dados biométricos. Por meio de malware, engenharia social e exploração de vulnerabilidades não corrigidas, invasores já roubaram bilhões de nomes de usuário e senhas. Se conseguirem violar os bancos de dados que armazenam nossas senhas, certamente também conseguirão invadir os bancos de dados que armazenam nossos dados biométricos. E, depois que uma única violação expuser nossos dados biométricos, talvez não seja mais seguro usá-los para autenticação, dependendo da possibilidade de detectar sua falsificação.
O fato de não podermos alterar facilmente as características medidas pela biometria agrava o risco de segurança decorrente da cópia e da falsificação. Quando um invasor rouba uma senha, podemos alterá-la. Se um invasor roubar um token OPT ou um celular, podemos substituí-lo e redefinir a semente. No entanto, se um invasor obtiver acesso à nossa impressão digital, impressão palmar, imagem facial ou qualquer outra característica biológica e aprender a falsificá-las de forma eficaz, não poderemos alterar essas características físicas sem sofrer dores significativas.
Aprimorando a segurança da MFA
Embora a MFA represente uma melhoria em relação à autenticação de fator único baseada em senha, ela ainda é vulnerável, pelo menos nas formas de implementação mais populares atualmente. Portanto, em vez de considerar a MFA o fim da jornada de segurança, encare-a como um novo começo. As práticas recomendadas de segurança de aplicativos continuam tão relevantes quanto sempre foram, incluindo modelagem de ameaças, revisões de código, varredura de vulnerabilidades, testes de invasão e red teaming. Na modelagem de ameaças, analise cada aspecto do processo de autenticação e gerenciamento de sessões, considerando os diversos pontos de ataque, desde o repositório de identidades até a segurança física, de rede e de dados. Os ataques cibernéticos provavelmente terão como alvo o elo mais fraco. Em particular, as vulnerabilidades da MFA indicam algumas áreas importantes de preocupação que exigem mais atenção: mitigação da automação, proteção contra ataques à cadeia de suprimentos de JavaScript e consideração do contexto de risco.
Remova bots da sua rede
Os criminosos usam bots para ampliar vários ataques importantes contra a MFA, incluindo preenchimento de credenciais, proxies de phishing em tempo real e bombardeio de MFA. Portanto, combater os bots é essencial para proteger todas as formas de MFA.
Em ataques de preenchimento de credenciais, conforme definido pela OWASP, os criminosos obtêm credenciais roubadas em violações de dados anteriores, geralmente comprando-as na dark web, e testam essas credenciais nas páginas de login de outros aplicativos. Como bilhões de credenciais foram expostas em violações de dados, os criminosos maximizam seus ganhos automatizando os testes com bots, o que lhes permite testar um enorme volume de credenciais. O Federal Bureau of Investigation, a Securities and Exchange Commission e a Procuradoria-Geral de Nova York emitiram alertas sobre os riscos financeiros do preenchimento de credenciais, e a Assembleia Global de Privacidade, uma associação que reúne mais de 130 órgãos reguladores, declarou que o preenchimento de credenciais é uma ameaça global à privacidade.
Prevenir ataques de preenchimento de credenciais é tão importante para a autenticação multifator (MFA) quanto para a autenticação baseada apenas em senha. O objetivo da MFA é justamente usar mais de um fator, mas, se você não proteger o primeiro fator, restará apenas um. Quando um invasor descobre a senha de um usuário, a autenticação de dois fatores passa a ser uma autenticação de fator único, e a defesa em profundidade é comprometida.
Além disso, mitigar bots é fundamental, pois os criminosos os utilizam para atacar muito mais do que apenas senhas. Na verdade, os bots são uma ferramenta essencial para realizar ataques bem-sucedidos de proxy de phishing em tempo real, que são os mecanismos mais comuns para burlar a MFA. Sempre que um usuário é vítima de um e-mail de phishing que o induz a inserir suas credenciais em um site falso, o invasor precisa encaminhar essas credenciais ao aplicativo de destino para gerar a solicitação de MFA, seja ela por SMS, aplicativo autenticador ou biometria sofisticada. Para encaminhar a solicitação rapidamente e em grande escala, o criminoso precisa automatizar o processo, o que significa que a solicitação será encaminhada ao aplicativo por um bot. (Para uma visão geral dos serviços que usam bots para burlar senhas de uso único (OTP), consulte a publicação do Krebs on Security A ascensão dos bots de interceptação de senhas de uso único.) Isso significa que, ao impedir que bots indesejados enviem credenciais, uma organização pode comprometer a eficácia dos proxies de phishing em tempo real e proteger com mais eficiência tanto os fatores de autenticação por posse quanto os fatores de autenticação por inerência.
Outra maneira óbvia pela qual os criminosos usam bots para atacar a MFA é por meio do bombardeio de MFA. Nesse contexto, o bombardeio consiste em gerar um grande volume de tentativas de login para acionar tantas solicitações de autenticação que o usuário acabe aprovando uma delas, seja por engano ou apenas para se livrar do incômodo. Para gerar solicitações suficientes para muitos usuários e tornar o ataque lucrativo, o criminoso precisará automatizar o processo, o que, mais uma vez, significa que as tentativas de login que chegam ao seu site serão criadas por bots.
Como esses exemplos demonstram, praticamente qualquer ataque contra a MFA dependerá de bots para ser bem-sucedido em larga escala, o que significa que as organizações que implementam a MFA precisam levar a sério a mitigação de bots.
Infelizmente, muitas organizações não reconhecem a sofisticação dos bots nem a determinação dos criminosos em reconfigurá-los com grande frequência para evitar a detecção. Em vez disso, muitas empresas ainda dependem de técnicas de mitigação de bots que já não funcionam, incluindo CAPTCHA, listas de bloqueio de endereços IP e impressões digitais de cabeçalhos HTTP.
O CAPTCHA pouco contribui para a proteção contra bots, além de incomodar clientes reais, pois os bots conseguem contornar esses desafios usando serviços baratos de resolução de CAPTCHA que recorrem a aprendizado de máquina e fazendas de cliques. Basta fazer uma pesquisa na web por serviços de resolução de CAPTCHA e você encontrará pelo menos uma dúzia deles competindo em preço e velocidade. Para uma boa leitura sobre esses serviços, confira um artigo de Dan Woods, chefe de inteligência da F5, intitulado Eu fui um solucionador humano de CAPTCHA. Ainda mais interessante: o ChatGPT conseguiu contornar o CAPTCHA usando engenharia social para convencer uma pessoa a resolvê-lo em seu nome.
Para as organizações que dependem de listas de bloqueio de IP baseadas em WAF para mitigar bots, a tarefa é igualmente desafiadora. Há serviços disponíveis que oferecem aos criadores de bots dezenas de milhões de endereços IP residenciais destinados a contornar a detecção de bots. Esses serviços são anunciados como proxies residenciais rotativos; o bot envia solicitações HTTP ao proxy, assim como muitos navegadores corporativos enviam solicitações por meio de proxies de encaminhamento, e o serviço alterna continuamente o endereço IP público usado para enviar a solicitação ao site ou à API. No passado, os bots normalmente usavam proxies de data centers, muitas vezes de serviços de nuvem, que são bem conhecidos e fáceis de identificar. No entanto, esses novos serviços de proxy usam endereços IP residenciais da mesma região geográfica que seus clientes. Como cada endereço IP pode representar simultaneamente um bot ou um cliente legítimo devido ao uso de NAT pelos provedores de serviços de Internet (ISPs), não é viável bloquear todos esses endereços IP sem também impedir o acesso de seus clientes reais. (Para saber mais sobre como esses serviços obtêm esses endereços IP, consulte o artigo Seu telefone é meu proxy.)
Tentar detectar bots com base em diferenças na ordem dos cabeçalhos também não funciona mais, pois os bots já descobriram esse truque. De fato, vários projetos de código aberto, incluindo stealth-puppeteer e undetected-chromedriver, ajustam corretamente a ordem dos cabeçalhos, facilitando contornar os mecanismos de detecção ao usar essas populares estruturas de automação.
Atualmente, detectar bots avançados exige coleta avançada de sinais, monitoramento 24 horas por dia, 7 dias por semana, aprendizado de máquina e resposta rápida à reformulação dos bots. Sem uma solução dedicada de gerenciamento de bots — uma defesa capaz de detectar e responder rapidamente a essas reformulações —, os bots permitirão que criminosos ampliem de forma eficaz os ataques contra a autenticação multifator (MFA).
Proteja-se contra ataques à cadeia de suprimentos de JavaScript
Praticamente qualquer forma imaginável de MFA falhará diante do comprometimento de uma aplicação. Se o invasor inserir código em uma aplicação, não há mais o que fazer. O invasor pode capturar credenciais e outros dados de entrada de MFA, assumir o controle de sessões roubando identificadores de sessão ou exfiltrar dados diretamente da aplicação. Como as aplicações web modernas geralmente são compostas por mais de 20 arquivos JavaScript, em sua maioria provenientes de terceiros e não revisados pela equipe de segurança de aplicações da organização, o risco de comprometimento de aplicações por meio de ataques à cadeia de suprimentos de JavaScript é maior do que geralmente se imagina.
Os protocolos de segurança existentes no lado do cliente são estáticos demais para proteger os aplicativos web dinâmicos atuais. A Política de Segurança de Conteúdo (CSP) restringe as ações dos scripts de maneiras que poderiam impedir ataques à cadeia de suprimentos de JavaScript, mas a CSP poderia facilmente comprometer a funcionalidade de um site caso um fornecedor terceirizado atualizasse dinamicamente um script de forma incompatível com as restrições da CSP. Embora possa ser desejável que um script falhe ao violar uma política de segurança, essa falha em produção poderia afetar drasticamente os clientes. (Veja Por que a CSP está falhando?) A Integridade de Sub-recursos (SRI), outro protocolo de segurança web, é ainda menos viável para conteúdo dinâmico de terceiros, pois exige a atualização das tags de script com o valor de hash sempre que um script é alterado, o que não é possível quando as alterações ocorrem sem aviso prévio. Na verdade, a SRI foi criada para impedir justamente o tipo de atualização de script do qual depende a maioria dos aplicativos modernos.
Sem controles claros para eliminar as vulnerabilidades da cadeia de suprimentos de JavaScript, as organizações precisam ser criativas para encontrar maneiras de, pelo menos, monitorar o risco. As organizações podem documentar melhor os scripts em seus sites e classificá-los por nível de risco com base na origem e na frequência das alterações. Os scripts adicionados por meio de gerenciadores de tags devem passar por revisões periódicas para avaliação de riscos. É possível utilizar ferramentas de monitoramento que acompanham o comportamento dos scripts por meio de monitoramento sintético, CSP no modo de geração de relatórios ou agentes baseados em JavaScript executados no navegador.
Como os scripts de terceiros mudam com muita frequência e sem a oportunidade de uma análise de segurança, é importante que as organizações monitorem continuamente seus aplicativos em busca de comportamentos suspeitos, como scripts que leem dados confidenciais e os exfiltram para domínios não confiáveis. Sem esse monitoramento de ataques à cadeia de suprimentos do JavaScript, nenhuma forma de MFA manterá os usuários seguros.
Reconheça usuários legítimos conhecidos e questione comportamentos suspeitos
O objetivo da MFA deve ser aumentar a segurança, e não sobrecarregar os clientes com medidas de segurança meramente performáticas e sem propósito. Ao adaptar os requisitos de login ao risco contextual, as organizações podem evitar penalizar continuamente clientes recorrentes valiosos com exigências de MFA e, em vez disso, facilitar sua jornada com sessões de usuário prolongadas, oferecendo uma experiência personalizada e sem esforço, assim como a TSA agiliza o processo para viajantes confiáveis com o TSA PreCheck.
O risco contextual tem muitas dimensões:
- Geografia: com base nos endereços IP, o usuário está fazendo login a partir de sua localização habitual?
- ASN (Número de Sistema Autônomo): Com base no endereço IP, o usuário está fazendo login pelo mesmo provedor de internet de sempre, talvez associado à sua casa, ao trabalho ou ao café que costuma frequentar?
- Dispositivo: o usuário está fazendo login pelo mesmo dispositivo de sempre?
- Horário/dia: o usuário está fazendo login no mesmo horário do dia ou dia da semana de costume, talvez pela manhã para realizar operações bancárias e à noite para jogar?
- Comportamento: o usuário está digitando na mesma velocidade de sempre, movimentando o mouse seguindo os mesmos padrões e copiando e colando de maneiras semelhantes?
- Funcionalidade: o usuário está utilizando as mesmas funcionalidades de sempre?
Se o usuário tiver um histórico comprovado de bom comportamento e acessar um site do mesmo local, no mesmo dispositivo, no mesmo horário do dia, com um comportamento semelhante e usando as funcionalidades habituais, talvez nem seja necessário exigir que ele faça login. Em vez disso, é possível realizar uma autenticação silenciosa contínua para estender a sessão e proporcionar mais conveniência ao usuário. Se o contexto se desviar do padrão, indicando um risco maior, você poderá adicionar políticas adaptativas ao seu aplicativo para aumentar gradualmente os requisitos de segurança: exigir login com senha, exigir autenticação de dois fatores (2FA), sinalizar uma conta para análise, alertar o usuário por SMS ou e-mail sobre o login ou bloquear a conta para obrigar o usuário a entrar em contato com o suporte.
Com muita frequência, a duração da sessão é definida como um período fixo, independentemente do risco contextual, permitindo que qualquer pessoa com um token de sessão continue acessando os dados para os quais o usuário tem autorização, sem considerar o risco de sequestro de sessão. Uma abordagem mais segura é seguir os princípios de confiança zero: presumir que houve uma violação e monitorar continuamente. Se o contexto mudar durante uma sessão, encerre-a antecipadamente e exija autenticação adicional, com um nível de rigor proporcional à magnitude da mudança no contexto e à sensibilidade dos dados.
Conclusão
Seguindo o clichê de que a segurança é uma jornada, a MFA criou várias bifurcações no caminho, oferecendo opções adicionais que, quando implementadas corretamente, reforçam a segurança de maneira significativa. No entanto, nenhuma forma de MFA — independentemente da quantidade de fatores, da qualidade da implementação ou do custo — nos permite pular a jornada e chegar diretamente ao destino. Certamente veremos mais declarações sobre a morte das senhas e mais alarde de que novas técnicas de MFA tornarão a autenticação segura de uma vez por todas, mas ainda haverá maneiras de invasores determinados contornarem as novas tecnologias.
Em sua jornada para proteger melhor aplicações críticas, você conta com a parceria da F5. Os Serviços de Nuvem Distribuída da F5 incluem o Bot Defense para mitigação de bots, o Client-Side Defense para monitorar ataques à cadeia de suprimentos de JavaScript e o Authentication Intelligence para reconhecer usuários recorrentes e quantificar o risco contextual. Com o suporte da F5, você pode garantir a segurança da MFA e, ao mesmo tempo, otimizar a experiência do cliente. Saiba mais sobre os Serviços do F5 Distributed Cloud e cadastre-se para falar com nossa equipe.
PUBLICADO EM 26 DE JUNHO DE 2023