Redash SAML Authentication Bypass
Redash is a popular data analysis and visualization tool. We recently reported a critical SAML authentication bypass vulnerability affecting its latest version (10.1.0).
The vulnerability could be exploited by anyone to gain highest possible privileges on the system. Its discovery led to an important announcement from the project’s maintainer.
The Vulnerability
We encountered Redash in a recent engagement. This is not the first time we met this open-source software, so we decided to take a closer look.
Most of Redash's attack surface is put behind authentication. That’s why SAML was among the areas we audited first. We had a couple of findings, but the most critical by far is a SAML authentication bypass.
The vulnerability works as follows:
In the SAML flow, Redash acts as the Service Provider (SP), and popular providers like Okta or Google act as the Identity Provider (IdP).
SAML relies on digital signatures to authenticate users. The user logs into the IdP and gets redirected back to Redash with a signed SAML message containing the user’s information.
Redash uses the library pysaml2 6.1.0 to implement SAML authentication at the two endpoints /saml/login and /saml/callback. However, pysaml2 before version 6.5.0 is vulnerable to CVE-2021-21239, which allows one to bypass signature verification on arbitrary SAML messages.
Specifically, the default backend of pysaml2, CryptoBackendXmlSec1, uses the command line utility xmlsec1 to verify signed SAML messages. However, xmlsec1 by default prefers the key embedded in the message over explicitly loaded keys (such as specified on the command line). This dangerous behaviour was first reported by Greg Vishnepolsky in 2013.
The Exploit
The vulnerability allows us to forge SAML messages from any identity providers. To exploit it against real-world Redash instances, we have to overcome a few small obstacles:
Obtaining SAML Entity ID: in the SAML world, each identity provider is uniquely identified by a SAML Entity ID. Redash will only accept SAML messages if this value is correct. Fortunately, most IdP uses SAML entity IDs that can be inferred from observing a SAML login session. For example, Google uses the pattern https://accounts.google.com/o/saml2?idpid=<IDPID> as shown in the screenshot below.
Signing in as administrator: when a user signs in to Redash over SAML with a non-existent email address, Redash automatically creates an account for that address. This is called Just In Time (JIT) provisioning. So we can sign in as test@victim.com, go to Settings → Users to obtain a list of all accounts on the Redash instance - like the screenshot below - and forge another SAML message to sign in as one of the admin accounts.
Other than that, Redash allows unsolicited SAML responses, which means one does not have to go through the whole SP-initiated logon flow to craft a valid SAML response payload, simplifying the exploit.
Remediation
Redash quickly acknowledged the vulnerability, but has not released a new version with the dependency fix. The official advisory recommends upgrading pysaml2 to version >= 6.5.0.
As a defense-in-depth, consider:
switch to OAuth2 instead of SAML
update REDASH_COOKIE_SECRET to invalidate all existing sessions
Impact
We reported the issue to multiple affected organizations. Considering the fix has to be applied manually, it’s impressive how they resolved this in a matter of days. Most classified the vulnerability as critical and rewarded generously for it.
Timeline
Jan 16, 2023: Discovered the vulnerability
Mar 17, 2023: Reported to Redash
Mar 18, 2023: Redash confirmed the vulnerability
Apr 4, 2023: GitHub advisory published
Apr 4, 2023: Reported to known affected organizations
Apr 28, 2023: Published this blog post
Parting words
This vulnerability is unfortunate. Despite being very popular, Redash’s development has been halted since it was acquired by Databricks. This is probably why this issue has evaded detection for so long. Any automation tool could have caught it. In fact, GitHub’s dependapot submitted a pull request to upgrade pysaml2 a while ago, but it was ignored.
On the bright side, we’re glad to see this work is driving positive changes. Redash made another announcement after the disclosure and decided to resurrect the project, as per A New Chapter as a Community-Led Project.
As always, SAML is tricky to implement correctly and remains a large attack surface to explore.
Finally, props to the team for a great collaboration on this little research, especially to An for finding the vulnerability and Gia for doing all the heavy work.
[1] https://github.com/getredash/redash/security/advisories/GHSA-rm5x-rgmf-qv5c
[2] https://github.com/IdentityPython/pysaml2/security/advisories/GHSA-5p3x-r448-pc62
[3] https://www.aleksey.com/pipermail/xmlsec/2013/009717.html