Ameaças à delegação: aprofunde-se no patch da Microsoft da vulnerabilidade CVE-2020-17049 KCD

*****Por Dor Segal, pesquisador de segurança da Silverfort*****

Em 11 de novembro de 2020, a Microsoft divulgou o CVE-2020-17049, um novo Kerberos Vulnerabilidade de desvio de recurso de segurança. Embora a vulnerabilidade em si não seja corrigida antes de 8 de fevereiro de 2021, a Microsoft emitiu patches em 8 de novembro e 8 de dezembro para mitigar a sua exploração entretanto. Muito pouco foi divulgado sobre o funcionamento interno da vulnerabilidade, sem um POC público ou uma análise técnica.
Esta postagem tenta preencher parte dessa lacuna, lançando luz sobre a Delegação Kerberos em geral e se aprofundando no patch que a Microsoft lançou para a própria vulnerabilidade CVE-2020-17049 KCD.

Delegação Kerberos 101

Delegação Kerberos é um dos conceitos mais complicados do Kerberos autenticação processo. Esta extensão do protocolo padrão foi originalmente criada para prestação de serviços, e o contas de serviço eles usam, acesso a recursos sem realmente conceder-lhes qualquer tipo de permissão.

Desde a sua introdução inicial, a delegação passou por algumas mudanças importantes até se tornar a Delegação Restrita Baseada em Recursos que usamos hoje (também conhecida como KCD). Portanto, antes de abordarmos a vulnerabilidade em si, vamos rever os diferentes tipos de delegação e os seus respectivos prós e contras.

Etapa 1: Delegação irrestrita

A delegação irrestrita foi introduzida no Windows Server 2000 e foi a primeira a permitir que os serviços representassem um usuário com permissões de acesso. Como o nome indica, este tipo de delegação dá ao serviço o poder de utilizar as credenciais do usuário para acessar qualquer recurso a qualquer momento.

O processo exige que o usuário solicite um TGT premiável e o anexe ao ticket de serviço. Em seguida, o serviço pega o TGT e o injeta no cache local lsass.exe para uso posterior.

Hoje em dia sabemos que este método é altamente arriscado porque concede acesso ilimitado aos serviços delegados, o que no caso de comprometimento – permitiria ao invasor coletar todos os tickets armazenados em cache e obter acesso total a todos os seus privilégios.

Esse tipo de delegação ainda existe hoje, principalmente para oferecer suporte à compatibilidade com versões anteriores, e pode ser detectada consultando o sinalizador ADS_UF_TRUSTED_FOR_DELEGATION no atributo userAccountControl. Este sinalizador também é monitorado por Silverfort, que informa sobre serviços que usam delegação irrestrita.

Etapa 2: Delegação restrita

A próxima geração de delegação é mais limitada e permite que o serviço represente o acesso apenas a recursos definidos com o sinalizador “A conta é sensível e não pode ser delegada” em Active Directory para limitar a representação de usuários específicos.
Este tipo de delegação é onde o serviço realiza a autenticação utilizando as extensões S4U2Self e S4U2Proxy (MS-SFU).

Então, como é que funciona?

Nossa conta de serviço deve ter o sinalizador TRUSTED_TO_AUTH_FOR_DELEGATION ativado e o atributo ms-AllowedToDelegateTo que inclui o SPN do recurso.

Um usuário se autentica normalmente no serviço usando a negociação Kerberos (TGT e TGS).

Agora isso começa a ficar complicado: uma conta de serviço delegada solicita um TGT encaminhável para si mesma. Usamos esse ticket para solicitar um ticket de serviço usando S4U2SELF usando o nome de usuário personificado para nosso campo cname PA-DATA.

O serviço pega esse ticket e o anexa ao ticket de serviço de recursos (S4U2Proxy) com o sinalizador de delegação restrita.

O ticket recebido é uma representação do usuário atual pelo nosso serviço.

Etapa 3: Delegação restrita baseada em recursos

A principal diferença nesta delegação é principalmente administrativa.

Em vez de permitir que o serviço tenha acesso delegado a um recurso, damos o poder ao proprietário do recurso para definir qual serviço tem permissão para realizar a delegação.

Isso é configurável pelo PowerShell usando o PrincipaisAllowedToDelegateToAccountparâmetro t ou simplesmente editando o atributo msDS-AllowedToActOnBehalfOfOtherIdentity

Patch de segurança da Microsoft para CVE-2020-17049 – Análise técnica

As vulnerabilidades do protocolo são sempre mais difíceis de mitigar devido ao suporte de compatibilidade com versões anteriores necessário.

Começamos a analisar o patch da Microsoft lendo as informações publicadas no site oficial.

Entendemos que a vulnerabilidade é sobre “adulteração de tickets” e está localizada em algum lugar no processo de delegação restrita do Kerberos.

Optamos por simular a delegação em um Controlador de Domínio vulnerável e reproduzi-la em um corrigido para verificar a diferença:

A primeira mudança perceptível está localizada no comprimento de cada pacote, podemos ver que a solicitação do ticket autoassinado (S4U2Self) é a mesma, mas sua resposta é 40 bytes a mais.

Isso também se aplica à próxima solicitação e resposta do S4U2Proxy, então o que mudou?

Uma comparação textual não foi útil porque o texto alterado está criptografado dentro do ticket.

Depois de descriptografar a cifra usando o keytab do serviço, o texto fica legível, mas ainda precisa ser compreendido.

Olhando para o campo AuthorizationData, podemos ver um novo campo Desconhecido, começando no deslocamento 840 com tamanho 20.

De onde vem esse novo campo? Como o KDC lida com isso?

O que mais adoro nos protocolos é que a maioria deles mantém e atualiza regularmente RFCs – e o Kerberos não é exceção.

Visitante MS-SFU notei que foi atualizado em 11/23/2020. Quando abrimos o Documento diferencial aprendemos na seção 3.2.5.2.2 que existe uma nova assinatura que é usada para validar a integridade do ticket. Além disso, o patch da Microsoft sugere que o primeiro ticket modificado é o S4U2Self.
Extraímos mais algumas informações da RFC observando a referência de assinatura do ticket – MS-PAC 2.8.3:
“O KDC usará a chave KDC (krbtgt) [RFC4120], para que outros KDCs possam verificar esta assinatura ao receber um PAC.”
“A assinatura do tíquete é usada para detectar adulteração de tíquetes por outras partes que não o KDC. A assinatura do ticket DEVE ser incluída em tickets que não são criptografados na conta krbtgt (incluindo o serviço de alteração de senha) ou em uma conta confiável.”
“correspondente à assinatura do ticket conterá o valor 0x00000010”
O MS-PAC RFC revelou o mistério por trás do campo desconhecido no deslocamento 840 – é uma nova assinatura de ticket, criptografada usando a chave krbtgt para validar sua integridade.

Broca Kerberos Bronze

No dia 8 de dezembro uma implementação do CVE-2020-17049 Vulnerabilidade KCD no Kerberos ataque de bronze foi divulgado com mais detalhes, esclarecendo mais sobre a manipulação do ticket S4U2Self.

A exploração trata da descriptografia e edição do bit do campo encaminhável dentro do encRepPart do ticket.

Um serviço com capacidade de delegação pode produzir tickets S4U2Self para todos os usuários mesmo aqueles com o sinalizador 'A conta é confidencial e não pode ser delegada' ativada.
Este sinalizador define o sinalizador encaminhável como False, mas o ticket nunca é validado pelo KDC em caso de modificação.

Palavras finais

A divulgação de novas vulnerabilidades sempre desperta interesse entre os pesquisadores de segurança. Normalmente, tal divulgação não envolve descrição detalhada dos bits e bytes envolvidos. Embora isto possa fazer sentido do ponto de vista operacional, é igualmente importante aproveitar essas divulgações para obter melhores insights sobre a implementação do software – neste caso, o mecanismo de delegação Kerberos. Se Conhecimento é Poder, espero que esta análise nos tenha tornado um pouco mais fortes.