Les Bell

Welcome to today's daily briefing on security news relevant to our CISSP (and other) courses. Links within stories may lead to further details in the course notes of some of our courses, and will only be accessible if you are enrolled in the corresponding course - this is a shallow ploy to encourage ongoing study. However, each item ends with a link to the original source.

News Stories

Tricky Configuration Tasks Compromise Security

We've long known that asking users - or even developers - to manually establish cryptographic keys or otherwise configure security is a generally futile approach. We saw this, for example, with the popular osCommerce open-source merchant server package, which required the user who installed it to manually edit the .htaccess file for the software. When used by novices who were simply trying to turn a hobby into a side gig, this step was inevitably skipped, leading to thousands of vulnerable sites being exploited.

Now comes a similar tale of security misconfiguration, courtesy of the security researchers at Horizon3.ai. This time, the offending software is the Apache Superset open-source data visualization software. Superset is written in Python, using the Flask web framework, and like most web server applications, it uses cookies for user session management. Of course, these need to be protected to avoid various attacks, and Flask does this by signing the cookie with a SECRET_KEY value which should be randomly generated for the installation and stored in a local configuration file. With each user request, the browser returns the cookie to the server, which checks the signature to authenticate the user before processing the request.

I'm sure you can see where this is going. When first installed, Superset provides a default SECRET_KEY value of \x02\x01thisismyscretkey\x01\x02\\e\\y\\y\\h. The Superset configuration guide specifically advises the user to modify this, replacing it with a genuinely random value.

But how many really do this, wondered the Horizon3.ai researchers? Back in 2021,, using a Shodan search to locate Superset servers, they found out, by the simple test of requesting the Superset login page. Of the 1,288 Internet-accessible servers they located, 918 - that's just over 71% - used the default value for SECRET_KEY.

They notified the Superset developers, who changed the SECRET_KEY to a new default value and added additional warnings, but user behaviour has not improved much: a repeat of the original experiment in January 2022 found that while Superset adoption had increased - with 3176 servers accessible on the Internet, 2124 were still using a default value for SECRET_KEY.

That's got to be worrying for the users of those systems, since the flask-unsign tool will allow an attacker to easily forge an authentication cookie with administrator privileges - and from there, they can access the databases from which Superset queries the data, or execute code, or mine credentials.

The developers have now updated the code so that Superset will not start with a default SECRET_KEY value, although there are still some cases which this will not fix. And the Horizon3.ai researchers have provided additional guidance on remediation, in their blog post.

But there's a lesson here for all developers, especially of open-source projects: we need to make the generation of unique keys, tokens, certificates, etc. an automatic part of the installation process. Relying on users to manually edit files just isn't going to fly.

Sunkavally, Naveen, CVE-2023-27524: Insecure Default Configuration in Apache Superset Leads to Remote Code Execution, blog post, 25 April 2023. Available online at https://www.horizon3.ai/cve-2023-27524-insecure-default-configuration-in-apache-superset-leads-to-remote-code-execution/.

These news brief blog articles are collected at https://www.lesbell.com.au/blog/index.php?courseid=1. If you would prefer an RSS feed for your reader, the feed can be found at https://www.lesbell.com.au/rss/file.php/1/dd977d83ae51998b0b79799c822ac0a1/blog/user/3/rss.xml.

Copyright to linked articles is held by their individual authors or publishers. Our commentary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License and is labeled TLP:CLEAR.