Enquanto ajudava Andrew Schwartz com seu post sobre o Kerberos FAST (que tem mais informações sobre o que é o FAST e como ele funciona, então dê uma lida), notei algo interessante. Os AS-REQs para contas de máquinas não são blindados. A blindagem do Kerberos é descrita pela Microsoft:
A blindagem Kerberos utiliza um bilhete de concessão de bilhete (TGT) para o dispositivo para proteger as trocas de serviços de autenticação com o KDC, pelo que a troca de serviços de autenticação do computador não é blindada. O TGT do utilizador é utilizado para proteger as suas trocas de TGS com o KDC.
Isto fez-me pensar se seria possível solicitar bilhetes de serviço (STs) ao serviço de autenticação (AS). A capacidade de pedir STs ao AS tem várias consequências, incluindo novos caminhos de ataque, desvios de detecção e potencial enfraquecimento dos controlos de segurança. Todos os problemas discutidos nesta publicação foram comunicados à Microsoft e foram "considerados como tendo sido concebidos"(Figura 1).
Leitura relacionada
Recapitulação do Kerberos
Em primeiro lugar, eis uma visão geral de alto nível do fluxo típico do Kerberos(Figura 2, proveniente da ADSecurity):
- Uma conta solicita um TGT ao controlador de domínio (DC).
- O CD responde com um TGT, que tem a sua própria chave de sessão.
- O TGT e a sua chave de sessão são utilizados para solicitar um bilhete de serviço (ST) ao CD.
- O CD responde com um ST, que tem a sua própria chave de sessão.
- O ST e a sua chave de sessão são utilizados para autenticar o serviço final.
- O serviço final concede ou proíbe o acesso.
O facto de ser emitida uma chave de sessão para cada bilhete é uma característica importante para a investigação que se segue. Esta chave de sessão é devolvida à conta requerente numa secção encriptada da resposta; a chave de encriptação já é conhecida pelo requerente.
Por exemplo, a chave de sessão TGT é armazenada numa secção que é encriptada com a chave utilizada para provar a identidade do requerente ao solicitar um TGT. Esta chave é normalmente a chave de longo prazo (hash da palavra-passe) 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 numa secção que é encriptada com a chave de sessão TGT.
A chave de sessão do bilhete é necessária para utilizar o bilhete no passo seguinte do fluxo Kerberos.
Um pedido Kerberos tem duas secções principais:
- padata (dados de pré-autenticação)
- req-body (corpo do pedido)
O req-body é enviado maioritariamente em texto simples e contém várias informações:
- kdc-options: várias opções
- cname: nome da conta requerente (facultativo)
- realm: nome de domínio
- sname: nome da entidade de serviço (SPN) para o bilhete resultante (opcional)
- from: hora a partir da qual o cliente pretende que o bilhete seja válido (facultativo)
- até: tempo até ao qual o cliente pretende que o bilhete seja válido
- rtime: o tempo de renovação solicitado (opcional)
- nonce: número aleatório
- etype: lista dos tipos de encriptação suportados pelo cliente
- endereços: lista de endereços do cliente requerente (facultativo)
- enc-authorization-data: várias secções de dados de autorização, encriptadas com a chave de sessão que é normalmente utilizada para privilégios locais (opcional)
- additional-tickets: lista dos bilhetes necessários para o pedido (facultativo)
Uma resposta Kerberos tem várias secções e contém uma parte encriptada:
- pvno: número da versão
- msg-type: tipo de mensagem (11 AS, 13 TGS)
- padata: dados de pré-autenticação (facultativo)
- crealm: nome do domínio do cliente
- cname: nome da conta requerente
- bilhete: bilhete resultante
- enc-part: dados encriptados para utilização pelo cliente
O problema dos bilhetes de serviço solicitados por AS
A parte do fluxo do Kerberos em que este post se concentra é o AS-REQ/AS-REP, que normalmente é usado para solicitar um TGT. Em operações normais, um AS-REQ tem um de dois valores no seu campo sname dentro do req-body:
- krbtgt/domain.local: utilizado para solicitar um TGT inicial
- kadmin/changepw: utilizado para solicitar um bilhete de curta duração, que pode ser utilizado para repor as palavras-passe utilizando uma mensagem KRB-PRIV (definida no RFC 3244)
Notei que, com o Kerberos Flexible Authentication Secure Tunneling (FAST) aplicado, as contas de máquina ainda enviavam seus AS-REQs sem blindagem. Perguntei-me se um AS-REQ poderia ser usado para solicitar um ST diretamente, em vez de um TGT. Isso fez com que eu modificasse o Rubeus para determinar se a especificação de outro SPN dentro do sname de um AS-REQ faria com que o DC respondesse com um ST para esse SPN. Como se vê, a resposta foi "sim"(Figura 3).
Ao utilizar uma conta de máquina, posso pedir um ST sem utilizar a blindagem quando o FAST é aplicado. O que mais é possível?
Novas formas de Kerberoast
O Kerberoasting, descoberto por Tim Medin, é um método para recuperar a palavra-passe em texto simples ou o hash NT de uma conta de serviço, geralmente uma conta de utilizador com um SPN. O Kerberoasting é possível porque parte de um ST é encriptada com a chave de longo prazo da conta de serviço (hash da palavra-passe). Ao extrair a parte encriptada do bilhete, é possível formar um hash a partir de várias palavras-passe em texto claro e tentar desencriptar a parte encriptada. Se a desencriptação for bem sucedida, então o hash utilizado é a chave de longo prazo utilizada para encriptar o bilhete. Essa chave pode então ser usada para autenticar como a conta de serviço.
Além disso, qualquer conta pode solicitar um ST para qualquer serviço. Por conseguinte, a capacidade de autenticação no Active Directory (AD) é necessária para efectuar o ataque. Pelo menos, isso costumava ser verdade.
Kerberoasting sem pré-autenticação
Primeiro, tentei utilizar uma conta que não exigia pré-autenticação(DONT_REQ_PREAUTH) para pedir um ST. Quando uma conta não requer pré-autenticação para autenticar, um TGT pode ser solicitado sem requerer dados de pré-autenticação, que são encriptados com alguma forma de credencial (por exemplo, hash de palavra-passe, certificado). Se um atacante não tiver obtido uma credencial válida para uma conta, não pode ser gerada uma pré-autenticação válida. Se a pré-autenticação não for necessária, isto não é um problema.
Quando um bilhete é solicitado sem pré-autenticação, o resultado continua a incluir uma parte cifrada. Esta parte encriptada é encriptada com a chave de credencial utilizada para a autenticação e contém a chave de sessão para o bilhete incluído na resposta. Estes são os dados encriptados utilizados no ataque ASREPRoast de Will Schroeder. O TGT resultante é utilizável apenas com acesso à chave da conta solicitante, uma vez que a chave de sessão do TGT é necessária.
No entanto, para o Kerberoasting, o acesso à chave de sessão não é necessário. Apenas o ST resultante - ou mais precisamente, a parte encriptada do ST, que não está protegida com a chave da conta requerente - é necessária. Por conseguinte, se qualquer conta estiver configurada para não exigir pré-autenticação, é possível efectuar o Kerberoasting sem quaisquer credenciais. Este método de Kerberoasting foi implementado no Rubeus no âmbito deste PR.
Demonstração
Como o acesso a uma conta válida ainda não foi obtido, o LDAP não pode ser consultado. Em vez disso, é necessária uma lista de potenciais contas de serviço. Pesquisas anteriores de Arseniy Sharoglazov mostram que os STs podem ser solicitados usando apenas o nome de utilizador da conta de serviço, em vez de exigir o SPN real - muito útil para esta pesquisa.
Uma lista de nomes de utilizador pode ser gerada de várias formas, incluindo a enumeração de utilizadores utilizando sessões nulas num DC, gerando uma lista de nomes de utilizador utilizando inteligência de fonte aberta (OSINT) ou adivinhando potenciais nomes de utilizador. Qualquer lista de potenciais nomes de utilizador pode ser facilmente verificada enviando um AS-REQ sem pré-autenticação. Um nome de utilizador válido que requer pré-autenticação recebe um erro KDC_ERR_PREAUTH_REQUIRED(Figura 4).
Um nome de utilizador válido que não necessite de pré-autenticação recebe um TGT(Figura 5).
Um nome de utilizador inválido recebe um erro KDC_ERR_C_PRINCIPAL_UNKNOWN(Figura 6).
Para fins de demonstração, uma lista é gerada usando uma sessão nula no DC, usando o método de ciclo RID do enum4linux-ng(-R), como mostra a Figura 7.
Utilizando esta lista de nomes de utilizador, é fácil determinar as contas que não requerem pré-autenticação no AD(Figura 8).
Note-se que os AS-REQs sem pré-autenticação não são registados como um evento do Windows, a menos que a conta não exija pré-autenticação.
Com a lista de nomes de utilizador e o nome de utilizador de uma conta que não requer pré-autenticação, o ataque pode ser lançado(Figura 9).
A saída resultante pode então ser usada para tentar decifrar a palavra-passe offline.
Prova de conceito: RoastInTheMiddle
Outra consequência interessante é a capacidade de efectuar Kerberoast a partir de uma posição Man-in-the-Middle (MitM). Este tipo de ataque geralmente não é possível com TGS-REQs porque o campo cksum opcional no autenticador dentro do AP-REQ protege o corpo req do pedido e é frequentemente incluído por clientes Windows Kerberos genuínos. Por conseguinte, modificar o nome de um TGS-REQ sem actualizar a soma de controlo no autenticador invalida a soma de controlo do autenticador e devolve um erro KRB_AP_ERR_MODIFIED. Mas isto não é um problema para os AS-REQs porque o corpo do req e, consequentemente, o campo sname, não estão protegidos.
Ao testar esta abordagem, descobri que os AS-REQs podem ser reproduzidos muitas vezes. Um atacante precisa de capturar apenas um AS-REQ para enviar muitos AS-REQs com diferentes valores de sname.
Demonstração
Para demonstrar essa abordagem, escrevi uma prova de conceito (POC) aproximada. Esta POC, RoastInTheMiddle, implementa um ARP spoof entre DCs e sistemas vítimas para efectuar um ataque MitM. O POC então passa o tráfego enquanto escuta por AS-REQs. Quando um AS-REQ é encontrado, o POC efectua um Kerberoast. O POC não está pronto para o ataque, mas demonstra que um ataque é possível.
Primeiro, o POC inicia quatro threads, um sniffer, um ARP spoofer, um re-assembler (para pedidos que são divididos em vários pacotes) e o roaster(Figura 10).
Quando vê um AS-REQ, o POC começa a tentar fazer Kerberoast da lista fornecida, que pode conter nomes de utilizador ou SPNs(Figura 11).
Como mostra a Figura 11, esta tentativa resulta na saída de quaisquer STs recebidos em formato hashcat, prontos para a quebra de senhas offline.
A capacidade de MitM AS-REQs, depois modificá-los e reproduzi-los, também pode ser útil no desenvolvimento de outros ataques. Eu tentei modificar o kdc-options para incluir a opção proxiable que resulta em um ticket com a flag proxiable definida. No entanto, não consegui encontrar um caminho de ataque usando esse ticket e bandeira. Esse comportamento também pode permitir o uso de outras contas para executar um Kerberoast, permitindo que os invasores evitem queimar uma conta comprometida.
Melhorias
Algumas melhorias podem ser possíveis para este processo. Em primeiro lugar, é possível coagir um AS-REQ a partir de um TGS-REQ, interceptando-o e respondendo com um erro KRB_AP_ERR_BAD_INTEGRITY. Isso força o cliente a se autenticar novamente enviando um AS-REQ.
Também deve ser possível efectuar este ataque usando a injecção de um servidor de nomes DHCPv6 (como o mitm6 de Dirk-jan Mollema ou o Inveigh de Kevin Robertson), respondendo a consultas DNS SRV para o serviço LDAP e depois lidando com a seguinte ligação LDAP.
O suporte para modificar os etypes dentro do pedido permite ataques de downgrade do tipo de encriptação quando o ambiente o permite, tal como descrito por Will Schroeder aqui.
Por fim, o POC requer a instalação do Npcap no sistema que executa o POC (que usa sharppcap), principalmente para falsificação de ARP. Se você seguir a rota IPv6 ou implementar as respostas ARP usando soquetes brutos, poderá remover essa dependência.
Contornar as detecções
Muitas detecções Kerberos baseiam-se em eventos 4769(Foi pedido um bilhete de serviço Kerberos). No entanto, o pedido de um bilhete de serviço utilizando um AS-REQ não produz eventos 4769, mas sim eventos 4768(Foi pedido um bilhete de autenticação Kerberos (TGT)).
A figura 12 mostra um evento 4768 quando um ST é solicitado através de um AS-REQ.
Por conseguinte, os atacantes que utilizam este método podem facilmente contornar muitas detecções que se baseiam em eventos 4769.
Outras consequências dos bilhetes de serviço solicitados por AS
Embora eu não tenha conseguido solicitar bilhetes S4U2self ao AS, os STs recuperados do AS não têm o Ticket Checksum (trazido para proteger os bilhetes S4U2self contra o ataque de bronze bit por Jake Karnes).
Por último, um ST solicitado ao TGS é geralmente devolvido com um PAC(Figura 13).
É possível solicitar um ST sem um PAC do TGS, mas para tal é necessário alterar o bit NO_AUTH_DATA_REQUIRED das contas de serviço no atributo useraccountcontrol(Figura 14).
Quando esta configuração está em vigor, o ST devolvido carece de um PAC, como mostra a diferença de tamanho do bilhete devolvido(Figura 15).
Um ST sem PAC pode ser solicitado ao SA simplesmente definindo a secção de dados PA-PAC-OPTIONS PA como falsa, acrescentando o interruptor /nopac ao Rubeus(Figura 16).
Esta abordagem pode ser utilizada como alternativa à criação de silver tickets, solicitando um ST sem um PAC e, em seguida, injectando outro PAC, incluindo-o na secção enc-authorization-data do pedido. Pode também fornecer outros potenciais caminhos de ataque.
Detecção de bilhetes de serviço solicitados por AS
Como a Microsoft aparentemente não acha que vale a pena corrigir esses problemas, a detecção de dentro da sua organização é a única opção. Como mostrado anteriormente, quando um ST é solicitado ao AS, o evento 4768 é registado(Figura 17).
Todos os bilhetes genuínos solicitados ao AS, incluindo os bilhetes kadmin/changepw, têm um Nome de Serviço e ID de Serviço de krbtgt(Figura 18).
A verificação do tráfego de rede para AS-REQs que não são para o krbtgt/domain ou kadmin/changepw também deve detectar esses pedidos(Figura 19).
Esta investigação, juntamente com a resposta da Microsoft, demonstra a necessidade de monitorização contínua e de medidas de protecção adequadas. A capacidade de contornar as detecções actuais e executar ataques eficazes, como o Kerberoasting, a partir de uma posição não autenticada é um problema sério que não deve ser ignorado. A investigação aqui descrita pode levar a novos ataques inovadores, potencialmente colocando as organizações em maior risco.
Assegurar a existência de detecções quando estes tipos de pedidos de bilhetes são feitos.
Agradecimentos
Gostaria de agradecer às seguintes pessoas pelas suas contribuições para esta investigação:
- Andrew Schwartz por me ter enviado por este caminho com o seu post Kerberos FAST (que também devia ler)
- Elad Shamir, por me ter deixado trocar ideias com ele
- Will Schroeder por escrever Rubeus
- Tomer Nahum, Sapir Federovsky e Andrea Pierini pela revisão deste post e pelas críticas
Linha do tempo
- 25 de Maio de 2022: Comunicado à MSRC
- 27 de Maio de 2022: O MSRC alterou o estatuto para Revisão/Reprovação
- 13 de julho de 2022: A MSRC respondeu que o comportamento era "intencional"
- 27 de Setembro de 2022: Divulgação pública
Saiba mais sobre a Investigação da Semperis
