Two flaws in Apache SuperSet allow to remotely hack servers
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2023-27524 +1 in the same advisory: …30776 | Insecure default SECRET_KEY in Apache Superset enables auth bypass and RCE Apache Superset versions up to and including 2.0.1 ship with a known, hard-coded default SECRET_KEY that signs all session cookies and encrypts sensitive data in the database. Installations that never changed this default value, contrary to the vendor's installation instructions, can be attacked over the network with no privileges or user interaction, because anyone who knows the public default key can forge valid, authenticated session cookies. By forging an administrator's session cookie, an attacker gains unauthorized access to Superset resources, and public proofs of concept demonstrate chaining this authentication bypass to remote code execution. Only deployments still using the default SECRET_KEY are affected; administrators who set a unique, strong key per the vendor instructions are not impacted. Exploitation is confirmed in the wild: CISA added the issue to the Known Exploited Vulnerabilities catalog on 2024-01-08, EPSS estimates a 97.4% probability of exploitation within 30 days, and public scans show thousands of exposed servers. Do: Upgrade Superset beyond 2.0.1 to a patched release (fixed in 2.1.0) and, critically, set a unique, strong random SECRET_KEY in superset_config.py or via the SUPERSET_SECRET_KEY environment variable on every deployment, since upgrading alone does not help if the well-known default key remains in use. If the default key was ever used, rotate it, invalidate existing sessions, and review affected servers—especially internet-exposed ones—for unauthorized access or code execution. Per CISA KEV, apply mitigations per vendor instructions or discontinue use of affected installations. | 9.8 group max | 97% | KEV PoC ×2 |
| moderate≈ thousands of internet-exposed Apache Superset instances (public internet scans); total self-hosted deployments likely higher | |
| CVE-2023-39265 +1 in the same advisory: …37941 | Apache Superset would allow for SQLite database connections to be incorrectly registered when an attacker uses alternative driver names like sqlite+pysqlite or Apache Superset would allow for SQLite database connections to be incorrectly registered when an attacker uses alternative driver names like sqlite+pysqlite or by using database imports. This could allow for unexpected file creation on Superset webservers. Additionally, if Apache Superset is using a SQLite database for its metadata (not advised for production use) it could result in more severe vulnerabilities related to confidentiality and integrity. This vulnerability exists in Apache Superset versions up to and including 2.1.0. NVD description · AI analysis pending | 6.5 group max | 86% |
| — |
Full article414 words · extracted from securityaffairs.com · click to collapse
Pierluigi Paganini
September 07, 2023
A couple of security vulnerabilities in Apache SuperSet could be exploited by an attacker to gain remote code execution on vulnerable systems.
Apache Superset is an open-source Data Visualization and Data Exploration Platform, it is written in Python and based on the Flask web framework. Version 2.1.1 addressed two vulnerabilities, respectively tracked as CVE-2023-39265 and CVE-2023-37941, that could be exploited to take control of Superset’s metadata database.
The Horizon3 researchers pointed out that Superset by design allows privileged users to connect to arbitrary databases and execute arbitrary SQL queries using the SQLLab interface. By tricking Superset can into connecting to its own metadata database, an attacker can directly read or write application configuration through the interface potentially leading to credential harvesting and remote code execution.
Below is the description for the flaw CVE-2023-39265 described as SQLite Access via SQLAlchemy URI Bypass.
“By default Superset uses SQLite as its metadata database, and the SQLite file is located on the Superset web server. Attempting to connect to this SQLite database through the Superset UI doesn’t work, as Superset has safeguards in place to prevent sqlite connections.” reads the post published by Horizon3.
“We discovered, however, that it’s possible to bypass this safeguard by putting in the full SQLAlchemy URI containing both the dialect and driver name, e.g. sqlite+pysqlite:////app/superset_home/superset.db“
The URI bypass flaw CVE-2023-39265 affects Superset versions <= 2.1.0. The flaw was fixed by blocking any SQLAlchemy URIs starting with sqlite instead of just blocking the sqlite:// syntax.
The experts also noticed that certain installations of Superset, such as docker-compose, use default credentials to access the metadata database. An attacker that knows the default credentials can connect to the metadata database and gain control over it.
The second vulnerability, tracked as CVE-2023-37941, is a remote code execution. The experts reported that Superset versions from 1.5 to 2.1.0 use python’s pickle package to store certain configuration data. Threat actors with write access to the metadata database can insert an arbitrary pickle payload into the store, and then trigger deserialization of it, leading to remote code execution.
The latest version also fixed a leak of database credentials in plaintext when querying the /api/v1/database API as a privileged user. This issue has been tracked as CVE-2023-30776.
In April 2022, Horizon3 researchers discovered a remote code execution, tracked as CVE-2023-27524 (CVSS score: 8.9), in Apache Superset.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Superset)
Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/150461/hacking/apache-superset-flaws.html