CVE-2023-30465 - SQL Injection Vulnerability in Apache InLong (Versions 1.4.

Recently, a serious security vulnerability was found in Apache InLong, an open-source system for massive data integration. This flaw, tracked as CVE-2023-30465, allows attackers to use SQL Injection to access sensitive user data. In this article, we break down how this vulnerability works, show an example exploit, and provide resources to fix and protect your system.

What is CVE-2023-30465?

This CVE references an "Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')" flaw. That means Apache InLong doesn’t properly filter out dangerous characters in some API parameters, so attackers can "inject" their own SQL code. Specifically, between versions 1.4. and 1.5., the orderType parameter in API calls is vulnerable.

What Can an Attacker Do?

By abusing this flaw, an attacker can run custom SQL queries on the InLong database. The most alarming case is that they can extract usernames or other sensitive data — one character at a time — from the user table.

Suppose the backend code looks something like this (simplified for clarity)

// Vulnerable Java code (simplified)
String orderType = request.getParameter("orderType");
String sql = "SELECT id, username FROM user ORDER BY " + orderType;

Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

The orderType parameter is directly pasted into the SQL query — no checks or filtering! This means an attacker can give it malicious SQL instead of a normal value.

The Exploit (Extracting the Username of User 1)

Say you want to steal the first user's username (ID 1). You could use a technique called "blind SQL injection," guessing each letter one by one.

Here’s an example attack. The attacker sends this as orderType

CASE WHEN (SELECT ascii(substring(username,1,1)) FROM user WHERE id=1)=65 THEN id ELSE username END

This tells the database to order by id ONLY IF the first character of the username with ID 1 is ASCII 65 (which is "A"). If not, the order changes obviously in the API response, and the attacker learns the true value.

Suppose the vulnerable endpoint is

GET /api/users?orderType=CASE%20WHEN%20(SELECT%20ascii(substring(username,1,1))%20FROM%20user%20WHERE%20id=1)=65%20THEN%20id%20ELSE%20username%20END

The attacker repeats this process for substring(username,2,1), substring(username,3,1), etc., and for different ASCII values, learning each letter.

Result: In just a few requests, any username can be reconstructed.

How to Fix (or Mitigate)

The Apache InLong team fixed this in version 1.6.. If you use v1.4. to v1.5., you need to upgrade ASAP or cherry-pick the fix (see issue #7529).

For developers: Never use user input directly in your SQL. Use parameterized queries or prepared statements instead!

Safe code

String orderType = request.getParameter("orderType");
if (!orderType.equals("id") && !orderType.equals("username")) {
    orderType = "id"; // default fallback
}
String sql = "SELECT id, username FROM user ORDER BY " + orderType;

Or, better yet, use constants or an Enum for values.

References & Further Reading

- Official Apache InLong Issue #7529
- CVE-2023-30465 Security Advisory
- JDBC deserialization vulnerability learning

Conclusion

CVE-2023-30465 is a vivid reminder of the dangers of SQL Injection. If you run Apache InLong (1.4.-1.5.), upgrade immediately or patch your system! Never trust user input in your database queries, and always keep an eye on security advisories.

Timeline

Published on: 04/11/2023 15:15:00 UTC
Last modified on: 04/18/2023 19:30:00 UTC