6.1 Kerberos Attacks

While it may not be possible for a hacker to feed your Kerberos KDC a spiced cake to put it to sleep, there are some electronic attacks that can compromise the security of your Kerberos system. Listed below are potential compromise scenarios, and their effect on the security of the Kerberos system.

• Root compromise of a Kerberos KDC machine. A root-level compromise of a KDC machine (master or any of the slaves) gives the attacker full control over the entire Kerberos authentication system. Even though the Kerberos database is encrypted on disk with the Kerberos master key, the master key is also kept on the KDC's disk so no manual intervention is required (to enter in the master password) when the KDC service is started. In addition, since all Kerberos implementations provide fail-safe access to the Kerberos database for the root or Administrator user on the KDC, your entire Kerberos database should be considered compromised in the event of attackers gaining root access to any KDC on your network. See Section 6.4 later in this chapter for tips on preventing a successful attack against your KDC.

• Compromise of a Kerberos administrator's credentials. If an attacker obtains the password of a Kerberos administrative principal, that attacker has complete access to the entire Kerberos database. Most KDC implementations allow administrators to remotely dump the contents of the database for backup purposes, and an attacker can use this functionality to make a complete copy of your authentication database. With full access to the database, the attacker can also create and modify any Kerberos principal. Ensure that only a very small set of users have administrative access, and set policies on those users that enforce strict password checking and at least monthly password changes.

• Root compromise of a server machine. For Kerberos's mutual authentication to work, a service must have access to a service principal. These service principals, as explained in Chapter 4, reside on the server's filesystem, either as part of a keytab typically used by Unix implementations, or the LSA Secrets in Microsoft implementations (see Q184017 on Microsoft's support site). If an attacker obtains root access to a server machine, all Kerberized services running on that machine are compromised. In addition, some services, such as the AFS distributed filesystem, share a single service principal across all servers. In this case, root access to an AFS file server machine would compromise all file and database servers in the AFS cell. Once an attacker has access to a service principal's credentials, the attacker can impersonate that service and also decrypt encrypted traffic sent between clients and the compromised service. The security of Kerberized services running on a server depends on the security of that individual server; therefore, all servers should be secured in proportion to the value of the resources stored on that server.

  It is important to note that while the compromise of a server machine does compromise the services running on that machine, it does not compromise individual users' credentials. At no time in the Kerberos protocol exchange does a Kerberos service receive any information that would allow it to reconstruct the authenticating user's password directly. However, it's still possible to mount a brute-force or dictionary attack against credentials presented to services, as the authenticator is encrypted with the user's long-term key.

• Root compromise of a client machine. A root compromise of a client machine will provide an attacker with all cached tickets on that machine. Since tickets are time-limited, it is not as critical a compromise as an attacker obtaining the users' password. However, with root access to a client machine, the attacker can surreptitiously install a keyboard sniffer to capture a users' password when logging into their machine. Therefore, when a client machine is compromised, passwords of all users who have logged into that machine should be considered compromised as well. In the event of a client compromise, the users who have logged into that client should immediately change their passwords.

• Compromise of user credentials. There are two possibilities in this scenario: either the user's credential (ticket) cache is exposed, or a user's password is compromised. If an attacker obtains a user's unencrypted credential cache, the tickets contained in that cache are only valid for the time period specified in the tickets. On the other hand, if an attacker acquires the user's password, the attacker can impersonate that user until the user changes his password.

From the above list, the one fact that underlies all of those scenarios is the importance of keeping all machines on your network secure. Installing Kerberos on your network does not diminish the importance of keeping all machines, even end user desktops, secure from outside attack. The compromise of any machine in your network will have some detrimental effect on the security of your Kerberos authentication system.

6.1.1 Other Attacks

Since Kerberos only provides an authentication service, there are several security threats that a Kerberos installation will not protect against. The following attacks are not attacks directly against the Kerberos system itself, but are problems related to providing a secure, available authentication service in general. These techniques can be used to attack any authentication system, and Kerberos is no exception:

Denial of service

A denial of service attack can be mounted against your organization's KDCs by flooding them with authentication requests. The large numbers of requests arriving can slow down response times to legitimate requests, or even, in extreme cases, crash the machines on which your KDCs reside. Kerberos cannot protect against denial of service attacks and it is generally recommended that your network, including your Kerberos KDCs, be firewalled from the Internet to prevent this type of attack. Adding additional KDCs to your network for redundancy can also mitigate the effects of a DoS attack.

The "insider"

Kerberos cannot protect against an internal authorized user who decides to misuse their privileges. For example, a rogue Kerberos administrator could modify or remove information from the Kerberos database.

Social engineering and password exposure

Similarly, Kerberos cannot protect against individual users who divulge their passwords to attackers, either inadvertently or as a result of a social engineering attack. The use of Kerberos does not diminish the importance of user training on keeping passwords secure and not revealing their passwords to anyone, including those who claim to be part of your computer staff. Similarly, Kerberos cannot prevent users from reusing their passwords at other, less secure sites that may handle passwords in the clear. Hackers who successfully attack a less secure site where a user has recycled their Kerberos password will obtain a valid username and password for your Kerberos realm.

Security holes in the Kerberos software itself

This risk cannot be overstated. Unfortunately, with the current state-of-the-art in software engineering, it is very difficult to write secure code. Just like all other software packages available, every Kerberos implementation has had security issues at some point or another, and these issues can sometimes lead to a compromise of your KDCs. Therefore, it is extremely important to keep informed of your Kerberos vendor's patches, and apply them as soon as they become available.

Now that we've covered the attacks that can be performed against a Kerberos network, we'll take a look at some security issues in the Kerberos protocol itself.