O parche de emerxencia para a infame vulnerabilidade da biblioteca de Java Log4j non é infalible. Apache Software Foundation está a lanzar unha nova versión para corrixir a vulnerabilidade dunha vez por todas.
Unha vulnerabilidade nunha biblioteca moi popular para Java está sacudindo o panorama global das TI. Estímase que a biblioteca existe na maioría dos ambientes corporativos.
Log4j úsase principalmente para rexistrar. Os eventos nas aplicacións pódense rexistrar con notas. Pense nunha impresión dos datos de inicio de sesión despois dun intento de inicio de sesión. Ou, no caso dunha aplicación web en Java, o nome do navegador ao que un usuario está tentando conectarse.
Estes últimos exemplos son comúns. En ambos os casos, un usuario externo inflúe no rexistro que saca Log4j. É posible abusar desa influencia. Os rexistros de calquera versión de Log4j entre o 13 de setembro de 2013 e o 5 de decembro de 2021 poden indicar ás aplicacións Java que executen o código desde un servidor remoto nun dispositivo local.
Desde 2013, Log4j está a procesar unha API: JNDI, ou Java Naming and Directory Interface. A adición de JNDI permite que unha aplicación Java execute código desde un servidor remoto nun dispositivo local. Os programadores instrúen engadindo unha única liña de detalles sobre o servidor remoto nunha aplicación.
O problema é que non só os programadores son capaces de engadir a regra ás aplicacións. Supoñamos que Log4j rexistra os nomes de usuario dos intentos de inicio de sesión. Cando alguén introduce a liña mencionada anteriormente no campo do nome de usuario, Log4j executa a liña e a aplicación Java interpreta un comando para executar o código no servidor especificado. O mesmo ocorre cos casos nos que Log4j rexistra unha solicitude HTTPS. Se cambia o nome dun navegador pola liña, Log4j executa a liña, indicándolle indirectamente que execute o código segundo o desexa.
O parche de emerxencia tamén pode ser inseguro
O 9 de decembro, a vulnerabilidade saíu á luz a gran escala. Apache Software Foundation, desenvolvedor de Log4j, lanzou un parche de emerxencia (2.15) para corrixir a vulnerabilidade. Desde entón, foi unha prioridade para os provedores de software procesar a versión 2.15 e proporcionar un parche para as organizacións.
Non obstante, a organización de seguridade LunaSec afirma que o parche non é completamente estanco. Segue sendo posible axustar unha configuración e executar os comandos JNDI rexistrados.
Teña en conta: a configuración relevante debe axustarse manualmente, para que as variantes non modificadas de 2.15 sexan seguras. Non obstante, Luna Sec recomenda que os provedores e organizacións actualicen a Log4j 2.16. 2.16 foi publicado pola Apache Software Foundation en resposta a LunaSec. A nova versión elimina completamente a configuración vulnerable, polo que é imposible crear as condicións para o abuso.