Pesquisadores de segurança em Silverfort, fornecedora de plataforma de autenticação sem agente, identificou uma vulnerabilidade grave que pode permitir que hackers obtenham controle sobre o Cisco Adaptive Security Appliance (ASA). Todas as versões do ASA são afetadas. Depois de divulgar a vulnerabilidade à Cisco, a Cisco corrigiu todas as versões suportadas do ASA e publicou um comunicado nele. A vulnerabilidade (CVE-2020-3125) recebeu uma pontuação de risco CVSS de 8.1 em 10, que é considerada “Alta”. Isso ocorre porque a vulnerabilidade pode permitir que um invasor contorne o Kerberos autenticação para Cisco ASA. Silverfort os pesquisadores creditados pela descoberta da vulnerabilidade são: Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach.

A Cisco corrigiu esta vulnerabilidade em todas as versões do ASA. É altamente recomendável que as empresas atualizem para as versões mais recentes do ASA para se protegerem contra explorações.

Este artigo descreve a vulnerabilidade de falsificação do KDC e mostra como ela pode ser usada para ignorar a autenticação no Cisco ASA. Ele explicará como evitar essas vulnerabilidades tanto para desenvolvedores que implementam Kerberos quanto para empresas que já implementaram essas soluções em suas redes.

Explicando a vulnerabilidade

A vulnerabilidade está na implementação Kerberos da Cisco. 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 Cisco usa o protocolo de autenticação Kerberos em muitas interfaces ASA – por exemplo, VPN, abertura de sessões de firewall e acesso administrativo, seja através do console de gerenciamento web ou através de SSH. Portanto, ignorar a autenticação Kerberos permite que um invasor assuma o controle do dispositivo Cisco, contorne sua segurança e obtenha acesso a outras redes.

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 Cisco ASA com qualquer senha, mesmo que seja errada.

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 relatou uma 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. 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í.

Como descobrimos a vulnerabilidade no Cisco ASA

Estávamos procurando uma maneira de adicionar Autenticação multifator (MFA) para administradores que acessam Cisco ASA e Anyconnect VPN. Depois de configurar a Cisco para usar Kerberos como protocolo de autenticação, examinamos os logs de autenticação em Silverfortconsole. Silverfort fornece visibilidade total de todas as atividades de autenticação na rede. SilverfortOs registros do Cisco ASA estavam solicitando um TGT sem solicitar um tíquete de serviço.

Voltamos ao guia de configuração Cisco. 2007. PIX/ASA: Autenticação Kerberos e grupos de servidores de autorização LDAP para usuários de clientes VPN por meio de exemplo de configuração ASDM/CLI. 30 de julho. ; e observei os parâmetros necessários para configurar a autenticação Kerberos:

Como visto acima, não há lugar para inserir a senha ou configuração do keytab para autenticação Kerberos. A senha ou keytab são necessários para uma implementação correta, pois criam o 'segredo' usado pelo Kerberos para autenticar de forma confiável no KDC. Sem o 'segredo', a autenticação não pode ser criptograficamente confiável.

Seguimos em frente e tentamos o mesmo para outras interfaces Cisco e vimos que a mesma vulnerabilidade existe ao abrir sessões de firewall, autenticação administrativa e até mesmo ao usar SSH para acessar a VM. Veja abaixo a coluna Kerberos na tabela que resume o suporte da Cisco para diferentes protocolos de autenticação.

Exploração

A seguir, queríamos ver se essa vulnerabilidade pode ser explorada. Para isso, sequestramos o tráfego Kerberos destinado ao DC e o desviamos para o nosso servidor. Em vez de desenvolver nossa própria lógica KDC, simplesmente instalamos o AD Domain Services em nosso servidor não autorizado, promovendo nosso servidor a um controlador de domínio. Claro, não sendo administrador do domínio original, criamos um novo domínio falso.

Como sabemos o nome de usuário do administrador Cisco no primeiro domínio (Bob neste exemplo), criamos um usuário chamado Bob em nosso domínio falso. Configuramos a senha desse usuário em nosso domínio falso como “1”.

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. Primeiro de tudo, atualize seu Cisco ASA para uma versão fixa e faça as alterações de configuração necessárias detalhadas no Consultor Cisco
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 Silverfort'S 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 Política MFA 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 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, é 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)