Hijacking Playing with MIT Kerberos Authentication Tickets

I often end up reading about kerberos authentication especially MIT open source  version and Heimdal Kerberos authentication. Just an interesting protocol to read to understand bit more on  how MIT Kerberos Distribution Center (KDC) inner functionality works.

The objective with this article is to play with MIT KDC and some of the tricks i would use during authorized penetration testing and red team engagements to circumvent technical security controls and avoid blue team to recon, compromise and move laterally.

We all familiar with Windows Active Directory Key Distribution Center and widely deployed in large network enterprise – MIT Kerberos authentication provides similar authentication functionality used in Linux environments especially adding a Linux servers/services hassle free and works well with MIT KDC version.

Environment Lab Setup:

cryptolab.local  192.168.1.20 # Primary Key Distribution Center installed on Raspberry Pi

private.cryptolab.local 192.168.1.25 # Kerberbroised SSH service accepts Kerberos tickets as opposed to PAM Password based authentication

nebu.cryptolab.local 192.168.1.29  # SSH client uses kerberos keys to authenticate the SSH service.

Questions:
  • What would happen if someone gets hold MIT version kerberos ticket granting ticket cache ?
  • Can the stolen ticket be destroyed and will the attacker be able to reuse kerberos ticket in different user session?

 

The short answer to above questions – An attacker can steal valid tickets and use session for days even if the legitimate user destroys the ticket.  This is obviously subject to kdc configuration on the server side.

But but before we divine into MIT kerberos authentication a brief description would be a good starting point for those less familiar with Kerberos protocol.

The Kerberos protocol is designed to provide reliable authentication over open and insecure networks where communications between the hosts belonging to it may be intercepted.  No kerberos is not authorization protocol. One should be aware kerberos does not provide any guarantees if a system begin used are vulnerable/compromised.

In nutshell kerberos provides the following and more:
  • End user’s password must never travel over the network
  • User password never to be stored in any form on the client machine
  • User password should never be stored in unencrypted form even in the authentication server database.
  • User asked to enter password once per work session and access transparently access to all the authorized kerberorised services e.g. ssh a.k.a SSO ( Single Sign On)
#Install MIT kerberos 
apt-get install krb5-admin-server krb5-kdc 

Specify Realm in my lab i decided to name my realm CRYPTOLAB.LOCAL

1-krbconfigFigure 1 key distribution service kdc set to kdc.cryptolab.local and admin server to kdc.cryptolab.local on the same server.

 

Initial setup  on KDC server to setup realm master database similar to NTDS.dit in windows environment ( By default krb5_newrealm selects default realm CRYPTOLAB.LOCAL and master key is required to decrypt user TGT tickets.

2-krb5-newrealm-databasecretedFigure 2 master database is created.

kadmin  is kerberos database administration management

3-createkdc-principlesFigure 3 addprinc kdcadmin created a new  remote and local admin in window world this account known as domain administrator (DA)

addprinc pexsr as authenticated standard user

4-pexsr-user-createdFigure 4 pexsr standard authenticated user.

MIT Kerberos authentication supports kerberoised services allowing end users to authenticate ssh services using KDC instead of  traditional password authentication or public key authentication.

addprinc -randkey specifies that the encryption key should be chosen at random instead of being derived from a password.

5-create-randkey-sshFigure 5 kadmin.local we create network service for ssh server  private.cryptolab.local.

Service princiaples are needed for the following reasons:

  • To allow services to verify that service tickets were issued by ginuine Key Distribution Center
  • To allow end clients to verify that they are communicating with correct intended service.

Kadmin.local to create  a keytab for the ssh service. a keytab  is a file used to store encryption keys for the service principals – Keytab is used for obtaining a ticket granting ticket (TGT) so having an encryption key can be equated to having a password.

5-create-ssh-key-serviceFigure 6 ktadd used to create a private.keytab.

 

8Figure 7 secure copy from KDC to ssh server /etc/krb5.keytab.

Kdestroy – destroy Kerberos tickets utility to destroy users active kerberors tickets by overwritting and deleting the credential cache that contains them.

Even though we destroyed the TGT ticket  from the target system –  the ticket still valid on the system we copied the ticket over.  Its seems kdestroy utility on local and would not communicate to KDC to invalidate the ticket. An attacker with copy of ticket can have a valid session for at least 10 hours default  MIT kerberos ticket expire.

kdestroy

Figure 8 Kdestroy utility to remove the TGT ticket from local machine.

Kinit to obtain kerberos ticket granting ticket for user pexsr

kinitFigure 9 obtained  initial TGT ticket for user pexsr

Wireshark traffic capture from target machine KRB5 AS-REQ & AS-REP

7-forwardable-renewable

Figure 10 Key Distribution Center options shows Ticket Granting Ticket with Renewable flag set allows  TGT ticket to be renewed before expire time  subject to KDC configurations.

 

Imagine now an attacker have access to user pexsr workstation – it would be very simple to steal, transfer existing kerberos session to attackers control to maintain valid session.

8-krb-ticket-copiedFigure 11 /tm/krb5cc_1000 valid kerberos session issued by KDC for user pexsr copied to attacking machine.

Kdestroy – destroy Kerberos tickets utility to destroy users active kerberors tickets by overwriting and deleting the credential cache that contains them.

Even though we destroyed the TGT ticket  from the target system –  the ticket still valid on the system we copied the ticket over.  Its seems kdestroy utility on local and would not communicate to KDC to invalidate the ticket. An attacker with copy of ticket can have a valid session for at least 10 hours default  MIT kerberos ticket expire.

kdestroy

Figure 12 Now that we copied kerberos  key to our attacking machine /tmp folder  we can ssh to  kerberoised ssh  service and login to different servers/services using the stolen kerberos ticket.

kerberorized-ssh

Figure 13  successful ssh connection from attacker system.

Klist on the target SSH service shows the copy of stolen key /tmp/krb5cc_1000 still valid and the host/private.cryptolab.local SSH kerberosized ssh services authenticated with the stolen key as opposed to traditional Password authentication.

 

kerberos-ticket-still-validFigure 14  Klist  valid ticket granting ticket and ticket granting service for user pexsr with stolen kerberos ticket.

Summary:

  • Kerberos ticket can be copied to attacker machine for reuse and lateral movement
  • Kdestory is local ticket overwrite only no validation on the KDC server side and the ticket remains valid for 10 hours and it might be possible to renew it.
  • Set Strong complex master key database password
  • Enable auditing against kerberos authentication services

 

 

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s