Silverfort Researchers Discover KDC Spoofing Vulnerability in F5 Big-IP [CVE-2021-23008]

Last year we reported three Key Distribution Center (KDC) spoofing vulnerabilities in Cisco ASA, Palo Alto Networks PAN-OS and IBM QRadar. We did mention another one was coming, and now that F5 has issued a fix, we’re publishing the fourth KDC spoofing vulnerability we’ve identified – this time in Big-IP.  The KDC Spoofing vulnerability allows an attacker to bypass the Kerberos authentication to Big-IP Access Policy Manager, bypass security policies and gain unfettered access to sensitive workloads. In some cases this can be used to bypass authentication to the Big-IP admin console as well. We have been working closely with F5 engineers to help fix this issue, resulting in the recently issued advisory. This blog post outlines the vulnerability, explains how to avoid these flaws when implementing Kerberos, and discusses mitigation steps for customers using Big-IP and other Kerberos-based systems.

Explaining the Vulnerability

F5 Big-IP Application Delivery Services is a solution that delivers applications in a secure and scalable manner. One of its core components is Access Policy Manager (APM), which manages and enforces policies to ensure access is properly authenticated and authorized. APM is sometimes also used to protect access to the Big-IP admin console.

The vulnerability lies in F5’s implementation of the Kerberos protocol. Kerberos is the most common authentication protocol for on-premise authentication. It is widely used in corporate networks due to the popularity of Active Directory, and it is preferred over weaker authentication protocols such as NTLM.

Kerberos can be used as an authentication protocol for authentication required by an APM policy. When a user accesses an application through Big-IP, they may be presented with a captive portal and required to enter a username and password. The username and password are verified against AD with the Kerberos protocol to ensure the user is who they claim they are. Therefore, bypassing Kerberos authentication allows an attacker to gain access to Big-IP applications, without having legitimate credentials.

For the Kerberos protocol to work, three things should happen:

1. The user authenticates to the server
2. The server authenticates to the client
3. The KDC authenticates to the server

Apparently, KDC authentication to the server is often overlooked. Perhaps because requiring it complicates configuration requirements. However, if the KDC does not authenticate to the server, the security of the protocol is entirely compromised, allowing an attacker that hijacked network traffic to authenticate to Big-IP with any password, even an invalid one.

For Kerberos terminology and background about how a KDC spoofing attack works, see the end of this blog post.

Below is a screenshot of the instructions for configuring AD authentication for an access policy, taken from the F5 website.

After this configuration, when a user attempts to authenticate to an app sitting behind the proxy, the user is challenged to enter a username and password. When the user enters their password, the product uses Kerberos to authenticate to the domain controller (DC). However, APM does not request a service ticket and grants access based on a successful AS_REP.
Unlike with other scenarios, F5 lets you configure an admin username and password.

Theoretically, this password could be used to authenticate the DC and prevent the vulnerability. However, it is not used for these purposes, but only for the purpose of fetching primary or nested groups, prompting the user for a password change, or performing a complexity check or a password reset.

Spoofing Kerberos authentication

Here are the steps an attacker can take to spoof a DC to bypass this kind of authentication. Let’s assume that we have the ability to hijack the network communication between Big-IP and the DC. In this case, we can create a fake DC with a username identical to the admin’s username and a password of our choice. Then we initiate an authentication to Big-IP and use the user and password we chose. Big-IP authenticates with Kerberos, and we hijack the Kerberos communication and return an AS_REP that corresponds to the password we chose; and a TGS_REP that consists of a service ticket, encrypted with a service session key of our choice, and a session key of our choice, encrypted with the password that we chose. Since at these phases the only verification that is done on the Big-IP side relies on the password we chose, Big-IP will allow the authentication.

Exploitation

We simulated an attack by redirecting the traffic between Big-IP and the KDC (in this case a domain controller) on port 88 (the Kerberos port) to our own Windows Server. We set up a fake domain on the windows server and made sure there is a user with the same UPN as the Big-IP administrator in the real domain. We configured that user’s password to be “1” in the fake domain.

We then tried the following scenarios:

• Regular login (Traffic not diverted) – we managed to login with the user’s original password, as expected. When trying the password “1”, the login failed.
• Logging in with the traffic diverted to our fake DC – logging in with the administrator’s original password failed, but logging in with the password “1” worked.

Prevention and Mitigation

Mitigation Steps for Security Professionals

1. Upgrade your Big-IP to a fixed version
2. If a fixed version is not available for the version of Big-IP you are using, make sure MFA is enabled.
3. Update your Silverfort policy for Big-IP accordingly
4. Continuously monitor your Kerberos authentication. Look for resources that request only AS_REQ. If there are no TGS_REQs, it’s a red flag.
5. Use Silverfort’s open source tool to search the authentication logs for services that don’t request service tickets.
6. See developer recommendations for any internally developed applications that implement Kerberos and systems you configured yourself.

For Developers

We recommend a few steps to make sure that your solution is not susceptible to KDC spoofing:

1. Validate that the implementation of Kerberos requires a password or keytab: To validate the DC, you need to use some kind of shared secret. If your solution does not enable configuring a keytab file, or a service account password, the application is surely susceptible to KDC spoofing.
2. Run Wireshark – use Wireshark to see what Kerberos requests are sent during authentication. If there is no TGS_REQ, this is a red flag.
3. If you want to implement an authentication protocol yourself, you must follow the protocol specification diligently. We recommend taking the easier route and using an existing implementation of these protocols.
4. Use 3rd party libraries properly – some 3rd party libraries require specific configuration to avoid KDC spoofing. For example, a common library used for Kerberos called pam-krb5, has to have a keytab configured to work properly. Here is the relevant paragraph from their documentation (https://github.com/rra/pam-krb5/blob/master/README.md)

What’s Next?

I am sure this is the last KDC spoofing vulnerability we will ever encounter.

Background

An overview of the Kerberos Protocol

The Kerberos authentication protocol was developed in the 1980s by Steve Miller and Clifford Neuman. It allows Single Sign-On (SSO) in a managed network and its Active Directory (AD) implementation has turned it into the primary authentication protocol for on-premises enterprise environments.
The protocol consists of three exchanges to provide mutual authentication for the user and the server accessed. When the user logs in, they enter their credentials and the Authentication Service (AS) exchange takes place. The user gets a Ticket Granting Ticket (TGT), which is later used to obtain tickets to specific services during the Ticket Granting Service (TGS) Exchange. The ticket is then used during the Client/Server Exchange to complete the authentication:

1. Authentication Service (AS) Exchange

During the AS exchange the user authenticates with the Key Distribution Center (KDC). In return, the user obtains the ticket and key required to authenticate with services in the network without re-entering the credentials. When the user first enters the credentials, the client sends an AS_REQ to the Authentication Service (AS) function of the KDC. The AS_REQ is a message signed by the Master Key, which is a function of the user’s password. The Authentication Service, which is part of the KDC, verifies the AS_REQ according to the master key, which is also available to the KDC. After validation of the AS_REQ, the KDC returns an AS_REP, which contains a logon session key and a Ticket-Granting Ticket (TGT), that is encrypted with the KDC’s key. The AS Exchange is outlined below. The TGT will be used by the TGS exchange to obtain access to specific services.

2.Ticket-Granting Service (TGS) Exchange

When the user attempts to access a service in the network, the user sends a TGS_REQ to the Ticket Granting Server (TGS) function of the KDC. This message is encrypted with the logon session key, which is obtained during the AS Exchange. The TGS_REQ is verified by the TGS, which then returns a TGS_REP. The TGS_REP contains a service session key and a service ticket, which is encrypted with the master key of the server that hosts the service. The master key of the server in a Unix-based system is configured in a file called a keytab file. The master key of the server in a member server is derived from the computer account’s password. The TGS Exchange is outlined below.

3.Client/Server Exchange

Now the client has everything it needs to authenticate to the service. The client sends an AP_REQ to the service, which is encrypted with the service session key. The service decrypts the service session key to validate the AP_REQ. Then the server returns an AP_REP message and the authentication is complete. The client server exchange is outlined below:

Spoof-Proof Protocol

When the Kerberos protocol is implemented correctly, an attacker attempting to impersonate the KDC cannot bypass the authentication. That is because even if an attacker successfully creates a valid AS_REP in response to a hijacked AS_REQ, the attacker will never be able to engineer a valid service ticket. Since the service ticket is encrypted with the server key, a key that the attacker does not have, that would be impossible.

What is KDC Spoofing?

In 2000, Dug Song reported a vulnerability that affects the Kerberos protocol (Song, Dug.2000. Kerberos KDC Spoofing Vulnerability. 28 August.).

He discovered that certain implementations and configurations of Kerberos clients fail to execute the Client/Server exchange, and allow the authentication based on the success of the previous exchanges. Unfortunately, this behavior is not secure, and can be exploited by an attacker. An attacker that is able to hijack the communication between the client and the DC, can take the following steps:

1. Create a fake KDC.
2. Obtain a username authorized to access the service they want to attack.
3. Create a user in the fake KDC with a password of the attacker’s choice. For example, let’s call this password ”1”.
4. Authenticate to the service with the obtained username and the password ”1”.
5. Hijack the communication from the client to the DC and divert it to the fake KDC.
6. During the AS Exchange, return an AS_REP that corresponds to the password ”1”, the fake KDC key, and a fake logon session key.
7. During the TGS Exchange, return any TGS_REP.
8. The client will accept the authentication without performing an application exchange.

KDC spoofing attacks assume the attacker is able to hijack traffic to and from at the KDC and answer on the KDC’s behalf. This can be done using a variety of techniques. For example, if the attacker is within the same physical network segment as the client, it can perform an ARP spoofing attack as outlined in Network Security Hacks (Lockhart 2007).  Another possible approach is to take over a networking device such as a switch or router and control the communication from there.

Acknowledgements

The research and discovery of this vulnerability was a joint effort with Thierry Van Steirteghem, who worked at Exclusive Networks at the time of discovery.