Protocolo Kerberos

O Kerberos é um protocolo de autenticação de rede e acesso a serviços amplamente utilizado em ambientes de Active Directory. Desenvolvido no MIT (Instituto de Tecnologia de Massachusetts) na década de 1980, o Kerberos foi projetado para resolver o desafio de autenticar a identidade de usuários e serviços em uma rede aberta e potencialmente insegura.

A principal função do Kerberos é fornecer autenticação, garantindo que apenas usuários e serviços legítimos tenham acesso aos recursos da rede. Ele opera na camada de aplicação do Modelo OSI e utiliza criptografia simétrica e assimétrica, dependendo da etapa, para proteger as informações de autenticação durante a transmissão.

O funcionamento do Kerberos envolve três componentes principais: o cliente, o servidor de autenticação, também conhecido como Key Distribution Center (KDC), e os servidores de serviços. O processo de autenticação envolve a geração e troca de tickets entre os componentes.

O Kerberos também oferece recursos de segurança, como autenticação mútua entre o cliente e o servidor e permite que os usuários autentiquem-se apenas uma vez (single sign-on), facilitando o acesso a vários serviços sem a necessidade de autenticação repetida. Além disso, o Kerberos é altamente flexível e escalável, permitindo sua implementação em uma variedade de ambientes, desde redes locais até redes corporativas distribuídas.

História

O Kerberos foi desenvolvido por Steve Miller e Clifford Neuman no MIT e entrou em uso em janeiro de 1987. Ele foi baseado no protocolo de chave simétrica Needham-Schroeder e foi originalmente projetado para proteger a rede do “Project Athena”. O projeto visava criar um ambiente de computação distribuída que fornecesse recursos de computação para estudantes e pesquisadores.

As primeiras três versões do Kerberos foram experimentais e não foram lançadas publicamente. A primeira versão disponível para o público foi a versão 4, que foi lançada em 24 de janeiro de 1989. No entanto, essa versão enfrentou restrições de exportação devido ao uso do algoritmo de criptografia Data Encryption Standard (DES), proibido pelo governo dos Estados Unidos para exportação para outros países.

Em 1993, foi publicada a versão 5 do Kerberos para corrigir algumas limitações e problemas de segurança das versões anteriores. Essa versão foi documentada na RFC 1510 e posteriormente atualizada pelo Kerberos Working Group da Internet Engineering Task Force (IETF) em 2005, na RFC 4120. Sendo essa a versão utilizada atualmente.

Para continuar o desenvolvimento e promover a adoção do Kerberos, o MIT criou o Kerberos Consortium em 2007. O consórcio é composto por várias empresas e instituições acadêmicas, incluindo a Apple, Google, Microsoft, MIT, Stanford University, entre outros.

Desde o Windows 2000, o Kerberos se tornou o principal meio de autenticação para clientes e serviços em um domínio. No caso de clientes e serviços não estarem no mesmo domínio, é utilizada a autenticação com NTLM. Além disso, sistemas operacionais baseados em Unix, como macOS, Linux, Red Hat, Solaris e outros, também implementam a autenticação por Kerberos V para clientes e serviços.

Componentes

O Key Distribution Center (KDC) é o coração do sistema Kerberos, sendo um servidor centralizado responsável pela autenticação dos usuários e criação dos tíquetes de identificação. No caso de ambientes de Active Directory, o KDC é o Domain Controller. Ele consiste em dois componentes principais: o Authentication Service (AS) e o Ticket-Granting Service (TGS).

O AS é responsável por autenticar os usuários que desejam acessar os serviços protegidos do sistema. Quando um usuário solicita autenticação, o AS verifica as credenciais do usuário e, se forem válidas, gera um tíquete de Autenticação (TGT) criptografado, que é enviado de volta ao cliente.

O TGS é o segundo componente do KDC e atua como um intermediário entre os clientes e os serviços protegidos. Quando um cliente deseja acessar um serviço específico, ele envia o TGT recebido do AS juntamente com uma solicitação de serviço ao TGS. O TGS verifica a autenticidade do TGT e, se válido, gera um Service Ticket (ST) criptografado, que é enviado de volta ao cliente.

Processo de Autenticação

O processo de autenticação do Kerberos envolve várias etapas e requer a interação entre o cliente, o AS, o TGS e o servidor de aplicação.

O cliente solicita um TGT ao AS a partir de uma mensagem AS-REQ. Essa mensagem contém o nome de usuário do cliente em texto claro e um autenticador, que é o registro de tempo encriptado utilizando a chave do cliente. Então o AS tentará descriptografar utilizando a chave do cliente que ele possui salva no seu banco de dados, caso consiga o cliente estará autenticado.

Com o cliente autenticado o AS responderá com uma mensagem AS-REP, que contém uma chave de sessão temporária e o TGT. A chave de sessão é aleatória e não fica salva no KDC, uma vez que o Kerberos é um protocolo sem estado, ela é enviada encriptada com a chave do cliente. Já o TGT contém todas as informações do cliente e uma cópia da chave de sessão, sendo encriptado utilizando a chave do KDC para que não seja alterado pelo cliente.

Agora que o cliente possui um TGT, ele pode solicitar ST para acessar os serviços que desejar. Essa requisição é feita por meio de uma mensagem TGS-REQ para o TGS. A mensagem contém o nome do serviço que se deseja acessar, o TGT recebido no passo anterior e um autenticador encriptado com a chave de sessão.

Como o KDC não tem salvo o chave de sessão, ele desencripta o TGT para extrair a que está no ticket e com ela verifica o autenticador recebido. Assim o KDC responderá com uma TGS-REP que contém uma nova chave de sessão para ser utilizada apenas entre o cliente e o serviço requisitado e um tíquete encriptado com a chave do serviço que contém as informações do usuário e essa nova chave de sessão. Todas essas informações são encriptadas utilizando a chave de sessão antiga do cliente com o KDC.

Agora o cliente pode finalmente enviar uma solicitação ao serviço de aplicação que quer utilizar, enviando uma mensagem AP-REQ. Essa mensagem contém o tíquete que recebeu do TGS e um autenticador encriptado com a nova chave de sessão. Como as informações do cliente estão no tíquete e este está encriptado com a chave do serviço, o cliente não consegue modificar suas permissões e níveis de acesso.

Com o autenticador e o TGS desencriptado, o serviço poderá saber todas as informações do cliente e ter certeza que são válidas. Com a autenticação concluída é retornada uma mensagem AP-REP para o cliente. O Kerberos é apenas um protocolo de autenticação e não de autorização, então o serviço utilizará outros protocolos para verificar se o cliente pode realmente ter acesso ao que ele está requisitando.

Como pode ser visto, todo o processo depende de chaves compartilhadas e é um trabalho entre as três entidades. O protocolo protege usuários e serviços contra roubos e repetição de tíquetes, pois os invasores não saberiam as chaves para emitir autenticadores válidos.

Mensagens

Como pode ser visto acima, cada mensagem do processo de autenticação possui um padrão específico com informações diferentes. Mas também existem outros tipos de mensagens além das que foram mostradas que são utilizadas em outros casos pelas entidades.

Alguns exemplos de outras mensagens são o KRB-ERROR que contém o máximo de informações sobre erros que acontecem para que uma das entidades consiga lidar com o erro, essa mensagem não possui nenhum tipo de proteção. E o KRB-CRED para transmitir credenciais entre aplicações que não possuem nenhuma relação prévia.

Tickets

Anteriormente foi mostrado as informações básicas de cada tíquete, já nessa seção será explicado cada campo presente nos tíquetes de acordo com a RFC 4120. No processo de autenticação do Kerberos V5, os tickets são compostos por duas partes: uma parte encriptada e outra não encriptada.

A parte não encriptada do tíquete é formada pelos campos tkt-vno, realm e sname. Já a parte encriptada contém os seguintes campos: flags, key, crealm, cname, transited, authtime, startime, endtime, renew-till, caddr e authorization-data.

O campo tkt-vno especifica a versão do Kerberos utilizada. Neste caso, trata-se da versão 5, portanto, esse campo é sempre definido como 5. O campo realm descreve uma rede lógica, similar a um domínio, que define um grupo de sistemas sob o mesmo KDC para o qual o tíquete é válido. Por fim, o campo sname identifica exclusivamente uma instância de um serviço.

O campo flags indica as opções que foram utilizadas ou solicitadas durante a emissão do tíquete. Cada opção é representada por um bit específico, podendo estar ligado ou desligado. As opções são as seguintes: forwardable, forwarded, proxiable, proxy, may-postdate, postdates, invalid, renewable, initial, pre-authent, hw-authent, transited-policy-checked e ok-as-delegate. Essas opções ocupam os bits de 1 a 13, enquanto os bits 0 e 14 a 31 são reservados para uso futuro.

Em seguida, o campo key armazena a chave de sessão. O campo crealm contém o nome do realm ao qual o cliente pertence, e o campo cname é o identificador único do cliente. O campo transited é uma lista dos realms pelos quais a autenticação do usuário do tíquete passou.

Os próximos quatro campos são registros de tempo. Eles indicam, respectivamente, quando o usuário foi autenticado, a partir de quando o tíquete é válido, a data de expiração do tíquete e a data máxima para renovação, esse último apenas utilizado quando a flag renewable está presente.

O campo caddr representa os endereços a partir dos quais o cliente pode utilizar o tíquete. Essa informação visa prevenir que atacantes copiem e o enviem a partir de outras máquinas. Esse campo pode ser nulo, representando qualquer endereço, ou conter uma lista de endereços.

Como o Kerberos é exclusivamente um protocolo de autenticação, não realiza validações sobre se um usuário possui os privilégios necessários para acessar um serviço específico. Nesse sentido, o campo authorization-data informa todos os privilégios do usuário, que serão utilizados pelo serviço para realizar a autorização.

Problemas e Limitações

Apesar do Kerberos ser um protocolo robusto que tem sido amplamente utilizado por muitos sistemas ao longo do tempo, ainda existem certos problemas e limitações em suas capacidades, principalmente em relação à sua implementação.

Se um usuário escolher uma senha fraca, é possível que um atacante consiga deduzi-la ou realizar um ataque de força bruta para descobri-la, uma vez que o protocolo não possui proteção contra esses tipos de ataques. Além disso, se um atacante obtiver o hash da senha, é possível se passar pelo usuário, uma vez que o hash é usado para criptografar as requisições, conforme explicado anteriormente.As chaves secretas utilizadas pelo KDC são um ponto de vulnerabilidade significativo do protocolo. Se essas chaves forem comprometidas, é possível gerar tickets para qualquer serviço em nome de qualquer usuário.

Uma grande limitação do protocolo é que os serviços precisam ser modificados para se integrarem ao Kerberos e aceitarem os tíquetes. Nem todos os serviços suportam esse tipo de autenticação. Os registros de tempo presentes nos tíquetes são elementos essenciais do Kerberos. Portanto, todas as máquinas que aceitam a autenticação precisam ter seus relógios sincronizados com o KDC, minimizando a diferença de tempo entre eles.

Por fim, outra limitação está relacionada à disponibilidade do KDC. Se o KDC não estiver disponível por algum motivo, os usuários não conseguirão acessar nenhum serviço do domínio. Para mitigar esse problema, é possível usar vários KDCs dentro de um domínio, mas então surge a questão da sincronização adequada das informações em seus bancos de dados.

Ataques

Com o passar dos anos foram descobertas vários pontos fracos e configurações incorretas que podem ser exploradas para atacar o Kerberos. Os principais ataques são conhecidos como Kerberoasting, Golden Ticket e Silver Ticket.

O ataque Kerberoasting é uma técnica utilizada por invasores para obter acesso a contas de serviço no ambiente Kerberos. Nesse tipo de ataque, o invasor busca identificar contas de serviço que possuam serviços associados e cujas chaves de serviço estejam armazenadas no banco de dados do Kerberos. Uma vez identificadas essas contas, o invasor pode solicitar um tíquete de serviço para uma dessas contas e, em seguida, descriptografar a chave de serviço contida no tíquete.

A vulnerabilidade explorada no ataque Kerberoasting reside no fato de que as chaves de serviço são criptografadas com uma chave derivada das senhas das contas de serviço. Um invasor com acesso ao tíquete de serviço pode extrair a chave criptografada e usar técnicas offline para tentar quebrar essa criptografia, visando recuperar a senha original da conta de serviço. Uma vez que o invasor obtenha a senha da conta de serviço, ele pode comprometer a integridade e a segurança dos sistemas e serviços associados a essa conta.

O ataque Golden Ticket é uma técnica utilizada por invasores para obter acesso privilegiado e persistente em um ambiente que utiliza o protocolo Kerberos. Nesse tipo de ataque, o invasor compromete a chave do KDC, conhecida como “KRBTGT”, e gera um tíquete de autenticação conhecido como “Golden Ticket”. Esse tíquete permite ao invasor se autenticar como um usuário legítimo, concedendo acesso total aos sistemas e serviços protegidos pelo Kerberos, sem a necessidade de fornecer credenciais válidas.

O ataque ocorre quando o invasor obtém acesso privilegiado ao controlador de domínio do Kerberos, permitindo-lhe extrair a chave KRBTGT. Com essa chave, o invasor pode gerar um tíquete de autenticação válido para qualquer usuário ou serviço, com um tempo de vida longo e permissões amplas. O Golden Ticket permite que o invasor se autentique sem a necessidade de autenticar-se com um servidor de autenticação. Como resultado, o invasor obtém controle total sobre o ambiente, podendo acessar recursos, espionar atividades e até mesmo criar novas contas de usuário com privilégios elevados.

No ataque Silver Ticket, o invasor consegue gerar um tíquete de serviço falsificado, conhecido como “Silver Ticket”, para obter acesso não autorizado a recursos protegidos pelo Kerberos. O ataque ocorre quando o invasor obtém acesso a uma chave de serviço válida, geralmente por meio de comprometimento de uma conta de serviço ou exploração de vulnerabilidades. Com o Silver Ticket em mãos, o invasor pode se autenticar como um serviço legítimo no ambiente Kerberos, concedendo acesso aos recursos associados a esse serviço. O tíquete falso é criado usando a chave de serviço comprometida, permitindo ao invasor burlar a autenticação legítima e acessar recursos, como sistemas, servidores e bancos de dados, sem ser detectado.

Referências

SALTZER, J. H. On the Origin of Kerberos. IEEE Annals of the History of Computing, v. 43, n. 1, 2021. Disponível em: https://web.mit.edu/Saltzer/www/publications/Kerberosorigin.pdf. Acesso em: 04 de junho de 2023.

LI, H. Kerberos (Protocol). Encyclopedia. Disponível em: https://encyclopedia.pub/entry/31033. Acesso em: 04 de junho de 2023.

PAES, L. M. J. A.; ALBUQUERQUE, P. P. B. Kerberos. Universidade Federal do Rio de Janeiro. Disponível em: https://www.gta.ufrj.br/grad/07_1/kerberos/index.html. Acesso em 01 de julho de 2023.

NEUMAN, C.; TS’O, T. The Kerberos Network Authentication Service (V5). Request for Comments, n. 1510. RFC Editor, 1993. Disponível em: https://www.rfc-editor.org/info/rfc1510. Acesso em: 04 de junho de 2023.

NEUMAN, C.; et al. The Kerberos Network Authentication Service (V5). Request for Comments, n. 4120. RFC Editor, 2005. Disponível em: https://www.rfc-editor.org/info/rfc4120. Acesso em: 30 de junho de 2023.

Hack The Box Academy. Kerberos Attacks. 2023. Disponível em: https://academy.hackthebox.com/module/details/25. Acesso em: 01 de julho de 2023.

KOHL, J. T.; et al. The Evolution of the Kerberos Authentication Service. IEEE Computer Society Press, 1991. Disponível em: https://www.cs.fsu.edu/~awang/courses/cop5611_s2023/kerberos.pdf. Acesso em: 05 de junho de 2023.