Superset Security Update (default `SECRET_KEY` vulnerability)

This article is written to raise awareness among the Apache Superset community and Preset users about a new security vulnerability that was reported, addressed, and recently made public. Our goal is simply to make sure that we do everything we can to help Superset users around the world have a secure installation.

Here’s the TL;DR:

• Make sure you set a unique SECRET_KEY when you run Superset!
• Preset users are (and always have been) safe!

The rest of this post will hopefully provide all the context needed to better understand and address this situation.

What happened, exactly?

The Apache Superset community has recently announced an important vulnerability as CVE-2023-27524, and we want to fill in as many people as possible in the Superset community about it. This CVE (or Common Vulnerabilities and Exposures) acts as a publicly disclosed unique identifier for a known security vulnerability in software or hardware. The original report was brought to the community’s attention via Horizon3.ai, who have published their findings in full detail here.

When issues like this are brought to the attention of the Superset PMC (Project Management Committee), and the Apache Security team, a discussion takes place on the Apache Superset Private mailing list (only accessible to PMC members), and details/solutions are hashed out there as well as in the Security working group, which is part of Superset’s Operational Model. This confidential approach prevents potential attackers from exploiting the vulnerability before a fix is publicly available. We thank Horizon3 for their collaboration and patience in the discovery, testing, and mitigation of this issue prior to publishing the CVE and their findings.

Who does it affect?

While warnings about using a default SECRET_KEY are covered in the documentation, and warnings about any use of a default key appear in the server logs, it has become clear that these were not heeded by all installations of Superset, and these default keys could be used in production instances on versions of Superset up to and including 2.0.1.

What’s the risk, in a nutshell?

Superset’s session cookie is signed with this secret key, and it states/validates who you are as a user. If you know the SECRET_KEY, you can forge your own cookie, similar to attacks that involve stealing a user session cookie. If an installation of Superset uses a default (and thus well-known) secret key, an attacker can log in as an administrator or other users and have that user’s access level to the system.

To be extra transparent about how scary this could be in a worst-case scenario, an attacker could log in as an Admin user, with all the possible implications this may have. These might include sensitive data exposure, possible modification of Superset's metadata, SSRF, possible DoS on connected data stores, and possible remote code execution on connected data stores if they were configured with high enough credentials.

RCE on the databases is only possible if users configure a db (Postgres, etc.) as a Superset database connection with default Admin credentials. This kind of thing is impossible for Superset to prevent.

Am I vulnerable? What should I do?

Since we’re publishing this blog under the Preset brand (on behalf of the community, as well), we’d like to take a moment to point out that Preset was not and is not susceptible to this vulnerability. We have a different secure SECRET_KEY for each workspace (and we’ve always had it configured this way). The report also mentions potential credential harvesting, which was a critical vulnerability found on Superset 2.0.1 or prior versions. Preset had already been patched as well, mitigating the RCE (remote code execution) vulnerability mentioned.

That said, as numerous news sources are pointing out, there are many instances in the wild that are, so we’d like to address some of these concerns. If you are using open-source Superset in your own deployments (business or personal), we want to underscore the importance of two key items worthy of your immediate attention:

• Confirm you’re secure by validating that you are using a custom/unique SECRET_KEY.
  • In most cases, you can check your SECRET_KEY by logging into your Superset instance and running echo app.config["SECRET_KEY"] | flask shell to make sure that the result is not one of the previous defaults mentioned in the report. Alternatively, you can run the Python Script provided by Horizon3. If you’re not sure, you might as well change it!
  • To set a new SECRET_KEY, first generate a new one using: openssl rand -base64 42 and then set that unique key in your config using SECRET_KEY=<generated key>. You will also need to run superset re-encrypt-secrets as outlined in the documentation. When you restart the Superset server, you will be fully secured!
• Upgrade to the latest version of Superset (2.1.0 as of this writing) where a change was made to mitigate this problem (along with numerous other fixes and features). Please refer to the docs.

What changed in 2.1.0?

The remediation direction that was decided upon was simply to disallow this behavior. Starting with Superset 2.1.0, you are not allowed to start Superset with the default key (on non-dev/non-debug environments).

This solves the problem outright for the bulk of users, though people that deploy Superset via Docker and Helm charts will also want to verify that they are not using any default credentials in their configurations. The general spirit of the CVE is this: double-check your credentials, and don’t use the defaults.

How does Preset handle CVEs?

At Preset, we take security very seriously and have implemented robust processes to handle CVEs for Superset, which we offer as a managed service. Our team at Preset includes numerous Superset PMC members who diligently monitor and validate these reports on the private Apache mailing list. In cases where the issue's severity is high and directly impacts Preset, we have resolved and deployed the necessary fixes within just 24 hours in the past. However, it is essential to note that the release process for open-source versions of Superset takes place on a less frequent, semi-fixed cadence that spans multiple months and requires a multi-day voting process.

While our engineers promptly address the issue in the code repository, the fix to Apache Superset itself is often deployed during the next release cycle (often, but not always, in a “patch” version). We then disclose these vulnerabilities to the public once they’ve been mitigated. This approach ensures that we provide a secure environment for our customers while maintaining the integrity and stability of Apache Superset as a managed service.

What’s next?

We’ll be working to further emphasize these issues and how to address them in Superset’s documentation, and will continue to add details to this blog post as they become relevant. If you have further questions after reading this, please let us know on Slack!

---

*I also want to add a Special shout-out to Daniel Gaspar, for his input on this article, and all his hard work in handling/validating the report and mitigating the issue.*