banner
Lar / Notícias / Novos caminhos de ataque? Tíquetes de serviço solicitados pelo AS
Notícias

Novos caminhos de ataque? Tíquetes de serviço solicitados pelo AS

Jul 18, 2023Jul 18, 2023

Home » Cibersegurança » Notícias do SBN » Novos caminhos de ataque? Tíquetes de serviço solicitados pelo AS

Ao ajudar Andrew Schwartz com seu post Kerberos FAST (que tem mais informações sobre o que é FAST e como ele funciona, então leia), notei algo interessante. AS-REQs para contas de máquina não são blindados. Isso é descrito pela Microsoft aqui:

A proteção Kerberos usa um tíquete de concessão de tíquete (TGT) para o dispositivo proteger as trocas de serviço de autenticação com o KDC, portanto, a troca de serviço de autenticação do computador não é blindada. O TGT do usuário é usado para proteger suas trocas TGS com o KDC.

Isso me fez pensar se era possível solicitar tickets de serviço (STs) do serviço de autenticação (AS). A capacidade de solicitar STs do AS tem várias consequências, incluindo novos caminhos de ataque, desvios de detecção e potencial enfraquecimento dos controles de segurança. Todos os problemas discutidos nesta postagem foram relatados à Microsoft e foram "considerados por design" (Figura 1).

Primeiro, aqui está uma visão geral de alto nível do fluxo típico do Kerberos (Figura 2, proveniente do ADSecurity):

O fato de ser emitida uma chave de sessão para cada ticket é uma característica importante para a pesquisa a seguir. Essa chave de sessão é passada de volta para a conta solicitante em uma seção criptografada da resposta; a chave de criptografia já é conhecida pelo solicitante.

Por exemplo, a chave de sessão TGT é armazenada em uma seção que é criptografada com a chave usada para provar a identidade do solicitante ao solicitar um TGT. Essa chave normalmente é a chave de longo prazo (hash de senha) da conta. Mas no caso da Criptografia de Chave Pública para Autenticação Inicial (PKINIT) no protocolo Kerberos, a chave é derivada do certificado. A chave de sessão ST é armazenada em uma seção criptografada com a chave de sessão TGT.

A chave de sessão do ticket é necessária para usar o ticket na próxima etapa do fluxo Kerberos.

Uma solicitação Kerberos tem duas seções principais:

O req-body é enviado principalmente em texto simples e contém várias informações:

Uma resposta Kerberos tem várias seções e contém uma parte criptografada:

A parte do fluxo Kerberos que esta postagem aborda é AS-REQ/AS-REP, que geralmente é usada para solicitar um TGT. Em operações normais, um AS-REQ tem um dos dois valores dentro de suadecolacampo dentro do req-body:

Percebi que, com o Kerberos Flexible Authentication Secure Tunneling (FAST) aplicado, as contas de máquina ainda enviavam seus AS-REQs sem proteção. Eu me perguntei se um AS-REQ poderia ser usado para solicitar um ST diretamente, em vez de um TGT. Isso me levou a modificar o Rubeus para determinar se especificar outro SPN dentro dodecola de um AS-REQ faria com que o DC respondesse com um ST para aquele SPN. Acontece que a resposta foi "sim" (Figura 3).

Ao usar uma conta de máquina, posso solicitar um ST sem usar blindagem quando o FAST é aplicado. O que mais é possível?

Kerberoasting, descoberto por Tim Medin, é um método para recuperar a senha de texto simples ou hash NT para uma conta de serviço, geralmente uma conta de usuário com um SPN. Kerberoasting é possível porque parte de um ST é criptografada com a chave de longo prazo da conta de serviço (hash de senha). Ao extrair a parte criptografada do ticket, é possível formar um hash de várias senhas de texto não criptografado e tentar descriptografar a parte criptografada. Se a descriptografia for bem-sucedida, o hash usado será a chave de longo prazo usada para criptografar o ticket. Essa chave pode ser usada para autenticar como a conta de serviço.

Além disso, qualquer conta pode solicitar um ST para qualquer serviço. Portanto, a capacidade de autenticação no Active Directory (AD) é necessária para executar o ataque. Pelo menos, isso costumava ser verdade.

Primeiro, tentei usar uma conta que não exigisse pré-autenticação (DONT_REQ_PREAUTH) para solicitar um ST. Quando uma conta não requer pré-autenticação para autenticação, um TGT pode ser solicitado sem exigir dados de pré-autenticação, que são criptografados com alguma forma de credencial (por exemplo, hash de senha, certificado). Se um invasor não obteve uma credencial válida para uma conta, a pré-autenticação válida não pode ser gerada. Se a pré-autenticação não for necessária, isso não é um problema.