miniOrange Authentication Bypass via SAML Manipulation - CVE-2022-26493

Known Versions Affected

This vulnerability was discovered using Drupal 9.3.4 and 9.3.6, in miniOrange Premium versions 8.x-30.3 and 8.x-30.4. It has been confirmed to affect the Drupal SAML SP modules provided by miniOrange utilizing Okta. Other authentication schemas and content management systems may also be affected.

miniOrange Enterprise and Standard versions may be affected but were not tested. Xecurify has released patches for all variants of miniOrange since the discovery of this vulnerability: Standard, Premium, and Enterprise. It is advised to upgrade to the newest available version of miniOrange, regardless of free or paid subscription service, as it is possible this vulnerability is present in multiple product and release versions of the miniOrange Drupal SAML SP module.

This vulnerability has not been identified in the free versions of miniOrange.

Vulnerability

This module has an authentication and authorization bypass vulnerability. Any individual with access to a HTTP request intercepting method is able to bypass authentication and authorization - impersonating existing users and any existing role. All that is required is for the attacker to know (or guess) a valid username.

Due to the SAML SP module’s failure to verify the existence of a signature, any applications using the affected versions of miniOrange are effectively without authentication or authorization controls. Enabling certificate or signature checking in affected versions of miniOrange will not mitigate the vulnerability.

Explanation

miniOrange versions 8.x-30.3 and 8.x-30.4 do not properly check for the existence of a valid signature in SAML authentication communications. Manipulating the contents of the SAML response from an Identity Provider (IDP) will affect the signature - rendering the SAML communication invalid. This occurs because the miniOrange SAML module can be configured to check the signature provided in SAML communications. If the signature displays indications of modification, the authentication request is denied.

However, removal of this signature will bypass the signature check entirely. As a result, an attacker may simply remove the signature in the SAML assertion from an IDP, modify the username and/or role, and forward the packet on to the web server. The web server will interpret this manipulated package as a valid communication from the IDP, and allow the attacker to access the application with whatever user account and role he chooses.

SAML (Security Assertion Markup Language) is an authentication standard that is used to transmit authentication data between two parties. In the case of this vulnerability - and in many authentication schemas - SAML allows a web application to be hosted indepently of the authorization service. SAML works by facilitating communcation between the web application servers and the authentication servers.

Simple Example

Let’s look at a simplified example:

A web application possesses a login button that redirects the user to an external authentication source. As the user is redirected, a token or session cookie is often attached to their request. The username and password provided by the user are never sent to the web application - but to the Identity Provider (IDP) authentication service. This service will validate the user’s credentials and - if present - conduct a two-factor authentication step. Once authenticated, the IDP will bundle up information about the user such as username, user role, status of authentication attempt (successful or failed) in a SAML Assertion response. This assertion is signed to validate that (a) the IDP and only the IDP generated the data and (b) that the integrity of the data has not been compromised.

This SAML Assertion is then forwarded from the IDP to the web application. The web application will read this response (and signature) to confirm that the authentication was successful, obtain the correct username for the user, and apply the correct user role.

In a functioning SAML schemas - any manipulation to the data in-trasit results in a small but significant change to the signature. The signature contained in the SAML response is compared with what the web application possesses. Any differences between the two will result in the authentication attempt failing. In the versions of MiniOrange discussed in this write-up, this functionality did not fail, and signature changes were correctly detected.

However, the versions of MiniOrange investigated did not properly check for the existance of the signature. If the signature was removed, the signature check failed open. This leaves the affected versions of MiniOrange vulnerable to SAML manipulation attacks. Furthermore, enabling signature checking and SAML signing makes no difference in the vulnerability.

SAML Manipulation

During the authentication process, an attacker can modify the contents of a SAML assertion to impersonate users or obtain unauthorized role access. This is accomplished by intercepting the SAML response from the IDP, modifying it in-transit, and forwarding it to the web application. In the vulnerability discussed here, SAML replay attacks were also possible. As such, once a single SAML Assertion is obtained by an attacker, whether through Man-In-The-Middle attacks, Cross-site Scripting, etc. - it can be reused repeatedly. If an attacker is able to intercept or obtain a SAML assertion for an application, the application authentication and authorization logic can be bypassed. During testing, credential checks and two-factor authentication were both bypassed. Likewise, I was able to assume any valid role within the application.

When modifying a SAML Assertion, we can capture the traffic in an HTTP Proxy like Burp Suite and view the SAML data. In order to bypass authentication in these versions of MiniOrange, an attacker only needs to know (or guess) an existing, valid username. This can be accomplished through fuzzing different common usernames such as WPAdmin, Admin, Drupal_admin, or through directly targeting known usernames. Once identified in the SAML Assertion, the username only needs to be replaced with the targeted username.

SAML Assertions are encoded. Encoding is not encryption however, and it is trivial to decode. Once decoded, we can locate and modify the username. Here, I changed my user account to an admin account within the SAML Assertion:

If an attacker does not know or does not want to guess an existing username they can modify the user role. An existing user may be malicious or an attacker may have valid credentials and want to elevate their privileges. To demonstrate, I modified my user role to “Admin”:

After modifying the username and/or the user role, an attacker may remove the signature and forward the packet on to its final destination at the web application server. We will be met with a response like this one - indicating a successful authentication and a redirect to the webpage - now as an authenticated user:

Discussion

This authentication bypass was confirmed through testing to affect MiniOrange Premium versions 8.x-30.3 and 8.x-30.4. The vulnerability was disclosed to the vendor and to the Drupal security team on March 1st, 2022. The MiniOrange team at Xecurify released a patch the same week. Their disclosure statement can be found here.

A similar vulnerability was discovered by another researcher - Cristian Guistini - in late 2021. The vulnerability disclosed by Guistini affected the free version of MiniOrange, version 8.x.2.22, which was available through the Drupal plugin marketplace. His write-up can be found here. This vulnerability was assigned SA-CONTRIB-2021-036 by Drupal, as the affected software was available for download through Drupal.

The bug Guistini discovered was identified to be related to poor enforcement of x509 Certificate values and SAML assertion signatures. Unfortunately, in the vulnerability I disclosed in early March and discuss here - the selection of these options makes no difference. The signature existence check is bypassed regardless of user configuration in the premium versions of MiniOrange noted here.

The Premium, Standard, and Enterprise versions of MiniOrange are only available for download from Xecurity for paying customers. The vulnerability described in this write-up was not assigned a Drupal Security Advisory, as it is only available through Xecurify, and not through the Drupal marketplace.

Xecurify advises users to update to at least the following versions:

According to Xecurify’s advisory:

“If you are using an out-dated/vulnerable version of the SAML SP module, you can download the latest version by signing in to your miniOrange dashboard using the registered credentials”.