Security vulnerabilities often come in all shapes and sizes. Sometimes, something as simple as a verbose log can end up being a huge data leak. This is exactly what happened with CVE-2024-52975, an information disclosure bug in Elastic's Fleet Server. If your organization uses Fleet Server with Elastic integrations, you should definitely pay attention to this one.

What is Fleet Server?

Fleet Server is a service running within the Elastic Stack that handles configuration management for Elastic Agents. It's a central point for managing security, monitoring, and observability agents across your infrastructure.

What is CVE-2024-52975?

CVE-2024-52975 is an information disclosure vulnerability that affects Fleet Server. The issue? When you managed or updated policies through Fleet Server, those full policies—including potentially sensitive information—were logged at both the INFO and ERROR log levels.

Depending on which integrations you deployed, these logs could accidentally include passwords, API keys, tokens, or other secrets.

The Nature of the Leak

Every time a policy is created, edited, or an error occurs while processing it, Fleet Server would log the entire policy payload. This payload could have embedded API keys, secret access tokens, credentials for cloud providers, or other sensitive settings entered via integrations.

That means anyone with access to Fleet Server logs, even at the INFO level, could view secret configuration details—making lateral movement or further compromise much easier in the event of a breach.

Exploitation Details and Risk

To exploit this vulnerability, an attacker doesn’t have to breach your security perimeter. All they would need is access to the machine (or whatever cluster centralizes your logs) running Fleet Server with verbose logging enabled. From there, the attacker could simply grep logs or search for secrets that should only be known to admins.

Example: Policy with Sensitive Info

Let’s say you’re running the AWS integration to collect CloudWatch logs. You might input your AWS secret access keys directly into the policy for Fleet:

{
  "inputs": [
    {
      "type": "aws/metrics",
      "config": {
        "access_key_id": "AKIAIOSFODNN7EXAMPLE",
        "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
      }
    }
  ]
}

This whole object gets written to the logs! Now imagine those logs being shipped and stored somewhere with weaker access controls.

How the Vulnerable Code Works

In the vulnerable versions of Fleet Server, the code responsible for logging incoming policy payloads did so without redacting sensitive fields first. Here’s a simplified pseudocode snippet:

// Vulnerable code
logger.Infof("Applying new policy: %s", policyPayload)

On any error

logger.Errorf("Failed to apply policy: %s. Error: %v", policyPayload, err)

Fixing the Problem

The Elastic team has fixed the bug in recent Fleet Server releases by ensuring that sensitive fields are redacted before logging. Now, if you try to update a policy, the log output looks like this:

logger.Infof("Applying new policy: %s", redactSensitive(policyPayload))

Where redactSensitive replaces all secrets with asterisks or similar placeholders.

Upgrade Now:
Update your Fleet Server to the latest patched version as soon as possible. Audit your existing logs for exposed secrets, rotate any credentials found, and consider tightening logging access.

References and Further Reading

- Elastic CVE-2024-52975 Security Advisory
- NVD Entry for CVE-2024-52975
- Elastic Fleet Server Documentation


Takeaway:
If Fleet Server is deployed in your environment, treat your logs as sensitive and upgrade immediately. A simple logging mistake can open the door to attackers without them needing a foothold. Review your logs and access policies, and always sanitize logs—before it's too late.

Timeline

Published on: 01/23/2025 08:15:16 UTC