Apache Superset: A story of insecure default keys, thousands of vulnerable systems, few paying attention

Apache Superset until earlier this year shipped with an insecure default configuration that miscreants could exploit to login and take over the data visualization application, steal data, and execute malicious code.

The open source application, based on Python's Flask framework, defaulted to a publicly known secret key:

SECRET_KEY = '\2\1thisismyscretkey\1\2\e\y\y\h'

In an advisory on Tuesday, security firm Horizon3.ai explained that when a user logs into a Superset instance, the web application sends a session cookie with a user identifier back to the visitor's web 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," said Naveen Sunkavally, chief architect at Horizon3.ai.

If an attacker knows the value of SECRET_KEY, that person can then generate and sign cookies, effectively authenticating as the app administrator. And it turns out to be trivial to check whether Superset is using the default key with a tool called flask-unsign.

According to Sunkavally, about two-thirds of those using the software failed to generate a new key when setting up Superset: as of October 11, 2021, the application had almost 3,000 instances exposed to the internet, about 2,000 of which relied on the default secret key.

The Apache security team responded the following day and by January 11, 2022, made some changes, which established a new default secret key:

"CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET"

But this time the app included a check to see whether the new default remained unchanged. If so, the app issued a warning to the app's log file, with instructions for how to generate a secure key. Heeding the warning, however, was left to users.

More than a year after this change was made, on February 9, 2023, Horizon3.ai again checked to see how many Superset instances were configuring their app with a public default secret key. This time they expanded their Shodan.io search to four different default keys – the original, the new one, and two others – one from a deployment template and one from the documentation.

And not much had changed. Out of 3,176 Superset instances, 2,124 (~67 percent) were using one of the four default keys.

So Horizon3.ai contacted the Apache security team again. And two weeks later, on February 24, 2023, the project maintainers committed an update that would ship as part of the 2.1 release on April 5, 2023, to "impose harsher measures when a default SECRET_KEY is identified."

The change made it so the app would not start with a default key.

• Juniper slips out update after hardcoded credentials left in switches
• Cisco sneaks hardcoded secret root backdoor into vid surveillance kit
• Pupil mental health monitor promises app rewrite after hardcoded login creds discovered
• It's this easy to seize control of someone's Nexx 'smart' home plugs, garage doors

"With this update, many new users of Superset will no longer unintentionally shoot themselves in the foot," said Sunkavally, who cautioned that it's still possible to end up with an insecure version of Superset if the software is installed via a docker-compose file or a helm template.

"The docker-compose file contains a new default SECRET_KEY of TEST_NON_DEV_SECRET that we suspect some users will unwittingly run Superset with. Some configurations also set admin/admin as the default credential for the admin user."

The Superset vulnerability was disclosed as CVE-2023-27524 on Monday. Sunkavally said concerned Superset users can check to see whether their server has a default key with this script that relies on flask-unsign.

The 2,000+ vulnerable Superset instances identified were operated by companies large and small, government agencies, and universities, according to Sunkavally, who added that some of these organizations addressed the vulnerability after being notified about it.

Sunkavally said this episode illustrates that users do not read documentation and don't read logs. "The best approach is to take the choice away from users and require them to take deliberate actions to be purposefully insecure," he said. ®