helsecert/cve-2021-44228Guía en noruego sobre las vulnerabilidades de Log4j (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, CVE-2019-17571) con scripts de detección, pasos de mitigación y mapas mentales para identificar y remediar sistemas afectados.
Actualización 19.12.2021: Se siguen descubriendo nuevas vulnerabilidades y nuevas formas de explotarlas en Log4j. Hemos añadido tres diagramas de flujo (mapas mentales) al repositorio git que describen respectivamente versiones vulnerables de Log4j, cómo comprobar si se es vulnerable y mitigación de las distintas vulnerabilidades.
Identifique el software que utiliza Log4j versión 2.x
Mitigue las vulnerabilidades en Log4j
Si lo anterior no es posible
Context Lookups en Pattern Layouts en la configuración de Log4j2Identifique el software que utiliza Log4j versión 1.x.
Si se utiliza Log4j versión 1.x en la organización, contacte con el proveedor y exija que
El lobo feroz de las vulnerabilidades en Log4j. La vulnerabilidad se explota cuando una variante de la cadena ${jndi:ldap://\<angrepskode>/a} es registrada por Log4j. CVSS 10.0, RCE.
No es tan grande como CVE-2021-44228, pero igual de fea. Requiere una configuración no estándar de Log4j. CVSS 9.0, RCE y DoS.
No es tan grande como CVE-2021-44228, y también un poco menos fea. CVSS 7.5, DoS
Solo afecta a Log4j versión 1.x. Requiere que Log4j utilice JMSAppender. CVSS 6.6, RCE La explotación requiere que Log4j utilice JMSAppender. Ya sea porque JMSAppender está configurado directamente - algo poco habitual - o porque el atacante lo añade él mismo a la configuración de Log4j. Además, el atacante debe tener acceso para modificar la configuración de JMSAppender. Si este es el caso, el atacante normalmente ya tendría acceso al sistema. Por lo tanto, la vulnerabilidad se considera poco relevante.
Solo afecta a Log4j versión 1.x. Requiere que Log4j utilice SocketServer. CVSS 9.8, RCE Otorga al atacante con acceso de red al socket correspondiente la posibilidad de ejecutar código. El código de explotación está disponible públicamente.
Para Java 8, Log4j v. 2.17.0 es la última versión. Mitiga todas las vulnerabilidades anteriores.
La versión 2.16.0 mitiga las peores vulnerabilidades.
Para Java 7, Log4j se ha publicado en la versión 2.12.2. Esta no mitiga CVE-2021-45105. El equipo detrás de Log4j señala además que ya no se soportan ni Java 6 ni Java 7. No está claro si publicarán otra actualización de seguridad para Log4j en Java 7.
El diagrama de flujo "Mind map #1" ofrece una buena visión general de las condiciones para saber si se tienen las distintas vulnerabilidades.
Creado por Loïc Castel. Obtenido de github.
Parte del desafío es que no son necesariamente los servidores directamente expuestos a internet los que son vulnerables. La vulnerabilidad puede estar en un servidor más atrás en la 'cadena' que recibe los mismos datos y los registra. Esto puede dificultar saber qué está expuesto y qué no.
El diagrama de flujo "Mind map #2" ofrece una buena visión general de cómo comprobar los propios sistemas en busca de las vulnerabilidades.
Creado por Loïc Castel. Obtenido de github.
- User-agent
- Campo de búsqueda
- Nombre de usuario
- ...
4. Haga seguimiento de las alertas del canario y averigüe dónde se ejecuta log4j.
Este comando recorre todos los discos, incluidas las unidades de red asignadas:
Get-PSDrive -PSProvider FileSystem | foreach {(gci ($_.Root) -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path)}
Ref: https://twitter.com/0gtweet/status/1469661769547362305
Si solo se desea comprobar los discos locales:
Get-CimInstance win32_volume | Where-Object { $_.DriveType -eq 3 -and $_.DriveLetter -ne $null} | ForEach-Object {(gci ($_.DriveLetter+"\") -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path)}
Ref: https://twitter.com/webmastir/status/1470386184052486155?s=20
Si además se desea revisar el registro de eventos de la máquina.
Get-WinEvent -ListLog * |
foreach { get-winevent @{logname=$_.logname; } -ea 0 } |
where message -match 'jndi'
#!/bin/bash
find / -name '*log4j*.jar' -print0 2>/dev/null -print0 | while read -d $'\0' log4j; do
echo -en "${log4j}: "$(unzip -p "${log4j}" | strings | grep -Po '^Implementation-Version:\s+([0-9\.]+)' | awk '{ print $NF }')"\n"
done
exit 0
Se ejecuta como root
lsof | grep log4j-core
El diagrama de flujo "Mind map #3" ofrece una visión general de las opciones de mitigación.
Creado por Loïc Castel. Obtenido de github.
A continuación hemos enumerado algunos recursos para llevar a cabo las mitigaciones.
Actualice Log4j a la v 2.17.0
Actualice Log4j a la v 2.12.2 NOTA: no mitiga CVE-2021-45105
⚠️ este método ya no se considera una solución completamente válida, ya que no mitiga todas las vulnerabilidades en todas las situaciones.
[Environment]:https://raw.githubusercontent.com/helsecert/cve-2021-44228/main/:SetEnvironmentVariable(%22LOG4J_FORMAT_MSG_NO_LOOKUPS%22,%22true%22,%22Machine%22)
NOTA: Requiere reinicio