TL;DR

El FilteredObjectInputStream (FOIS) de Log4j es una lista blanca de deserialización basada en resolveClass. Su lista blanca incluye java.rmi.MarshalledObject. Un MarshalledObject almacena su carga útil como un byte[] opaco, y MarshalledObject.get() deserializa esa carga útil en un ObjectInputStream nuevo y sin filtrar — por lo que la lista blanca nunca inspecciona el grafo interno.

Log4j lo activa por sí mismo: Log4jLogEvent$LogEventProxy (la forma serializada en el cable de un LogEvent, desde 2.8) transporta el Message del evento dentro de un MarshalledObject y llama a .get() automáticamente durante la deserialización (readResolve() → message()). Cualquier aplicación que lea un LogEvent serializado a través de FOIS realiza, por tanto, una deserialización sin filtrar de bytes del atacante — y como message() se traga la excepción resultante y recurre a SimpleMessage, el receptor registra un evento benigno y sigue ejecutándose. El exploit es silencioso.

Causa raíz (verificada contra rel/2.26.1)

Qué ejecuta el laboratorio

Un sustituto fiel del obsoleto ObjectInputStreamLogEventBridge de log4j-samples: un receptor TCP no autenticado que lee un LogEvent serializado por conexión a través de FOIS. El atacante envía un único objeto serializado; el oráculo es un archivo de prueba escrito en un directorio montado por bind únicamente en el contenedor del receptor, de modo que su aparición demuestra que el código se ejecutó dentro del receptor mediante deserialización.

rce = código ejecutado. rechazo = FOIS lanzó una excepción en el flujo externo. silencioso = objeto externo procesado, no se ejecutó código (bloqueado más adentro, o la versión del gadget es segura).

Ejecutarlo

Requisitos: solo Docker (se descarga un JDK como eclipse-temurin:17-jdk). El script descarga los jars oficiales y los verifica contra el SHA-1 de Maven Central antes de usarlos. Fija una versión diferente de Log4j dentro del rango vulnerable con LOG4J_VERSION=2.20.0 ./run.sh.

Impacto y método de ataque

• Entrega: una única escritura TCP no autenticada de ~2.8 KB de un LogEvent serializado a un receptor basado en FOIS. No se puede activar haciendo que se registre una cadena (a diferencia de Log4Shell) — necesita bytes serializados crudos que lleguen al puente de socket.
• Resultado: ejecución arbitraria de comandos en el proceso receptor, de forma silenciosa.
• Ruta de ataque: construir un LogEvent → writeReplace()/writeObject() de Log4j envuelve el Message en un MarshalledObject → el gadget se oculta dentro de su byte[] opaco → en el receptor, readResolve() → message() → MarshalledObject.get() abre un flujo nuevo sin filtrar → gadget → Runtime.exec. src/attacker/Attacker.java (poc2) inserta un grafo de CommonsCollections6 puro en el objBytes del MarshalledObject, por lo que no se necesita ninguna clase del atacante en la víctima.

Mitigación

• Fiable: -Djdk.serialFilter='!java.rmi.MarshalledObject' en la JVM del receptor (S5). Advertencia: esto también bloquea los objetos LogEventProxy serializados legítimos (también usan MarshalledObject) — es eficaz pero no transparente para el transporte de logs serializados.
• Poco fiable: filtros genéricos de maxdepth/maxbytes. El filtro de todo el proceso se propaga al flujo interno del MarshalledObject y la profundidad se reinicia allí, por lo que maxdepth=5 bloquea CC6 (S6) pero un gadget poco profundo pasaría. Depende de la profundidad de la cadena, no es un límite.
• Estructural: eliminar el transporte de logs serializados en Java (usar JSON / RFC 5424 sobre TLS autenticado); eliminar las dependencias de gadgets conocidos; no exponer receptores serializados heredados a redes no confiables. Parche ascendente (según el problema): eliminar MarshalledObject de la lista blanca y mover el mensaje marshalled a los métodos filtrados writeWrappedObject/readWrappedObject de Log4j.

Alcance y limitaciones honestas

• Condicionado a la aplicación, no una RCE general de Log4j. Requiere una aplicación que exponga un receptor de LogEvent serializado no autenticado basado en FOIS y que tenga una versión de gadget utilizable en su classpath. Las implementaciones ordinarias de Log4j no ejecutan tal receptor.
• El servidor de socket serializado en el núcleo existió solo hasta 2.8.2 (net.server.TcpSocketServer se sacó de log4j-core en 2017; ausente desde 2.9.0). Los receptores modernos son código de aplicación/ejemplo, que es lo que este laboratorio modela.
• Depende de la versión del gadget. commons-collections 3.2.1 → RCE; 3.2.2 lo bloquea (S7). Cualquier gadget utilizable es suficiente, pero "tener commons-collections" no es por sí solo suficiente.
• uid=0 en el laboratorio es root del contenedor — no hay escape de Docker; la RCE se ejecuta como el proceso receptor.
• La primitiva (MarshalledObject burlando un filtro de resolveClass) es arte previo conocido; ver la discusión de Apache #4168 ("Endurecimiento de deserialización de Log4j 2.x"). La auto-activación específica de Log4j es la contribución de #4255.

Estructura

Referencias

• Problema #4255 — https://github.com/apache/logging-log4j2/issues/4255
• Discusión #4168 (endurecimiento de deserialización) — https://github.com/apache/logging-log4j2/discussions/4168
• FAQ de CWE-502 de Log4j — https://logging.apache.org/security/faq.html
• Aviso de seguridad de Apache Commons Collections — https://commons.apache.org/proper/commons-collections/security.html

Créditos

Vulnerabilidad reportada por U-Sec (Wujie Security) en Apache log4j2 #4255. Este repositorio es un laboratorio independiente de reproducción/validación para investigación defensiva e ingeniería de detección.