CVE-2023-27524: Insecure Default Configuration in Apache Superset Leads to Remote Code Execution

A Default Flask Secret Key

Superset is written in Python and based on the Flask web framework. A common practice for Flask-based applications is to use cryptographically signed session cookies for user state management. When a user logs in, the web application sends a session cookie that includes a user identifier back to the end user’s browser. The web application signs the cookie with a SECRET_KEY, a value that is supposed to be randomly generated and typically stored in a local configuration file. With every web request, the browser sends the signed session cookie back to the application. The application then validates the signature on the cookie to re-authenticate the user prior to processing the request.

The security of the web application depends critically on ensuring the SECRET_KEY is actually secret. If the SECRET_KEY is exposed, an attacker with no prior privileges could generate and sign their own cookies and access the application, masquerading as a legitimate user. The off-the-shelf flask-unsign tool automates this work: “cracking” a session cookie to discover if it was signed by a weak SECRET_KEY, and then forging a fake but valid session cookie using a known SECRET_KEY.

Back in October 2021, when we first started researching Superset, we noticed that the SECRET_KEY is defaulted to the value \x02\x01thisismyscretkey\x01\x02\\e\\y\\y\\h at install time. It’s the end user’s responsibility to modify the application configuration to set the SECRET_KEY to a cryptographically secure random string. This is documented in the Superset configuration guide. But we were curious what percentage of users actually read the documentation. So, using Shodan, we did a basic search for Superset servers on the Internet. Simply requesting the Superset login page (without attempting to login) returns a session cookie that we then passed through flask-unsign to determine if it was signed with the default SECRET_KEY. To our surprise, we found that 918/1288 (> 70%) of all servers were using the default SECRET_KEY!

Exploitation

Superset is designed to enable integrations with a variety of databases for exploring data and creating visualizations. Admin access gives attackers a lot of control over these databases and the ability to add and remove database connections. By default database connections are set up with read-only permissions but an attacker with admin access can enable writes and DML (data model language) statements. The powerful SQL Lab interface allows attackers to run arbitrary SQL statements against connected databases. Depending on database user privileges, attackers can query, modify, and delete any data in the database as well as execute remote code on the database server.

Remote Code Execution and Credential Harvesting

Administrative interfaces to web applications are often feature-rich and result in remote code execution on the application server. We found reliable paths to remote code execution across different Superset versions in a variety of configurations. Remote code execution is possible both on databases connected to Superset and the Superset server itself. We also found a host of methods for harvesting credentials. These credentials include Superset user password hashes and database credentials, both in plaintext and in a reversible format. We are not disclosing any exploit methods at this time, though we think it’ll be straightforward for interested attackers to figure it out.

More Default Flask Secret Keys

After our initial report to the Superset team back in Oct. 2021, we decided to re-check the state of Superset in Feb. 2023 to see if the situation with the default Flask key had improved.

We discovered that in January 2022 the SECRET_KEY value was rotated to a new default CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET, and a warning was added to the logs with this Git commit.

Detection

Telling if you’ve already been compromised is not that easy because exploiting this misconfiguration allows anyone to masquerade as a legitimate user. Superset provides a detailed action log in the interface that can be used to inspect user activity. We recommend looking for unusual admin-level actions such as viewing or modifying database configuration, adding a new database,, exporting data, or unusual queries in the SQLLab query history. We also recommend looking at the application access log to check for unusual API calls such as calls to the /api/v1/database endpoint. Of course an attacker can easily cover their tracks once they fully compromise the server.