Elad Shamir

Algumas pessoas são um martelo em busca de um prego, mas eu sou um martelo em busca da delegação Kerberos. Por isso, quando ouvi dizer que um WriteSPN edge foi introduzido no BloodHound 4.1, comecei a explorar técnicas alternativas de abuso para além do Kerberoasting direccionado, e encontrei um caso limite (trocadilho intencional) que pode ser encadeado com o Kerberos Constrained Delegation.

Tl;dr

Suponha que um atacante compromete uma conta definida para Delegação Restrita, mas não tem o privilégio SeEnableDelegation. O atacante não será capaz de alterar as restrições (msDS-AllowedToDelegateTo). No entanto, se o atacante tiver direitos WriteSPN sobre a conta associada ao SPN alvo, bem como sobre outra conta de computador/serviço, o atacante pode temporariamente sequestrar o SPN (uma técnica chamada SPN-jacking), atribuí-lo ao outro computador/servidor e efectuar 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.

Serei o primeiro a admitir que esta não é uma descoberta inovadora, mas pode reavivar caminhos de ataque aparentemente sem saída em determinadas circunstâncias. O SPN-jacking também pode ser uma técnica alternativa de aquisição se o RBCD ou as Shadow Credentials não forem viáveis.

Manual de delegação Kerberos

A delegação Kerberos é um mecanismo que permite aos serviços fazer-se passar por utilizadores para 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 com 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

Suponhamos que existem três servidores no ambiente: ServidorA, ServidorB e ServidorC. O ServerA está configurado com Delegação Restrita para um determinado SPN. O atacante comprometeu o ServerA e a conta NotAdmin, que tem direitos WriteSPN em contas de computador/serviço no ambiente. O objectivo do atacante é comprometer o ServerC.

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 afectado ao ServerC e depois executar o ataque S4U completo utilizando a conta do ServerA para obter um bilhete de serviço para um utilizador privilegiado no ServerC.

O nome do serviço desse bilhete não seria válido para aceder ao ServerC porque 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 é encriptado para ServiceC, e o nome do serviço não está na parte encriptada do bilhete, pelo que o atacante pode alterá-lo para um 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 ServerB e só depois adicionando-o ao ServerC. O atacante pode então executar o ataque S4U completo utilizando a conta do ServerA para obter um bilhete de serviço para um utilizador privilegiado no ServerC.

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 (Uma conta de computador foi alterada) no controlador de domínio. Os detalhes do evento mostram os atributos alterados e seu novo valor. Os Defensores podem detectar SPNs com um nome de anfitrião diferente dos nomes DNS do computador, conforme mostrado 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.