La madriguera del backdoor de xz en sshd es mucho más profunda de lo esperado

 (twitter.com/bl4sty)
2 puntos por GN⁺ 2024-04-07 | 1 comentarios | Compartir por WhatsApp
  • El backdoor de xz en sshd activa parcialmente rutas de código adicionales más difíciles de alcanzar, más allá del hook inicial de RSA_public_decrypt
  • El flujo del ataque instala un hook en mm_answer_keyallowed con un comando manipulado y luego ensambla un búfer de comandos usando varias claves públicas ssh-rsa falsas
  • Ese “magic buffer” contiene comandos adicionales del backdoor y 2 firmas ed448; las firmas incorporan el digest SHA256 de la host key y el session_id del KEX
  • El PoC actual usa una biblioteca cliente SSH paramiko fuertemente modificada, y el comando 0x03 permite RCE basada en system() y configurar uid/gid
  • También se confirmó el bypass de autenticación: con mm_keyallowed_backdoor cmd 1 se puede sobrescribir la respuesta de mm_answer_authpassword e iniciar sesión con cualquier contraseña

Ruta del backdoor conectada más profundamente

  • El backdoor de xz en sshd incluye funciones más profundas que el comportamiento conocido inicialmente, y algunas ya fueron activadas directamente
  • El punto de entrada clave es el hook de RSA_public_decrypt
    • Al enviar un comando construido correctamente, se instala otro hook en la función mm_answer_keyallowed de sshd
    • Después se entregan varias claves públicas ssh-rsa falsas para fragmentar y recomponer el “magic buffer”
  • El “magic buffer” es un búfer que contiene comandos adicionales del backdoor
    • También incluye 2 firmas ed448
    • Estas firmas, al igual que la firma del backdoor del lado de RSA_public_decrypt, usan como salt el digest SHA256 de la host key
    • La firma final también incorpora el session_id de 0x20 bytes derivado del intercambio inicial de claves SSH (KEX)

PoC y bypass de autenticación

  • El PoC actual está implementado con una biblioteca cliente SSH paramiko fuertemente modificada
  • El comando activado actualmente es 0x03 en esta ruta de código
    • Vuelve a habilitar RCE básica mediante system()
    • También permite configurar uid/gid
  • Aún queda más código por entender, y parece posible un bypass completo de autenticación de sesiones interactivas porque uno de los comandos del backdoor en mm_answer_keyallowed termina haciendo hook también en mm_answer_keyverify
  • Después se confirmó el bypass de autenticación
    • mm_keyallowed_backdoor cmd 1 puede sobrescribir la respuesta de mm_answer_authpassword con un valor definido por el usuario
    • Si la respuesta se establece en { u32(9), u8(13), u32(1), u32(0) }, es posible iniciar sesión con cualquier contraseña

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-07
Comentarios de Hacker News

  • https://threadreaderapp.com/thread/1776691497506623562.html

  • Este incidente, en cierto sentido, se ve muy profesional y, en otro, bastante amateur, lo cual resulta extraño
    Construyeron durante mucho tiempo una identidad lo bastante confiable como para volverse mantenedores de un paquete importante, llevaron a cabo un ataque de ingeniería social en el que parece que participaron varias personas, no expusieron su identidad real ni el origen del ataque, y la ofuscación fue sofisticada
    Aun así, parece descuidado que se colaran bugs y una regresión de rendimiento en la versión de producción. Si de verdad hubiera sido una organización respaldada por un Estado y muy competente, uno pensaría que habrían hecho suficientes pruebas en privado antes de enviar algo a un proyecto público para eliminar una caída de rendimiento que levantara sospechas

    • Creo que la expectativa al oír “respaldado por un Estado” es demasiado alta. Las organizaciones grandes al final se parecen a otras organizaciones grandes: sufren burocracia, fechas límite, ciclos de lanzamiento y problemas de comunicación entre equipos
      El reciente incidente de iOS “que podría haber sido una puerta trasera” también muestra que las organizaciones que acumulan muchas vulnerabilidades no siempre se preocupan por quemar algunas
    • No es nada increíble que quienes desarrollaron el código no estuvieran al mismo tiempo ejecutando Valgrind y revisando el rendimiento
      El objetivo eran servidores y appliances, y ¿cuántos servidores o appliances ejecutan Valgrind en sus imágenes base? Viéndolo en retrospectiva parece obvio, pero probablemente probaron con las imágenes de sistema a las que apuntaban, no con las imágenes personalizadas de un desarrollador común
    • El 2024-02-29 se envió un PR para dejar de enlazar liblzma con libsystemd [0]
      Kevin Beaumont especuló que “Jia Tan” vio eso y se dio cuenta de inmediato de que la puerta trasera podía quedar inutilizada, así que se apresuró para no perder la enorme cantidad de trabajo invertida en este exploit [1], y eso suena plausible
      Esa presión de plazo habría provocado los crashes en 5.6.0, y no les habría dejado tiempo para pulir o eliminar la regresión de rendimiento, que fue la razón clave por la que se detectó este caso
      [0]: https://github.com/systemd/systemd/pull/31550
      [1]: https://doublepulsar.com/inside-the-failed-attempt-to-backdo...
    • Si hasta Google pudo lanzar Gemini como si nada, ¿de verdad es tan difícil de creer que una organización en las sombras pueda fracasar de formas más sutiles?
      Como ha observado Patrick McKenzie en otros contextos, las organizaciones criminales también funcionan con comités y consensos, igual que las no criminales. Visto así, tiene sentido que el barco se hunda por una caída de rendimiento causada por el exceso de funciones. En las empresas en las que he trabajado he visto errores todavía más amateurs
    • Incluso en organizaciones competentes respaldadas por un Estado puede haber accidentes. A veces los servicios de inteligencia no son tan implacablemente competentes como uno imagina. Los intentos de asesinato del Kremlin en el Reino Unido parecían casi una comedia de errores [1]
      Quizá también se les cerró otra puerta trasera o algún otro acceso alternativo que estaban usando, y necesitaban con urgencia una nueva vía
      [1] https://en.wikipedia.org/wiki/Poisoning_of_Alexander_Litvine...

  • Lo realmente interesante aquí es lo sofisticado que fue, y aun así al final cayó por una regresión de rendimiento bastante visible
    Me recuerda una cita que escuché de un programa real sobre crimen: “Hay un millón de maneras de que te atrapen por asesinato, y si puedes pensar siquiera en la mitad, eres un genio”

    • Tiene sentido si había un equipo detrás de la cuenta. Alguien pudo haber desarrollado la funcionalidad, y otra persona, más descuidada o con menos experiencia, pudo haberla integrado
      Otra persona también pudo haber estado administrando las cuentas falsas e interactuando en los comentarios y en los PR
    • Tal vez soy ingenuo o demasiado confiado, pero cada vez que me preocupa que estas puertas traseras ya estén ampliamente distribuidas, pienso en esto
      No sé si esta vez simplemente tuvieron mala suerte y los descubrieron, o si en realidad este tipo de ataque es demasiado difícil de ejecutar con éxito. Ojalá fuera lo segundo, pero la verdad es que no se puede saber
    • Si no recuerdo mal, la regresión de rendimiento solo ocurría cuando el código se compilaba con -fno-omit-frame-pointer, que no es el valor predeterminado. https://mastodon.social/@AndresFreundTec/112187000944648334
    • Si hubieran tenido suficiente tiempo y hecho más pruebas locales, es muy probable que lo hubieran logrado
      Estoy seguro de que el parche de @teknoraver para libsystemd cambió su fecha límite
    • ¿Eso de “si puedes pensar siquiera en la mitad” también aplica para el lado que intenta resolver los asesinatos?

  • Cuando salen muchos textos técnicos que se meten a fondo en los detalles de un caso así, a menudo me pregunto por qué todos dicen “esto seguro fue patrocinado por un Estado” o “miren las marcas de tiempo, es evidencia irrefutable”
    Es cierto que el caso de xz fue un ataque sigiloso y trabajado durante mucho tiempo, pero ¿de verdad hacía falta algo más allá de una sola persona muy capaz? El hecho de que personas aleatorias en internet puedan analizarlo y entenderlo también significa que está dentro del rango de comprensión de una sola persona
    ¿Por qué no puede haber sido simplemente obra de una sola persona inteligente pero resentida?

    • El mayor elemento que hace pensar en un actor estatal es la magnitud de la recompensa esperada frente al tiempo invertido en el ataque de ingeniería social
      Un plan con fines de lucro de este tipo es irracional. Eso no excluye la posibilidad de un actor irracional o de una persona motivada por algo distinto al dinero, pero sí hace que un actor estatal parezca un candidato probable
      Si hubiera tenido éxito, el valor de venta habría sido enorme, pero la probabilidad de insertar un exploit en infraestructura crítica y que permanezca sin ser detectado el tiempo suficiente para que un cliente lo compre y lo use es muy baja. Un Estado puede permitirse ese tipo de moonshot, pero una persona normalmente buscaría objetivos con mayor valor esperado
      Claro, eso no significa que haya sido un actor estatal especialmente competente ni que se le hayan asignado muchos recursos
    • De acuerdo. Este hack requirió mucha habilidad, determinación y tiempo
      Pero eso también aplica a una buena parte de los desarrolladores de código abierto, ¿no? Además, la motivación es clara. Este exploit probablemente habría valido millones de dólares en el mercado negro
    • Nada. Nadie sabe quién es
    • Me gustaría saber de dónde salió eso de la “evidencia irrefutable”
      He visto muchas especulaciones de gente que sabe del tema, pero no esa clase de afirmación

  • ¿Hay algún texto que resuma la ofuscación del backdoor en sí? Me refiero al backdoor real, no al script de compilación para la instalación
    Metí el binario en Ghidra y revisé por encima las funciones que encontré, pero como no estoy familiarizado con el mecanismo ifunc que usan para interceptar la ejecución, lo dejé y se lo encargué a otras personas
    Como tiene funciones anti-debugging, asumí que el código también estaría ofuscado. Como se distribuyó como un binario opaco, pensé que al menos parte del código estaría cifrado con una clave que no tenemos, como partes del payload de STUXNET

    • Todavía no ha salido un análisis completo del backdoor en sí. Hay tipos de anti-debugging que se pueden esquivar con flags, pero en este caso se resolvió en la etapa de compilación, así que es más complicado
      Que exista una función anti-debugging no significa necesariamente que el código esté ofuscado. Como se dijo arriba, ocurrió en el momento de la compilación. Es como si ya hubiera puesto la trampa en su propia casa
      Este caso muestra el problema que surge cuando el mantenedor de paquetes no obtiene el código fuente del origen correcto

  • No he seguido este caso con tantísimo detalle, pero me parece muy raro que casi no se escuche discusión sobre el autor del hack

    • “Aun así, creo que en realidad él proviene de una zona horaria UTC+02 en invierno / UTC+03 con DST, es decir, una región que incluye Europa del Este (EET) o Israel (IST)”
      https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
    • Sí ha habido muchas especulaciones. Parece más probable que hayan sido varias personas y no una sola, y que pueda tratarse de un grupo de ransomware o de una agencia estatal de inteligencia
    • Sería interesante hacer un análisis semántico de la comunicación de las personas en línea vinculadas al caso, como se hizo con el análisis sobre Satoshi, para estimar la orientación cultural
      Si se mira si hubo diferencias de estilo con el paso del tiempo, también podría verse si varias personas usaron la misma personalidad en línea. Además, hay bastante código commiteado, así que también valdría la pena revisar si las diferencias de estilo en el código sugieren que participó más de una persona
    • ¿Qué se va a discutir? No se sabe nada

  • Da bastante suerte que lo hayan descubierto antes de que se propagara ampliamente
    Y no solo por la razón obvia de que no queremos que una entidad desconocida tenga ejecución remota de código en nuestra infraestructura. Si la gente sigue escarbando, es posible que al final logren crear un payload que permita a cualquiera usar el backdoor
    Que una sola entidad tenga acceso ya es malo, pero que cualquiera pueda acceder sería mucho peor

    • Si el payload es una clave RSA privada que no se ha hecho pública, ¿no sería casi imposible?

  • Un enlace alternativo para verlo, en lugar de thereaderapp.com:
    https://nitter.poast.org/bl4sty/status/1776691497506623562

  • Me sorprende que, incluso después de varios días, todavía no se haya resuelto por completo
    Con la atención de todo el mundo puesta encima y con las piezas clave teóricamente disponibles al público, que haya resistido tanto tiempo significa que la ofuscación estaba bastante bien hecha

  • Lo preocupante de este caso es su carácter de juego largo
    Primero, esperaron durante mucho tiempo para construir la “infraestructura” con la que crear el backdoor. Segundo, incluso después de que el exploit llegara a producción real, seguramente se estaban preparando para otro juego largo. La forma correcta de gastar un premio de lotería es invirtiéndolo
    Tercero, me hace preguntarme si ahora mismo siguen en curso otros juegos como este. Da miedo