Common insecure configuration opens Apache Superset servers to compromise

An insecure default configuration issue (CVE-2023-27524) makes most internet-facing Apache Superset servers vulnerable to attackers, Horizon3.ai researchers have discovered.

Administrators in charge of Apache Superset instances should check whether they are among that lot, upgrade them to a fixed version, and check whether attackers might have exploited the weakness to breach them.

Apache Superset and the widespread exploitable weakness

Apache Superset is a data exploration and visualization platform that’s usually integrated with a variety of databases.

The problem lays in the fact that the Flask-based web app uses a default secret key to cryptographically sign session cookies for user state management, and many users don’t change that key after installation.

“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,” Naveen Sunkavally, chief architect at Horizon3.ai, explained.

“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.”

After forging a session cookie with a user_id or _user_id value set to 1 (a value often associated with the admin account), the attacker can simply put the cookie in the browser’s local storage and refresh the page and they’re in: they have administrator access to the web app.

“Administrative interfaces to web applications are often feature-rich and result in remote code execution on the application server,” Sunkavally added.

“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.”

There’s a fix!

The researchers reported the flaw back in October 2011 and the Apache Superset team addressed it by changing the default SECRET_KEY and adding a warning to users about the necessity of changing it to a random, complex one.

Apache Superset team’s warning to users (Source: Horizon3.ai)

But the warning went unheeded by many: the researchers recently swept the Internet with Shodan to see how many Apache Superset setups there are out there with this insecure configuration, and found that two-thirds (i.e., 2124) instances were using a default key (the first, the second, or one of the two additional ones found in deployment templates and documentation).

“It’s commonly accepted that users don’t read documentation and applications should be designed to force users along a path where they have no choice but to be secure by default,” Sunkavally commented.

So this time around, the Superset team decided to force the change: v2.1 of the web app does not allow allow the server to start up if it’s configured with a default SECRET_KEY.

But, Sunkavally warned, it’s still possible to run Superset with a default SECRET_KEY if it’s installed through a docker-compose file or a helm template. “Some configurations also set admin/admin as the default credential for the admin user,” he added.

It now remains to be seen if this improvement will, in time, lead to a smaller number of vulnerable Apache Superset instances on the internet.

The researchers did their part by finding and reporting the flaw, and by notifying a number of affected organizations. They have also provided remediation instructions and advice on how to search for evidence of intrusion.