Kerberos is a network authentication system that can help solve those two
issues. It reduces the number of passwords each user has to memorize to use an
entire network to one the Kerberos password. In addition, Kerberos incorporates
encryption and message integrity to solve the second issue, ensuring that
sensitive authentication data is never sent over the network in the clear. By
providing a secure authentication mechanism, Kerberos is an essential part of a
total network security plan, providing clear benefits for both end users and
administrators. It is important to recognize that implementing Kerberos on
your network does not guarantee perfect security. While Kerberos is extremely
secure in a theoretical sense, there are many practical security issues to be
considered. In addition, it is important to remember that Kerberos provides only
an authentication service; it does not prevent compromises caused by buggy
server software, administrators granting permissions to unauthorized users, or
poorly chosen passwords.
While most documentation on the subject of Kerberos security simply says to
"secure the KDC," there is much more to the story of Kerberos security than
turning off unnecessary services on your KDC machines (although that is
certainly good advice!). In this article, we will begin with a discussion of
potential attacks against your Kerberos authentication system, follow up with
steps that should be taken to prevent these attacks, and finally examine
Kerberos KDC logs. After reading this article, you should understand the
security implications that Kerberos presents and how to protect your network
from the attack scenarios presented.
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.
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, 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.
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
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.
Protocol Security Issues
First, let's revisit the
underlying reason why the Kerberos protocol was developed. Kerberos was designed
to protect authentication data from passing over a network in the clear. Before
Kerberos, when a user wished to log into a remote service, the client software
would pass the user's credentials (a password) to the server in clear text.
Since networks are broadcast mediums, where every station connected to a network
segment can "hear" all traffic on that segment, sending passwords in the clear
over a network is extremely insecure. Therefore, Kerberos encrypts all
authentication exchanges that occur over the network. Encryption is only part of
the solution, however, and the designers of Kerberos have put much thought into
ensuring as secure a system as possible.
Dictionary and Brute-Force
Attacks In the original Kerberos 4 protocol, the KDC issues an
encrypted TGT to any client that requests it. The security of the entire system
is dependent on not being able to decrypt this message, since if an attacker is
able to retrieve the key used to encrypt the message, he now has the user's
password and can impersonate that user at will. Therefore, if an attacker wishes
to obtain a user's password, he can ask the KDC for a valid TGT for the victim's
username. While there are no ways to break the encryption methods used in
Kerberos tickets directly, the attacker can then continue to brute-force the
decryption of the TGT by launching an offline dictionary attack.
During a
dictionary attack, an attacker feeds a list of commonly used passwords, or a
dictionary, to a cracking program. For each entry in the dictionary, a program
attempts to decrypt the message using the password. If a hit is made, the
program reports back to the attacker the user's password.
This method is
made possible since there is a known plaintext included in the TGT, namely the
string "tgt" itself. The Kerberos Ticket Granting Service principal name is
always "krbtgt," and that principal name is the signal that indicates a
successful decryption. By the time the attacker has successfully determined the
password, the now unencrypted ticket has expired; however, the attacker now has
a valid username/password combination to the Kerberos server and can obtain new
tickets using that valid username and password.
Replay
Attacks Another attack that can be mounted against Kerberos is known
as a replay attack. Since all protocol exchanges are simply electronic messages
that are sent over a computer network, an attacker can listen to the network
messages involved in a successful authentication exchange, make a copy of the
messages, and replay them at a later time. The attacker doesn't need to guess
the users' password or decrypt any messages in this scenario. Since the replay
attack requires access to listen to all network messages as well as the ability
to send fake messages, a replay attack is an active
attack.
Man-in-the-Middle Attacks Finally, a
man-in-the-middle attack affects most any protocol that attempts to verify the
identity of connection endpoints (in this case, a user and the machine they wish
to reach). A man-in-the-middle attack is an active attack, meaning that the
attacker must be able to read all messages on the network as well as send out
arbitrary messages of his own design
The goal of the man-in-the-middle
attack is to impersonate the server, resulting in the user thinking that he
connected to the legitimate server, when in fact he is talking to the attacker.
Once the attacker has control of the session, she can act as a simple
pass-through (passing messages between the user and the legitimate server,
without modification), or she can actively inject, modify, or delete messages
between the user and the server. The attacker now is part of the conversation
between the user and the legitimate server, and can modify any messages that
pass through her, hence the name "man-in-the-middle."
The good news is
that the Kerberos protocol has built-in protection against man-in-the-middle
attacks. Since Kerberos performs mutual authentication, by confirming not only
the end user's identity but also the server's identity, man-in-the-middle
attacks are thwarted.
To prevent against man-in-the-middle attacks, some
mechanism to validate the server's encryption key must exist. Other protocols
use manual verification (such as Secure Shell, where the "fingerprint" of the
server's public key is printed on the screen when the user first connects), or
signing authorities (in the case of SSL-enabled web sites). Kerberos uses the
fact that a copy of all of the keys for both services and users are stored on
the KDC to ensure protection against man-in-the-middle attacks. Since the
session key generated by the KDC and then sent to the service is encrypted with
the service's key, an attacker cannot recover the session key without the
service's secret key.
A client can then detect whether the server he is
talking to is genuine by requesting mutual authentication, where the server must
demonstrate her identity by recovering the session key, encrypting a response,
and sending it back to the client. If the server is not genuine, and does not
have a copy of the service key, then the server cannot send back a valid
encrypted message, and the client disconnects.
While Kerberos provides
the ability to perform mutual authentication, applications must have code to
enable that protection. In addition, several applications, such as the PAM
modules available for authentication against Kerberos passwords, do not use the
ticket-based authentication process. Instead, they take in a password over the
network (hopefully encrypted) and verify it on the server side by asking the KDC
for a TGT and then decrypting the TGT. This is where a practical
man-in-the-middle attack can be mounted against Kerberos.
Security
Solutions
Now that you have a solid understanding of the security
issues and limitations of Kerberos, let's examine how to work around these
limitations and ensure that your Kerberos implementation is as secure as
possible.
First, choose a Unix operating system that you are intimately
familiar with. Good selections for a dedicated KDC machine include the free Unix
systems, such as FreeBSD, OpenBSD, and Linux. These operating systems can be
downloaded for free, include full source code, and are well supported by the
online community, which addresses security issues quickly. Other Unix operating
systems such as Solaris are also good choices, but more care must be taken in
preparing commercial operating systems, as they usually ship with more network
services enabled by default.
When installing the operating system, choose
the smallest distribution of software possible. Since there will not be any
users directly logging into this machine's console, do not install X Window
System servers or clients, or desktop environments such as CDE, Gnome, and KDE.
The only optional component that should be installed is a C compiler to compile
the KDC software, if you are going to use one of the open source Kerberos
implementations.
After operating system installation, download and
install all recommended security patches applicable to your operating
system.
An important factor in the security of your KDC is its network
visibility. It is important to disable all network-based services on your KDC
other than the KDC software itself, as well as a Secure Shell server if remote
login is required. To determine what network services are installed, use the
netstat command from a shell prompt
The focus on securing the KDC should
not end with the successful implementation of a Kerberos network authentication
system; the administrator must continue to monitor security mailing lists, such
as Bugtraq, and vendor-specific mailing lists that announce the latest security
patches for both the operating system and the Kerberos KDC software. While
keeping the KDC up-to-date with security patches may cause occasional downtime
and service outage, it saves days of lost productivity caused by reinstalling
the KDC, re-keying all services, and resetting all user passwords in the
aftermath of an intrusion
Be first to comment this article
