Resolução para aquisição de conta: Por que o MFA é apenas um primeiro passo
A autenticação multifator (MFA) não resolve a ameaça de invasão de conta. Isso acrescenta obstáculos, sim, mas invasores determinados descobriram maneiras engenhosas de contornar todos os fatores de autenticação disponíveis. Em vez de resolver a autenticação, devemos pensar na MFA como uma ampliação da superfície de ataque: cada fator introduz um novo sistema de dependências, novas fontes de bugs e vulnerabilidades e novas oportunidades para engenharia social. Infelizmente, muitas organizações de segurança veem o MFA como antigamente víamos o perímetro da rede, como um baluarte que resolve uma ampla gama de ataques. A falácia do perímetro seguro, exposta pelos proponentes da segurança de confiança zero , permitiu que invasores explorassem vulnerabilidades dentro das redes para se moverem lateralmente e aumentarem privilégios. Da mesma forma, a falácia que o MFA resolve para a aquisição de contas impede que as organizações de segurança reconheçam as fraquezas do MFA e as muitas vulnerabilidades restantes do sistema que expõem as contas de usuários à aquisição criminosa. Ao analisar como os invasores ignoram o MFA, este whitepaper demonstra que o MFA torna certas outras medidas de segurança ainda mais importantes, como mitigação de bots, proteções da cadeia de suprimentos de JavaScript e monitoramento de risco contextual, técnicas que reforçam as vantagens de segurança do MFA ao mesmo tempo que reduzem o atrito que ele impõe aos usuários.
Os impulsionadores do MFA
Apesar de suas fraquezas, o MFA veio para ficar e por um bom motivo: a autenticação somente por senha claramente falhou.
Nós, humanos, simplesmente não conseguimos lembrar de longas sequências aleatórias de caracteres. Como resultado, pegamos atalhos; escolhemos senhas fáceis de lembrar e previsíveis, reutilizamos senhas em diferentes aplicativos e rabiscamos senhas em post-its. Embora as empresas mitiguem esse risco impondo requisitos de comprimento e complexidade de senhas, há limites para a memória humana; mesmo diante dos requisitos de complexidade, encontramos maneiras de ser previsíveis: colocando apenas a primeira letra em maiúscula, inserindo caracteres especiais no lugar de caracteres alfanuméricos de aparência semelhante ($ para S), adicionando dígitos adivinháveis, como 123, no final de uma senha. (Veja os resultados da pesquisa sobre previsibilidade de senhas .)
Nós, humanos, também compartilhamos falhas que nos tornam vulneráveis à engenharia social. Nós revelamos nossas senhas quando invasores abusam de nossa confiança, desejo de conformidade, respeito pela autoridade e disposição para ajudar. Acontece que às vezes as pessoas revelam suas senhas se você simplesmente perguntar, o que você pode assistir neste vídeo divertido do Jimmy Kimmel Live .
Dadas essas fraquezas da autenticação baseada em senha, agências governamentais e associações do setor estão impulsionando a adoção do MFA. Em maio de 2021, o presidente Biden emitiu uma ordem executiva exigindo que as agências federais adotem o MFA em 180 dias, e a Agência de Segurança Cibernética e de Infraestrutura (CISA) está promovendo o MFA para empresas privadas. O Payment Card Industry Security Standards Council está exigindo com seu Data Security Standard v4.0 que as organizações implementem o MFA para todo acesso aos dados do titular do cartão de crédito até 31 de março de 2025.
Com as vantagens claras do MFA sobre a autenticação somente por senha impulsionando sua adoção, os profissionais de segurança precisam prestar cada vez mais atenção às desvantagens do MFA, à forma como ele expande a superfície de ataque e cria novas vulnerabilidades que permitem que invasores ignorem os controles de autenticação.
A superfície de ataque expandida do MFA
MFA é definido como a aplicação de dois ou mais fatores no processo de autenticação. Por fator, queremos dizer uma maneira de provar 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ê tem, como um dispositivo móvel, cartão inteligente, token de hardware ou unidade USB
- Inerência: algo que você é, conforme determinado por biometria, como impressões digitais, escaneamentos faciais e padrões de íris
Há inúmeras maneiras de implementar o MFA, e muitas delas abrem novas superfícies de ataque ou deixam os aplicativos expostos às mesmas vulnerabilidades que caracterizam a autenticação somente por senha.
MFA baseado em SMS
Há inúmeras maneiras de implementar o MFA, e muitas delas abrem novas superfícies de ataque ou deixam os aplicativos expostos às mesmas vulnerabilidades que caracterizam a autenticação somente por senha.
A implementação mais difundida do 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 senha, acionando o aplicativo para enviar a mensagem de texto. O usuário então visualiza o OTP e o insere no aplicativo, concluindo a autenticação e gerando um token de sessão que será válido por um período definido.
Vulnerabilidades restantes da autenticação baseada em SMS
A implementação do fator de posse via SMS não consegue fechar diversas vulnerabilidades importantes. Como o usuário insere o OTP e a senha no aplicativo e como o aplicativo envia o OTP de volta ao servidor pelo mesmo canal de comunicação usado pelo aplicativo, um invasor que tenha comprometido o aplicativo, o dispositivo ou a rede poderá acessar a senha, o OTP e o token de sessão.
Atacando o ponto final
Usando muitas técnicas bem estabelecidas e ainda predominantes, os invasores assumem o controle dos dispositivos infectando-os com malware, resultando em um ataque do tipo man-in-the-browser (MitB). Executar código no navegador permite que invasores obtenham a senha e o OTP que eles podem autenticar 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 ignorar a autenticação e acessar a conta de um usuário. (Para tendências recentes em malware infectando endpoints, veja o relatório do F5 Labs sobre o BlackGuard Infostealer .)
Comprometendo o aplicativo
Ao infectar um aplicativo, os invasores podem assumir o controle das contas de 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 compõem o aplicativo, uma tática conhecida como ataque do lado da oferta.
Em um ataque à cadeia de suprimentos de software, o invasor normalmente tem como alvo um fornecedor terceirizado confiável ou um repositório de código aberto que fornece componentes de software (bibliotecas, estruturas, serviços) para a organização visada. O invasor injeta 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 impor práticas de codificação seguras.
Aplicativos 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 às páginas dinamicamente 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 de uma organização. Se um invasor puder comprometer qualquer um desses scripts, ele obterá controle total do aplicativo, o que significa que poderá ler a entrada do usuário, acessar dados na memória do navegador ou sequestrar a jornada do usuário para direcioná-lo a um aplicativo malicioso sem aviso prévio.
Esses ataques à cadeia de suprimentos , como o Magecart, causaram violações de segurança de centenas de milhares de credenciais. Muito parecidos com os ataques MitB, esses ataques à cadeia de suprimentos funcionam contra qualquer solução MFA na qual o token que comprova a posse é inserido no aplicativo, o que é típico da maioria das implementações que usam OTPs. Como o código malicioso lê a entrada do usuário, ele pode roubar tanto a senha estática quanto o OTP, bem como qualquer outra informação pessoal ou financeira coletada pelo aplicativo.
Ouvindo na rede
Como com a 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 permanece vulnerável a ataques do tipo man-in-the-middle (MitM) usando vetores de ataque típicos, como envenenamento de DNS, envenenamento de ARP e pontos de acesso sem fio desonestos.
Engenharia social
Um dos ataques mais comuns e bem-sucedidos contra MFA baseado em SMS usa engenharia social para estabelecer um ataque MitM por meio de proxies de phishing em tempo real (RTPP).
Neste ataque, o fraudador usa e-mails de phishing para enganar um usuário e fazê-lo visitar um site controlado pelo invasor, onde o usuário insere devidamente suas credenciais. Até agora, essa tática é idêntica a um ataque de phishing para roubo de credenciais, mas contornar o MFA requer uma etapa extra. Quando o usuário insere seu nome de usuário e senha no aplicativo, o invasor encaminha essas credenciais para o aplicativo de destino, que então emite uma segunda solicitação de fator ao usuário. É muito provável que o usuário aprove a solicitação porque ele acha que está autenticando em um aplicativo confiável; o usuário clica no botão aprovar ou insere obedientemente o token no aplicativo. Em ambos os casos, o invasor obtém acesso ao aplicativo. (Para uma demonstração do ataque, veja 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 RTPP podem ter sucesso em larga escala. (Para mais dados sobre o crescimento de proxies de phishing em tempo real, consulte o Relatório de Phishing e Fraude do F5 Labs .)
Novas vulnerabilidades de autenticação baseada em SMS
Além de não fechar muitas das vulnerabilidades existentes na autenticação somente por senha, usar SMS como um segundo fator expõe um aplicativo a vetores de ataque adicionais.
Roubo de 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 telefone pode obter acesso a uma OTP exibida em uma notificação, mesmo com o telefone bloqueado. Muitas vítimas de roubo de telefone acabaram perdendo fundos em suas contas bancárias.
Troca de SIM (Módulo de Identidade do Assinante)
Os criminosos não precisam ter posse física de um telefone para obter acesso às OTPs enviadas por mensagem de texto. A troca de SIM , também conhecida como sequestro de SIM ou portabilidade de SIM, permite que invasores ignorem a autenticação baseada em SMS, que é a forma mais popular de MFA usada em aplicativos voltados para o cliente. Em um ataque de troca de SIM, o fraudador explora a capacidade dos provedores de serviços de telecomunicações de transferir um número de telefone para outro dispositivo, um recurso que é benéfico sempre que um telefone é perdido ou roubado.
O fraudador começa coletando informações pessoais sobre a vítima por meio de pesquisa 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 SIM do fraudador. Ou o invasor pode invadir a conta do usuário com o provedor de serviços usando preenchimento de credenciais, adivinhação de força bruta ou um ataque de dicionário.
Com o controle do serviço telefônico da vítima, o fraudador receberá todos os SMS e chamadas de voz destinados à vítima. Isso permite que o fraudador intercepte quaisquer tokens de segurança enviados via texto.
Dispositivos de token de hardware
Dispositivos de token de hardware são dispositivos especializados, geralmente bem pequenos, que exibem um OTP, que o usuário digita em um aplicativo para autenticação. Esses dispositivos fornecem um meio de comprovar a posse sem exigir comunicação do aplicativo com o usuário, o que remove uma das principais vulnerabilidades da autenticação baseada em SMS.
Em vez de depender do envio do OTP ao usuário para cada login, o dispositivo gera um fluxo de OTPs com base em um valor inicial e um algoritmo. O valor inicial é compartilhado entre o dispositivo e o serviço de autenticação na configuração. O valor inicial é aumentado com um contador que é incrementado com um evento, como uma solicitação de login, ou uma duração de tempo, como 60 segundos . Nós nos referimos a eles respectivamente como OTP baseado em eventos (EOTP) e OTP baseado em tempo (TOTP). EOTP e TOTP são tipos de OTP baseado em hash (HOTP) porque o contador e a semente são passados juntos para uma função hash que gera uma sequência aparentemente aleatória de dígitos que, quando implementada corretamente, não revela um padrão previsível.
Ao evitar a necessidade de enviar o OTP via texto, os tokens de hardware tornam impossível capturar o OTP antes que ele chegue ao usuário por meios como troca de SIM. No entanto, como o usuário precisa inserir o OTP no aplicativo, que o transporta para o serviço de autenticação usando o mesmo canal de comunicação da senha, a maioria das outras vulnerabilidades da autenticação baseada em SMS permanecem. O invasor pode obter acesso à senha e ao OTP comprometendo o endpoint, a rede ou o aplicativo das mesmas maneiras que faria com OTPs entregues via texto.
O ataque mais comum contra autenticação baseada em SMS, proxies de phishing em tempo real, funciona igualmente bem para OTPs gerados em dispositivos de hardware, já que o usuário é enganado e digita o OTP no site falso, independentemente de o OTP aparecer em um telefone ou dispositivo especializado.
Embora os dispositivos de hardware eliminem a possibilidade de invasores capturarem o OTP em trânsito para o usuário, os dispositivos dependem de valores iniciais que podem ser comprometidos. Os invasores podem acessar o valor inicial obtendo acesso físico aos dispositivos (veja a menção de um ataque de microscópio eletrônico em Mais de 12 maneiras de hackear o MFA ), comprometendo o banco de dados usado pelo serviço de autenticação ou interceptando o processo de configuração no qual o valor inicial é acordado entre o dispositivo e o serviço de autenticação.
Aplicativos autenticadores
Os aplicativos autenticadores podem funcionar como tokens de hardware, gerando um fluxo de OTPs com base em uma semente e algoritmo iniciais, evitando a necessidade de comunicar a semente por um canal vulnerável, mas também podem ir um passo além ao utilizar um canal alternativo para comunicar o OTP. Nesse cenário, após a verificação bem-sucedida de um nome de usuário e senha, o serviço de autenticação envia uma notificação push ao aplicativo autenticador, que solicita que o usuário aprove a solicitação. Após a aprovação, o aplicativo autenticador envia o OTP diretamente para o serviço de autenticação sem exigir que o usuário o 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.
Usar um canal de comunicação alternativo significa que um invasor não pode acessar o OTP comprometendo o aplicativo, já que o OTP nunca é inserido no aplicativo. Também é mais difícil coletar a senha e o OTP comprometendo a conexão de rede porque a senha e o OTP são entregues por canais seguros distintos. No entanto, comprometer o endpoint pode permitir que um invasor acesse a senha e o OTP se o aplicativo em si e o aplicativo autenticador estiverem em execução no mesmo dispositivo. (Veja o relatório do F5 Labs sobre malware 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 é enganado e induzido a digitar seu nome de usuário e senha em um site falso por meio de uma mensagem de texto de phishing. Ao inserir suas credenciais, o aplicativo acionará uma solicitação ao aplicativo autenticador. Como o usuário acredita que está no processo de login em um aplicativo confiável, é provável que o usuário aprove a solicitação, o que conclui a autenticação. Embora o invasor nunca veja o OTP, o proxy do invasor agora terá controle sobre uma sessão autenticada, dando ao invasor acesso à conta do usuário. (Para mais informações sobre RTPP e autenticação de notificação push, veja este artigo sobre plataformas de phishing no Hacker News.)
Além disso, a facilidade de uso de aplicativos autenticadores criou outro meio pelo qual os invasores podem derrotar o MFA por meio da engenharia social. Em ataques de bombardeio ou fadiga de MFA, o invasor engana o alvo para que ele forneça seu código de autenticação enviando várias solicitações fraudulentas do código. O invasor normalmente usa ferramentas automatizadas para gerar um grande número de solicitações, sobrecarregando a vítima com um número excessivo de notificações ou mensagens solicitando que ela insira seu código de autenticação.
Embora o bombardeio de MFA possa induzir um usuário a inserir um OTP a partir de uma mensagem SMS ou dispositivo de hardware, ele é particularmente eficaz contra aplicativos autenticadores porque o usuário pode facilmente fazer com que o fluxo de solicitações pare com o toque de um botão.
Autenticação biométrica
Há ainda mais maneiras de implementar autenticação biométrica do que a autenticação baseada em posse. Não só existem vários métodos para acionar a solicitação de autenticação e comunicar esses dados de volta ao serviço de autenticação, mas também há muitas formas de biometria, desde impressões digitais até escaneamentos de íris. O hardware necessário para executar a digitalização pode estar incorporado ao dispositivo que executa o aplicativo, como uma câmera com leitor de impressão digital em um laptop, ou exigir hardware separado. O leitor biométrico pode ser controlado pelo sistema operacional ou por um aplicativo especializado. Dadas essas variações na implementação, é difícil modelar todas as vulnerabilidades. No entanto, é importante perceber que, apesar da reputação da autenticação biométrica de maior segurança, ainda existem vulnerabilidades muito claras na autenticação biométrica.
De fato, um dos métodos mais populares para contornar o fator posse, os proxies de phishing em tempo real, também podem ser usados para contornar a biometria. Quando o usuário efetua login em um aplicativo controlado pelo invasor, pensando que é um aplicativo confiável, esse aplicativo usará as credenciais para efetuar login no aplicativo em nome do usuário, acionando a solicitação de autenticação biométrica. Contanto que o usuário acredite que está se autenticando no aplicativo real, ele 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 da web.)
Se a autenticação biométrica pode ser anulada por meio do comprometimento do endpoint, do aplicativo ou da rede depende da implementação específica. Na medida em que o sistema de autenticação biométrica é executado no mesmo dispositivo que o aplicativo, comprometer o endpoint pode interromper a autenticação. Na medida em que o aplicativo gerencia o processo de autenticação biométrica, comprometer o aplicativo pode interromper a autenticação. E na medida em que a autenticação biométrica é enviada pelo mesmo canal de comunicação usado pelo aplicativo, comprometer a rede pode quebrar a autenticação. Em resumo, a autenticação biométrica requer modelagem detalhada de ameaças específica para a implementação.
A autenticação biométrica abre a clara vulnerabilidade de cópia e falsificação. Considere as impressões digitais. Nós os deixamos espalhados por todo lugar, em quase todas as superfícies lisas que tocamos. Nós os deixamos em maçanetas, em restaurantes, no lixo. Coletar impressões digitais dessas superfícies é trivial; todos nós já vimos isso ser feito inúmeras vezes em dramas policiais. Replicar impressões digitais também é trivial usando qualquer coisa, desde uma impressora 3D até ursinhos de goma .
Para outras formas de biometria, há uma disputa em andamento entre pesquisadores de segurança revelando como a biometria pode ser falsificada e fornecedores desenvolvendo tecnologia antispoofing. Máscaras 3D enganaram leitores faciais em aeroportos, embora essas máscaras possam ser detectadas por meio de verificações de atividade e outros métodos. Da mesma forma, os invasores usaram gravações de voz com síntese de voz deepfake para contornar sistemas de reconhecimento de voz, embora seja possível detectar essas falsificações por meio de distorções sutis adicionadas por dispositivos de gravação. Até mesmo imagens de íris podem ser reproduzidas e falsificadas usando lentes de contato cosméticas ou um olho artificial, embora várias técnicas anti-spoofing — incluindo distinções de iluminação entre tecido humano e materiais sintéticos — possam detectar a falsificação. Em suma, a segurança dos leitores biométricos dependerá do estado atual da tecnologia de spoofing e anti-spoofing.
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 roubaram bilhões de nomes de usuários e senhas. Se os invasores conseguirem invadir os bancos de dados que armazenam nossas senhas, eles certamente invadirão os bancos de dados que armazenam nossas informações biométricas. E quando uma única violação expõe nossa biometria, podemos não estar seguros ao usá-la para autenticação, dependendo se sua falsificação pode ser detectada.
O que agrava o risco de segurança da cópia e da falsificação é o fato de que não podemos alterar facilmente as características que a biometria mede. Quando um invasor rouba uma senha, podemos alterá-la. Se um invasor roubar um dongle 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 como falsificá-las de forma eficaz, não poderemos alterar essas características físicas sem sofrer uma dor significativa.
Melhorando a segurança do MFA
Embora o MFA seja uma melhoria em relação à autenticação de fator único baseada em senha, ele ainda é vulnerável, pelo menos nas formas de implementação atualmente populares. Então, em vez de pensar na MFA como o fim da jornada de segurança, pense nela como um novo começo. As melhores práticas de segurança de aplicativos continuam tão relevantes quanto sempre, incluindo modelagem de ameaças, revisões de código, varredura de vulnerabilidades, testes de penetração e red teaming. Na modelagem de ameaças, analise cada aspecto do processo de autenticação e gerenciamento de sessão, considerando os muitos pontos de ataque, desde o armazenamento de identidade 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 do MFA apontam para algumas áreas-chave 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 contam com bots para escalar vários ataques importantes contra MFA, incluindo preenchimento de credenciais, proxies de phishing em tempo real e bombardeio de MFA, o que significa que mitigar 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 de violações anteriores, normalmente por meio de compras na dark web, e testam essas credenciais em relação aos logins de outros aplicativos. Como bilhões de credenciais foram expostas por meio de violações, os criminosos maximizam seus retornos automatizando os testes com bots para que possam testar um grande número de credenciais. O Federal Bureau of Investigation , a Securities and Exchange Commission e o Procurador-Geral de Nova York emitiram alertas sobre os riscos financeiros do credential stuffing, e a Global Privacy Assembly , uma associação de mais de 130 agências reguladoras, declarou o credential stuffing uma ameaça global à privacidade.
Evitar o preenchimento de credenciais é tão importante para a MFA quanto para a autenticação somente por senha. O objetivo do MFA é usar mais de um fator, mas se você não proteger o primeiro fator, ficará com apenas um fator. Depois que um invasor descobre a senha de um usuário, a autenticação de dois fatores se torna autenticação de fator único e a defesa em profundidade é perdida.
Além disso, mitigar bots é fundamental porque os criminosos usam bots para atacar mais do que apenas senhas. De fato, os bots são uma ferramenta essencial para lançar ataques de proxy de phishing em tempo real, que são os mecanismos mais comuns para derrotar o MFA. Sempre que um usuário for vítima de um e-mail de phishing que o induz a inserir suas credenciais em um site falso, o invasor precisará encaminhar essas credenciais ao aplicativo de destino para gerar a solicitação de MFA, independentemente se essa solicitação envolve SMS, um aplicativo autenticador ou biometria sofisticada. Para encaminhar a solicitação de forma rápida e em larga escala, o criminoso precisará 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 ignorar o OTP, consulte a postagem de Krebs on Security: The Rise of One-Time Password Interception Bots. ) Isso significa que, ao impedir que bots indesejados enviem credenciais, uma organização pode prejudicar a eficácia dos proxies de phishing em tempo real e proteger de forma mais eficaz os fatores de autenticação de posse e de inerência.
Outra maneira óbvia pela qual criminosos usam bots para atacar o MFA é por meio do bombardeio do MFA. Bombing neste contexto implica gerar solicitações de login em grandes volumes para disparar tantas solicitações de autenticação que o usuário atenderá por engano ou apenas para acabar com o incômodo. Para gerar um número grande o suficiente de solicitações para muitos usuários, de modo que o ataque se torne lucrativo, o criminoso precisará automatizar, o que novamente significa que as solicitações de login que chegarem ao seu site serão criadas por bots.
Como esses exemplos ilustram, quase qualquer ataque contra MFA dependerá de bots para ter sucesso em larga escala, o que significa que as organizações que implementam MFA precisam levar a mitigação de bots a sério.
Infelizmente, muitas organizações não conseguem reconhecer a sofisticação dos bots e a determinação dos criminosos em reequipar os bots com grande frequência para contornar a detecção. Em vez disso, muitas empresas dependem de técnicas de mitigação de bots que não funcionam mais, incluindo CAPTCHA, listas de negação de endereços IP e impressões digitais de cabeçalho HTTP.
O CAPTCHA faz pouco pela proteção de bots além de irritar clientes reais, porque os bots podem contornar esses quebra-cabeças usando serviços de resolução de CAPTCHA de baixo custo que dependem de aprendizado de máquina e fazendas de cliques. Basta fazer uma pesquisa na internet sobre 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, leia um artigo de Dan Woods, chefe de inteligência do F5, intitulado Eu era um solucionador de CAPTCHA humano . Ainda mais interessante, o ChatGPT conseguiu contornar o CAPTCHA por meio de engenharia social, fazendo com que uma pessoa resolvesse o CAPTCHA em seu nome.
Para organizações que dependem de listas de negação de IP baseadas em WAF para mitigar bots, a tarefa é igualmente assustadora. Existem 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 para o proxy, assim como muitos navegadores corporativos enviam solicitações por meio de proxies de encaminhamento, e o serviço rotaciona continuamente o endereço IP público usado para enviar a solicitação para o site ou API. No passado, os bots normalmente usavam proxies de data center, geralmente 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 área geográfica dos seus clientes. Como cada endereço IP pode representar simultaneamente um bot ou um cliente válido devido ao NAT dos Provedores de Serviços de Internet (ISPs), não é possível bloquear todos esses endereços IP sem afastar seus clientes reais. (Para pesquisar sobre como esses serviços obtêm esses endereços IP, consulte o artigo Seu telefone é meu proxy .)
Tentar detectar bots com base nas diferenças na ordem dos cabeçalhos também não funciona mais porque os bots descobriram o truque. De fato, vários projetos de código aberto, incluindo stealth-puppeteer e undetected-chromedriver , fazem o trabalho de obter a ordem correta dos cabeçalhos, facilitando a eliminação de detecções ao usar essas estruturas de automação populares.
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 reação rápida à reformulação dos bots. Sem uma solução de gerenciamento de bots dedicada, uma defesa que detecte e reaja rapidamente à reformulação, os bots permitirão que os criminosos dimensionem efetivamente os ataques contra o MFA.
Proteja-se contra ataques à cadeia de suprimentos de JavaScript
Quase qualquer forma de MFA imaginável falhará diante do comprometimento do aplicativo. Se o invasor inserir código em um aplicativo, o jogo acaba. O invasor pode capturar credenciais e outras entradas de MFA, assumir o controle de sessões roubando identificadores de sessão ou exfiltrar dados diretamente do aplicativo. Como os aplicativos da Web modernos geralmente são compostos de mais de 20 arquivos JavaScript , a maioria de terceiros e não revisados pela equipe de segurança de aplicativos da organização, o risco de comprometimento do aplicativo por meio de ataques à cadeia de suprimentos de JavaScript é maior do que geralmente se imagina.
Os protocolos de segurança existentes do lado do cliente são muito estáticos para defender os aplicativos web dinâmicos de hoje. A Política de Segurança de Conteúdo (CSP) restringe as ações de scripts de maneiras que podem impedir ataques à cadeia de suprimentos de JavaScript, mas a CSP pode facilmente interromper a funcionalidade de um site se um fornecedor terceirizado atualizar um script dinamicamente de maneiras contrárias às restrições da CSP. Embora você possa querer que um script falhe se ele violar uma política de segurança, essa falha na produção pode impactar drasticamente os clientes. (Veja Por que o CSP está falhando? ) O Sub-resource Integrity (SRI), outro protocolo de segurança da web, é ainda menos viável para conteúdo dinâmico de terceiros, pois exige a atualização de tags de script com valor de hash toda vez que um script é alterado, o que não é possível se as alterações ocorrerem sem aviso prévio. Na verdade, o SRI tem como objetivo evitar o tipo de atualização de script do qual a maioria dos aplicativos modernos depende.
Sem controles claros para eliminar vulnerabilidades da cadeia de suprimentos do JavaScript, as organizações precisam ser criativas para encontrar meios de pelo menos monitorar o risco. As organizações podem documentar melhor os scripts em seus sites e classificá-los quanto ao risco com base na origem e na frequência da alteração. Scripts adicionados por meio de gerenciadores de tags devem passar por revisões regulares para avaliar riscos. É possível obter ferramentas de monitoramento que rastreiam o comportamento de scripts usando monitoramento sintético, CSP em modo de relatório ou agentes baseados em JavaScript em execução no navegador.
Como os scripts de terceiros mudam com tanta frequência e sem uma oportunidade de revisão de segurança, é importante que as organizações monitorem continuamente seus aplicativos em busca de comportamento suspeito, como scripts lendo dados confidenciais e os exfiltrando para domínios não confiáveis. Sem esse monitoramento de ataques à cadeia de suprimentos de JavaScript, nenhuma forma de MFA manterá os usuários seguros.
Reconhecer bons usuários conhecidos e desafiar comportamentos suspeitos
O objetivo do MFA deve ser melhorar a segurança em vez de sobrecarregar os clientes com procedimentos de segurança inúteis. Ao adaptar os requisitos de login ao risco contextual, as organizações podem evitar punir continuamente clientes valiosos que retornam com requisitos de MFA e, em vez disso, facilitar sua jornada com sessões de usuário estendidas, recebendo-os com uma experiência personalizada e sem esforço, como a TSA agiliza 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á efetuando login em seu local habitual?
- ASN (Número do Sistema Autônomo): Com base no endereço IP, o usuário está efetuando login no mesmo ISP de sempre, talvez associado à sua casa, trabalho ou café favorito?
- Dispositivo: O usuário está efetuando login no mesmo dispositivo de sempre?
- Hora/dia: O usuário está efetuando login no mesmo horário do dia ou dia da semana como de costume, talvez de manhã para fazer transações bancárias e à noite para jogar?
- Comportamento: O usuário está digitando na mesma velocidade de sempre, movendo o mouse nos mesmos padrões, copiando e colando de maneiras semelhantes?
- Funcionalidade: O usuário está utilizando a mesma funcionalidade de sempre?
Se o usuário tiver um histórico comprovado de bom comportamento e acessar um site do mesmo lugar, mesmo dispositivo, mesma hora do dia, com comportamento semelhante, usando sua funcionalidade usual, pode nem ser necessário exigir que o usuário faça login; em vez disso, conduza uma autenticação silenciosa contínua para estender a sessão para a conveniência do usuário. Se o contexto se desviar do normal, indicando maior risco, você tem a capacidade de adicionar políticas adaptáveis ao seu aplicativo para aumentar as demandas de segurança em etapas medidas: exigindo um login com senha, exigindo 2FA, sinalizando uma conta para revisão, alertando o usuário por SMS ou e-mail sobre o login ou bloqueando a conta para forçar o usuário a entrar em contato com o suporte.
Muitas vezes, a duração da sessão é um período definido, independentemente do risco contextual, permitindo que qualquer pessoa com um token de sessão continue acessando dados para os quais o usuário está autorizado, ignorando o risco de sequestro de sessão. Uma abordagem mais segura é seguir os princípios de confiança zero: assumir a violação e monitorar continuamente. Se o contexto mudar dentro de uma sessão, encerre a sessão mais cedo e exija autenticação adicional, com o rigor dependendo de quanto o contexto mudou e da sensibilidade dos dados.
Conclusão
Seguindo o clichê de que a segurança é uma jornada, a MFA criou diversas bifurcações no caminho, fornecendo opções adicionais que, quando implementadas corretamente, melhoram a segurança de maneiras significativas. No entanto, nenhuma forma de MFA, não importa quantos fatores, quão bem implementada ou quão custosa, nos permite pular a jornada para chegar ao destino. Certamente veremos mais proclamações sobre a morte das senhas, mais propaganda enganosa 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 aplicativos críticos, você tem um parceiro na F5. Os serviços de nuvem distribuída da F5 incluem Bot Defense para mitigação de bots, Client-Side Defense para monitorar ataques à cadeia de suprimentos de JavaScript e Authentication Intelligence para reconhecer usuários recorrentes e quantificar o risco contextual. Com o suporte da F5, você pode garantir a segurança do MFA e, ao mesmo tempo, otimizar a experiência do cliente. Saiba mais sobre os F5 Distributed Cloud Services e inscreva-se para falar com nossa equipe.
Conecte-se com F5
