By: Walker Rowe, June 02, 2017 (05:59 AM)

OKTA and SAML Security Critical Vulnerability

Okta says they have updated the Okta SAML Toolkit for Java to fix what they call a critical vulnerability.  But they do not give any technical details saying, “Okta maintains a responsible disclosure policy, and as such, will only divulge specific details about this vulnerability after adequate time has been given for customers to upgrade.”  That is 30 days.

Okta is a cloud security sign on product that brings single sign on (SSO) to business.  In the past they targeted the consumer market too, but OAuth, which lets users use their social media accounts to sign in to websites, has killed off that market.

What SSO does is solve a big headache for business which is let their many different applications use one sign in web page to access SalesForce.com, SAP, Office 365, etc.  Prior to that companies had to maintain their own complicated LDAP, Active Directory (a type of LDAP), and Siteminder or other systems to handle authentication into different systems.

OKTA uses both proprietary and industry standard SAML to login to these downstream systems.

It works by providing hooks to log users into these other applications with a single userid, password, token, etc.  This speeds up onboarding new employees and reduces support tickets to the help desk for lost passwords, problems getting access, etc. But the company might have to do some of that integration themselves using a SAML SDK, if it is a proprietary app.

The Open Web Application Security Project (OWASP) publishes some details of the SAML implementation details in their Security Cheat Sheet and describes some vulnerabilities due to improperly following those.

They describe SAML as, “The Security Assertion Markup Language (SAML) is an open standard for exchanging authorization and authentication information. The Web Browser SAML/SSO Profile with Redirect/POST bindings is one of the most common SSO implementation.”

So their document focuses on the web piece.  SAML is also used for business-to-business and system-to-system integration in enterprise apps.  For example, a company can use it to let employees sign into the 401K system provided by a brokerage firm without having to log in twice.  And employees can connect to business partners, like vendors, of all types this way.  That is called federation.

Web browser implementation is particularly fraught with difficulty with OKTA saying it is possible to introduce “security gaps simply because of the vast number of steps to assert.”  They are talking about the need to check the SAML XML document for proper format, validate the X.509 certificate and signature inside, and do the proper handshake between the browser and the application.  And there are many browser redirects in all this back-and-forth.

Among the countermeasures they discuss are ways to block these kind of attacks:

  • Stolen Assertion (The SAML assertion tells the downstream app that a user is authenticated.)
  • Man-in-the-middle
  • Browser State Exposure
  • Forged Assertion

Some years ago, Google made a mistake with their SAML implementation that allowed a man-in-the-middle attack because “the SAML Response did not contain all of the required data elements necessary for a secure message exchange.”  They were using AVANTSSAR which according to a conference paper is “an integrated toolset for the formal specification and automated validation of trust and security of service-oriented architectures.”

SAML does more than authentication too.  It does authorization.  So in addition to checking the user’s credentials, the SAML assertion sends the downstream app roles and other info needed to determine what permissions the user has in the targeted app.

Programmers add SAML to their application using opensource SAML toolkits.  OKTA lists plenty: Kentor Authentication Services (for .NET), OpenSAML (Java), PHP (SimpleSAMLphp), PySAML2 (Python), and Ruby-SAML (Ruby),  and, of course, the Okta SAML Toolkit for Java

So what do you need to do?  They say, “Okta strongly recommends that customers download and update the latest SAML toolkit and necessary Jira or Confluence authenticators.”  For customers using OKTA to sign into, for example, SalesForce, they do not need to do anything, as they are using the browser and SalesForce is responsible for its SAML implementation.

Walker Rowe

Walker Rowe is an American freelance tech writer and programmer living in Chile. He specializes in big data analytics, cybersecurity, and IoT and publishes the website SouthernPacificReview.com.

Notice: The views expressed here are those of the authors and do not necessarily represent or reflect the views of Cursive Security.

Be Informed. Stay One Step Ahead.

Sign up for our newsletter and stay up to date with the latest industry news, trends, and technologies