Elad Shamir

Há quem seja um martelo à procura de um prego, mas eu sou um martelo à procura da delegação Kerberos. Por isso, quando soube que tinha sido introduzida uma funcionalidade «WriteSPN» no BloodHound 4.1, comecei a explorar técnicas alternativas de exploração para além do «Kerberoasting» direcionado e descobri um caso-limite (trocadilho intencional) que pode ser combinado com a delegação restrita do Kerberos.

Tl;dr

Suponha que um atacante comprometa uma conta configurada para «Delegação Restrita», mas não possua o privilégio «SeEnableDelegation». O atacante não conseguirá alterar as restrições (msDS-AllowedToDelegateTo). No entanto, se o atacante tiver direitos de escrita (WriteSPN) sobre a conta associada ao SPN alvo, bem como sobre outra conta de computador/serviço, poderá sequestrar temporariamente o SPN (uma técnica denominada «SPN-jacking»), atribuí-lo ao outro computador/servidor e realizar um ataque S4U completo para o comprometer.

Além disso, se o SPN alvo não estiver actualmente associado a nenhuma conta, o atacante pode apropriar-se dele de forma semelhante.

Sou o primeiro a admitir que esta não é uma descoberta revolucionária, mas pode reativar vias de ataque que parecem não ter saída em determinadas circunstâncias. O «SPN-jacking» também pode ser uma técnica alternativa de tomada de controlo caso o RBCD ou as «Shadow Credentials» não sejam viáveis.

Manual de delegação Kerberos

A delegação Kerberos é um mecanismo que permite que os serviços assumam a identidade dos utilizadores perante outros serviços. Por exemplo, um utilizador pode aceder a uma aplicação front-end e essa aplicação pode, por sua vez, aceder a uma API back-end utilizando a identidade e as permissões do utilizador.

A delegação Kerberos está disponível em três tipos: Delegação sem restrições, Delegação com restrições e Delegação com restrições baseada em recursos (RBCD).

Delegação sem restrições

A delegação sem restrições exige que os utilizadores enviem o seu bilhete de concessão de bilhete (TGT) para o serviço front-end (servidor A). Em seguida, o serviço front-end pode utilizar esse bilhete para se fazer passar pelo utilizador para qualquer serviço, incluindo o serviço back-end (Servidor B).

Delegação condicionada

A Delegação Restrita permite que o serviço front-end (Servidor A) obtenha bilhetes de serviço Kerberos para os utilizadores numa lista predefinida de serviços especificados pelo seu Nome Principal de Serviço (SPN), tal como o serviço back-end, Servidor B.

Note-se que a Delegação Restrita permite que o serviço se faça passar por utilizadores a partir do nada, quer estes se tenham autenticado no serviço ou não. Muitos pensam que isso depende da configuração do atributo TrustedToAuthForDelegation. No entanto, quando encadeada com a Delegação restrita baseada em recursos, essa limitação pode ser contornada, como explico nesta publicação do blogue.

Delegação condicionada baseada em recursos

O RBCD é muito semelhante à Delegação Restrita, excepto que a direcção da restrição é invertida. Ele especifica quem tem permissão para delegar a um serviço e não a quem o serviço tem permissão para delegar. Por outras palavras, se o Servidor A tiver permissão para delegar no Servidor B na Delegação Restrita, a restrição seria configurada num atributo do Servidor A. No RBCD, seria configurada num atributo do Servidor B.

Outra diferença importante entre a Delegação Restrita e o RBCD é que a Delegação Restrita especifica o SPN do serviço de destino. Em contrapartida, o RBCD especifica o SID do serviço de origem num Descritor de Segurança.

Privilégios necessários

A configuração da Delegação Unconstrained e da Delegação Constrained requer o privilégio SeEnableDelegation, que, por predefinição, é concedido apenas aos Administradores de Domínio. Por conseguinte, mesmo que um utilizador tivesse controlo total (GenericAll) sobre uma conta AD, não poderia configurar qualquer um destes tipos de delegação Kerberos sem ter também o privilégio SeEnableDelegation. Ao contrário da Unconstrained Delegation e da Constrained Delegation, o RBCD requer o direito de alterar o atributo msDS-AllowedToActOnBehalfOfOtherIdentity, mas não requer privilégios especiais.

Note-se que os utilizadores necessitam de privilégios especiais para alterar a configuração da Delegação Restrita, mas não são necessários privilégios especiais para alterar os SPN. Por conseguinte, pode ser interessante abordar cenários com o compromisso da Delegação Restrita de um ângulo diferente - manipulando o atributo SPN em vez da configuração da delegação.

Preparar o terreno

Suponha que existam três servidores no ambiente: ServidorA, ServidorB e ServidorC. O ServidorA está configurado com «Delegação Restrita» para um determinado SPN. O atacante comprometeu o ServidorA e a conta NotAdmin, que possui direitos «WriteSPN» sobre contas de computador/serviço no ambiente. O objetivo do atacante é comprometer o ServidorC.

Roubo de SPN fantasma

O primeiro cenário é o mais simples. O ServidorA está configurado para Delegação Restrita a um SPN anteriormente associado a um computador ou conta de serviço que já não existe. Pode ser um SPN padrão, como cifs/hostname, associado a uma conta de computador/serviço eliminada ou a uma conta computorizada renomeada se os SPNs forem actualizados em conformidade. Ou a conta pode ser um SPN personalizado com uma classe de serviço não padrão que foi removida da conta de computador/serviço, ou a própria conta pode não existir mais.

Neste cenário, o atacante pode adicionar o SPN afetado ao ServerC e, em seguida, executar o ataque S4U completo utilizando a conta do ServerA para obter um bilhete de serviço de um utilizador com privilégios no ServerC.

O nome do serviço desse bilhete não seria válido para aceder ao Servidor C, uma vez que o nome do anfitrião não corresponderia e a classe do serviço poderia ser inútil. No entanto, o importante é que o bilhete está encriptado para o Serviço C e o nome do serviço não consta da parte encriptada do bilhete, pelo que o atacante pode alterá-lo para um nome válido.

Finalmente, o atacante pode passar o bilhete e comprometer o ServidorC.

A cadeia de ataque é ilustrada no diagrama seguinte:

O ataque é demonstrado na seguinte captura de ecrã:

SPN-jacking em directo

O segundo cenário é um pouco mais artificial. O ServidorA está configurado para Delegação Restrita a um SPN actualmente associado ao ServidorB, e o atacante tem direitos de WriteSPN no ServidorB e no ServidorC.

Em ambientes totalmente corrigidos, apenas os Administradores de Domínio podem configurar SPNs em conflito, ou seja, SPNs associados a duas ou mais contas diferentes. Por conseguinte, se o atacante neste cenário tentasse adicionar o SPN alvo ao ServidorC, o DC rejeitaria essa alteração porque já está associado ao ServidorB.

O atacante pode contornar essa barreira removendo temporariamente o SPN alvo do Servidor B e só depois adicionando-o ao Servidor C. O atacante pode então executar o ataque S4U completo utilizando a conta do Servidor A para obter um bilhete de serviço de um utilizador com privilégios para o Servidor C.

Tal como no cenário anterior, o nome do serviço desse bilhete não seria válido para aceder ao ServidorC. No entanto, o importante é que o bilhete é encriptado para o ServerC e o nome do serviço não está na parte encriptada do bilhete, pelo que o atacante pode alterá-lo.

Finalmente, o atacante pode passar o bilhete e comprometer o ServidorC.

Um atacante bem comportado deve também reverter as alterações, removendo o SPN alvo do ServerC e restaurando-o no ServerB.

A cadeia de ataque é ilustrada no diagrama seguinte:

SPN-jacking com a classe de serviço HOST

A situação torna-se mais interessante quando o SPN alvo não é definido explicitamente. Por predefinição, as contas de computador têm SPNs associados às classes de serviço TERMSRV, RestrictedKrbHost e HOST. Se forem instalados outros serviços, como LDAP ou SQL Server, também são adicionados SPNs adicionais para esses serviços.

A classe de serviço HOST é mapeada para as seguintes classes de serviço por padrão:
alerter, appmgmt, cisvc, clipsrv, browser, dhcp, dnscache, replicator, eventlog, eventsystem, policyagent, oakley, dmserver, dns, mcsvc, fax, msiserver, ias, messenger, netlogon, netman, netdde, netddedsm, nmagent, plugplay, protectedstorage, rasman, rpclocator, rpc, rpcss, remoteaccess, rsvp, samss, scardsvr, scesrv, seclogon, scm, dcom, cifs, spooler, snmp, schedule, tapisrv, trksvr, trkwks, ups, time, wins, www, http, w3svc, iisadmin, msdtc.

Se o atacante tentasse visar uma classe de serviço mapeada para HOST, o controlador de domínio rejeitaria adicionar essa classe de serviço ao ServerC, mesmo que não esteja directamente associada ao ServerB. O atacante teria primeiro de remover os SPNs HOST do ServerB e depois adicionar explicitamente o SPN alvo ao ServerC. No entanto, depois de adicionar o SPN de destino ao ServerC, o atacante pode adicionar os SPNs HOST de volta ao ServerB sem encontrar quaisquer erros de validação, apesar de já ter um SPN mapeado associado ao ServerC, como demonstrado na seguinte captura de ecrã:

Ao solicitar bilhetes de serviço para o SPN ambíguo, cifs/SERVERB na captura de ecrã acima, o Controlador de Domínio emite-os para o ServidorC e não para o ServidorB.

A cadeia de ataque é ilustrada no diagrama seguinte:

Como é que os atacantes podem utilizar o SPN-jacking?

Se um atacante comprometesse uma conta com direitos GenericAll ou GenericWrite em contas de computador, o atacante poderia usar RBCD ou Shadow Credentials para comprometer o host ou serviço associado. Suspeito que o comprometimento de uma conta com direitos apenas de WriteSPN em contas de computador não é muito provável. No entanto, encadeado com o comprometimento de um anfitrião com Delegação Restrita já configurada, os atacantes podem utilizar esta técnica em ambientes onde o RBCD e as Credenciais Sombra são monitorizados ou bloqueados. Os defensores devem seguir as recomendações abaixo para mitigar os ataques de SPN-jacking.

Detectar o SPN-jacking

As alterações ao atributo ServicePrincipalName de uma conta de computador geram eventos de segurança com o ID 4742 (Foi alterada uma conta de computador) no controlador de domínio. Os detalhes do evento mostram os atributos alterados e os seus novos valores. Os utilizadores do Defender podem detetar SPNs com um nome de anfitrião diferente dos nomes DNS do computador, conforme ilustrado na captura de ecrã abaixo:

A remoção da classe de serviço HOST de uma conta de computador também pode ser suspeita.

O ataque S4U gera dois eventos de segurança com o ID 4769 (Foi solicitado um bilhete de serviço Kerberos).

O primeiro evento é para o S4U2Self. Os defensores podem detectá-lo quando as informações da conta e as informações do serviço apontam para a mesma conta, como mostra a captura de ecrã abaixo:

O segundo evento é para o S4U2Proxy. Os Defensores podem detectá-lo quando o atributo Transited Services não está em branco, como mostra a captura de ecrã abaixo:

Evitar o SPN-jacking

Os defensores podem aplicar várias tácticas para evitar este tipo de abuso:

  • Auditoria regular do Active Directory para Delegação Restrita apontando para SPNs fantasmas
  • Auditar regularmente o Active Directory para detectar direitos anómalos de WriteSPN
  • Adicione todas as contas privilegiadas ao grupo Utilizadores Protegidos para bloquear quaisquer tentativas de se fazerem passar por elas através da delegação Kerberos

Os atacantes podem manipular o SPN de contas de computador/serviço para redireccionar a Delegação Restrita pré-configurada para alvos não pretendidos, mesmo sem obter privilégios de SeEnableDelegation.

Embora os cenários descritos neste artigo não sejam comuns, podem apresentar caminhos de ataque viáveis quando uma conta comprometida está configurada para Delegação Restrita que, de outra forma, seria considerada benigna ou como alternativa ao RBCD e às Credenciais Sombra.

Os defensores devem tomar as medidas necessárias para detectar e prevenir tais ataques.

Referências

Este post também foi publicado em shenaniganslabs.io e eladshamir.com.