intro

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between parties, such as an identity provider (IdP) and a service provider (SP).

In a typical SAML scenario, the user tries to access a resource on the SP’s system. The SP requests authentication from the user and redirects the user to the IdP for authentication. The IdP authenticates the user and generates a SAML assertion, which is an XML document containing information about the user, including their identity and authentication status. The IdP sends the SAML assertion back to the SP, which uses the information in the assertion to grant the user access to the requested resource.

SAML provides a secure and standardized way for web applications and services to communicate and share user authentication and authorization data, without requiring the user to repeatedly enter their login credentials. SAML is widely used in enterprise environments, such as single sign-on (SSO) solutions, and is supported by many popular identity and access management (IAM) systems. This is particularly important for Active Directory Federation Service (ADFS) flow.

A typycal SAML authentication flow looks like below

Client                           SP                                IDP
   (1) ---------- login ------------> 
                                --------------- redirect -----------> (2)
   -------------------------------------------- enter password -----> (3)
   (4) <---------------------------------------- auth token ---------
   ---------- forward token -----> (5)
                        check token signature (6)
                        check saml response   (7)
   <---------- welcome ----------- (8)

Typically, attack vectors can be found at (4), (5), (6), (7). A fairly recent vulnerability CVE-2022-47966 is a good example of attack vector that takes place at (5)

CVE-2022-47966

According to NVD: “Multiple Zoho ManageEngine on-premise products, such as ServiceDesk Plus through 14003, allow remote code execution due to use of Apache xmlsec (aka XML Security for Java) 1.4.1, because the xmlsec XSLT features, by design in that version, make the application responsible for certain security protections, and the ManageEngine applications did not provide those protections.”

This is a RCE without authentication, therefore, is considered a very severe vulnerability.

Horizon3ai also did a good analysis on affected products which is summarized here: https://github.com/horizon3ai/CVE-2022-47966, they also provided a poc exploit that can be used to taret on entities managed by the affected products. Metasploit also authored a payload for this exploit: https://github.com/rapid7/metasploit-framework/pull/17527

For active directory related products, there are two key components to using this exploit: GUID and ISSUER_URL:

GUID: From the Metasploit PR, GUID is something generated when you first register an entity, if you missed it during registration, this value can typically be found in the server’s access log.

> type <access_log> | findstr /i "samlLogin"

ISSUER_URL: This can simply be referred as the service (sometime the endpoint) that is used to issue the token in (3) and (4). If we refer back to the graph above, this information should be identifiable at the client’s side in step (3) and (4) during an ADFS flow. The content needs to be set by the IDP server in a way, e.g cookie, response content.

Mitigation

Each affected product has released an update to address the issue, it is advisable to upgrade each affected product to the lastest version to mitigate this proble.