Silverfort Pesquisadores descobrem vulnerabilidade de falsificação de KDC no F5 Big-IP [CVE-2021-23008]

No ano passado, relatamos três vulnerabilidades de falsificação de Key Distribution Center (KDC) em Cisco ASA, Palo Alto Networks PAN-OS e IBM QRadar. Mencionamos que outro estava chegando, e agora que F5 emitiu uma correção, estamos publicando a quarta vulnerabilidade de falsificação de KDC que identificamos – desta vez no Big-IP. A vulnerabilidade KDC Spoofing permite que um invasor ignore a autenticação Kerberos para o Big-IP Access Policy Manager, ignore políticas de segurança e obtenha acesso irrestrito a cargas de trabalho confidenciais. Em alguns casos, isso também pode ser usado para ignorar a autenticação no console de administração do Big-IP. Temos trabalhado em estreita colaboração com os engenheiros da F5 para ajudar a corrigir esse problema, resultando no comunicado emitido recentemente. Esta postagem do blog descreve a vulnerabilidade e explica como evitar essas falhas ao implementar Kerberose discute etapas de mitigação para clientes que usam Big-IP e outros sistemas baseados em Kerberos.

Explicando a vulnerabilidade

F5 Big-IP Application Delivery Services é uma solução que entrega aplicativos de maneira segura e escalável. Um de seus componentes principais é o Access Policy Manager (APM), que gerencia e aplica políticas para garantir que o acesso seja devidamente autenticado e autorizado. Às vezes, o APM também é usado para proteger o acesso ao console de administração do Big-IP.

A vulnerabilidade está na implementação do protocolo Kerberos pela F5. Kerberos é o protocolo de autenticação mais comum para autenticação local. É amplamente utilizado em redes corporativas devido à popularidade de Active Directory, e é preferível a protocolos de autenticação mais fracos, como NTLM.

Kerberos pode ser usado como um protocolo de autenticação exigido por uma política APM. Quando um usuário acessa um aplicativo através do Big-IP, pode ser apresentado a ele um portal cativo e solicitado a inserir um nome de usuário e uma senha. O nome de usuário e a senha são verificados no AD com o protocolo Kerberos para garantir que o usuário é quem afirma ser. Portanto, ignorar a autenticação Kerberos permite que um invasor obtenha acesso a aplicativos Big-IP, sem ter credenciais legítimas.

Para que o protocolo Kerberos funcione, três coisas devem acontecer:

1. O usuário se autentica no servidor
2. O servidor autentica para o cliente
3. O KDC autentica no servidor

Aparentemente, a autenticação KDC para o servidor é frequentemente ignorada. Talvez porque exigi-lo complique os requisitos de configuração. Porém, se o KDC não autenticar no servidor, a segurança do protocolo fica totalmente comprometida, permitindo que um invasor que sequestrou o tráfego da rede se autentique no Big-IP com qualquer senha, mesmo que seja inválida.

Para obter a terminologia Kerberos e informações básicas sobre como funciona um ataque de falsificação de KDC, consulte o final desta postagem do blog.

Abaixo está uma captura de tela das instruções para configurar a autenticação AD para uma política de acesso, retirada do Site da F5.

Após essa configuração, quando um usuário tenta se autenticar em um aplicativo atrás do proxy, o usuário é desafiado a inserir um nome de usuário e uma senha. Quando o usuário insere sua senha, o produto usa Kerberos para autenticar no controlador de domínio (DC). No entanto, o APM não solicita um tíquete de serviço e concede acesso com base em um AS_REP bem-sucedido.
Ao contrário de outros cenários, F5 permite configurar um nome de usuário e uma senha de administrador.

Teoricamente, essa senha poderia ser usada para autenticar o DC e prevenir a vulnerabilidade. No entanto, ele não é usado para esses fins, mas apenas para buscar grupos primários ou aninhados, solicitar ao usuário uma alteração de senha ou realizar uma verificação de complexidade ou uma redefinição de senha.

Falsificando a autenticação Kerberos

Aqui estão as etapas que um invasor pode seguir para falsificar um DC e ignorar esse tipo de autenticação. Vamos supor que temos a capacidade de sequestrar a comunicação de rede entre o Big-IP e o DC. Neste caso, podemos criar um DC falso com um nome de usuário idêntico ao nome de usuário do administrador e uma senha de nossa escolha. Em seguida iniciamos uma autenticação no Big-IP e utilizamos o usuário e senha que escolhemos. O Big-IP autentica com Kerberos e sequestramos a comunicação Kerberos e retornamos um AS_REP que corresponde à senha que escolhemos; e um TGS_REP que consiste em um ticket de serviço, criptografado com uma chave de sessão de serviço de nossa escolha, e uma chave de sessão de nossa escolha, criptografada com a senha que escolhemos. Como nestas fases a única verificação que é feita do lado do Big-IP depende da senha que escolhemos, o Big-IP permitirá a autenticação.

Exploração

Simulamos um ataque redirecionando o tráfego entre o Big-IP e o KDC (neste caso, um controlador de domínio) na porta 88 (a porta Kerberos) para a nossa. Windows Server. Configuramos um domínio falso no servidor Windows e garantimos que haja um usuário com o mesmo UPN do administrador Big-IP no domínio real. Configuramos a senha desse usuário como “1” no domínio falso.

Em seguida, tentamos os seguintes cenários:

• Login normal (tráfego não desviado) – conseguimos fazer o login com a senha original do usuário, conforme o esperado. Ao tentar a senha “1”, o login falhou.
• Efetuar login com o tráfego desviado para nosso DC falso – o login com a senha original do administrador falhou, mas o login com a senha “1” funcionou.

Prevenção e Mitigação

Etapas de mitigação para profissionais de segurança

1. Atualize seu Big-IP para uma versão fixa
2. Se uma versão fixa não estiver disponível para a versão do Big-IP que você está usando, certifique-se de MFA está ativado.
3. Atualize seu Silverfort política para Big-IP em conformidade
4. Monitore continuamente sua autenticação Kerberos. Procure recursos que solicitem apenas AS_REQ. Se não houver TGS_REQs, é uma bandeira vermelha.
5. Use Silverfortferramenta de código aberto do para pesquisar nos logs de autenticação serviços que não solicitam tickets de serviço.
6. Consulte as recomendações do desenvolvedor para quaisquer aplicativos desenvolvidos internamente que implementem Kerberos e sistemas que você mesmo configurou.

Para desenvolvedores

Recomendamos algumas etapas para garantir que sua solução não seja suscetível à falsificação de KDC:

1. Valide que a implementação do Kerberos requer uma senha ou keytab: Para validar o DC, é necessário usar algum tipo de segredo compartilhado. Se a sua solução não permitir a configuração de um arquivo keytab ou de um conta de serviço senha, o aplicativo certamente é suscetível à falsificação de KDC.
2. Execute o Wireshark – use o Wireshark para ver quais solicitações Kerberos são enviadas durante a autenticação. Se não houver TGS_REQ, isso é um sinal de alerta.
3. Se você quiser implementar um protocolo de autenticação sozinho, deverá seguir diligentemente as especificações do protocolo. Recomendamos seguir o caminho mais fácil e usar uma implementação existente desses protocolos.
4. Use bibliotecas de terceiros corretamente – algumas bibliotecas de terceiros exigem configuração específica para evitar falsificação de KDC. Por exemplo, uma biblioteca comum usada para Kerberos chamada pam-krb3 precisa ter um keytab configurado para funcionar corretamente. Aqui está o parágrafo relevante da documentação deles (https://github.com/rra/pam-krb5/blob/master/README.md)

Qual é o próximo?

Tenho certeza de que esta é a última vulnerabilidade de falsificação do KDC que encontraremos.

BACKGROUND

Uma visão geral do protocolo Kerberos

O protocolo de autenticação Kerberos foi desenvolvido na década de 1980 por Steve Miller e Clifford Neuman. Permite Single Sign-On (SSO) em uma rede gerenciada e seu Active Directory (AD) o transformou no principal protocolo de autenticação para ambientes corporativos locais.
O protocolo consiste em três trocas para fornecer autenticação mútua para o usuário e o servidor acessado. Quando o usuário faz login, ele insere suas credenciais e a troca do Authentication Service (AS) ocorre. O usuário obtém um Ticket Granting Ticket (TGT), que posteriormente é usado para obter tickets para serviços específicos durante a troca do Ticket Granting Service (TGS). O ticket é então usado durante a troca cliente/servidor para completar a autenticação:

1. Troca de serviço de autenticação (AS)

Durante a troca AS, o usuário se autentica no Centro de Distribuição de Chaves (KDC). Em troca, o usuário obtém o ticket e a chave necessários para se autenticar nos serviços da rede sem inserir novamente as credenciais. Quando o usuário insere as credenciais pela primeira vez, o cliente envia um AS_REQ para a função Authentication Service (AS) do KDC. O AS_REQ é uma mensagem assinada pela Master Key, que é função da senha do usuário. O Serviço de Autenticação, que faz parte do KDC, verifica o AS_REQ de acordo com a chave mestra, que também está disponível para o KDC. Após a validação do AS_REQ, o KDC retorna um AS_REP, que contém uma chave de sessão de logon e um Ticket-Granting Ticket (TGT), que é criptografado com a chave do KDC. O AS Exchange é descrito abaixo. O TGT será utilizado pela central TGS para obter acesso a serviços específicos.

2. Troca de serviço de concessão de ingressos (TGS)

Quando o usuário tenta acessar um serviço na rede, o usuário envia um TGS_REQ para a função Ticket Granting Server (TGS) do KDC. Esta mensagem é criptografada com a chave de sessão de logon, obtida durante o AS Exchange. O TGS_REQ é verificado pelo TGS, que então retorna um TGS_REP. O TGS_REP contém uma chave de sessão de serviço e um ticket de serviço, que é criptografado com a chave mestra do servidor que hospeda o serviço. A chave mestra do servidor em um sistema baseado em Unix é configurada em um arquivo denominado arquivo keytab. A chave mestra do servidor em um servidor membro é derivada da senha da conta do computador. O TGS Exchange é descrito abaixo.

3.Troca cliente/servidor

Agora o cliente tem tudo que precisa para se autenticar no serviço. O cliente envia um AP_REQ ao serviço, que é criptografado com a chave de sessão do serviço. O serviço descriptografa a chave de sessão de serviço para validar o AP_REQ. Então o servidor retorna uma mensagem AP_REP e a autenticação é concluída. A troca cliente-servidor é descrita abaixo:

Protocolo à prova de falsificação

Quando o protocolo Kerberos é implementado corretamente, um invasor que tenta representar o KDC não consegue ignorar a autenticação. Isso ocorre porque mesmo que um invasor crie com êxito um AS_REP válido em resposta a um AS_REQ sequestrado, o invasor nunca será capaz de criar um tíquete de serviço válido. Como o ticket de serviço é criptografado com a chave do servidor, uma chave que o invasor não possui, isso seria impossível.

O que é falsificação de KDC?

Em 2000, Dug Song relatou um vulnerabilidade que afeta o protocolo Kerberos (Canção, Dug.2000. Vulnerabilidade de falsificação do Kerberos KDC. 28 agosto.).

Ele descobriu que certas implementações e configurações de clientes Kerberos falham ao executar a troca Cliente/Servidor e permitem a autenticação com base no sucesso das trocas anteriores. Infelizmente, este comportamento não é seguro e pode ser explorado por um invasor. Um invasor capaz de sequestrar a comunicação entre o cliente e o DC pode executar as seguintes etapas:

1. Crie um KDC falso.
2. Obtenha um nome de usuário autorizado para acessar o serviço que deseja atacar.
3. Crie um usuário no KDC falso com uma senha à escolha do invasor. Por exemplo, vamos chamar essa senha de “1”.
4. Autentique-se no serviço com o nome de usuário obtido e a senha “1”.
5. Sequestre a comunicação do cliente para o DC e desvie-a para o KDC falso.
6. Durante o AS Exchange, retorne um AS_REP que corresponda à senha “1”, à chave KDC falsa e a uma chave de sessão de logon falsa.
7. Durante a troca de TGS, retorne qualquer TGS_REP.
8. O cliente aceitará a autenticação sem realizar uma troca de aplicação.

Os ataques de falsificação de KDC pressupõem que o invasor é capaz de sequestrar o tráfego de e para o KDC e responder em nome do KDC. Isso pode ser feito usando uma variedade de técnicas. Por exemplo, se o invasor estiver no mesmo segmento de rede física que o cliente, ele poderá realizar um ataque de falsificação de ARP, conforme descrito em Network Security Hacks (Lockhart 2007). Outra abordagem possível é assumir o controle de um dispositivo de rede, como um switch ou roteador, e controlar a comunicação a partir daí.

Agradecimentos

A pesquisa e descoberta desta vulnerabilidade foi um esforço conjunto com Thierry Van Steirteghem, que trabalhava na Exclusive Networks na época da descoberta.