SAML Vulnerability FAQ (Feb 27, 2018) Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka02a000000u92tsac&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2fsaml-vulnerability-faq-feb-27-2018
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Average Rating:
SAML Vulnerability FAQ (Feb 27, 2018)
Published: Feb 27, 2018   -   Updated: Mar 1, 2018

Summary:

On February 27, 2018, CERT announced a recently discovered SAML vulnerability in some SAML implementations which threat actors could use to elevate permissions and impersonate privileged accounts.  Details about the reported vulnerability can be found here.

Okta was made aware of the vulnerability before the public disclosure and immediately patched all of our systems. Okta is not vulnerable to this vulnerability, and we have no indication that the vulnerability was exploited within our systems.  

The following FAQ has been made available to our customers to help understand the issue and answer any questions you may have.

 

How does the SAML vulnerability work?

Security Assertion Markup Language (SAML) is an XML-based markup language for security assertions regarding authentication and permissions. By modifying SAML content without invalidating the cryptographic signature, a remote, unauthenticated attacker may be able to bypass primary authentication for an affected SAML service provider.  More simply, this means that through the vulnerability, if an attacker is able to create or successfully compromise an account, he or she could use this vulnerability to add comments to an attribute in order to get access to a privileged account, like an administrator account. Two examples:

By creating or compromising nonadmin@company.com, an attacker could use non<comment>admin@company.com to potentially get access to either "non" or admin@company.com – the latter of which giving privileged access into an organization.

An attacker targeting SAML assertions that deal with groups could escalate privileges by performing the same type of attack as the userID, but with changing group membership at the time the service provider parses authentication.

While these are two examples, the threat actor could use any SAML attribute to exploit this vulnerability. It is important to note though that the threat actor must first obtain access to either a created or compromised account in order to exploit this vulnerability.

You can read more about the vulnerability here.

 

How did Okta find out about the vulnerability?

Security research teams look for vulnerabilities in order to find – and patch – them before a threat actor can exploit a vulnerability. They are a critical part of the security community, exploring a variety of technologies to catch problems before they can be exploited. Our own research team, Okta REX (Research and Exploitation), publishes research on our security blog. We also work with organizations like Bugcrowd to expand coverage of our internal attack team by adding a solid bench of diversity and breadth of capabilities.

In this case, another security research team found a vulnerability in a technology we leverage at Okta. Before they published the research, they worked with an organization called CERT as a part of their Responsible Disclosure process to notify us of the vulnerability so we could patch prior to the research was made public.

 

What did Okta do once notified?

After US-CERT reached out to notify us of the vulnerability, we immediately performed a thorough investigation and patched our systems. Okta is not vulnerable to this vulnerability, and we don't have any indication that the vulnerability was exploited in our systems.

As such, no actions need to be taken by our customers in their Okta deployment. However, our partners and customers do have a separate step to take in order to mitigate threats acting on this vulnerability in other applications.

 

What do I need to do?

Customers: Reach out to your SAML service providers — such as those that provide SaaS applications — to make sure they have evaluated the vulnerability and if needed, taken the steps required on their end to mitigate threats acting on this vulnerability. If applicable, you should also check your own custom SAML integrations to see if a patch needs to be applied.

We have created a simple draft email template for you to send to service providers to confirm.  If applicable, you should also check your own custom SAML integrations to see if a patch needs to be applied.


          Subject: SAML Vulnerability

          <SAML Service Provider>,

          On Feb, 27th, the team at Okta made me aware of a vulnerability which can impact some SAML implementations, according to CERT.  Details on the vulnerability can be found here: 

                  https://www.kb.cert.org/vuls/id/475445

          Can you please confirm whether this vulnerability impacts your SAML Application?  If your app is impacted, can you please provide a timeline when this risk will be mitigated?

          Thank you,

          [Your Name]

We are also compiling a list of the top third-party SAML applications which inter-operate with the Okta platform as they confirm with us whether the vulnerability has been addressed within their own environment.  We have reached out to these providers and have published the list here.  Note, the accuracy of this list is dependent upon the service providers self-reporting to Okta.


Partners/ISVs: Once you have performed your own investigation and patched, please reach out to patch@okta.com and we will add you to our customer-facing website.


What is Okta doing to help Partners and ISVs? 

Okta has published the following article targeted towards Developers and ISV's to provide a developer oriented perspective on the vulnerability and how to protect your SAML integrations.

 

Why didn’t Okta tell partners this was happening before the announcement? Couldn’t they have been patched in advance, too?

Okta is not able to share information in a Zero Day because of the restrictions of the responsible disclosure. We did however make the recommendation to US-CERT that they notify the most widely used apps in our ecosystem, and they responded that they would reach out to the companies we requested.

 

Who is impacted by this?

Any organizations which leverage SAML may be at risk.  Okta has already patched all of our systems prior to the public announcement of the vulnerability, but the vulnerability may be present in 3rd party SAML implementations and customers should confirm 3rd parties are not vulnerable or have patched their systems.

 

How do you know that your customers weren’t impacted? Didn’t you just find out about the vulnerability?

Okta was made aware of the vulnerability prior to the public disclosure, and given the vulnerability was not publicly disclosed, there's very low likelihood of it ever having been exploited.  In addition, we carefully monitor our systems to watch for anomalies around user access and have not seen any indication that a threat actor has used this vulnerability to gain privileged access into Okta.

 

Are customers still at risk because of the ecosystem?

Okta itself was patched against this issue, but this is a vulnerability on Service Provider (SP) side of SAML authentication flow.  As a result any custom application or third-party application accepting SAML assertions should be reviewed and confirmed not to be vulnerable.  Please contact your SAML Service Providers to confirm this 

 

Is any one company better positioned to mitigate this attack?

Cloud vendors are generally better positioned to mitigate threats of this nature. As with other vulnerabilities that affect a protocol or library like SAML, cloud vendors and service providers are able to quickly investigate and patch to mitigate threats without requiring any action on the part of the customer.

 

Does this mean cloud security is not secure?

No, if anything, it’s the opposite. The threat landscape is constantly changing, which is why security research teams are invaluable to finding and helping companies mitigate vulnerabilities before an attacker takes advantage. And, because of the resources and speed at which cloud vendors can patch, organizations that use cloud technologies do not have to spend time waiting for their vendors to investigate, create and make a patch public before implementing their own solutions. Instead, vendors can move quickly to mitigate issues directly for the benefit their customers.


Are Okta's SAML toolkit and JIRA/Confluence Authenticators susceptible to this SAML vulnerability?

No, we have reviewed our code and tested to confirm the SAML Toolkit and JIRA/Confluence Authenticators are not vulnerable.
 

What do I do if my question isn't answered here?

Customers should reach out to their Customer Success Managers with any questions, or if your support entitlement does not provide you with a CSM, please reach out to Okta Customer Support for assistance.

Post a Comment