~ 3 min read

Confluent Kafka Connector Analysis for Log4j (CVE-2021-44228) vulnerability

A post about how we performed an analysis of the Kafka connectors in use for a customer to detect if they were vulnerable to the recently discovered Log4j vulnerability - CVE-2021-44228 and CVE-2021-45046.

Background

The Log4j vulnerability has taken the Internet by storm since its discovery late last week. We at Kloudle have been busy keeping up with the different announcements and advisories from Cloud platforms and SaaS providers and creating easy to consume reading and sharing material for your teams and customers. There is constant and ongoing investigations for a host of software being conducted to identify the scope and extent of the vulnerability.

As part of aiding a customer with identifying all vulnerable software, the Platform Security Team at Kloudle undertook an analysis of the Kafka connectors in use to see if they are vulnerable to CVE-2021-44228 and CVE-2021-45046.

Confluent released an advisory to address the prevalence of this vulnerability in Kafka and other products. However, information about whether Kafka connectors are vulnerable or not was not made available when this exercise was undertaken. This analysis was conducted to identify if the Confluent Kafka Connectors in use by our customer are vulnerable or not independently of the updates provided by Confluent.

Steps Taken to Verify

  1. We logged into Confluent Cloud
  2. The names and Connector Class for all the clusters in use were noted. This was done to get a sense of what is running within the clusters.
  3. For each unique connector class, the documentation link was obtained. This was done by attempting to “Add a new Connector”, which on Confluent Cloud also presents a link to the documentation page on https://docs.confluent.io/
  4. From each documentation page, we identified the Confluent Platform hub URL for an offline install of the Connector for the Confluent Platform
  5. A local copy of the Connector in zip format was downloaded
  6. The code within each of the Connector was reviewed for references to log4J within properties, manifests and other JAR binaries for vulnerable instances or references to JMSAppender in case of log4j1
  7. The results of the findings were reported

What did we discover?

We analysed the following Kafka Connectors for the log4j vulnerability. None of them were found to be vulnerable.

  1. Redshift Sink (https://docs.confluent.io/kafka-connect-aws-redshift/current/overview.html)
  2. S3 Sink (https://docs.confluent.io/kafka-connect-s3-sink/current/overview.html)
  3. MongoDb Kafka Connector (https://docs.mongodb.com/kafka-connector/master/)
  4. JDBC Connector (Source and Sink) (https://docs.confluent.io/kafka-connect-jdbc/current/index.html)

Potential Next Steps?

There are over several hundred Kafka connectors and a lot of them are not Confluent-supported. Confluent has released a notification of the impact to Confluent supported connectors that it was able to identify and is requesting information about any third party connectors if found vulnerable. Our team will continue to identify and report any vulnerable connectors we do discover. Please check back for updates.

We have also added an issue to the CISA Gov Github page regarding our findings.

;