CVE-2024-33857

Executive Summary

CVE-2024-33857 is a Server-Side Request Forgery (SSRF) vulnerability discovered in Logpoint, a Security Information and Event Management (SIEM) platform. The flaw resides in the threat intelligence module, where URLs are not properly validated before being fetched by the server. An attacker with low-level authenticated access can exploit this to make the server send crafted requests to internal or external systems, potentially leading to information disclosure, internal network scanning, or further lateral movement. The vulnerability is fixed in Logpoint version 7.4.0. No public proof-of-concept (PoC) or exploit code has been released at this time.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a direct product flaw in Logpoint’s proprietary codebase. No supply chain implications are identified.

CVSS Breakdown & Threat Level

• CVSS Score: 0.0 (NVD) – However, based on analysis, a more realistic score is 7.5 (High).
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (authenticated user)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: None
• Availability Impact: None
• Threat Level: High – SSRF can lead to internal network reconnaissance and data exfiltration.

Deep Dive & Mechanics

The vulnerability exists in the threat intelligence ingestion feature of Logpoint. When the system processes threat intelligence feeds (e.g., URLs to blocklists or IoC sources), it does not sanitize or validate the URLs provided by users. An attacker with low-level access (e.g., a user with permissions to configure threat intelligence sources) can supply a malicious URL pointing to internal resources (e.g., http://169.254.169.254/latest/meta-data/ for cloud metadata, or http://internal-service:8080/admin).

The server then makes an HTTP request to that URL, and the response is processed or stored. This allows the attacker to:

• Scan internal network services.
• Access cloud metadata endpoints (e.g., AWS, GCP, Azure).
• Read internal files via file:// protocol if supported.
• Potentially pivot to other internal systems.

The root cause is a lack of input validation and insufficient URL whitelisting/blacklisting in the threat intelligence module.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-7.4.0):

# Example of vulnerable code (conceptual)
def fetch_threat_intel(url):
    response = requests.get(url)  # No validation of URL
    return response.text

Patched Code (7.4.0+):

# Example of patched code (conceptual)
import re
from urllib.parse import urlparse

ALLOWED_DOMAINS = ["threatintel.example.com", "feeds.example.org"]

def fetch_threat_intel(url):
    parsed = urlparse(url)
    if parsed.hostname not in ALLOWED_DOMAINS:
        raise ValueError("URL not allowed")
    if parsed.scheme not in ["http", "https"]:
        raise ValueError("Invalid scheme")
    response = requests.get(url)
    return response.text

The patch introduces a whitelist of allowed domains and restricts the URL scheme to HTTP/HTTPS only, preventing SSRF to internal or arbitrary external hosts.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Low-level authenticated access to Logpoint (e.g., user with "Threat Intelligence" configuration rights).
• Network connectivity to the Logpoint server.

Exploitation Steps:

1. Log in to Logpoint as a low-privileged user.
2. Navigate to the Threat Intelligence configuration section.
3. Add a new threat intelligence source with a malicious URL, e.g.:

   http://169.254.169.254/latest/meta-data/
   

4. Trigger the fetch operation (e.g., by saving or manually refreshing).
5. Observe the response in the Logpoint interface or logs, which may contain cloud metadata.

Example Payloads:

• http://127.0.0.1:9200/ (Elasticsearch)
• http://internal-admin:8080/
• file:///etc/passwd (if file protocol is supported)

Blue Team (Defender)

Detection Steps:

1. Monitor Logpoint logs for unusual outbound HTTP requests from the threat intelligence module.
2. Look for requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16).
3. Check for requests to cloud metadata endpoints (e.g., 169.254.169.254).
4. Review user activity logs for unauthorized changes to threat intelligence sources.

Lab Setup:

• Deploy a vulnerable Logpoint instance (version < 7.4.0) in an isolated environment.
• Set up a simple HTTP server (e.g., python -m http.server 8000) to simulate internal services.
• Use a low-privileged user account to test the SSRF.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests to private IP ranges from the Logpoint server.
  • Requests to cloud metadata IPs (169.254.169.254, 100.100.100.200 for Alibaba Cloud).
  • Requests to internal hostnames (e.g., internal-service, localhost).
• Log IOCs:
  • Log entries showing GET requests to suspicious URLs in the threat intelligence module.
  • User activity logs showing creation or modification of threat intelligence sources with unusual URLs.
• File IOCs:
  • Presence of internal data (e.g., cloud metadata, config files) in threat intelligence response logs.

Detection Engineering

YARA Rule

rule CVE_2024_33857_SSRF_Logpoint {
    meta:
        description = "Detects SSRF attempts targeting internal IPs in Logpoint threat intelligence URLs"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-33857"
    strings:
        $private_ip = /(127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|169\.254\.)/
        $metadata_ip = "169.254.169.254"
        $file_protocol = "file://"
    condition:
        any of them
}

Sigma Rule

title: CVE-2024-33857 SSRF via Logpoint Threat Intelligence
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects SSRF attempts in Logpoint threat intelligence module
author: Valters IT
date: 2025-04-10
logsource:
    product: logpoint
    service: threat_intel
detection:
    selection:
        url|contains:
            - "127.0.0.1"
            - "10."
            - "172.16."
            - "172.17."
            - "172.18."
            - "172.19."
            - "172.20."
            - "172.21."
            - "172.22."
            - "172.23."
            - "172.24."
            - "172.25."
            - "172.26."
            - "172.27."
            - "172.28."
            - "172.29."
            - "172.30."
            - "172.31."
            - "192.168."
            - "169.254."
            - "file://"
    condition: selection
falsepositives:
    - Legitimate internal threat intelligence feeds (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-33857 Logpoint SSRF Attempt"; flow:to_server; content:"GET"; http_method; content:"/"; http_uri; pcre:"/(127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|169\.254\.)/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Logpoint to version 7.4.0 or later.
2. If immediate upgrade is not possible, restrict network access for the Logpoint server using firewall rules (e.g., block outbound traffic to private IP ranges).
3. Review and remove any suspicious threat intelligence sources.

Long-Term Mitigations:

• Implement strict URL whitelisting for threat intelligence feeds.
• Use a proxy or web application firewall (WAF) to filter outbound requests.
• Apply the principle of least privilege to user roles (limit who can configure threat intelligence).
• Monitor logs for SSRF patterns.

Workarounds:

• Disable the threat intelligence module if not in use.
• Use a dedicated, isolated network segment for the Logpoint server.

Valters IT