Apache Log4j: Resumen de vulnerabilidades asociadas a Log4Shell

No suelo realizar publicaciones de este tipo pero considero este caso como una excepción.

"Log4j" o "Log4Shell" se han convertido en trending topic no solo en las comunidades de Ciberseguridad sino también en los entornos tecnológicos en general. 

Si hablásemos de un "Top Vulnerabilidades 2021" está claro que se lo llevarían las asociadas a Apache Log4j, el revuelo de esto no está tanto por el número de vulnerabilidades publicadas y su gravedad, sino por el impacto de afectación que está teniendo en una enorme cantidad de productos y servicios. El mayor problema es identificar las aplicaciones que lo usan, en muchos casos las empresas carecen de un inventario actualizado de las aplicaciones que utilizan. El inventario es fundamental en materia seguridad.

Por esta razón he realizado un resumen de las vulnerabilidades asociadas a Log4j publicadas hasta la fecha. (Este post se irá actualizado según se vayan publicando nuevas vulnerabilidades relacionadas)

CVE-2021-44228

• Base Score: Crítico, 10.0
• Publicación: 10/12/2021
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
• Versiones afectadas: Apache Log4j2 2.0-beta9 a 2.12.1 y 2.13.0 a 2.15.0.
• CWE: Deserialización de datos, validación de entrada incorrecta, consumo incontrolado de recursos.

Vulnerabilidad Log4Shell original es una falla de deserialización. Otorga capacidades de ejecución remota de código (RCE) a atacantes no autenticados. Se encuentra explotable en componentes log4j-core, limitado a las versiones 2.x: desde la 2.0-beta9 hasta la 2.14.1 inclusive.

Se implementó una solución para Log4Shell en la versión 2.15.0, pero actualmente se considera incompleta.

CVE-2021-45046

• Base Score: Crítico, 9.0
• Publicación: 14/12/2021
• Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
• Versiones afectadas: 2.0.1 - 2.12.2 (excluido) y 2.13.0 - 2.16.0 (excluido).
• CWE: Deserialización de datos.

Tras la explotación provoca una denegación de servicio (DoS). Log4j 2.16.0 soluciona este problema eliminando la compatibilidad con los patrones de búsqueda de mensajes y desactivando la funcionalidad JNDI de forma predeterminada.

CVE-2021-4104

• Base Score: Alto, 8.1
• Publicación: 14/12/2021
• Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
• Versiones afectadas: JMSAppender en Log4j 1.2.
• CWE: Deserialización de datos.

Aunque anteriormente se pensaba que Log4j 1.x era seguro, ya no es así. Esencialmente, la configuración no predeterminada de las instancias de Log4j 1.x que utilizan la clase JMSAppender también se vuelve susceptible a la falla de deserialización que no es de confianza. 

Este CVE afecta todas las versiones de los componentes log4j:log4j y org.apache.log4j:log4j para los cuales solo existen versiones 1.x. Debido a que estas son versiones al final de su vida útil, no existe una solución para la rama 1.x en ninguna parte, y se debe actualizar a Log4j-core 2.16.0 o superior. 

Es posible protegerse eliminando JMSAppender por completo de log4j-1.2.17.jar, con el siguiente comando. https://www.slf4j.org/log4shell.html

zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

 

CVE-2021-42550

• Base Score: Medio, 6.6
• Publicación: 16/12/2021
• Vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
• Versiones afectadas: Versión 1.2.7 de Logback y versiones anteriores.
• CWE: Deserialización de datos.

Esta es una vulnerabilidad en el framework Logback, un sucesor de la biblioteca Log4j 1.x. Se han publicado versiones más recientes de Logback v1.3.0-alpha11 y v1.2.9 que abordan esta vulnerabilidad menos grave.

CVE-2021-45105

• Base Score: Alto, 7.5
• Publicación: 18/12/2021
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Versiones afectadas: Log4j2 2.0-alpha1 hasta 2.16.0 (incluido).
• CWE: Validación de entrada incorrecta, recurrencia incontrolada.

Se descubrió que Log4j 2.16.0 era vulnerable a una falla DoS calificada como Alta. Apache ha lanzado una versión log4j 2.17.0 que corrige esta vulnerabilidad. 

https://logging.apache.org/log4j/2.x/security.html

CVE-2021-44832

• Base Score: Medio, 6.6
• Publicación: 28/12/2021
• Vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
• Versiones afectadas: Log4j2 2.0-beta7 hasta la 2.17.0 (excluyendo las versiones de corrección de seguridad 2.3.2 y 2.12.4).
• CWE: Validación de entrada incorrecta, RCE (Ejecución remota de código).

Vulnerabilidad de ejecución remota de código (RCE) en el que un atacante con permiso para modificar el archivo de configuración de registro puede construir una configuración maliciosa utilizando un JDBC Appender con una fuente de datos que haga referencia a un URI JNDI que pueda ejecutar código remoto. Se trata una vulnerabilidad RCE con un score medio debido a su complejidad de explotación y al nivel de alto privilegio que el atacante debería conseguir previamente para explotar esta vulnerabilidad de forma exitosa.

Este problema se soluciona limitando los nombres de fuentes de datos JNDI al protocolo java en las versiones 2.17.1, 2.12.4 y 2.3.2 de Log4j2.

Saludos!

Renovar certificados SSL: Comprabar si el certificado, clave privada y el CSR coinciden (OpenSSL)

Al renovar los certificados de un servidor web podemos encontrarnos con errores en el momento de sustitución de los ficheros de certificados.

Apache + configuración SSLCipher strong

# SSLCiphers strong encryption
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

# SSL certs config
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/web/public.crt
SSLCertificateKeyFile /etc/apache2/ssl/web/private.key
SSLCertificateChainFile /etc/apache2/ssl/web/intermediate.crt

Nginx + configuración SSLCipher strong

ssl on;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# Fix 'The Logjam Attack'.

ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

ssl_dhparam /etc/ssl/dh2048_param.pem;

#SSL certs config

ssl_certificate /etc/nginx/ssl/web/intermediate.crt;

ssl_certificate_key /etc/nginx/ssl/web/private.key;

 

CA Bundle

Si disponemos de un fichero CA Bundle no es otra cosa que un certificado intermediate y raíz de la CA en un solo archivo, uno detrás del otro, debes combinarlos en uno solo para tener un CA_bundle completo. Los certificados raíz no son necesarios cuando se instala el certificado, para la instalación es suficiente activar en el servidor el correspondiente certificado intermediate.

El orden de los certificados es partir del dominio y hacia la raíz. Intermedio cert1, intermedio cert2 por encima y así sucesivamente.

La cadena es necesaria para mejorar la compatibilidad de los certificados con los navegadores web y otro tipo de clientes para que los navegadores reconozcan su certificado y no aparezcan advertencias de seguridad.

Comprobar la integridad

Para Comprobar la integridad de los ficheros de certificados, debemos revisar que la suma de verificación (checksum) es la misma para el certificado, la clave privada y el CSR (Certificate Signing Request). Los tres deben coincidir para ser válidos entre sí.

Si se obtiene un valor MD5 o SHA256 diferente, significa que el certificado, la clave privada y el CSR no coinciden. De ser así podría ser que el certificado no se hubiese creado con el mismo CSR o el CSR se ha creado con otra clave privada. Para comprobar estos valores podemos hacerlo mediante modulus usando OpenSSL.

Usando OpenSSL: MD5 y sha256sum

Certificado, clave privada, CSR: 

# openssl x509 -noout -modulus -in public.crt | md5
# openssl rsa -noout -modulus -in private.key | md5
# openssl req -noout -modulus -in intermediate.csr | md5

# openssl x509 -noout -modulus -in public.crt | sha256sum
# openssl rsa -noout -modulus -in private.key | sha256sum
# openssl req -noout -modulus -in intermediate.csr | sha256sum

Saludos!

fail2ban: Control de ataques de fuerza bruta en servicios de sistemas Linux

fail2ban es una aplicación IDPS (Intrusion Detection and Prevention Systems) que supervisa las conexiones externas de direcciones IPs a servicios internos, se puede parametrizar para bloquear los intentos de accesos externos por fuerza bruta. En base al cumplimiento de las directivas definidas y asociadas a determinados servicios.

fail2ban detecta conexiones que puedan ser anómalas y bloquea la IP pública que intenta acceder a dichos servicios por lo que sería un sistema activo (analiza, detecta y actua al momento), lo hace añadiendo reglas iptables rechazado las conexiones procedentes de esa dirección IP pública.

fail2ban escanea los ficheros de logs de los servicios configurados como por ejemplo "/var/log/auth.log" (ssh) o "/var/log/apache/error_log" (apache), comprobando los criterios establecidos en las directivas de cada servicio y banenado aquellas direcciones IPs públicas que intentaron acceder a dicho servicio y baneando estas direcciones IPs.

En el fichero de configuración de servicios asociados a fail2ban, se refieren a estos servicios como "jails".

/etc/fail2ban/jail.conf

En el caso de configurar el servicio SSH se podría definir de la siguiente manera.

[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
bantime = 86400
findtime = 600
maxretry = 3

Donde las directivas son:

• bantime = Número de segundos en el cual una dirección IP permanecerá prohibida (10 min por defecto).
• findtime = Cantidad de tiempo entre intentos de inicio de sesión, antes de que se elimine el host. (predeterminado 10 min).
• maxretry = Número de intentos que deben realizarse antes de que se aplique una prohibición. (por defecto 3 intentos).

Consultar las IPs que intentaron acceder y fueron baneadas o bloqueadas

Desde el cliente fail2ban-client indicando el tipo de jail (servicio sshd).

# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 1
|  |- Total failed:     4
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     2
   `- Banned IP list:   67.10.125.108

A través de iptables.

# iptables -L -n
Chain f2b-sshd (1 references)
target     prot opt source               destination
REJECT     all  --  67.10.125.108        0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

REJECT - reject-with icmp-port-unreachable: Conexión rechazada

Visualizar los registros de logs

Se almacenan en el fichero de log /var/log/fail2ban.log.

Podemos hacer un "grep Ban" para ver los registros de las direcciones IPs baneadas y un "grep Unban" para las IPs que ya hayan sido desbloqueadas, transcurrido los tiempos definidos anteriormente en las directivas del fichero jail.conf.

# cat /var/log/fail2ban.log | grep Unban
2019-07-15 21:12:41,602 fail2ban.actions        [18533]: NOTICE  [sshd] Unban 67.10.125.108
2019-07-15 21:32:01,540 fail2ban.actions        [18705]: NOTICE  [sshd] Unban 74.15.62.217
2019-07-15 21:42:50,191 fail2ban.actions        [18705]: NOTICE  [sshd] Unban 49.80.215.108
...

Banear dirección IP manualmente

fail2ban-client set <JAIL-NAME> banip <IP-ADDRESS>

# fail2ban-client set sshd banip 37.10.145.208

Desbanear dirección IP manualmente

fail2ban-client set <JAIL-NAME> unbanip <IP-ADDRESS>

# fail2ban-client set sshd unbanip 37.10.145.208

Desbanear dirección IP manualmente a través de iptables indicando el número de regla.

# iptables -L f2b-sshd --line-numbers
Chain f2b-sshd (1 references)
num  target     prot opt source               destination
1    REJECT     all  --  67.10.125.108        0.0.0.0/0            reject-with icmp-port-unreachable
2    RETURN     all  --  anywhere             anywhere

# iptables -D f2b-sshd 1

Desbanear IP manualmente a través de iptables indicando directamente la dirección IP pública.

iptables -D f2b-sshd -s 67.10.125.108 -j REJECT

Configurar una Whitelist en fail2ban

Configurar un pool de IPs a ignorar de los baneos o bloqueos temporales. Se define con la directiva ignoreip en el fichero de configuración /etc/fail2ban/jail.conf.

ignoreip = 127.0.0.1/8 ::1 <IP interna o externa, rango de red a ignorar>
ignoreip = 127.0.0.1/8 ::1 192.168.10.0/24

Saludos!