CVE-2024-56128

Incorrect Implementation of Authentication Algorithm in Apache Kafka&amp;#39;s SCRAM implementation.<br /> <br /> Issue Summary:<br /> Apache Kafka&amp;#39;s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].<br /> Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.<br /> However, Kafka&amp;#39;s SCRAM implementation did not perform this validation.<br /> <br /> Impact:<br /> This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly<br /> discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].<br /> Deployments using SCRAM with TLS are not affected by this issue.<br /> <br /> How to Detect If You Are Impacted:<br /> If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.<br /> To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.<br /> <br /> Fix Details:<br /> The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.<br /> <br /> Affected Versions:<br /> Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.<br /> <br /> Fixed Versions:<br /> 3.9.0<br /> 3.8.1<br /> 3.7.2<br /> <br /> Users are advised to upgrade to 3.7.2 or later to mitigate this issue.<br /> <br /> Recommendations for Mitigation:<br /> Users unable to upgrade to the fixed versions can mitigate the issue by:<br /> - Using TLS with SCRAM Authentication:<br /> Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.<br /> - Considering Alternative Authentication Mechanisms:<br /> Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.