Puerta trasera SSH
Un mantenedor nefasto o comprometido insertó un comportamiento malicioso en una biblioteca llamada liblzma, parte de las bibliotecas y herramientas de compresión xz, lo que da como resultado una puerta trasera en SSH. Este es un ataque avanzado a la cadena de suministro de software, ya que la biblioteca fue modificada intencionalmente para la puerta trasera, con técnicas de ofuscación y sigilo para ocultar la carga útil del ataque a los revisores. Se descubrió y divulgó recientemente (el pasado 29 de marzo) y el manejo del ataque está en curso. Sin embargo, se contuvo rápidamente ya que parece afectar solo a versiones preliminares de un conjunto limitado de entornos (paquetes DEB y RPM, para la arquitectura x86_64 y creados con GCC). De todos modos, el CVE se le dio un Puntuación base del CVSS de 10, que se reserva para las vulnerabilidades de ciberseguridad más críticas. Si se incluyera en distribuciones estables, el impacto sería abrumador. El análisis técnico del ataque, incluyendo la Explicación detallada de la puerta trasera XZ, se analizó en otro lugar. En este artículo nos centraremos en la cronología del ataque, cómo se pudo detectar, cómo se manejó el incidente hasta la fecha y qué lecciones se pueden extraer del ataque.Cómo se inyectó la puerta trasera del XZ
Nota: El repositorio de git está en git.tukaani.org. Sin embargo, también hubo un Repositorio alojado en GitHub (actualmente bloqueado) donde la cuenta de GitHub publicaba los cambios que luego se integraron en el repositorio de Git. Una parte de la puerta trasera parece estar solo en los archivos comprimidos distribuidos para las versiones 5.6.0 y 5.6.1, no en los repositorios de git y se basa en un una sola línea en build-to-host.m4 Archivo de macro utilizado por autoconf. La otra parte estaba en dos supuestos archivos de prueba. malo-3-corrupto_lzma2.xz y bueno-grande_comprimido.lzma que eran comprometido por la cuenta de GitHub “Jia Tan” (JiaT75) En la repositorio xz el 23 de febrero. Fue un cambio inocuo al agregar archivos de prueba (supuestamente bloques comprimidos .lzma y .xz). Curiosamente, ¡las pruebas no utilizaron los archivos de prueba! La línea en el archivo .m4 inyecta un script ofuscado (incluido en el tarball) que se ejecutará al final de la configuración si algunas condiciones coinciden. Modifica el Makefile para el liblzma biblioteca que contiene código que extrae datos del archivo .xz, que finaliza después de la desofuscación en este guión, se invoca al final de configure. Decide si modificar el proceso de compilación para inyectar código: solo bajo GCC y el vinculador GCC, bajo Debian o rpm, y solo para Linux x86_64. Cuando coincide, el código inyectado intercepta la ejecución reemplazando dos sifunc resolutores para que ciertas llamadas sean reemplazadas. Esto hace que las tablas de símbolos se analicen en la memoria (esto lleva tiempo, lo que llevó a la detección, como se explica más adelante). Entonces las cosas se ponen interesantes: la puerta trasera instala un gancho de auditoría en el vinculador dinámico, esperando que llegue el símbolo de función RSA_public_decrypt, que se redirige a un punto dentro del código de la puerta trasera, que a su vez vuelve a llamar. libcripto, presumiblemente para realizar una autenticación normal. Y la carga útil se activa si el programa en ejecución tiene el nombre del proceso. / usr / sbin / sshd. Estaba claro que el objetivo eran los servidores SSH. Tradicionalmente, sshd servidores como OpenSSH no estaban vinculados con liblzma, pero sshd es a menudo parcheado para admitir systemd-notify para que otros servicios puedan iniciarse cuando sshd se esté ejecutando. Y luego liblzma se carga indirectamente por sistemad, cerrando el círculo. La puerta trasera aún no está completamente analizada, pero parece que sí permitiendo la ejecución remota de comandos (ICE) con los privilegios del demonio sshd, ejecutándose en un contexto de autenticación previa. La información del certificado remoto, cuando coincide con la puerta trasera, se descifra con ChaCha20 y, cuando se descifra correctamente, se pasa al sistema(). Así que esto es esencialmente un RCE cerrado, mucho peor que una simple omisión de clave pública. Un tarball 5.6.1 posterior mostró esfuerzos adicionales para ocultar los rastros, agregando más ofuscación a los nombres de los símbolos e intentando corregir los errores observados. Un mecanismo de extensión También se implementó un lugar donde se buscaron archivos de prueba adicionales para ciertas firmas para agregar a la puerta trasera. Este ataque bastante sofisticado podría pasar desapercibido hasta que se alcancen distribuciones estables de Linux. Afortunadamente, a algunas personas les gusta comprobar por qué suceden cosas anormales.El descubrimiento del ataque de puerta trasera XZ
Muchas veces, el comportamiento malicioso inyectado se descubre por casualidad o accidente. Un buen ejemplo fue un advertencia de desuso (“¿A quién le importan las advertencias?”) que llevó al descubrimiento de la ataque de flujo de eventos en octubre de 2018. Otro es el usuario que advirtió códigocov en abril de 2021 que su script de carga de bash no pasó la suma de verificación (“¿Quién verifica la integridad de los artefactos con sumas de verificación”?) Anomalías y síntomas extraños con ssh login(login(consumen mucha CPU y aumentan el tiempo transcurrido, errores de valgrind) despertaron la curiosidad de Andrés Freund, un desarrollador de PostgreSQL atento pero no un analista de seguridad (como afirmó). Después de investigar un poco con OpenSSH en Debian Sid, concluyó que un problema de tiempo de respuesta dependía de una biblioteca, liblzma, Parte de la xz-utils biblioteca de compresión. La razón: "el repositorio xz ascendente y los archivos comprimidos xz tienen una puerta trasera”. ¡Este diagnóstico fue tan preciso! El 29 de marzo de 2024 Andrés publicó en Openwall el primer análisis: “puerta trasera en xz/liblzma ascendente que lleva a comprometer el servidor ssh”. El hecho: los tarballs de XZ Utils 5.6.0 y 5.6.1 contienen una puerta trasera. Estos archivos comprimidos fueron creados y firmados por la cuenta de Jia Tan antes mencionada. He publicado en Mastodonte más tarde ese día, reconociendo que el descubrimiento fue accidental y requirió muchas coincidencias. Vale la pena leer los comentarios de otros usuarios. usuario de GitHub el mismo mismo (también conocido como Sam James) publicó una buena esencia Preguntas frecuentes sobre la puerta trasera xz-utils donde se resumió el ataque, vinculándolo a más análisis en profundidad de la carga útil del ataque. Estos análisis fueron técnicamente jugosos y nos ayudaron a comprender mejor la inyección, que estaba muy elaborada:- xz/liblzma: Explicación de la ofuscación en etapa Bash. Bonito análisis sobre la desofuscación mediante el script de inyección, en cuatro “etapas”.
- El hilo celeste de Filippo Valsorda Análisis de la propia puerta trasera en RSA_public_decrypt, que muestra su naturaleza: un RCE, sin bypass de autenticación y cerrado (acepta la clave privada del autor y, si no, vuelve al comportamiento normal) / irreembolsable. ¡El autor tenía la intención de mantener un perfil bajo para evitar ser detectado!
- Análisis de puerta trasera XZ por @smx-smx (WIP) – Análisis adicional de la puerta trasera (me perdí casi al principio 😀)
- Wiki de documentación de puerta trasera xz, otro análisis del script de inyección 5.6.1.
Cómo se manejó el incidente
La divulgación de Andreas Freund fue cautelosa porque, en sus propias palabras:Dada la aparente implicación del desarrollador original, no he reportado ningún error. Como inicialmente pensé que se trataba de un problema específico de Debian, envié un informe preliminar a security@...ian.org. Posteriormente, reporté el problema a distros@. CISA fue notificado por una distribución”.
Red Hat asignó a este problema CVE-2024-3094. Entonces la palabra circuló como la pólvora.
Lasse Collin, el otro mantenedor del XZ, agregó un New commit el sábado 30 de marzo titulado “CMake: Reparar la comprobación saboteada de la zona de pruebas de Landlock”. Uno de los métodos de aislamiento de la biblioteca fue saboteado, al menos cuando se construyó con CMake. Rápidamente reveló el problema en el Puerta trasera de XZ Utils.
Red Hat asignó este problema CVE-2024-3094 (ver también en CVE, NVD, Ubuntu). Se le asignó una enorme Puntuación base CVSS de 10. Este tipo de puntuaciones siempre arrasan en Internet.
CISEl mismo 29 de marzo se publicó un alerta, quizás demasiado simplista debido a la urgencia, recomendando a los usuarios bajar a la versión estable 5.4.6.
Los repositorios de GitHub bajo la organización Tukaani fueron deshabilitados (¿es esto bueno o malo? Creo que es bueno: muchas distribuciones y organizaciones todavía se vinculaban a las versiones de GitHub para obtener los archivos comprimidos infectados para la compilación. Deshabilitar el repositorio evita eso. De todos modos, hay una copia o los repositorios en git.tukaani.org). Las cuentas de GitHub JiaTan75 y Lasse Collins (Larhzu) también fueron suspendidas. Esto es parte del contención, incluso cuando pueda afectar a personas inocentes. JiaT75 actividad en repositorios no deshabilitados No se puede ver todavía.
La industria reaccionó rápidamente. Muchos proveedores publicaron reglas para detectar sistemas vulnerables, como reglas de yara, o soporte en herramientas comerciales de sysdig, PAN, y otros. Especialistas en seguridad como James Berthoty publicado sobre la revisión de cómo abordamos el software de código abierto.
Ahora estamos en la fase de Erradicación y Recuperación del incidente. Otros proyectos mantenidos por JiaTan75 están bajo estrecha revisión, en particular el libarchivo/libarchivo (donde JiaTan75 era un colaborador habitual) y el fuzzer oss-fuzz (donde esto commit hecho por JiaTan75 intentó evitar oss-fuzz, que de hecho no fue capaz de detectar la puerta trasera). Estos intentos de ocultamiento añaden más pruebas.
¿Quién está bajo ataque?
O la cuenta GitHub JiaT75 se vio comprometida (recuerde que GitHub exigió 2FA recientemente) o el usuario físico que debía la cuenta pasó al lado oscuro. Pero hay razones de peso para pensar en una amenaza persistente avanzada (APT), quizás respaldada por el Estado, debido a la sofisticación técnica del ataque. Una investigación más profunda por parte de las agencias de ciberseguridad y las fuerzas del orden dirá... Esta entrada en YCombinator Hacker News sobre Jia Tan arroja algo de luz sobre el “quién” y su actividad. ¡Recomendado! Proporciona mucha información sobre cómo los malos intentan engañar a otros usuarios mediante ingeniería social.“Muy molesto. El aparente autor de la puerta trasera estuvo en comunicación conmigo (rwmj) durante varias semanas intentando que se añadiera xz 5.6.x a Fedora 40 y 41 debido a sus "grandes nuevas características". Incluso trabajamos con él para solucionar el problema de valgrind (que ahora resulta que fue causado por la puerta trasera que había añadido). Anoche tuvimos que apresurarnos para solucionar el problema después de una ruptura involuntaria del embargo. Ha sido parte del proyecto xz durante 2 años, añadiendo todo tipo de archivos binarios de prueba y, para ser honesto con este nivel de sofisticación, sospecharía incluso de versiones anteriores de xz hasta que se demuestre lo contrario”.
Jia Tan tomó medidas para evitar ser rastreado: parece haber usado VPN (vpn.singapore.witopia.net) para conectarse, lo cual está bien en sí mismo. Y muchos cambios parecen estar respaldados por correos electrónicos temporales de un solo uso (de ProtonMail en este caso) que instan a fusionar los cambios.
El actor podría intentar profundizar aún más, hasta el kernel de Linux, como colaborador del xy-integrado proyecto. Un análisis inicial no encontró evidencia de aborto espontáneo, hasta el día de hoy.
Nota: otro Colaborador de bajo perfil de XZ "Hans Jansen" (Usuario de GitHub “hansjans162”) es bajo escrutinio. Su cuenta en debian ahora es bloqueado. Hizo muchas actualizaciones a Debian Games para ocultar el que quería en debian/xz-utils, una actualización a la versión 5.6.1 para acelerar la distribución del backdoor a debian/inestable.
Todo lo que podemos decir, por ahora, es que se trata de una APT (aún no identificada) que utiliza diferentes cuentas, que trabaja durante al menos dos años en esta campaña y que trabaja pacientemente para implantar un RCE en SSH.
¿Se podría haber evitado el ataque de puerta trasera de XZ?
Bastante difícil. En primer lugar, parte de la puerta trasera inyectada se incluía en archivos de prueba comprimidos que no se utilizaban en las pruebas. Retrospectivamente, esto podría generar algunas alarmas (ruidosas), pero ¿a quién le importa comprobar que todos los archivos de prueba se utilizan en las pruebas reales? En segundo lugar, parte de la puerta trasera inyectada se incluía en archivos de macro en los archivos tar de la versión, y es difícil comprobar manualmente las diferencias con los archivos tar esperados. La automatización también es compleja, ya que el resultado esperado de la propia compilación (para cualquiera que conozca el funcionamiento de automake/autoconf) es difícil de modelar para analizar si el archivo tar real cumple con las expectativas. Algunos lo plantearon as "El hecho de que los archivos comprimidos no coincidan con el árbol de git es una característica, no un error". La procedencia de los archivos comprimidos binarios a partir de su código fuente es un problema no resuelto. ¿Reputación del usuario? Bueno, la cuenta de GitHub de JiaTan75 no estaba haciendo cosas deshonestas según el pasado. commits. Fue suspendido sólo después de que se acumularon las pruebas, pero hasta el 29 de marzo era un usuario habitual que realizaba actividades normales. Bueno, no tan normal. Más tarde commit(este vídeo , este vídeo , este vídeo y este vídeo que ajustó el código de explotación) intentó corregir los errores y fallas de valgrind en algunas configuraciones, debido a diferencias con el diseño de pila esperado por la puerta trasera. Commit las revisiones podrían detectar esto, pero ¿quién tiene la paciencia para analizar los cambios en un archivo de prueba binario o la motivación real para un cambio en los atributos GCC en el código fuente C? ¿Deberíamos dar la alarma cuando un SSH login ¿Toma 800 ms en lugar de 300 ms? Probablemente sólo las personas hiperprudentes tomarían nota. Cicerón dijo, “La temeridad pertenece a la juventud; prudencia hasta la vejez”. La infraestructura ifunc fue agregada en junio de 2023 por “Hans Jansen” y “Jia Tan”. Este es el primero commit agregando soporte ifunc a crc64_fast.c (luego usado para inyectar la puerta trasera). ¡Meses antes de inyectar los binarios de puerta trasera en los archivos de prueba!
Nota: Autor y commitAquí pueden diferir, pero esto es normal: Lasse Collin es el responsable del proyecto y fusionó los cambios. Incluso agradece a “Hans Jansen”…
Nadie expresó preocupaciones ante la publicación de Andrés Freund y el CVE creado por RedHat. Si ve una cascada de herramientas que detectarían esto, ahora detectan el componente afectado, ex post facto.
Probablemente la mejor prevención provino de la naturaleza de las distribuciones de Linux, y de cómo las versiones inestables y de vanguardia solo pasan a distribuciones estables posteriores siguiendo un proceso pausado.
Lecciones aprendidas del ataque backdoor de XZ
Hemos observado lo difícil que es detectar intencional puertas traseras. Las puertas traseras deben considerarse una amenaza interna, ya que son colocadas por personal interno o a través de cuentas internas comprometidas. Y en ellos se confía principalmente. Y cuando la puerta trasera se implanta en el artefacto distribuido, resulta más difícil de detectar.
Algunos autores como Kevin Beaumont señaló a te, lo que abre una gran superficie de ataque de servicios de terceros a la puerta trasera. De esto es de lo que abusó el mal actor aquí. Systemd tiene muchos ojos, pero XZ es una biblioteca oscura en la cadena. “Cuando el río arriba está contaminado, todo el mundo bebe agua envenenada río abajo”.
Una solicitud de cambio no relacionada en el sistema para cargar dinámicamente bibliotecas de compresión, que eliminaría la puerta trasera, ya se incorporó al sistema pero aún no se entregó. Las dependencias adicionales introducidas por libsystemd pueden ser la fuente de vulnerabilidades, y ayer esta solicitud fue abierta.
A comentario en "xz: Desactivar ifunc para solucionar el problema" commit dio una idea clara sobre dónde poner el foco si queremos prevenir dicha actividad (el énfasis es mío):
“La lección que debemos aprender como comunidad es más bien asegurar software supply chain security De manera integral, auditar sistemas de compilación más allá del código fuente. Como la infracción de SolarWinds, donde los atacantes modificaron las actualizaciones de software para la oferta de software de monitoreo de código cerrado de SolarWinds”.
El descubrimiento temprano y la pronta reacción limitaron mucho el impacto. Si recuerdas el escena final de Hombres de Negro III: "Eso estuvo cerca". Una vez más, K no se olvidó de dejar la propina. Y ningún boglodita entró en las distribuciones estables de Linux.
1. "No soy investigador de seguridad ni ingeniero inverso". 2. Jia es un nombre común chino. Tan también es un apellido común que significa "magnífico". Muchas personas sin parentesco comparten este nombre, ¡por favor, no critiquen a nadie por este nombre!
