Cisco AnyConnect SAML Vulnerability Allows for User Impersonation

On June 1st, Cisco released a high severity security advisory related to its implementation of an open source SAML 2.0 library. The advisory indicates that the library is affecting Cisco’s Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) appliances running AnyConnect, as well as other appliances.

The presence of Security Assertion Markup Language (SAML) on its own doesn’t mean multi-factor authentication (MFA) is used. However, SAML is commonly used by network operators and application owners to increase the security of their services by integrating with an identity provider (e.g., Okta, Duo, Azure MFA, etc.) to also provide MFA and single sign-on (SSO) services for a better user experience. This can help prevent a user’s or administrator’s compromised credentials from being used by a malicious actor. Unfortunately, the aforementioned vulnerability allows for an already authenticated attacker to impersonate another user, possibly increasing their level of access.

What Went Wrong With the SAML Library?

SAML uses an XML document called an ‘assertion’ to describe the authentication status, authorization and additional attributes relating to a user. These assertion messages pass through a client side application such as a browser or application (e.g., AnyConnect) from the identity provider. The client forwards these messages to the service provider, which in this case is the Cisco ASA or FTD firewall with which the client wishes to form a remote access VPN connection.

In the context of Cisco firewalls, they can trust these assertion messages because the messages are signed by the identify provider (IdP) with a key that the firewall can authenticate. The client can’t manipulate the signatures on the assertion messages because the messages can only be signed with a private key, and only the IdP has this private key. This is the foundation of public key infrastructure (PKI) in providing integrity and authenticity.

However, as Lasso (the SAML library used by these firewalls) describes in the vulnerability, the library fails to check the signature on all but the first assertion message. This allows for a malicious client to manipulate the assertion messages in a way that may allow for those messages to provide details which gives the client additional access to the application, without the firewall validating these messages.

What Does This Mean for AnyConnect?

Administrators can configure their Cisco ASA and FTD firewalls’ WebVPN feature to use a SAML IdP of their choice. This is a great option to help provide an additional level of security to user logins of a very public-facing application: AnyConnect. Because AnyConnect is most commonly deployed facing the Internet, and with an increased number of workers using remote VPN solutions like AnyConnect as a result of the pandemic, remote access VPNs have become a prime target for malicious actors. This issue is highlighted by the fact that similar vulnerabilities for multiple other vendors’ products have been identified and abused in full force recently as well.

When using SAML with AnyConnect, you typically authorize a successfully authenticated user to a specific group-policy. Normally a user is authorized based on an additional query to a Lightweight Directory Access Protocol (LDAP) server or Cisco Identity Services Engine (ISE) to define which group-policy a user should be associated with. It is within this group-policy where you can configure multiple security-related features that enforce what a user can and cannot do, such as:

• A split-tunnel access control list (ACL) which defines what routes the user will receive for forwarding traffic across the VPN towards the firewall
• A VPN filter ACL which restricts what the user can access when coming across their VPN tunnel
• The number of simultaneous logins a user can have
• The timeout value of the VPN connection
• A warning banner providing legal notification of how the VPN can be used
• For clientless remote access VPN, any internal applications that they would have access to

If you are providing remote access to employees whose devices you control and have additional security mechanisms in place to detect malware or prevent manipulation, your risk may be relatively low. However, remote access VPNs are also a means to provide business-to-business (B2B) connectivity where you don’t control the device on the far side.

You may not be able to enforce that a vendor’s laptop is running the latest antivirus and host-based intrusion detection systems (HIDS) software, fully patched, and so on. Although you may have restricted their access based on the group-policy they are assigned to, what if a malicious application or user on that vendor’s laptop could manipulate the SAML assertion to present themselves as a different user? For example, an employee with a different group-policy that provides broader network access? Because this security advisory indicates that the signatures of subsequent assertion messages aren’t validated, this scenario is entirely possible given the right conditions.

4 Recommendations for Remediating Exposure

Optanix has several recommendations that can help mitigate some level of exposure on your Cisco firewalls relating to this security advisory. Keep in mind that a device is never 100% safe from a security breach, but these recommendations are some steps you can take to reduce your exposure and increase security for your network firewalls. Below we describe four recommendations that relate to the features found to be vulnerable in the latest firewall security advisories from Cisco.

Recommendation #1: Patch Your Firewall Immediately

If you are running an affected version of software and the necessary features, we recommend reviewing the upgrade path within the advisory. Once a target version of software is identified, follow your change management procedures and patch as soon as you can.

Recommendation #2: Maintain a Regular and Frequent OS Patching Policy

Maintaining a regular and frequent OS patching policy is an effective proactive measure that you can take to secure your network devices. Once a security advisory is released to the public, hackers will quickly latch on to newly identified vulnerabilities and begin scanning for equipment that is affected. By having a well-defined patching policy and change management procedure in place, you can narrow the time between when the advisory announcement is made and when your devices are no longer affected.

Recommendation #3: Implement a Zero-Trust Security Policy

As this vulnerability relies on either a compromised client device or a malicious client, the security of your remote access solution can be increased by using a product like Cisco ISE. Through its posture and profiling capabilities, you can enforce minimum software versions and specific configurations on the client devices connecting to your remote access VPN before they are permitted onto the network.

Recommendation #4: Identify Third-Party Security Practices

As remote access VPNs are commonly used for B2B connectivity where you don’t control the client device, it is important to have conversations with your partners and vendors around security. Discuss with them what their security practices are and how they enforce these practices on client devices. Do their users have to use a company-provided device? Is the device running the latest AV/HIDS? How are applications controlled? Have your third-party users read and accept an acceptable use policy (AUP) that outlines what is and is not acceptable when using your VPN.

Security Assistance

Optanix maintains a security-first culture which we extend to all of our customer engagements. If you would like assistance with reviewing security advisories or implementing best practices, our team of enterprise networking professionals can help you. Optanix customers can get in touch by contacting your customer success manager (CSM) or by opening a service request (ESR) in the Optanix Platform. For prospective clients, please click here to engage with Optanix.

This blog post was authored by Brian Yaklin, a senior member of Optanix’s route/switch engineering team. It is part of an ongoing series of posts by Optanix engineers focusing on the importance of security in the IT management space.