Following the white Rabbit

Down the SAML Code

This post is a more detail and personal write up version of the https://www.okta.com/blog/ post. If you are interested in reading the short — to the point — version of it, please follow the link. In any case, let’s get down to it. So what is SAML ?

Security Assertion Markup Language

According to wikipedia: “SAML is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee. SAML dates from 2001; the most recent major update of SAML was published in 2005, but protocol enhancements have steadily been added through additional, optional standards.

The single most important requirement that SAML addresses is web browser single sign-on (SSO). Single sign-on is common at the intranet level (using cookies, for example) but extending it beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies. (Another more recent approach to addressing the browser SSO problem is the OpenID Connect protocol.”

Out of that we can determine one simple important fact: SAML is XML. Because of this, a lot of developers build their applications using third-party XML Parsers or write their own to parse the SAML payloads. In either case, both could end up being a bad thing on itself. As we all know XML is a very rich protocol that can be exploited in several ways. One of those ways is XXE, a vulnerability that allows an attacker to load remote entities, read local files, among other things.

The Vulnerability(s)

Back in August, we found a Cloud Third-Party application used by us was vulnerable to an XXE attack. After finding it, we created a proper write up and followed up with the company’s security using our Responsible Vulnerability Disclosure process, but at the same time we raised the question.

“If they are vulnerable, who else will be?”

Java and other languages libraries with known XXE vulnerabilities date back to 2013, so I thought this was for the most part a fixed problem and there was nothing new to find. Nevertheless, being as hard headed and I am, I retested all known SAML SP endpoints; but where would I get a list? Totally kidding. I work for a Cloud Identify Provider, and our own app has one of the biggest SAML integration list in the world. :-) I had plenty of ACL endpoints to test.

Proof of Concept

At first, I started testing things manually using a custom proxy and replacing the SAMLResponse with a simple Malicious XML and/or by simply running the original response on a script that will inject a proof of concept XXE payload to the POST requests with an even simpler Listener embedded, the bash snipped below who we get a response back from a fake 1.2.3.4 IP.

In order to build a Proof of Concept of your own you can take a SAMLResponse from any POST request and using the methods below you can simply generate a non-malicious payload that will allow you to check whether or not you are vulnerable.

Basic Listener:

After a few hours, I had four new vulnerable services, appliances, etc, but this got boring very fast given manually testing each SAMLResponse was not fun. …Not to mention, the long emails doing responsible disclosure to each application or Appliance we found… AND to make it even worse sites were vulnerable by testing with thesimple XXE string mentioned above, which was not even valid SAML response. :(

List of vulnerable services/appliances: