{"id":102661,"date":"2021-12-19T03:36:43","date_gmt":"2021-12-19T01:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov"},"modified":"2021-12-19T03:36:43","modified_gmt":"2021-12-19T01:36:45","slug":"eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","title":{"rendered":"Otra vulnerabilidad en Log4j 2. Los problemas en Log4j afectan al 8% de los paquetes de Maven.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
En la biblioteca Log4j 2 se ha detectado otra vulnerabilidad (CVE-2021-45105), que a diferencia de los dos problemas anteriores, se clasifica como peligrosa, aunque no cr\u00edtica. Este nuevo problema permite causar una denegaci\u00f3n de servicio y se manifiesta como un bucle infinito y un cierre inesperado al procesar ciertas cadenas. La vulnerabilidad ha sido corregida en la versi\u00f3n de Log4j 2.17 publicada hace unas horas. La gravedad de la vulnerabilidad se mitiga por el hecho de que el problema se presenta solo en sistemas con Java 8. <\/p>\n
Los sistemas son vulnerables cuando utilizan consultas contextuales (Context Lookup) para determinar el formato de salida en el registro, como ${ctx:var}. En las versiones de Log4j, desde 2.0-alpha1 hasta 2.16.0, no hab\u00eda protecci\u00f3n contra la recursi\u00f3n no controlada, lo que permit\u00eda a un atacante, mediante la manipulaci\u00f3n del valor utilizado en la sustituci\u00f3n, generar un bucle, lo que resultaba en el agotamiento del espacio en la pila y la finalizaci\u00f3n abrupta del proceso. En particular, el problema surg\u00eda al sustituir valores como \"${${::-${::-$${::-j}}}}\". <\/p>\n
Adicionalmente, se puede se\u00f1alar que los investigadores de Blumira han propuesto un tipo de ataque a las aplicaciones Java vulnerables que no aceptan solicitudes de red externas; por ejemplo, sistemas de desarrolladores o usuarios de aplicaciones Java pueden ser atacados de esta manera. La esencia del m\u00e9todo es que, al tener procesos Java vulnerables en el sistema del usuario que solo aceptan conexiones desde el host local (localhost) o que procesan solicitudes RMI (Remote Method Invocation, puerto 1099), el ataque puede ser llevado a cabo por un c\u00f3digo JavaScript ejecutado al abrir a los usuarios una p\u00e1gina maliciosa en el navegador. Para establecer la conexi\u00f3n con el puerto de red de la aplicaci\u00f3n Java durante un ataque de este tipo se utiliza la API WebSocket, que a diferencia de las solicitudes HTTP, no tiene restricciones de same-origin (WebSocket tambi\u00e9n puede ser utilizado para escanear puertos de red en el host local con el fin de identificar manejadores de red existentes).
<\/center> <\/p>\n
Tambi\u00e9n es interesante observar los resultados de la evaluaci\u00f3n de vulnerabilidades de bibliotecas relacionadas con Log4j, publicados por Google. Seg\u00fan Google, el problema afecta al 8% de todos los paquetes en el repositorio de Maven Central. En particular, 35863 paquetes de Java relacionados con Log4j son vulnerables, tanto a trav\u00e9s de dependencias directas como indirectas. De este modo, Log4j se utiliza como dependencia directa de primer nivel solo en el 17% de los casos, mientras que en el 83% de los paquetes afectados por la vulnerabilidad, la vinculaci\u00f3n se realiza a trav\u00e9s de paquetes intermedios dependientes de Log4j, es decir, dependencias de segundo y niveles m\u00e1s altos (21% de segundo nivel, 12% de tercer nivel, 14% de cuarto nivel, 26% de quinto nivel, 6% de sexto nivel). La rapidez en la correcci\u00f3n de la vulnerabilidad a\u00fan deja mucho que desear, ya que una semana despu\u00e9s de su descubrimiento, la problem\u00e1tica se ha solucionado solo en 4620 de los 35863 paquetes identificados, es decir, en el 13%.
<\/center> <\/p>\n
Mientras tanto, la Agencia de Ciberseguridad y Seguridad de Infraestructura de EE. UU. ha publicado una directiva de emergencia que obliga a las agencias federales a identificar los sistemas de informaci\u00f3n vulnerables a Log4j y a implementar actualizaciones que bloqueen el problema antes del 23 de diciembre. Hasta el 28 de diciembre, se les ha ordenado a las organizaciones informar sobre el trabajo realizado. Para facilitar la identificaci\u00f3n de los sistemas problem\u00e1ticos, se ha preparado una lista de productos en los que se ha confirmado la aparici\u00f3n de la vulnerabilidad (la lista incluye m\u00e1s de 23,000 aplicaciones). \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Otra](\"\/wp-content\/uploads\/2021\/12\/811931e8c3ae3f3f3c2e81db361034e6.jpg\")
<\/center> <\/p>\n![\"Otra](\"\/wp-content\/uploads\/2021\/12\/1e61b09923c7e055fa635545f1b3de6b.jpg\")
<\/center> <\/p>\n