A Palo Alto Networks publicou um comunicado sobre uma vulnerabilidade de falsificação de KDC no PAN-OS que foi descoberta e divulgada de forma responsável à Palo Alto Networks por Silverfort pesquisadores Yoav Iellin, Yaron Kassner e Rotem Zach. A vulnerabilidade afetou todas as versões suportadas do PAN-OS e todas as interfaces que usavam um Kerberos autenticação perfil. Depois de divulgar a vulnerabilidade, a Palo Alto Networks corrigiu todas as versões suportadas do PAN-OS e publicou um consultivo sobre isso. A vulnerabilidade pode permitir que um invasor contorne o Kerberos autenticação para PAN-OS e acesso às interfaces administrativas para PAN-OS, bem como autenticação para sessões de firewall através do portal cativo.

Esta vulnerabilidade é semelhante a uma Vulnerabilidade de falsificação de KDC que nossos pesquisadores descobriram no Cisco ASA. Parece que a implementação do protocolo de autenticação Kerberos nem sempre é concluída corretamente, deixando os sistemas vulneráveis ​​a explorações.

A Palo Alto Networks corrigiu esta vulnerabilidade em todas as versões do PAN-OS. É altamente recomendável implantar este patch para proteção contra exploração.

Este artigo descreve a vulnerabilidade de falsificação de KDC no PAN-OS e mostra como ela pode ser usada para ignorar a autenticação sem saber a senha. Ele explica como evitar essas vulnerabilidades tanto para desenvolvedores que implementam Kerberos quanto para empresas que usam a autenticação Kerberos em seus sistemas.

Explicando a vulnerabilidade

A vulnerabilidade está na implementação Kerberos da Palo Alto Networks. Kerberos é o protocolo de autenticação mais comum para autenticação local. Está amplamente disponível em redes corporativas devido à popularidade do Active Directory, e é preferível a protocolos de autenticação mais fracos, como NTLM.

A Palo Alto Networks usa o protocolo de autenticação Kerberos em muitas interfaces PAN-OS – por exemplo, VPN SSL, Portal Cativo ou login de administrador. Portanto, ignorar a autenticação Kerberos permite que um invasor administre o Palo Alto Networks Strata, contorne sua segurança e obtenha acesso a redes adicionais.

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. No entanto, se o KDC não se 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 PAN-OS com qualquer senha, mesmo que seja errada.

Descobrindo a vulnerabilidade no PAN-OS

Descobrimos a vulnerabilidade quando tentamos adicionar Silverfortdo MFA para interfaces que dependem do protocolo Kerberos, incluindo SSL VPN, Captive Portal e Admin Login. Para configurar isso, configuramos Kerberos como método de autenticação e configuramos uma política de MFA correspondente no Silverfort lado. Uma explicação detalhada sobre o protocolo Kerberos e a falsificação de KDC pode ser encontrada no final deste artigo.
Conforme visto abaixo, a captura de rede inclui um AS-REQ e um AS-REP, mas nenhum TGS-REQ:

A autenticação foi bem-sucedida mesmo que o TGS-REQ seja exigido pelo protocolo e esteja faltando no processo de autenticação. Como já descobrimos um vulnerabilidade semelhante com Cisco ASA, queríamos verificar isso.

Voltamos e verificamos o guia da Palo Alto Networks para configurar a autenticação Kerberos – abaixo está uma captura de tela do guia da época:

Percebemos que não éramos obrigados a configurar um keytab ou uma senha de serviço em nenhum momento do processo de configuração. PAN-OS oferece uma opção para configurar um keytab, mas era opcional. Porém, mesmo que o keytab tenha sido configurado, vimos que ele não foi utilizado para o processo de autenticação nas referidas interfaces. Sem um keytab ou senha, o PAN-OS não possui as credenciais necessárias para validar a autenticidade do KDC. Isso significa que o PAN-OS é suscetível à falsificação de KDC.

Tentando explorar a vulnerabilidade

Agora que sabíamos que o PAN-OS é vulnerável, simulamos um ataque redirecionando o tráfego entre o PAN-OS e o KDC, neste caso o controlador de domínio, na porta 88 (a porta Kerberos), para o nosso próprio Windows Server. Configuramos um domínio falso no servidor Windows e garantimos que haja um usuário com o mesmo nome principal de usuário (UPN) que o administrador do PAN-OS no domínio real. Neste exemplo, vamos chamá-lo de 'Bob'. Configuramos a senha desse usuário como “1” no domínio falso.

Tentamos então as seguintes situações:

• Login normal (tráfego não desviado) – conseguimos fazer o login com a senha original do Bob, 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 de Bob falhou, mas o login com a senha “1” funcionou.

Prevenção e Mitigação

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

1. Em primeiro lugar, atualize seu PAN-OS para uma versão fixa e faça as alterações de configuração necessárias detalhadas no Assessoria da Palo Alto Networks.
2. Monitore continuamente sua autenticação Kerberos. Procure recursos que solicitem apenas AS_REQ. Se não houver TGS_REQs, é uma bandeira vermelha.
3. Use Silverfortferramenta de código aberto do para pesquisar nos logs de autenticação serviços que não solicitam tickets de serviço.
4. Consulte as recomendações do desenvolvedor para quaisquer aplicativos desenvolvidos internamente que implementem Kerberos e sistemas que você mesmo configurou.
5. Silverfort os clientes que estão aproveitando o recurso de autenticação avançada com a Palo Alto Networks devem atualizar seus Silverfort MFA política de uma política TGT para uma política de ticket de serviço após atualizar seu PAN-OS.

Como desenvolvedor

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 Kerboros 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, é uma bandeira vermelha.
3. Se você quiser implementar um protocolo de autenticação sozinho, deverá seguir diligentemente as RFCs do protocolo. Recomendamos seguir o caminho mais fácil e usar uma implementação existente desses protocolos.
4. Use um^rd bibliotecas partidárias corretamente – cerca de 3^rd bibliotecas de terceiros exigem configuração específica para evitar falsificação de KDC. Por exemplo, uma biblioteca comum usada para Kerberos chamada pam-krb5 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)

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 os usuários fazem login, eles inserem suas credenciais e a troca do Serviço de Autenticação (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, que mais tarde foi cofundador da Duo Security, relatou um técnica usado para ignorar o protocolo Kerberos em algumas situações:

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. Para demonstração, 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 do 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 Hacks de segurança de rede. 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í.