(This is part two of a two-part series offering guidance on how you can automate security tests for enterprise SAML infrastructure. In our first post we discussed the common vulnerabilities in enterprise SAML implementations and how to recognize them. We also provided guidance on how to try to eliminate false positives when attempting to detect issues. This post continues the conversation with additional guidance for setting up automated testing for issues and possible remediations)
Reporting Findings
Prioritizing Risk and Ownership Attribution
After tests have been conducted and true positives recorded, the detections must be analyzed for risk severity and attributed to the appropriate team for remediation efforts. Digital asset valuation will not be expounded here, but factors such as environment location (internal/external), legal compliance, data sensitivity and business importance/impact will affect the importance of an application and subsequently the urgency of remediation efforts. Vulnerabilities in high-value applications should be prioritized higher than similar vulnerabilities in a static lunch menu for example.
In the case of missing application ownership attribution in the application inventory, try to be creative in finding owners by other means. Perhaps you can find a similarly named mailing list where you can find the app’s admins or a support team? Perhaps the team has an internal wiki that you could search for? Or perhaps the application itself has a Contact Us form? Different architectures in use may be helpful as well, such as a record of who requested or owns the DNS record for the app, or a platform provisioning record, or an internal cost center that the server/resources are allocated to. And, as always, look for ways in which you could automate some of this information gathering to create a trail for attribution.
Presentation
Many organizations are split into different departments with often-competing priorities. To help ease digestion of the vulnerability report or ticket, it’s important to provide accurate and concise information about the initiative and the finding. The goal here is to make it as clear and self-explanatory as possible so as to avoid repetitive questions and conversations. An example ticket outline is provided in Appendix B.
Even with all of this information, teams may still want proof of actual exploitation or may argue that they have countermeasures in place. These arguments often diminish efficiency gains behind automation by introducing additional manual steps. Try to preemptively answer these objections before they arise. For example, screenshots or resulting HTML files can prove modification of displayed or returned SAML attributes. References to the time of the test may also point to evidence of a successful tests in application logs.
Another potential argument that app teams may offer is that they are using encryption in their SAML assertions. While the intention is good, if they don’t have specific countermeasures in place, confidentiality can be broken with published and proven attacks on XML encryption (white paper). The better approach is to fix the underlying issue, then add defense in depth measures, like encryption, on top of the root fix (these encryption attacks are mitigated if signatures are used properly).
Sustainable Action
Implementing Controls
After reporting on vulnerable applications, controls need to be put into place to prevent or quickly detect additional occurrences of these issues. Below is a list of potential controls that could help (ranked most-beneficial to least-beneficial):
- Require a clean SAML scan during IDP onboarding. If any errors or vulnerabilities are found, the application is prevented from completely onboarding or is disabled until the application successfully passes all SAML tests.
- Run automated SAML scans at regular intervals and report findings to appropriate channels (auto ticket generation, instant messaging channels, email lists, etc).
- Require the IDP team to manually validate the absence of SAML vulnerabilities as new applications are onboarded. This could be done using the free SAML Raider tool. Testing here would be thorough and catch issues before released, but the manual efforts could be burdensome, depending on the amount of new applications requesting SAML.
- Require app teams to self-attest that their application is free of SAML vulnerabilities before onboarding (also provide link to common SAML vulnerabilities). This is mostly to raise awareness about the issues rather than to ensure a secure state, as app teams could breeze past the checklist or struggle to accurately perform the SAML tests.
It is likely that new SAML vulnerabilities will be uncovered over time, so updates to the scanning tool and regular scans will need to accompany any implemented controls. Also, changes may be made to an application’s existing SAML configuration that may introduce vulnerabilities after deployment, so subsequent scans will detect vulnerabilities there as well.
Additional steps that could help secure applications earlier in the Software Development Life Cycle (SDLC) include trainings or communications, like quarterly events, group emails or presentations. This would hopefully stop the vulnerabilities from ever entering the code, thus saving time and resources in development costs.
Another approach, though an entirely different initiative, could be assessing all applications for outdated library dependencies. For example, a novel XSW vulnerability was discovered in SimpleSAMLphp in October 2019 (see here) that is not currently present in SAML Raider tests, as of July 2020. While automated scans that use SAML Raider would have missed this, a library dependency scanner could have caught this SAML authentication bypass vulnerability as it was made public.
Additional Tips
Since SAML is based on XML, XML External Entities (XXE) attacks are another risk that could be present in the SAML ACS. Though it is not specifically a vulnerability in the SAML protocol, it is a high-impact vulnerability that can exist within SAML processors. Testing for XXE in SAML can be much easier than running the other SAML tests, as all that is needed are the SAML ACS endpoints. Because XML is processed top-to-bottom, a payload doesn’t need to contain a valid SAML Response – the XXE would be processed before any SAML processing would occur. Simply send an XML Prolog and XXE payload to a SAML ACS and see if you can validate blind XXE injection using DNS or HTTP traffic. Keep in mind that SAML ACS’s process URL-encoded and base64-encoded data from the SAMLResponse POST parameter. Although you won’t need a valid SAML Response, you will need to mimic the presentation of a legitimate SAML Response.
In addition to typical SAML or XML vulnerabilities, keep an eye out for other issues, like communication over HTTP or dangling SAML configurations. SAML Responses sent over HTTP could potentially be sniffed and replayed to impersonate another user. Also, dangling application configurations in the IDP that remain after the application is decommissioned could be hijacked to point users and user attributes to new rogue applications.
Common SAML Weaknesses
As SAML is an XML-based language, the primary security controls in place are XML Signatures. At a minimum, IDPs should be configured to issue and sign either the SAML Response (the root node) or the Assertion node (the element containing the given user’s identity and attributes). Preferably, both nodes are signed with a CA-signed private key to ensure the integrity and non-repudiation of the message’s details and the user’s identity. As mentioned before though, the complexity involved in correctly configuring an application to an IDP and implementing the proper validation and consumption of incoming SAML assertions introduces several openings for risk. Exploitation of these weaknesses is facilitated as SAML assertions are often returned to the end user’s browser before they are forwarded to an SP. This forwarding functionality exposes assertions to Man-in-the-Middle attacks and drastically increases the attack surface, as all users of the application (often all Active Directory users) are able to intercept and modify their own assertions. If successful, attribute modification can lead to user impersonation, privilege escalation and potentially code injection.
Falsified Signatures
In the initial phases of onboarding an application to an IDP, metadata for each side is exchanged. Embedded in this information are various connection details, including the SP’s Assertion Consumer Service (ACS) URL (where SAML assertions are sent for processing) and the IDP’s x509 public certificate (used for XML signature validation). One common mistake that applications can make when validating SAML signatures is trusting and utilizing the x509 certificates that are presented within SAML messages. Because users have access to modify assertions before they are sent to the ACS, they can strip existing XML signatures, alter their user attributes, re-sign the SAML XML with a self-signed certificate and then forward their modified assertion and self-signed certificate to the application for processing. If SPs are not using the correct IDP certificate for signature validation and are instead using certificates from within the SAML assertions, then injected, self-signed certificates could be used to validate signatures over modified SAML elements. To ensure only the correct certificate is used, applications must pull the IDP’s certificate either directly from an IDP-controlled host (like a PKI-verified web server) or from the original, stored metadata file or value that was provided during onboarding.
XML Signature Wrapping (XSW)
Another category of vulnerabilities commonly found in SAML is XML Signature Wrapping (XSW). This occurs when XML – or SAML – elements are cloned and rearranged in an attempt to confuse the application’s ACS into validating provided signatures, but then processing other duplicate elements. SAML signatures often use references to point to specific nodes that they are attesting. Although provided signatures may validate their referenced nodes, applications will sometimes then use top-down tree-based navigation and indexes or getElementsByTagName or other methods to subsequently parse SAML nodes for processing and incorrectly process the wrong nodes. For example, Figure 2 below demonstrates how an Assertion could be duplicated and rearranged in an attempt to get the ACS to validate the second Assertion, but then process the first modified, unsigned Assertion.
Clik here to view.
Stripping Signatures
In another scenario, applications may fail to validate any signature at all. This is common among applications that attempt to process SAML with custom code, rather than using a specially designed SAML library. In this case, the ACS may verify the presence of a signature but not attempt to validate it, or it may simply ignore whether or not there is any signature.
Example SAML Incident Ticket Outline
This example is provided to help you set up an issue resolution workflow for your development team as they work to apply the guidance offered in this blog.
Summary: Describe the initiative and the potential impact of the finding. This adds authority and urgency to your report and provides a quick TLDR of the ticket.
Description: Provide a high-level overview of the issue detected and how it was discovered, then refer the reader to additional documentation established elsewhere (internal wiki, public reports, etc).
Scope: Identify the vulnerable resource (application URL, etc).
Risk Ranking: Score the vulnerability (1-10 or Low-High, etc) and provide justification for the scoring (ease of exploitability, impact, attack surface, etc). Many organizations have published authoritative and executive-backed standards that govern vulnerability management and can help support the report or ticket. The more detailed this section is, the more it will help reduce time-consuming counterarguments and repetitive requests.
Steps to Reproduce: Provide detailed instructions on how to reproduce the issue so that teams have the option to validate the vulnerability and any attempted fixes. These could be bullet points or How-To videos, though keep in mind that app teams may come back asking for help. If remediation steps are deemed too difficult, time-consuming or costly for app teams to reproduce on their own, then a regularly updated dashboard showing the status of each detection could be used to communicate the current state of the vulnerability. Another level of maturity in automation is to have the ticket strongly tied to the automation, so if the detection drops off the scans, then the ticket is closed automatically.
Suggested Remediation Steps: Because application environments and remediation limitations differ to varying extents, teams will likely be selective in which remediation steps they implement. A prioritized list of recommended solutions could be given, with further documentation linked for additional details and guidance on each option. Potential options could be migrating to other authentication methods, like OIDC, or updating the SAML library being used, or incorporating a popular, well-vetted SAML library instead of using a custom solution. Offering additional defense in depth solutions can further secure apps, like limiting visibility of apps on a need-to-know basis and adding encryption on top of secure implementations.
Additional Resources
The following are some resources that may prove useful in better understanding and testing SAML attacks:
How to Hunt Bugs in SAML (by epi052)
Attacking SSO: Common SAML Vulnerabilities and Ways to Find Them (by Jem Jensen)
On Breaking SAML: Be Whoever You Want to Be (by various authors)
SAML Raider Burp Extension (by Bischofberger and Duss)
Happy hunting,
Ty Anderson
Security Researcher