El parche de emergencia para la infame vulnerabilidad en la biblioteca Java Log4j no es infalible. Apache Software Foundation está lanzando una nueva versión para corregir la vulnerabilidad de una vez por todas.
Una vulnerabilidad en una biblioteca muy popular para Java está sacudiendo el panorama mundial de TI. Se estima que la biblioteca existe en la mayoría de los entornos corporativos.
Log4j se utiliza principalmente para el registro. Los eventos en las aplicaciones se pueden registrar con notas. Piense en una copia impresa de los detalles de inicio de sesión después de un intento de inicio de sesión. O, en el caso de una aplicación web en Java, el nombre del navegador al que el usuario intenta conectarse.
Los últimos ejemplos son comunes. En ambos casos, un usuario externo influye en el registro que genera Log4j. Es posible abusar de esa influencia. Los registros de cualquier versión de Log4j entre el 13 de septiembre de 2013 y el 5 de diciembre de 2021 pueden indicar a las aplicaciones Java que ejecuten el código desde un servidor remoto en un dispositivo local.
Desde 2013, Log4j ha estado procesando una API: JNDI, o Java Naming and Directory Interface. La adición de JNDI permite que una aplicación Java ejecute código desde un servidor remoto en un dispositivo local. Los programadores instruyen agregando una sola línea de detalles sobre el servidor remoto en una aplicación.
El problema es que no solo los programadores pueden agregar la regla a las aplicaciones. Supongamos que Log4j registra los nombres de usuario de los intentos de inicio de sesión. Cuando alguien ingresa la línea antes mencionada en el campo de nombre de usuario, Log4j ejecuta la línea y la aplicación Java interpreta un comando para ejecutar el código en el servidor especificado. Lo mismo ocurre con los casos en los que Log4j registra una solicitud HTTPS. Si cambia el nombre de un navegador a la línea, Log4j ejecuta la línea, indicándole indirectamente que ejecute el código como desee.
El parche de emergencia también puede ser inseguro
El 9 de diciembre, la vulnerabilidad salió a la luz a gran escala. Apache Software Foundation, desarrollador de Log4j, lanzó un parche de emergencia (2.15) para corregir la vulnerabilidad. Desde entonces, ha sido una prioridad para los proveedores de software procesar la versión 2.15 y proporcionar un parche para las organizaciones.
Sin embargo, la organización de seguridad LunaSec afirma que el parche no es completamente impermeable. Sigue siendo posible ajustar una configuración y ejecutar los comandos JNDI registrados.
Tenga en cuenta: la configuración relevante debe ajustarse manualmente, de modo que las variantes no modificadas de 2.15 sean realmente seguras. Sin embargo, Luna Sec recomienda que los proveedores y organizaciones actualicen a Log4j 2.16. 2.16 fue publicado por Apache Software Foundation en respuesta a LunaSec. La nueva versión elimina por completo la configuración vulnerable, por lo que es imposible crear las condiciones para el abuso.