Third KDC Spoofing Vulnerability Identified by Silverfort Researchers – This Time In IBM QRadar [CVE-2019-4545]

*****By Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach, Silverfort*****

KDC spoofing never gets old. We’ve disclosed KDC spoofing vulnerabilities in Cisco ASA and Palo Alto Networks PAN-OS back in May 2020. Now we can share that IBM QRadar is also vulnerable due to the way Kerberos has been implemented.
The KDC Spoofing vulnerability allows an attacker to bypass the Kerberos authentication to QRadar and, as a result, gain administrative access to the system. We have been working closely with IBM engineers to help fix this issue, resulting with the recently issued security bulletin . This blog post outlines the vulnerability, explains how to avoid these vulnerabilities as a developer implementing Kerberos and talks about mitigation for organizations using QRadar and other systems using Kerberos.

Explaining the Vulnerability

IBM QRadar Security Information and Event Management (SIEM) helps security teams detect and prioritize threats across the enterprise, and provides important insights that enable teams to respond quickly to reduce the impact of incidents.
The vulnerability lies in IBM’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.
IBM uses the Kerberos authentication protocol for authenticating administrative access. Therefore, bypassing Kerberos authentication allows an attacker to gain administrative access to IBM QRadar, view sensitive information and potentially alter logs – 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 the 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 the network traffic to authenticate to QRadar with any password, even a wrong one.

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

How We Discovered the Vulnerability in QRadar

Admin access to QRadar should be protected with strong authentication to prevent unauthorized access and system tampering. Using AD authentication is a popular option:
When an admin authenticates to QRadar, it uses a number of parameters to authenticate the admin (see below a snapshot of the implementation guide taken from here). First, QRadar requests a TGT from AD. After receiving the TGT, QRadar requests a service ticket for LDAP authentication to the domain controller. If successful, QRadar uses SASL to authenticate with LDAP to the DC. It uses the service ticket to prove the identity of the user.

Spoofing Kerberos/SASL authentication

Here are the steps an attacker will take to spoof a DC to bypass this kind of authentication. Lets assume that we have the ability to hijack the network communication between QRadar 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 QRadar and use the user and password we chose. QRadar 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 QRadar side relies on the password we chose, QRadar should not reject the authentication at this point. Now that QRadar received the service ticket, it can initiate an LDAP request to the DC. We will hijack the LDAP traffic as well. We have two options at this point:
1. LDAP is being used without TLS. In this case we can hijack the LDAP traffic. QRadar sends a bind request to the DC with a Kerberos AP_REQ message, which contains the service ticket we have. We can return an AP_REP that is based on the service session key we chose, and QRadar will accept it.
2. LDAPS has been configured. In this case we cannot return an answer on behalf of the DC, because TLS is being used to authenticate the DC, that is assuming the certificate has been configured on the QRadar side.

Spoofing Kerberos/SASL/LDAPS Authentication for QRadar

Before giving up on option 2, we noticed the following odd behavior. If we configure an IP address as the server URL, authentication still works. Theoretically, authentication with an IP address should not work, because Kerberos does not allow authentication to IP addresses unless a SPN has been explicitly configured.
When sending the TGS_REQ, QRadar requests a ticket to ldap/. Since the DC does not have a Service Principal Name (SPN) by that name, it returns a KRB_ERR_S_PRINCIPAL_UNKOWN error. According to the Kerberos protocol, QRadar is supposed to deny the authentication at this point. However, a network capture reveals that an LDAP request is opened even after the error, and immediately reset by QRadar. Then, the user is able to login. We conclude that QRadar considers the authentication as successful even before the completion of the Kerberos application exchange. This can be easily exploited. As attackers, we can send a KRB_ERR_S_PRINCIPAL_UNKOWN right after spoofing the AS_REP, and we can cause QRadar to accept an authentication with a password of our choice. The attack is depicted below.

An additional bug in QRadar causes it to request authentication from AD for a user that does not necessarily exists. QRadar has a built-in local admin user. It turns out that when attempting authentication with the admin user, QRadar first tries to authenticate to the DC with Kerberos. This username does not have to exist in AD. This makes the attack easier, because the username is known to the attacker in advance.

In addition, this bug could be considered a vulnerability on its own. Regardless of KDC Spoofing, if an attacker can obtain privileges for creating users in AD, e.g., by taking over a help desk account, the attacker can create a user called admin in AD. Then the attacker can use that user to authenticate to QRadar.

Exploitation

Now that we knew that the QRadar is vulnerable, we simulated an attack by redirecting the traffic between QRadar 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 QRadar administrator in the real domain. We configured that user’s password to be “1” in the fake domain.

We then tried the following situations:
– Regular login (Traffic not diverted) – we managed to login with the administrator’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.

IBM’s Mitigation

IBM’s approach to mitigate this vulnerability is simple and secure. Since the exact same functionality of authentication to QRadar can be achieved with LDAPS, the recommended mitigation is to simply switch from Kerberos to LDAPS authentication. After that you should install the patch by IBM. The patch will verify that the authentication is indeed set to LDAPS and fail if you haven’t switched to the LDAPS authentication yet. This is to make sure that your system is secure after the patch.

If you have been using Silverfort to secure authentication to your QRadar, you will need to also update the Silverfort policy for QRadar for protecting the LDAPS authentication rather than the Kerberos TGT request.

Prevention and Mitigation

Mitigation Steps for Security Professionals

1. Switch authenticationin your QRadar from Kerberos to LDAPS
2. Upgrade your QRadar to a fixed version
3. Update your Silverfort policy for QRadar 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 by yourself.

As a Developer

We recommend a few steps to make sure that your solution is not susceptible to KDC spoofing:
1. Validate that the implementation of Kerboros 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, it’s a red flag.
3. If you want to implement an authentication protocol yourself, you must follow the protocol RFCs 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?
We’ve discovered another KDC spoofing vulnerability and hope to write about it soon, but not before the vendor publishes a patch. Until then, stay tuned.

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 log ins, 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 the master key, which is also available to the KDC. After validation 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 you want to attack.
3. Create a user in the fake KDC with a password of the attacker’s choice. For demonstration, 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.

The 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.