Introducción
Como sistema de mensajería distribuido de código abierto, Apache Kafka proporciona un procesamiento de alto rendimiento y baja latencia para varios tipos de datos. Es ampliamente utilizado en los campos de recopilación de registros, procesamiento de flujos y colas de mensajes. Recientemente, Kafka se está enfrentando a un complicado ataque de seguridad, Kafka Connect Java Naming and Directory Interface (JNDI) Injection (CVE-2023-25194).
Kafka Connect es una herramienta de canalización de flujos de datos, incluida en las versiones 0.9 y posteriores de Kafka. Sus diversos conectores pueden conectarse a diferentes fuentes y destinos de datos, procesando la conversión de datos y el mapeo entre ellos. Se trata de una creación con sentido para simplificar la integración de otros sistemas en Kafka, pero su flexibilidad y eficacia tienen un coste.
Vulnerabilidad
Volvamos sobre los pasos del hackeo de Kafka Connect. Kafka Connect puede ser gestionado y monitorizado utilizando varias APIs, de las cuales el servicio HTTP REST API en el puerto 8083 está habilitado por defecto para configurar conectores en su versión standalone.
A partir de la versión 2.3.0 de Apache Kafka, para aumentar la reutilización y escalabilidad de los conectores, los operadores autenticados pueden modificar la configuración de SASL Java Authentication and Authorization Service (JAAS) del cliente Kafka y los protocolos de seguridad basados en SASL. Tras la versión 3.0.0, la integración está estandarizada y los operadores pueden configurar fácilmente las propiedades del conector en el clúster Kafka, incluida la configuración de la propiedad «sasl.jaas.config» del cliente Kafka a «com.sun.security.auth.module.JndiLogin Module».
Esto permitirá al servidor Kafka conectarse al servidor LDAP del atacante y deserializar (un procedimiento de conversión de datos serializados de nuevo en objetos o estructuras de datos) la respuesta LDAP. Los atacantes pueden entonces construir cadenas de gadgets en el servidor para provocar la deserialización sin restricciones de datos no confiables o vulnerabilidades de Ejecución Remota de Código (RCE), lo que se denomina inyección JNDI.
Solución
En la última versión de Apache Kafka, la 3.4.0, se ha añadido una nueva propiedad del sistema para deshabilitar los módulos de inicio de sesión problemáticos. Además, hemos recopilado una lista de medidas de precaución, que incluyen:
- Aceptar únicamente datos de fuentes de confianza y garantizar la autenticidad e integridad de los datos.
- Filtrar y verificar los datos serializados durante el proceso de deserialización.
- Actualizar conectores y dependencias, o eliminar conectores como opción correctiva.
- Generar políticas de anulación de la configuración del cliente del conector para gestionar qué propiedades se pueden anular directamente y cuáles no.
Implementación de la solución
Hillstone recoge esta vulnerabilidad como inteligencia de amenazas y proporciona una protección adecuada con la base de datos de firmas IPS (versión 3.0.145 y superior) y la base de datos de firmas Anti-Virus (versión 2.1.495 y superior). Dispositivos como Hillstone Next-generation Intrusion Prevention System (NIPS) e iSource pueden activar y desplegar automáticamente esta capacidad basándose en las bases de datos de firmas.
