SAML Implementation Vulnerability Impacting Some Akamai Services
This blog post provides an overview of a vulnerability discovered in Akamai's Enterprise Application Access (EAA) product which has been patched. This vulnerability could have allowed an actor to impersonate an authorized user when interacting with an application that used Security Assertion Markup Language Version 2 (SAMLv2, referred to as SAML in this document) to authenticate users.
Following the initial notification from a third party, Akamai engineers identified that the vulnerability was in Lasso, a third-party, open source library which implements the SAML v2.0 authentication protocol. Lasso is the library that Akamai EAA uses to verify SAML assertions for applications when a customer configures SAML authentication with third-party identity provider(s) (IdPs). Further investigation of the Lasso library determined that the weakness had a wider impact on other software which has Lasso as a dependency.
A comprehensive fix was deployed to the EAA network as of March 4th, 2021. No updates were required for the EAA connector appliances or the EAA Client. Akamai has determined that the SOGo and PacketFence packages maintained by Inverse, a company recently acquired by Akamai, also depend on Lasso for deployments using SAML for authentication. The SOGo package was also subject to another independent but related vulnerability, CVE-2021-33054. Information about the impact on SOGo and PacketFence may be found here. We have verified that all other external facing applications provided by Akamai, including Akamai Control Center, are not vulnerable to this attack vector.
The Lasso vulnerability has been assigned the CVE ID CVE-2021-28091. Due to the severity of this vulnerability, Akamai is urging all EAA customers who make use of the third-party SAML authentication feature of EAA for their applications to review their systems for potential past impersonation attacks by an internal actor. Akamai is also urging all users of the Lasso library or software that depends on Lasso to review their announcement and patch as soon as possible and to review their applications for impersonated access. The fix is available in Lasso 2.7.0. Suggestions on how to conduct an investigation into potentially affected systems are listed in the Actions Required section below.
Detailed information about the vulnerability is documented in a companion technical blog covering the in-depth technical details as well as the discovery, triage, patching, and notification processes for this vulnerability.
As part of the fix, Akamai added logging for incorrectly signed SAML responses. At the time of publication, all cases of incorrectly signed SAML responses logged on the EAA platform were not indications of compromise, but related to configurations being set up, where failures are expected, and tests to verify that the vulnerability had been fixed.
A brief explanation of the vulnerability
This vulnerability would have been triggered when a SAML response was provided to a SAML Service Provider (SP) which had an additional, unsigned assertion appended to the end of the SAML response body. This behavior was possible when an actor injected an unsigned, but otherwise well-formed, assertion for another user at the end of the SAML response document.
This vulnerability potentially allowed actors with access to a well-formed SAML response for an organization--typically authenticated users, but potentially compromised endpoints or malicious proxies--to modify their identity and impersonate another user within the same organization. The SAML response, or its individual assertions, could be signed, but the portion of the SAML response inserted by the attacker need not have been signed for the attack to succeed. To exploit this issue, the attacker would need to have had a valid credential for an Identity Provider(s) (IdP) or have obtained the credentials to authenticate as a valid user. We categorize the potential impact in four ways - enabling impersonated network access -- both unauthenticated and authenticated -- impersonated application access, and an alternative Lasso dependency for applications that rely on the Lasso library - as discussed below.
Vulnerability impact
The following three impact categories apply to Akamai EAA:
For EAA configurations where SAML was used to authenticate to Akamai for an access decision for a given application, unauthorized users could have reached the applications over the network, including bypassing application Access Control Lists (ACLs) or other access controls. This is functionally equivalent to the imposter being able to reach the target system on the local area network, which will be referred to as impersonated network access for this report. The risks associated with impersonated network access depend on the type of applications being accessed:
(1) Unauthenticated Applications: the risks associated are the same as any application where end users have full access by virtue of being on the same local area network.
(2) Authenticated Applications: the risks for this type of application are inherently lower by virtue of the application implementing its own authentication.
For EAA configurations which extend credentials to the application itself, through the use of Application-facing Authentication Mechanisms such as Kerberos constrained delegation, Header Authentication, or OpenID Connect, the application session user could impersonate a different user, which will be referred to as (3) impersonated application access for this report.
For applications which fall into the categories above, only those that use SAML for communication with a third party IdP which provides assertions to Akamai were vulnerable. EAA Applications using other authentication mechanisms like OpenID Connect (OIDC) or OAuth to communicate with third-party IDPs do not use the vulnerable section of Lasso. Additionally, Application configurations using the Akamai IDP feature were not vulnerable to this weakness. Further details about the vulnerability in the library will be discussed in our companion blog.
Review of our software indicated that this vulnerability has been present in the EAA service since the version 1.0 release in Q1 2014. Investigators should assume that the vulnerability has been present from the time third-party SAML support was added in the Customer's configuration until the 5th of March, 2021 when the patching of the EAA network was complete.
The final category of exposure applies to entities using the Lasso library. Most applications that rely on the Lasso library for SAML authentication may be subject to this user impersonation vulnerability. This will be referred to as (4) alternative Lasso dependency for this report.
Identification, patching and disclosure timeline
In the evening of Tuesday, February 23rd, 2021, Akamai received a notification of this issue from an engineer in Best Buy's Enterprise Information Protection team. Shortly after receiving the notification, Akamai's Information Security team reviewed the report and started our Incident Management process. Between the start of the incident and the customer patch notification early on February 27th, 2021 UTC, Akamai engineers recreated the issue in the report, implemented the fix, and began to investigate customer impact. Akamai published its customer notification about the patch shortly after 1 AM UTC, about an hour after the fix was handed off to our QA team. Our QA team then began the work of verifying the fix and ensuring the stability of the new release ahead of the scheduled rollout. The rollout started on March 2nd and was completed on March 4th.
During the investigation and fix stages of the response, we determined that the vulnerability in our platform was related to the Lasso library. Further investigation of the Lasso library determined that the weakness may have a wider impact on other software which has Lasso as a dependency. While working to patch the vulnerability on our network, Akamai's engineers and Akamai's Information Security team started the process to responsibly disclose the issue to the maintainers of the library and other verified users of Lasso.
To limit the impact to other users of the library, Akamai restricted its distribution of information related to the vulnerability to those involved with patching and coordinated vulnerability disclosure. The restrictions we applied are in line with industry standard responsible disclosure procedures and are intended to reduce the likelihood of further exploitation of the vulnerability.
During the time between our patch being fully deployed and this report being published, Akamai worked collaboratively with the Lasso maintainers, downstream consumers of Lasso, and CERT/CC to patch and coordinate the disclosure of this issue to as many impacted parties as reasonable in a safe and timely manner.
Actions required
As a result of the impact stated above, we recommend the following actions be taken based on the impact categories listed above.
For current or former customers, including those with current or former trial deployments, who have at any point used a third-party SAML IdP to authenticate with EAA, the following actions should be taken based on the impact categories:
Impersonated Network Access for Unauthenticated Applications: Users who are impersonating another user for systems that do not require authentication may have been the target of exploits that attempted to exfiltrate or modify data, system processes or application functionality. Responding to these applications should be treated the same way as if an attacker with access to a valid user credential had direct local area network access to the application in question. If group restrictions or any other user restriction controls were in place for the Application in the EAA portal, the restrictions should be reviewed considering what actions users who violated that control may have been able to take or what security goals were being implemented with that control.
Impersonated Network Access for Authenticated Applications: much like the prior category, this method would allow for one user to impersonate another user at the network connection level, but by the nature of the application implementing its own access control and authorization outside the EAA system, these applications may require less scrutiny. Barring additional vulnerabilities or weaknesses in the applications own authentication and authorization system, direct network access would not inherently imply that one user could impersonate another. Consideration should be given to these applications as to their potential categorization as having an alternative Lasso dependency (discussed below).
Impersonated Application Access: Applications in this category should be more carefully scrutinized due to the nature of the vulnerability described in this report. This category may be present in two forms.
The Application-facing Authentication Mechanisms will forward the improperly verified, impersonated user identity on to the origin application, allowing the actor to take any actions within the target application as if they were the impersonated user. This applies to Web applications that do not implement their own authentication system but rely on the identity assertion from the EAA platform.
The Remote Desktop Protocol (RDP) Auto-login feature for RDP applications which relies on administrator-provided credentials to access the origin RDP server. When user access to an RDP application is restricted by group membership, one user may impersonate another user in the allowed group, making use of the provided credentials, thus accessing the RDP service as if they were the impersonated user.
Administrators of the origin system should closely scrutinize those systems to rule out any unexpected software or configurations which may have been installed by an attacker, including malware, rootkits, or kernel extensions. Administrators should also consider if these applications could have allowed someone to pivot to additional access beyond their regular authorization. For persistent, long-lived sessions, administrators should consider terminating all such long-lived connections which started before March 5th, 2021. Additionally, for applications that manage user accounts, access control lists, authorization tokens, security infrastructure, or any other sensitive/high-value systems, administrators should take special care to review and verify that no unexpected changes were made.
For any developers, maintainers, or administrators of software that uses the Lasso library, due to the alternative Lasso dependency category listed above, Akamai recommends that you upgrade to the 2.7.0 release Lasso as soon as possible. Like in the above categories, system administrators should review actions of end users for anomalous usage patterns as impersonation attempts are unlikely to be logged. For software packages that depend on Lasso, monitor for patching notifications if the package has an established distribution channel. Updated Debian, Ubuntu and RedHat packages are expected to be released within hours of this post, if not before this report's publication.
Examples of how the vulnerability can be exploited
Impersonated network access of unauthenticated applications
Using EAA to access unauthenticated applications means that EAA is acting as an authenticator and authorizer to gain access to those applications and not proxying any authentication information to them. If an environment makes use of EAA to allow or deny access to unauthenticated applications, those internal applications would have no way of knowing that the user being presented to them is impersonated.
In this scenario, administrators would need to consider the impact of having users not authorized to access the application being able to connect to the application. For example, if the application processed only public information, the impact would be low, whereas if the application processed sensitive or regulated data, the impact could be potentially high.
Also, administrators of the application would need to analyze their application level logs for activity that may indicate an account was impersonated. Log analysis may show examples of user activity that did not conform to general, regular usage patterns, such as accessing the application at unusual times or accessing data or processes in the application that the user would not usually access.
Impersonated network access of authenticated applications
When using EAA to access applications that provide their own authentication, the risk this vulnerability may have placed on that application is lower than compared to that of unauthenticated applications. Successful impersonation of the EAA session would not affect authentication performed by the application.
Log analysis may show examples where someone authenticates as one user over EAA and as another user within the application. This analysis would give administrators hints as to whether or not someone had attempted to exploit the vulnerability to gain unauthorized access.
Administrators of applications in this category should review if the authentications done by the application itself made use of Lasso and thus were potentially in the alternate lasso dependency category as well.
Impersonated application access
When EAA passes the identity used for the EAA session to an application, the application assumes that the identity has been validated. Should an application session be created using an impersonated user, the application would assume the impersonated user is the true user. Successful impersonation could occur in this case when Kerberos constrained delegation, Header Authentication, or OpenID Connect (OIDC) were used when forwarding identity information to your application.
In the case of the RDP Application Auto-login feature, the actor who impersonates another user would be able to access the RDP service as if they were the impersonated user, using the administrator-provided credential to connect to the origin service. While the administrator-provided credential would not be exposed to the actor, access to the system would be granted as if the impersonated user were taking the action.
As with other cases, log analysis could help administrators find sessions that were behaving unusually based on the timing and nature of the activity.
Alternate Lasso dependency
Beyond any dependency on Lasso by EAA, any application that makes use of Lasso is likely affected by this vulnerability. Developers should review their code bases to understand if their applications make use of the Lasso library, and, if so, they should update the library or mitigate its impact as soon as possible. If you rely on an application which has Lasso as a dependency, monitoring that application for updates is suggested, allowing administrators to patch as soon as they are able. This vulnerability has been fixed in Lasso version 2.7.0.
Logging and forensics
As stated in the impact section above, the scope of the actions required is quite broad, this is informed by multiple factors:
The potential window of exposure for this vulnerability spans back to at least 2016, if not further.
The EAA platform only archives configurations for a period of 90 days after the configurations are deleted or superseded. Thus, Akamai is unable to determine if an EAA application configuration met the conditions for vulnerability for configurations that were deactivated more than 90 days ago.
The authentication component in EAA did not have sufficient logging to detect if this vulnerability was being exploited. During our testing of this vulnerability, Akamai made multiple attempts to explore the available logging information to determine if exploitation was identifiable, but the information logged could not confirm or rule out potential exploitation of this vulnerability. To limit the potential exposure of end user authentication tokens, and to preserve the secrecy and privacy of customer authentication tokens, Akamai also does not log the SAML assertions which we validate.
In response to this fix, new logging has been added to the EAA platform to detect malformed authentication attempts, which is how this attack would appear to EAA following the patch. At the time of publication, all fraudulent authentication attempts were attributed to post deployment regression testing,verification by the reporting party that the issue had been resolved, third-party IdPs with expired certificates and IdPs which were not configured correctly.
Acknowledgments
We would like to thank:
Best Buy, their Enterprise Information Protection team and Sam Tinklenberg for reporting the user impersonation vulnerability in EAA to us.
Entr'ouvert, the maintainers of the Lasso library for their assistance in patching and disclosing this vulnerability as well as for their continued maintenance of the library.
CERT/CC for helping us to disclose both of these vulnerabilities, as well as the entities that were contacted to quickly respond to this issue for their efforts.
Additional information
We encourage anyone with further questions to review our companion post, for EAA Customers who have additional questions, please contact Akamai Technical support.
