Usando MITM para contornar a proteção resistente a phishing FIDO2

FIDO2 é um termo de grupo de autenticação moderno para autenticação sem senha. A Fast Identity Online (FIDO) Alliance o desenvolveu para substituir o uso de senhas conhecidas herdadas e fornecer um método seguro de autenticação usando uma chave física ou incorporada.  

O FIDO2 é mais conhecido por proteger as pessoas contra ataques man-in-the-middle (MITM), phishing e sequestro de sessão.  

Neste artigo, apresentarei minha pesquisa descobrindo como usar ataques MITM para contornar o FIDO2. Primeiro, descreverei um fluxo completo de autenticação WebAuthn e, em seguida, examinarei as proteções do FIDO2. Em seguida, abordarei técnicas de ataque famosas e fornecerei casos de uso da vida real. Por último, discutirei as mitigações e o que você pode fazer para proteger sua empresa.   

Mas primeiro, algumas informações básicas

O fluxo de autenticação FIDO2 consiste na especificação da API WebAuthn para uma parte confiável do cliente (RP) – que é a comunicação do aplicativo em nuvem – e no protocolo Cliente para Autenticador (CTAP) para comunicação de hardware. Todo o processo é gerenciado pelo navegador e consiste em duas etapas de autenticação: registro e autenticação do dispositivo.  

É construído desta forma porque o FIDO2 é baseado em um mecanismo de criptografia de chave pública. É aqui que o cliente gera uma chave privada e pública e a envia de volta ao RP para verificação de assinatura no login. O FIDO pode ser aplicado como método de autenticação para uma única aplicação ou em uma federação. Para quem não sabe, uma federação refere-se a um logon único (SSO) para vários aplicativos não relacionados gerenciados por um único provedor de identidade (IdP).  

Recursos de segurança FIDO2 

O FIDO2 é famoso por seus recursos de segurança, principalmente por prevenir ataques de phishing, man-in-the-middle e sequestro de sessão.  

Como parte da minha pesquisa, eu queria ver se o FIDO2 é imune a esses ataques – e fiquei surpreso com os resultados. Comecei com o sequestro de sessão, uma técnica de ataque em que o adversário rouba a sessão de um navegador para obter acesso à aplicação e aos dados privados do usuário. O segundo ataque que investiguei foi um ataque man-in-the-middle (MITM) ao IdP, onde um adversário escuta, modifica e retransmite as comunicações entre dois dispositivos que acreditam estar transmitindo diretamente um para o outro.  

Hoje, o MITM é mais difícil de realizar graças à proteção TLS. Mesmo assim, existem muitos métodos para obter um MITM, incluindo falsificação de DNS/DHCP, envenenamento de ARP e SLAAC. Além disso, sabe-se que atores estatais superam e descriptografam o TLS roubando o certificado de uma organização. Um exemplo é atacar Active Directory Serviços de certificação. 

O FIDO foi projetado para prevenir esses ataques. No entanto, ao implementar este método de autenticação moderno, a maioria dos aplicativos não protege os tokens de sessão criados após a autenticação ser bem-sucedida. Descobri que muitos provedores de identidade ainda são vulneráveis ​​aos tipos de ataques MITM e de sequestro de sessão.  

Para entender como isso funciona, precisamos voltar ao básico. 

Com o tempo, os fundamentos da comunicação na web quase não mudaram. O protocolo HTTP e seus recursos são amplamente utilizados na World Wide Web, incluindo o uso de GET e POST para transferir atributos entre terminais e cookies para manter um estado de sessão para um cliente. Aplicativos Web e protocolos SSO, como OIDC e SAML, dependem do protocolo HTTP e são obrigados a seguir suas diretrizes para manter o estado do cliente. Ao longo dos anos, a segurança das sessões do usuário melhorou em termos de como ela é mantida localmente pelo navegador e como o aplicativo a calcula. Contudo, estas mudanças não são suficientes.  

Como exatamente o FIDO2 protege você? 

Para uma autenticação FIDO2 bem-sucedida, o usuário deve registrar o dispositivo FIDO na parte confiável ou solicitar que o navegador execute uma função navigator.credentials.create(). Isso instrui o dispositivo FIDO a gerar uma chave pública e privada para um usuário específico e vinculá-la a uma origem de domínio. O navegador pode então validar a origem do domínio da parte confiável durante o processo de autenticação.  

A seguir vem a etapa de autenticação, onde a parte confiável chama navigator.credentials.get() do navegador para cada solicitação de autenticação. Depois de acionado pelo RP, o navegador se comunica com a chave de segurança FIDO por meio do CTAP. Se a autenticação for aprovada pelo usuário final, a chave de segurança gera uma assinatura usando a chave privada armazenada. Esta assinatura é posteriormente verificada pelo RP através da sua chave pública. 

Num ataque de phishing a um website com um URL diferente, a origem do domínio do website validado evitará um possível roubo de credenciais porque o URL não corresponde à origem registada. No entanto, o mecanismo de ataque MITM é diferente. O pré-requisito para um ataque MITM é ter um certificado confiável da vítima alvo. A maioria dos navegadores modernos alertará e forçará a autenticação segura por TLS para um site remoto. Um ataque MITM bem-sucedido expõe todo o conteúdo de solicitação e resposta do processo de autenticação. Quando terminar, o adversário pode adquirir o cookie de estado gerado e sequestrar a sessão da vítima. Simplificando, não há validação por parte do aplicativo após o término da autenticação.  

Casos de uso de teste 

Eu decidi levar Entra IdP, PingFederate e Yubico como casos de uso de pesquisa. Cada um opera de maneira diferente e tem seus prós e contras.  

Caso de uso 1: Parque Yubico 

O Yubico Playground foi criado para demonstrar e testar recursos e chaves de segurança FIDO. Neste exemplo, o FIDO autentica o usuário diretamente por HTTP em um banco de dados de usuário local. Após a autenticação bem-sucedida, um cookie denominado “sessão” é gerado. Não há validação no dispositivo que solicitou esta sessão, e qualquer dispositivo pode utilizar este cookie até que ele expire. A aquisição deste cookie poderia permitir ao adversário contornar a etapa de autenticação, chegar à área privada do usuário e, neste caso, remover a chave de segurança do perfil do usuário. Este é um exemplo simples de sequestro de sessão; à medida que avançamos para cenários mais complicados, veremos como esse método muda.  

Caso de uso 2: Entra ID SSO 

O segundo caso de uso é Entra ID SSO, que possui recursos de segurança para autenticação em vários protocolos SSO e outros métodos modernos de autenticação. Isso é Acesso Condicional – força de autenticação recurso limita mecanismos sem senha – especificamente FIDO2. Nosso teste validou aplicativos nativos da Microsoft, como o Office 365 e o portal de gerenciamento do Azure sobre o protocolo OpenID Connect (OIDC) e exemplo de aplicativo de terceiros sobre o protocolo SAML. Em ambos os protocolos de federação, o IdP fornece um token de acesso assinado com prazo de validade de 3 hora que é passado como um atributo POST para a terceira parte confiável. No mecanismo de federação, o adversário nem precisa retransmitir o processo de autenticação. O invasor só precisa de um token assinado e ele pode ser usado novamente no prazo certo e gerar cookies de estado em um prazo mais longo. OIDC oferece suporte a tokens de atualização que podem gerar tokens de sessão por um período prolongado. 

Podemos ver no exemplo a seguir que a aplicação nativa do portal Azure Management não valida o token concedido pelo SSO. 

Caso de uso 3: PingFederate 

O terceiro caso de uso é PingFederate. Esse aplicativo abrangente fornece SSO de federação para uma grande variedade de aplicativos empresariais. Ao contrário do Entra, o Ping usa adaptadores de terceiros para realizar a autenticação. Esses adaptadores podem ser encadeados em um fluxo de política de autenticação. Cada adaptador possui seu próprio contexto e é separado um do outro. A autenticação bem-sucedida ocorre quando um usuário atende aos requisitos de todos os adaptadores da política. Os recursos FIDO2 podem ser usados ​​com o adaptador PingOne. Surpreendentemente, nossa equipe descobriu que se o desenvolvedor da terceira parte confiável não validar o token OIDC (ou resposta SAML), o ataque MITM descrito será bem-sucedido.  

Elo mais fraco de autenticação 

Os casos de uso de SSO são mais severos na abordagem direta. À medida que mais participantes estão envolvidos no processo de autenticação, a parte confiável tem menos controle na validação da integridade do dispositivo de origem. Embora o FIDO proteja contra ataques MITM, toda a cadeia depende dos seus elos mais fracos, que são os protocolos SSO onde os seus tokens de concessão podem ser reutilizados por um dispositivo diferente. 

Mitigações e próximas reflexões 

E se houvesse uma maneira de verificar se a sessão autenticada é usada exclusivamente pelo cliente autenticado? Apresentando Vinculação de token, um padrão proposto solicitado em 2018. 

O Token Binding permite que aplicativos e serviços vinculem criptograficamente seus tokens de segurança à camada TLS para mitigar o roubo de tokens e ataques MITM. O Token Binding v1.0 vinculará toda a sessão ao seu handshake TLS subjacente. A criptografia de chave pública se estende além do contexto de autenticação e o WebAuthn entregará com segurança a assinatura de ligação do token.  

Mas como funciona o Token Binding? 

• Após o Hello Client-Server, uma extensão Token Binding está disponível. 
• Os dois endpoints concordam com os campos TLS que o cliente assinará.  
• Exatamente como no WebAuthn, o navegador cria um par de chaves pública/privada de longa duração.  
• O cliente envia a chave pública ao RP para verificação de assinatura; então a assinatura é enviada pela camada de aplicativo.  
• O servidor verifica a assinatura e a vincula ao token da sessão. 

Inicialmente conduzi esta pesquisa em meados de 2023 e enviei as descobertas à Microsoft. Em resposta à divulgação inicial, a Microsoft afirmou que esta não é uma vulnerabilidade. Mesmo assim, é um superfície de ataque que poderia causar danos a uma organização exposta. Quatro meses depois, a Microsoft apresentou uma prévia do acesso condicional do Proteção de token, que é uma variante da ligação de token especificamente para Trusted Platform Module (TPM). Em sua documentação, a Microsoft explica que o roubo de tokens é raro, mas os danos causados ​​podem ser significativos. No caso de aplicações web, o TPM pode atuar de forma semelhante ao FIDO utilizando um método de comunicação diferente do chip de segurança. No entanto, o protocolo WebAuthn permanece o mesmo para a comunicação do navegador e do RP. A visualização atual está limitada a aplicativos Web específicos e versões de clientes Windows. A configuração atual é complicada e, no futuro, a Microsoft expandirá o recurso para chaves de segurança FIDO genéricas. 

Até o momento, o Microsoft EDGE é o único navegador que oferece Token Binding. O Chrome ofereceu Token Binding, mas o removeu devido à baixa adoção.  

A proposta do Token Binding discute dois tipos de vinculação de dispositivos. Um para autenticação direta é chamado de Provided Token Binding. Esse tipo é comum em aplicações simples como o playground Yubico. O segundo tipo, Vinculação de token referida discute a proteção do provedor de identidade e da parte confiável. Em qualquer um dos casos, WebAuthn pode passar a assinatura Token Binding com segurança na fase de autenticação.  

É recomendado que os gerentes de aplicativos exijam Token Binding em uma autenticação FIDO2, se disponível.  

Ao projetar um mecanismo de autenticação, você precisa entender a atribuição da ameaça e construir sua autenticação de acordo. Em casos sensíveis, a abordagem direta é recomendada, pois a aplicação pode ter mais controle sobre o token da sessão. 

Para desenvolvedores de aplicativos, recomendamos adicionar vinculação de token ao processo de autenticação FIDO2, se possível, ou pelo menos limitar o uso do token OIDC ou da resposta SAML de cada autenticação bem-sucedida para ser usado uma vez.  

É preocupante que os excelentes recursos de segurança do FIDO2 não protejam toda a sessão do usuário. É importante compreender que os métodos modernos de autenticação não são um amuleto mágico de segurança e não basta apenas comprar e implementar – é preciso compreender profundamente seus prós e contras. 

Para saber mais sobre Silverfort, obtenha uma demonstração aqui.