Xzbot: notas, honeypot y demo de exploit para la puerta trasera de xz

 (github.com/amlweems)
1 puntos por GN⁺ 2024-04-02 | 1 comentarios | Compartir por WhatsApp

Exploración de la puerta trasera de xz (CVE-2024-3094)

  • honeypot: detecta intentos de intrusión mediante un servidor vulnerable falso
  • ed448 patch: parchea liblzma.so para usar una clave pública ED448 propia
  • backdoor format: formato del payload de la puerta trasera
  • backdoor demo: CLI que activa RCE asumiendo que se conoce la clave privada ED448

honeypot

  • Se proporciona un parche simple para OpenSSH que registra todos los intentos de conexión cuyo valor N de clave pública coincide con el formato de la puerta trasera
  • Los intentos de conexión aparecen en los logs de sshd de la siguiente manera

ed448 patch

  • La puerta trasera usa una clave pública ED448 codificada de forma fija para verificar firmas y descifrar payloads
  • Si esta clave se reemplaza por una propia, es posible activar la puerta trasera
  • Se descarga el objeto compartido libxzma que contiene la puerta trasera y se ejecuta el script de parche para sustituir la clave

backdoor format

  • Es posible activar la puerta trasera conectándose con un certificado SSH e incluyendo el payload en el valor N de la clave de firma CA
  • Este payload debe estar cifrado y firmado con la clave ED448 del atacante
  • La estructura del payload sigue el formato especificado

backdoor demo

  • Se muestra cómo conectarse a un servidor SSH vulnerable y ejecutar el comando id > /tmp/.xz
  • En el servidor vulnerable se puede monitorear la llamada a system() y observar que el comando se ejecuta
  • El árbol normal de procesos de sshd y el árbol de procesos a través de la puerta trasera se ven diferentes

Opinión de GN⁺

  • Este artículo aborda una exploración profunda de la vulnerabilidad de puerta trasera de xz identificada como CVE-2024-3094, y ofrece información muy útil para investigadores de seguridad y administradores de sistemas.
  • Al presentar métodos para detectar y responder a la puerta trasera, puede ayudar a proteger sistemas vulnerables.
  • Dado que este tipo de vulnerabilidades puede eludir mecanismos fundamentales de seguridad del sistema, los desarrolladores de software y profesionales de seguridad deben comprenderlas y tomar medidas para prevenirlas.
  • Otras herramientas o proyectos de seguridad con funciones similares incluyen OpenSSH, Fail2Ban y Snort, que pueden aportar capas adicionales de defensa para proteger sistemas.
  • Como este artículo ofrece detalles técnicos sobre una nueva vulnerabilidad, puede ayudar a la comunidad de seguridad a desarrollar estrategias de defensa más sólidas.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-02
Opiniones de Hacker News
  • Resumen de comentarios de Hacker News:
    • Un señalamiento interesante sobre una vulnerabilidad de RCE (Remote Code Execution) que requería la clave privada del atacante. Corrección: entendí mal el enlace y dejo el comentario original como registro.

      • Esta vulnerabilidad, irónicamente, parecía haber sido diseñada con la seguridad en mente. Además, en el mismo hilo de correos se vio que la persona que hizo commit del backdoor también había contribuido recientemente al kernel.

    • Admiración por la rapidez con la que la comunidad hacker, y en particular amlweems, implementó y documentó el POC (Proof of Concept). Corrección: el siguiente paso es encontrar cómo identificar distribuciones vulnerables y cómo monitorear el probing activo contra servidores SSH.

      • Elogios a la rápida respuesta y análisis de la comunidad.

    • Curiosidad por saber si el PoC se ha probado contra herramientas que detectan comportamiento anómalo (Carbon Black, AWS GuardDuty, SysDig, etc.) y si eso permitiría detectarlo rápidamente.

      • Interés en pruebas del PoC con herramientas de detección de comportamiento anómalo.

    • Duda sobre si funcionaba incluso sin una conexión SSH. La lista de cadenas en GitHub incluye "DISPLAY" y "WAYLAND_DISPLAY".

      • Especulación sobre un alcance adicional del impacto debido a la presencia de cadenas no directamente relacionadas con SSH.

    • Pregunta sobre cómo se aplicó el parche a openssh_RSA_verify cuando liblzma.so.5.6.1 se cargaba en memoria, sin requerir openssh.patch en tiempo de ejecución.

      • Pregunta técnica sobre el proceso de explotación de la vulnerabilidad en tiempo de ejecución.

    • El hecho de que un ataque exitoso no dejara registros. Esto llevó a preguntar si el atacante podía ejecutar comandos arbitrarios sin dejar logs.

      • Preocupación por la posibilidad de atacar sin generar registros.

    • Opiniones sobre cómo respondieron a esta vulnerabilidad los responsables de los proyectos xz, OpenSSH y Linux, y sobre cómo podrían prevenirse vulnerabilidades similares en el futuro.

      • Interés en la respuesta de los responsables de los proyectos y en medidas de prevención a futuro.

    • Debate sobre espionaje a nivel estatal y backdoors. Estados Unidos tiende a preferir la intervención en hardware, mientras que otros países, como Israel, se enfocan en backdoors de software de largo plazo.

      • Análisis de estrategias de backdoors según el país.

    • Duda sobre la razón para usar ED448, a pesar de que normalmente se recomienda curve 25519.

      • Cuestionamiento de la elección de un algoritmo criptográfico específico.