Apache Superset RCE Vulnerability CVE-2023-27524 Highlights Ongoing Issues with Flask AppBuilder, Joining List of Previously Discovered CVEs

On Apr 24, 2023 Naveen Sunkavally, Chief Architect at Horizon3.ai, announced the discovery of a new vulnerability, CVE-2023-27524, in Apache Superset and wrote comprehensively about the whole process. The vulnerability was caused by an insecure default configuration in the application. This is not the first time this type of vulnerability has been found in similar applications. In 2020, Junghan Lee from Deliveryhero discovered a similar vulnerability, dubbed CVE-2020-17526, in Apache Airflow, an open-source platform for developing, scheduling, and monitoring batch-oriented workflows. Another instance occurred in 2021, when Ian Carroll discovered the same vulnerability, CVE-2021-41192, in Redash, an open source data visualization tool. All three vulnerabilities were caused by the use of Flask AppBuilder, which is responsible for managing user state through cryptographically signed session cookies. In all three cases, users had relied on the default SECRET_KEY configuration generated by the application, which was predictable and therefore vulnerable.

Flask Session Cookies

Flask AppBuilder is a web application framework that is built on top of the Flask microframework. It provides a high-level interface for developing complex web applications by automating common tasks such as authentication, authorization, and user management. 

Flask is using session cookies to store user state information, such as login credentials or user preferences. These cookies are encrypted to prevent tampering by unauthorized users.

Flask uses a cryptographic algorithm to generate a unique signature for each session cookie. This signature is created by hashing a combination of the cookie data and a SECRET_KEY that is known only to the server. When the user sends a request to the server with a session cookie, the server uses the same SECRET_KEY to verify the signature and ensure that the cookie has not been altered.

By using cryptographically signed session cookies, Flask can ensure that the user’s state information is secure and cannot be modified by unauthorized users. This is an important security feature that helps protect user data and prevent attacks such as session hijacking or cookie tampering.

If an attacker is able to find the SECRET_KEY used by Flask to generate the cryptographic signature for session cookies, they can potentially create valid session cookies themselves. This would allow them to bypass authentication and access user accounts, as well as modify user data and perform other actions on behalf of the user.

The Flaw

In all three instances, the vulnerabilities were caused by the use of the default SECRET_KEY configuration generated by the applications, rather than generating a new unique key or taking action when this type of configuration is applied.

Using the default SECRET_KEY is not secure, as it is publicly available and attackers can easily discover it. Once an attacker obtains the SECRET_KEY, they can generate a cookie and sign it using the key, allowing them to gain unauthorized access to the application.

The Process

All three CVEs were discovered using the Flask-Unsign, which is an open source command-line tool to fetch, decode, brute-force and craft session cookies of a Flask application by guessing secret keys. This indicates that the default SECRET_KEYs used in all three applications were not strong enough and easily cracked.

In addition to guessing the SECRET_KEYs, attackers needed to find the UUID of the user’s session they wanted to sign in with. In both the cases of Apache Airflow and Apache Superset, the sign-in worked by providing to Flask-Unsign the user_id or _user_id value set to 1, as the servers store a numeric user_id that auto-increments and indicates the first user created, typically the Administrator. However, in the Redash application, the 1 value did not work since it stores a random user UUID in the session, leading the attacker to find a way to bypass this through password resets.

CVE-2023-27524 

Impact

Superset applications are designed to enable database integrations, and having administrative access to the application can lead to the disclosure of sensitive information since admins can query connected databases using SQL and manage database connections. In addition to this, the researchers discovered ways to execute code remotely on both the connected databases and on the Superset servers themselves. They also found ways to harvest the credentials of Superset users, including password hashes and databases in plaintext and in a reversible format.

Findings

After discovering the vulnerability, the researchers conducted a thorough search for the number of Apache Superset applications exposed to the internet using Shodan, compared to those using the default SECRET_KEYs and exposed to the internet through the Flask-Unsign tool. Their search revealed that 71% of all servers were using the default SECRET_KEY. They reported the issue to Apache Superset on October 11, 2021, and the project subsequently changed the SECRET_KEY from “\2\1thisismyscretkey\1\2\e\y\y\h” to a new SECRET_KEY – “CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET,” accompanied by a warning. In February 2023, the researchers decided to perform another check, this time using the previous SECRET_KEY, the new default key, and two other keys they found in the deployment template, namely “thisISaSECRET_1234” and “YOUR_OWN_RANDOM_GENERATED_SECRET_KEY” mentioned in the documentation.

Image source: Horizon3.AI

As evidenced by the data, the compromised sessions still make up 66.9% of the Apache Superset servers that were exposed. This indicates that the previous solution was not effective, prompting the researchers to contact Apache Superset once more.

Fix

In response to the CVE-2023-27524 vulnerability discovered in Apache Superset, the development team took significant measures to address the issue. They implemented a fix similar to the one used by Redash, which involves preventing the server from starting if it is configured to deploy with the default SECRET_KEY, starting with version 2.1 of Apache Superset. This change requires users to generate and use their own unique SECRET_KEY, ideally one that is strong enough to resist attacks like the one that led to the discovery of the vulnerability. However, it is important to note that this patch does not cover all use cases, as users can still install Superset with a default SECRET_KEY if it is done through a docker-compose file or a helm template. The new SECRET_KEY of docker-compose is TEST_NON_DEV_SECRET.

Remediation

If you are using any of the versions affected by the vulnerabilities, it is strongly advised that you upgrade to the latest version immediately. The following information outlines the affected versions for each CVE:

• CVE-2023-27524: Apache Superset is vulnerable in versions up to and including 2.0.1
• CVE-2021-41192: Redash is vulnerable in versions up to and including 10.0.0
• CVE-2020-17526: Apache Airflow is vulnerable in versions up to but excluding 1.10.14.

Recommendations

• You can Execute the following script in order to check if your Apache Superset server is running with an insecure default configuration.
• If you are using a vulnerable version of Apache Superset, Apache Airflow, or Redash, it is strongly recommended that you upgrade to the fixed versions and update all your keys to your own key. 
• In Apache Superset, follow the following instructions in order to rotate the SECRET_KEY, make sure to use strong keys that cannot be easily cracked using tools like Flask-Unsign.
• If you are using Apache Superset via docker-compose, ensure that the fix is not already applied, and generate a new SECRET_KEY yourself.
• To avoid potential attacks, it is recommended that you do not expose your servers to the internet and monitor for any suspicious activity.
• If you are using any other application that uses Flask session cookies and allows the default SECRET_KEY, contact the application’s developers and suggest implementing the same approach of refusing to start the server if it is configured to deploy with the default SECRET_KEY. 
• Always use a strong, unique key to protect your application.

Conclusions

The discovery of yet another vulnerability caused by the insecure default configuration in Flask AppBuilder highlights the importance of proper security measures when developing web applications. The CVE-2023-27524 vulnerability discovered in Apache Superset can lead to unauthorized access to user accounts, data modification, and remote code execution. As in previous cases, the vulnerability was caused by the use of the default SECRET_KEY configuration, which can be easily cracked by attackers. The findings of the researchers emphasize the need for developers to generate unique keys and take other security measures to protect user data. In response to the vulnerability, Apache Superset changed the default key and provided a warning, but the researchers found that the majority of exposed servers still used the default key, indicating that more needs to be done to improve web application security.