Palo Alto Networks published an advisory about a KDC-spoofing vulnerability in PAN-OS  that was discovered and responsibly disclosed to Palo Alto Networks by Silverfort researchers Yoav Iellin, Yaron Kassner and Rotem Zach. The vulnerability affected all supported versions of PAN-OS, and all interfaces that used a Kerberos authentication profile. After disclosing the vulnerability, Palo Alto Networks fixed all supported versions of PAN-OS and published an advisory about it. The vulnerability can allow an attacker to bypass the Kerberos authentication to PAN-OS and gain access to the administrative interfaces to PAN-OS, as well as authentication to firewall sessions through the captive portal.

This vulnerability is similar to a KDC spoofing vulnerability our researchers discovered in Cisco ASA. It seems that the implementation of the Kerberos authentication protocol is not always completed correctly, leaving systems vulnerable to exploits.

Palo Alto Networks fixed this vulnerability in all versions of PAN-OS. We highly recommend deploying this patch to protect against an exploit.

This article outlines the KDC spoofing vulnerability in PAN-OS and shows how it can be used to bypass the authentication without knowing the password. It explains how to avoid these vulnerabilities as a developer implementing Kerberos as well as enterprises using Kerberos authentication to their systems.

Explaining the Vulnerability

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

Palo Alto Networks uses the Kerberos authentication protocol in many PAN-OS interfaces – for example, SSL VPN, Captive Portal or Administrator login. Therefore, bypassing Kerberos authentication allows an attacker to administer Palo Alto Networks Strata, bypass its security, and gain access to additional networks.

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 PAN-OS with any password, even a wrong one.

Discovering the Vulnerability in PAN-OS

We discovered the vulnerability when we tried to add Silverfort’s MFA to interfaces that rely on the Kerberos protocol, including the SSL VPN, Captive Portal and Admin Login. In order to set this up, we configured Kerberos as the authentication method and configured a matching MFA policy on the Silverfort side. A detailed explanation about the Kerberos protocol and KDC spoofing can be found at the end of this article.
As seen below, the network capture includes an AS-REQ and an AS-REP but no TGS-REQ:

The authentication was successful even though the TGS-REQ is required by the protocol and was missing from the authentication process. Since we already discovered a similar vulnerability with Cisco ASA, we wanted to verify this.

We went back and checked the Palo Alto Networks guide for configuring Kerberos authentication – below is a screenshot of the guide at that time:

We realized that we were not required to configure a keytab or a service password at any point of the configuration process. PAN-OS provides an option to configure a keytab, but it was optional. However, even if the keytab was configured, we saw that it was not used for the authentication process to the said interfaces. Without a keytab or a password, PAN-OS does not have the credentials required to validate the authenticity of the KDC. This means that PAN-OS is susceptible to KDC spoofing.

Attempting to Exploit the Vulnerability

Now that we knew that the PAN-OS is vulnerable, we simulated an attack by redirecting the traffic between PAN-OS and the KDC, in this case the 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 User Principal Name (UPN) as the PAN-OS administrator in the real domain. For this example we will call him ‘Bob.’ 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 Bob’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 Bob’s original password failed but logging in with the password “1” worked.

Prevention and Mitigation

Mitigation Steps for Security Professionals

1. First and foremost, upgrade your PAN-OS to a fixed version and make the required configuration changes detailed in the Palo Alto Networks advisory.
2. Continuously monitor your Kerberos authentication. Look for resources that request only AS_REQ. If there are no TGS_REQs, it’s a red flag.
3. Use Silverfort’s open source tool to search the authentication logs for services that don’t request service tickets.
4. See developer recommendations for any internally developed applications that implement Kerberos and systems you configured by yourself.
5. Silverfort customers are leveraging the step-up authentication capability with Palo Alto Networks should update their Silverfort MFA policy from a TGT policy to a service ticket policy after upgrading their PAN-OS.

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 3^rd party libraries properly – some 3^rd 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)

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 users log 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 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, who later co-founded Duo security, reported a technique used to bypass the Kerberos protocol in some situations:

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