El gran peligro de la vulnerabilidad de Log4Shell se debía a una combinación de factores de riesgo. Examinemos los más importantes:
1. La vulnerabilidad de Java provenía de la biblioteca de registro.
Una biblioteca de registro como Log4J puede parecer de primeras relativamente inofensiva. Si la comparamos con las bibliotecas de autentificación o cifrado, la biblioteca de registro puede parecer menos importante.
2. El uso de Java está muy extendido.
Una de las características principales de Java como lenguaje y entorno es que funciona prácticamente en todas las plataformas, por lo que la vulnerabilidad Log4Shell afecta a un gran número de programas y servicios. Además, Java está integrado parcialmente en sistemas embebidos como rúteres o dispositivos del internet de las cosas, p. ej. cámaras privadas o dispositivos de domótica.
3. Integra muchas tecnologías distintas.
La problemática de la seguridad surge debido a la encadenación de múltiples tecnologías. La combinación de Log4J, JNDI, LDAP y las sustituciones de strings lleva a fallos de seguridad y favorece los ataques.
4. El exploit se filtra por planos más profundos.
Si un punto débil solo afecta al sistema vulnerable, en el mejor de los casos, los daños serán localizados. Pero imaginemos que se recibe un exploit string y se registra a través de una interfaz web. El exploit string acabará pasando a los sistemas subyacentes y se activará cuando se evalúe ahí.
5. Los exploit strings son difíciles de descubrir.
Debido a lo complejas que son las sustituciones, pueden ocultar código malicioso de muchas formas distintas, de manera que pueden intercalarse. Un string del estilo de ${${lower:j}ndi} no contiene directamente la cadena de caracteres jndi, por lo que no se puede filtrar automáticamente. De hecho, el string ${jndi} solo aparece en la resolución. Además, también es posible ocultar parte del código codificando base64, por lo que el string ${base64:SGVsbG8gV29ybGQhCg==} se evalúa como ”Hello World!”.