Terceira vulnerabilidade de falsificação do KDC identificada por Silverfort Pesquisadores – desta vez no IBM QRadar [CVE-2019-4545]

*****Por Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach, Silverfort*****

A falsificação de KDC nunca envelhece. Divulgamos vulnerabilidades de falsificação de KDC em Cisco ASA e Palo Alto Networks PAN-OS em maio de 2020. Agora podemos compartilhar que o IBM QRadar também é vulnerável devido à forma como Kerberos foi implementado.
A vulnerabilidade KDC Spoofing permite que um invasor ignore a autenticação Kerberos para o QRadar e, como resultado, obtenha acesso administrativo ao sistema. Temos trabalhado em estreita colaboração com engenheiros da IBM para ajudar a corrigir esse problema, resultando na publicação recente boletim de segurança . Esta postagem do blog descreve a vulnerabilidade, explica como evitá-las como um desenvolvedor que implementa o Kerberos e fala sobre a mitigação para organizações que usam o QRadar e outros sistemas que usam o Kerberos.

Explicando a vulnerabilidade

O IBM QRadar Security Information and Event Management (SIEM) ajuda as equipes de segurança a detectar e priorizar ameaças em toda a empresa e fornece insights importantes que permitem que as equipes respondam rapidamente para reduzir o impacto dos incidentes.
A vulnerabilidade está na implementação do protocolo Kerberos pela IBM. 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.
A IBM usa o protocolo de autenticação Kerberos para autenticar o acesso administrativo. Portanto, ignorar a autenticação Kerberos permite que um invasor obtenha acesso administrativo ao IBM QRadar, visualize informações confidenciais e potencialmente altere logs – 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. No entanto, se o KDC não for autenticado no servidor, a segurança do protocolo será totalmente comprometida, permitindo que um invasor que tenha sequestrado o tráfego de rede se autentique no QRadar com qualquer senha, mesmo que seja uma senha errada.

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.

Como descobrimos a vulnerabilidade no QRadar

O acesso administrativo ao QRadar deve ser protegido com autenticação forte para evitar acesso não autorizado e adulteração do sistema. Usar a autenticação AD é uma opção popular:
Quando um administrador se autentica no QRadar, ele usa vários parâmetros para autenticar o administrador (veja abaixo uma captura instantânea do guia de implementação tirada de SUA PARTICIPAÇÃO FAZ A DIFERENÇA). Primeiro, o QRadar solicita um TGT do AD. Após receber o TGT, o QRadar solicita um ticket de serviço para autenticação LDAP para o controlador de domínio. Se for bem-sucedido, o QRadar usará SASL para autenticar com LDAP no DC. Ele utiliza o ticket de serviço para comprovar a identidade do usuário.

Falsificando a autenticação Kerberos/SASL

Aqui estão as etapas que um invasor executará 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 QRadar 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 QRadar e utilizamos o usuário e a senha que escolhemos. O QRadar 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 nessas fases a única verificação feita no lado do QRadar depende da senha que escolhemos, o QRadar não deve rejeitar a autenticação neste ponto. Agora que o QRadar recebeu o ticket de serviço, ele pode iniciar uma solicitação LDAP para o DC. Também sequestraremos o tráfego LDAP. Temos duas opções neste momento:
1. O LDAP está sendo usado sem TLS. Neste caso podemos sequestrar o tráfego LDAP. O QRadar envia uma solicitação de ligação ao DC com uma mensagem Kerberos AP_REQ, que contém o ticket de serviço que temos. Podemos retornar um AP_REP baseado na chave de sessão de serviço que escolhemos e o QRadar irá aceitá-lo.
2. O LDAPS foi configurado. Nesse caso, não podemos retornar uma resposta em nome do DC, porque o TLS está sendo usado para autenticar o DC, ou seja, assumindo que o certificado foi configurado no lado do QRadar.

Falsificando a autenticação Kerberos/SASL/LDAPS para QRadar

Antes de desistir da opção 2, notamos o seguinte comportamento estranho. Se configurarmos um endereço IP como URL do servidor, a autenticação ainda funciona. Teoricamente, a autenticação com um endereço IP não deveria funcionar, porque Kerberos não permite autenticação para endereços IP, a menos que um SPN tenha sido configurado explicitamente.
Ao enviar o TGS_REQ, o QRadar solicita um ticket para ldap/. Como o DC não possui um nome principal de serviço (SPN) com esse nome, ele retorna um erro KRB_ERR_S_PRINCIPAL_UNKOWN. De acordo com o protocolo Kerberos, o QRadar deve negar a autenticação neste ponto. No entanto, uma captura de rede revela que uma solicitação LDAP é aberta mesmo após o erro e reconfigurada imediatamente pelo QRadar. Então, o usuário poderá fazer login. Concluímos que o QRadar considera a autenticação bem-sucedida antes mesmo da conclusão da troca do aplicativo Kerberos. Isso pode ser facilmente explorado. Como invasores, podemos enviar um KRB_ERR_S_PRINCIPAL_UNKOWN logo após falsificar o AS_REP e podemos fazer com que o QRadar aceite uma autenticação com uma senha de nossa escolha. O ataque é descrito abaixo.

Um bug adicional no QRadar faz com que ele solicite autenticação do AD para um usuário que não existe necessariamente. O QRadar possui um usuário administrador local integrado. Acontece que ao tentar a autenticação com o usuário administrador, o QRadar primeiro tenta autenticar no DC com Kerberos. Este nome de usuário não precisa existir no AD. Isso facilita o ataque, porque o nome de usuário é conhecido antecipadamente pelo invasor.

Além disso, esse bug pode ser considerado uma vulnerabilidade por si só. Independentemente do KDC Spoofing, se um invasor puder obter privilégios para criar usuários no AD, por exemplo, assumindo o controle de uma conta de suporte técnico, o invasor poderá criar um usuário chamado admin no AD. Em seguida, o invasor poderá usar esse usuário para autenticar-se no QRadar.

Exploração

Agora que sabíamos que o QRadar está vulnerável, simulamos um ataque redirecionando o tráfego entre o QRadar e o KDC (nesse caso, um controlador de domínio) na porta 88 (a porta Kerberos) para nosso próprio Windows Server. Configuramos um domínio falso no servidor Windows e garantimos que haja um usuário com o mesmo UPN que o administrador do QRadar no domínio real. 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 administrador, 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.

Mitigação da IBM

A abordagem da IBM para mitigar esta vulnerabilidade é simples e segura. Como exatamente a mesma funcionalidade de autenticação para QRadar pode ser alcançada com LDAPS, a mitigação recomendada é simplesmente mudar da autenticação Kerberos para LDAPS. Depois disso você deve instalar o patch da IBM. O patch verificará se a autenticação está realmente definida para LDAPS e falhará se você ainda não tiver mudado para a autenticação LDAPS. Isso é para garantir que seu sistema esteja seguro após o patch.

Se você estiver usando Silverfort para proteger a autenticação em seu QRadar, será necessário atualizar também o Silverfort política para QRadar para proteger a autenticação LDAPS em vez da solicitação Kerberos TGT.

Prevenção e Mitigação

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

1. Alternar autenticaçãoem seu QRadar de Kerberos para LDAPS
2. Atualize seu QRadar para uma versão fixa
3. Atualize seu Silverfort política para QRadar adequadamente
4. Monitore continuamente sua autenticação Kerberos. Procure recursos que solicitem apenas AS_REQ. Se não houver TGS_REQs, é uma bandeira vermelha.
5. Usar 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.

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ê mesmo quiser implementar um protocolo de autenticação, deverá seguir diligentemente as RFCs 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?
Descobrimos outra vulnerabilidade de falsificação do KDC e esperamos escrever sobre ela em breve, mas não antes de o fornecedor publicar um patch. Até então, fique atento.

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 de 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. Sequestrar a comunicação do cliente para o DC e desviá-la 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í.