Security researchers at Silverfort, provider of agentless authentication platform, identified a severe vulnerability that can enable hackers to gain control over Cisco Adaptive Security Appliance (ASA). All ASA versions are affected. After disclosing the vulnerability to Cisco, Cisco fixed all supported versions of ASA and published an advisory on it. The vulnerability (CVE-2020-3125) was assigned a CVSS risk score of 8.1 out of 10, which is considered “High.” This is because the vulnerability can allow an attacker to bypass the Kerberos authentication to Cisco ASA. Silverfort researchers credited for discovering the vulnerability are: Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach.

Cisco fixed this vulnerability in all versions of ASA. We highly recommend enterprises upgrade to the latest ASA versions to protect against an exploit.

This article outlines the KDC spoofing vulnerability and shows how it can be used to bypass authentication to Cisco ASA. It will explain how to avoid these vulnerabilities as a developer implementing Kerberos as well as enterprises that have already implemented these solutions in their networks.

Explaining the Vulnerability

The vulnerability lies in Cisco’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.

Cisco uses the Kerberos authentication protocol in many ASA interfaces – for example, VPN, opening firewall sessions, and administrative access, either through the web management console or through SSH. Therefore, bypassing Kerberos authentication allows an attacker to take over the Cisco appliance, bypass its security, and gain access to other 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 Cisco ASA with any password, even a wrong one.

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

How We Discovered the Vulnerability in Cisco ASA

We were looking for a way to add Multi Factor Authentication (MFA) to administrators accessing Cisco ASA and Anyconnect VPN. After configuring Cisco to use Kerberos as the authentication protocol, we examined the authentication logs in Silverfort’s console. Silverfort provides full visibility into all the authentication activities in the network. Silverfort’s logs showed that Cisco ASA was requesting a TGT without requesting a service ticket.

We went back to the configuration guide Cisco. 2007. PIX/ASA : Kerberos Authentication and LDAP Authorization Server Groups for VPN Client Users via ASDM/CLI Configuration Example. 30 July. ;  and looked at  the parameters required to configure Kerberos authentication:

As seen above, there is no place to enter the password or keytab configuration for Kerberos authentication. The password or keytab are required for a correct implementation since they create the ‘secret’ used by Kerberos to authenticate in a trusted way to the KDC. Without the ‘secret’, authentication cannot be cryptographically trusted.

We went ahead and tried the same for other Cisco interfaces and saw the same vulnerability exists when opening firewall sessions, administrative authentication and even when using SSH to access the VM. See below the Kerberos column in the table summarizing Cisco support for different authentication protocols.

Exploitation

Next, we wanted to see is this vulnerability can be exploited. For that, we hijacked the Kerberos traffic intended for the DC and diverted it to our server. Instead of developing our own KDC logic, we simply installed AD Domain Services on our rogue server, promoting our server to be a domain controller. Of course, not being an admin in the original domain, we created a new fake domain.

Since we know the username for the Cisco administrator in the first domain (Bob in this example), we created a user named Bob in our fake domain. We configured that user’s password in our fake domain to be “1”.

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 of all, upgrade your Cisco ASA to a fixed version and make the required configuration changes detailed in the Cisco 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 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 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, 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)