Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

SAML roulette: the hacker always wins- 1635

Portswigger - Gareth HeyesPosted 11 Months Ago
  • SAML libraries often parse an XML document, store it as a string and later er-parse it. For secure authorization, the document must be parsed and serialized consistently. Otherwise, these differences could result in serious issues. Round trip attacks can be used break the parsing logic of programs.
  • In Ruby-SAML, this process involved two different parsers: REXML to parse/verify and Nokogiri to access the fields. This vulnerability had a collision with the researcher in the post. They decided to investigate notation declarations, based on previous research, to see if parsing issues could be found. While doing this, they found that mutations could be introduced using the SYSTEM identifier.
  • When parsing SYSTEM, a comment with a single quote in the attribute is initially fine. When it's reparsed, the comment is not properly escaped and the single quote is made into a double quote. This modifies the syntax of the document, causing an XML comment to be processed and adding data in another comment to be part of the node instead. Using this method, it's possible to smuggle in data on the second parse to falsify the fields, such as the necessary assertions for users.
  • In Ruby-SAML, the library verifies that the SAML response contains a valid certificate in the document. Here's how it works:
    1. On the first parse of the document, get the certificate to take a hash of it. This is used for signature validation later.
    2. Certificate is extracted from the SAMLResponse.
    3. The document is converted from XML back to its in-memory representation. This is the round-trip issue.
    4. The library ignores the attackers assertion when doing the processing on the original element.
    5. Accessing the data will now use the modified data added in by the attacker. Neat! We have a winner!
  • They wanted to see how far they could take this though. There is some XML scheme validation that prevents doing some trickery. This works by validating define elements, attributes, data types and number of elements. Although you could find an XML document on a developer forum, they went for a namespace confusion attack.
  • They use a discrepancy between the two parsers to bypass the signature verification. The XPath query on the signature uses the ds namespace, which would prevent element conflict. Normally, an included ATTLIST inclusion declaration with the same namespace would be rejected. However, REXML ignores this restriction in doctype declarations!
  • REXML will use the attacker defined namespace collisioned document. However, the other parser will use the original! This means that the verification will be done on a Digest that's real while the usage will be done on one that is fake.
  • To exploit this, a single valid signed XML document is necessary. WS-Federation is used by default on most IdPs though. Since this provides signed metadata, these signatures are accessible publicly from any user! The namespace confusion attack only requires a valid signature - it doesn't matter what it's for! By using this document, GitLab SAML authentication can be bypassed to login as any user.
  • Any time you see two different parsers, or data being parsed more than once, you hacker senses should start to tingle. This vulnerability was exploited in two different ways in this article and an entirely separate way in another post. This is awesome research - I will be looking for similar things in the future!