{"id":9071,"date":"2021-12-15T15:34:10","date_gmt":"2021-12-15T15:34:10","guid":{"rendered":"https:\/\/www.soltel.es\/?p=4449"},"modified":"2025-08-14T12:07:43","modified_gmt":"2025-08-14T12:07:43","slug":"log4shell-la-vulnerabilidad-critica-que-trae-de-cabeza-desde-elasticsearch-a-minecraft","status":"publish","type":"post","link":"https:\/\/www.soltel.es\/en\/log4shell-la-vulnerabilidad-critica-que-trae-de-cabeza-desde-elasticsearch-a-minecraft\/","title":{"rendered":"Log4Shell, la vulnerabilidad cr\u00edtica que trae de cabeza desde ElasticSearch a Minecraft"},"content":{"rendered":"

Fin de semana movidito para los equipos de IT. El pasado viernes 10 de Diciembre saltaron todas las alarmas habidas y por haber en el mundo de la ciberseguridad: Apache Log4J, una de las librer\u00edas de logs m\u00e1s extendida y utilizada del mundo, presentaba una vulnerabilidad zero-day que permit\u00eda a un atacante ejecutar de forma remota c\u00f3digo fuente malicioso en los sistemas que la utilizasen.<\/p>\n

Esta vulnerabilidad, etiquetada por el CVE como CVE-2021-44228<\/a> (<\/strong>pero conocida com\u00fanmente como Log4Shell)<\/strong>, por su facilidad de explotaci\u00f3n y la gravedad de la misma, ha sido catalogada con un 10 sobre 10<\/strong>, convirti\u00e9ndose en una de las m\u00e1s peligrosas de los \u00faltimos a\u00f1os.<\/p>\n

Por suerte, solo poco m\u00e1s de 24 horas despu\u00e9s ya se public\u00f3 una nueva versi\u00f3n de la librer\u00eda (2.15.0) que solventa el problema. Ahora, solo basta con actualizar a la versi\u00f3n 2.15.0<\/del>\u00a02.16.0<\/del>2.17.0<\/del> 2.17.1 para dejar de ser vulnerable.<\/p>\n

Desde Soltel, llevamos d\u00edas inmersos en el proceso de coordinarnos entre nuestros equipos y clientes para corregir el problema.<\/p>\n

Log4Shell: En que consiste y c\u00f3mo funciona<\/strong><\/em><\/h2>\n

A grandes rasgos, la vulnerabilidad explota por un lado la capacidad de evaluar expresiones existente en Log4j junto a que no comprueba ciertos protocolos como ldap<\/strong>. Uniendo estos dos factores, un atacante puede, mediante la intermediaci\u00f3n de un servidor ldap malicioso ser capaz de retornar c\u00f3digo java como respuesta y conseguir que el servidor vulnerable ejecute lo que se haya dejado en el ldap para su maliciosa \u201cevaluaci\u00f3n\u201d por parte de Log4J<\/strong>.<\/p>\n

\"LOG4SHELL.drawio\"<\/p>\n

\u00bfC\u00f3mo puedo saber si estoy afectado?<\/strong><\/em><\/h2>\n

Cualquier software que utilice las librer\u00edas log4j-core y log4j-api en su s versiones de la 2.0 a la 2.14.1<\/del> 2.15.0<\/del> 2.16.0 es vulnerable, por lo que hay que localizarlas. En proyectos mavenizados, por ejemplo, nos podemos precisamente apoyar en Maven para ello y su funci\u00f3n de lista de dependencias:<\/p>\n\n\n\n
\u00a0\u00a0mvn dependency:list | grep log4j<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Importante, no nos vayamos a creer que por usar una versi\u00f3n 1.x de Log4j vamos a estar a salvo.<\/strong> Log4j 1.x termin\u00f3 su ciclo de vida en Agosto de 2015<\/strong>, por lo que deber\u00edamos actualizar igualmente<\/strong>. Como prueba de ello se acaba de publicar precisamente la vulnerabilidad\u00a0CVE-2021-4104<\/a>, que por otros medios tambi\u00e9n permite la ejecuci\u00f3n de c\u00f3digo malicioso en nuestros entornos<\/strong>. Y no es la \u00fanica vulnerabilidad existente, hay algunas mas reportadas en a\u00f1os anteriores<\/a>.<\/p>\n

 <\/p>\n

Si est\u00e1s acostumbrado al uso de herramientas de an\u00e1lisis est\u00e1tico de seguridad, es casi seguro que ya est\u00e9n generando alertas al respecto.<\/p>\n

Por ejemplo, el analizador de dependencias OWSAP Dependency Check<\/strong><\/em> (uno de los m\u00e1s populares) ya es capaz de ello:<\/p>\n

\"owasplog4j\"<\/p>\n

 <\/p>\n

Pero \u00a1OJO!<\/strong>, cuidado con limitarse solo con el software propio<\/strong>. Es muy, muy posible que tu infraestructura est\u00e9 utilizando esta librer\u00eda a trav\u00e9s de otros productos intermedios. La lista de sistemas afectados no para de crecer<\/a>, pasando por\u00a0Minecraft: Java Edition, Twitter, Cloudflare, Tencent, ElasticSearch, Redis, Elastic Logstash<\/em><\/strong> y otro largo etc\u00e9tera, por lo que se debe estar atento.<\/p>\n

 <\/p>\n

Mitigando el error<\/strong><\/em><\/h2>\n

Si tu software est\u00e1 afectado, hay actualmente tres v\u00edas de mitigaci\u00f3n posibles: Actualizar tus librer\u00edas, desactivar la evaluaci\u00f3n por Lookup y, en ultima instancia, eliminar o parchear en nuestro sistema la clase JndiLookup.<\/p>\n

 <\/p>\n

Contramedida 1: Subir de versi\u00f3n Log4j<\/strong><\/h3>\n

Evidentemente la soluci\u00f3n ideal es subir log4j a una versi\u00f3n que no eval\u00fae\u00a0por defecto estas expresiones<\/b>. Esto ocurre a partir de la versi\u00f3n 2.15.0<\/del>, 2.16.0<\/del>, 2.17.0<\/del> 2.17.1 ya disponible.<\/p>\n

Tambi\u00e9n se han publicado parches para los sistemas que funcionen bajo versiones anteriores de java: 2.12.4<\/strong> (Java 7) y 2.3.2<\/strong> (Java 6).<\/p>\n

 <\/p>\n

Contramedida\u00a0\u00a0<\/strong><\/del>2: log4j2.formatMsgNoLookups = true<\/del> (OBSOLETO)<\/strong><\/h3>\n

Si no es sencillo el recambio inmediato la actualizaci\u00f3n de la librer\u00eda, \u00a0se puede mitigar el efecto arrancando el servicio afectado con el par\u00e1metro log4j2.formatMsgNoLookups seteado a true. De esta forma forzamos a que el sistema no realice lookups cuando eval\u00fae expresiones.<\/p>\n

Esto es v\u00e1lido para las versiones 2.10 a 2.14.1. Versiones inferiores pueden probar la tercera v\u00eda.<\/p>\n

Esta medida, es recomendable, aunque se aplique la actualizaci\u00f3n, aplicar este par\u00e1metro. Tened en cuenta que en sistemas dockerizables, se puede forzar desde su archivo de construcci\u00f3n de imagen DockerBuild.<\/p>\n\n\n\n
\u00a0\u00a0java -jar -Dlog4j2.formatMsgNoLookups=true mijar.jar<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n
\u00a0\u00a0export JAVA_OPTS=$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n\n\n\n
Actualizaci\u00f3n [2021-12-15]<\/strong><\/em>: Esta contramedida no ser\u00eda aplicable<\/strong> para mitigar la nueva vulnerabilidad\u00a0\u00a0CVE-2021-45046<\/a>\u00a0reportada el dia 14\/12\/2021, por lo que actualmente se considera insuficiente<\/strong>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Contramedida\u00a0\u00a0<\/strong>3: Eliminar clase JndiLookup de tu pila t\u00e9cnica.<\/h3>\n

Como ultimo recurso, si tu versi\u00f3n log4j no se puede actualizar a la versi\u00f3n 2.17.1 (o a las versiones 2.12.4 (Java 7) \/ 2.3.2 (Java 6)), solo te queda localizar si en tu pila t\u00e9cnica o la de tu servidor de arranque est\u00e1 la clase org.apache.logging.log4j.core.lookup.JndiLookup<\/em> y o bien eliminarla, o bien reemplazarla por una implementaci\u00f3n vac\u00eda.<\/p>\n

Ejemplo<\/strong><\/em>:<\/p>\n\n\n\n
\u00a0 \u00a0 zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Adem\u00e1s, para evitar las posteriores vulnerabilidades publicadas,\u00a0CVE-2021-45105 y CVE-2021-45106, Se recomienda en la configuraci\u00f3n de logging, evitar referencias a contextos que pueden venir de entradas no controladas (cabeceras http, datos introducidos por el usuario, etc) como ${ctx:loginId} o $${ctx:loginId}. Alternativamente, tambi\u00e9n se pueden utilizar patrones del\u00a0Thread Context Map (% X,% mdc o% MDC), evitando\u00a0as\u00ed la recursividad\u00a0 no controlada que genera el problema.<\/p>\n

Referencias:<\/em><\/h2>\n