Introduction
As a distributed open-source messaging system, Apache Kafka provides high throughput and low latency processing for various types of data. It is widely used in log collection, stream processing, and message queuing fields. Recently, Kafka is facing a tricky security attack, Kafka Connect Java Naming and Directory Interface (JNDI) Injection (CVE-2023-25194).
Kafka Connect is a data stream pipeline tool, included in Kafka versions 0.9 and later. Its various connectors can connect to different data sources and destinations, processing data conversion and mapping between them. This was a meaningful creation to simplify the integration of other systems into Kafka, but its flexibility and efficiency come at a cost.
Vulnerability
Let’s retrace the steps of Kafka Connect being hacked. Kafka Connect can be managed and monitored using various APIs, of which HTTP REST API service on port 8083 is enabled by default for configuring connectors in its standalone version.
Starting from Apache Kafka 2.3.0, to increase connector reusability and scalability, Authenticated operators can modify Kafka client’s SASL Java Authentication and Authorization Service (JAAS) configuration and SASL-based security protocols. After version 3.0.0, the integration is standardized and operators can easily configure connector properties in Kafka cluster, including setting the Kafka client’s ‘sasl.jaas.config’ property to ‘com.sun.security.auth.module.JndiLogin Module.’
This will allow the Kafka server to connect to the attacker’s LDAP server and deserialize (a procedure of converting serialized data back into objects or data structures) the LDAP response. Attackers can then construct gadget chains on the server to cause unrestricted deserialization of untrusted data or Remote Code Execution (RCE) vulnerabilities, which is called JNDI injection.
Remediation
In the latest release of Apache Kafka, version 3.4.0, new system property has been added to disable the problematic login modules. Additionally, we have compiled a list of precautionary measures, which include:
- Only accept data from trusted sources and ensure the authenticity and integrity of the data.
- Filter and verify serialized data during the deserialization process.
- Upgrade connectors and dependencies, or remove connectors as a remedial option.
- Generate connector client configuration override policies to manage which properties can be directly overridden and which cannot.
Implementing the Fix
Hillstone collects this vulnerability as threat intelligence and provides adequate protection with IPS signature database (version 3.0.145 and higher) and Anti-Virus signature database (version 2.1.495 and higher). Devices such as Hillstone Next-generation Intrusion Prevention System (NIPS) and iSource can automatically activate and deploy this ability based on the signature databases.
