▶ Lo que debemos sacar del XZ Backdoor ūü¶é

Lo que debemos sacar del XZ Backdoor

Se ha escrito mucho sobre XZ Backdoor en las √ļltimas semanas, por lo que es hora de mirar hacia adelante. Antes de hacerlo, compartimos m√°s detalles sobre lo sucedido con respecto a openSUSE. Para obtener una descripci√≥n general de c√≥mo afect√≥ a los usuarios de openSUSE, consulte la publicaci√≥n anterior.

Entre bastidores

Unos d√≠as antes de la divulgaci√≥n p√ļblica de la puerta trasera XZ, el equipo de seguridad del producto SUSE recibi√≥ un indicio de que hay algo extra√Īo con las versiones XZ 5.6.x. Soy el empleado de SUSE y el empaquetador de openSUSE que estaba actualizando e incluyendo esta versi√≥n en openSUSE Tumbleweed, as√≠ que me involucr√© en esto bastante temprano. En ese momento, no ten√≠amos a nuestra disposici√≥n ning√ļn contexto ni informaci√≥n que se compartiera en la divulgaci√≥n p√ļblica inicial. Sin embargo, esa pista era toda la informaci√≥n que necesit√°bamos. Cambi√≥ la forma en que ve√≠amos un proyecto central de c√≥digo abierto establecido. Sin eso, las peque√Īas diferencias en la etapa de “configuraci√≥n” del sistema de compilaci√≥n se habr√≠an ignorado f√°cilmente.

Un d√≠a antes de la divulgaci√≥n, el jueves por la noche, la seguridad del producto SUSE recibi√≥ un informe m√°s largo y detallado de Andr√©s Freund a trav√©s de la lista de divulgaci√≥n de seguridad de distribuciones compartidas. La lista de distribuciones es una lista de correo cifrada donde los distribuidores colaboran y coordinan la divulgaci√≥n de problemas de seguridad. Este informe aport√≥ nuevos conocimientos de que la puerta trasera XZ apuntaba espec√≠ficamente a OpenSSH, que es una de las partes de red de casi todos los sistemas Linux. Esto aument√≥ a√ļn m√°s nuestro nivel de amenaza hasta convertirlo en una puerta trasera de acceso remoto y tambi√©n nos hizo ampliar nuestros esfuerzos de comunicaci√≥n planificados.

El equipo de seguridad de SUSE y yo comenzamos a analizar. La seguridad de productos SUSE es miembro de varios foros de seguridad privados, como la lista de distribuciones y CERT VINCE y otros, que nos permiten coordinar correcciones entre proveedores de software y tener actualizaciones listas en las fechas de divulgaci√≥n. Con la informaci√≥n inicial de que hay algo sospechoso, fue relativamente f√°cil encontrar m√°s cosas sospechosas sin ning√ļn orden en particular:

  • openSUSE y SUSE rastrean las firmas de artefactos de lanzamiento con un conjunto de claves de firmas confiables. Notamos que la clave con la que se firmaron los artefactos cambi√≥ hace alg√ļn tiempo, por lo que tuvimos que actualizar nuestro conjunto de claves confiable para el proyecto XZ. Validamos que hubo un traspaso del mantenedor y que el nuevo mantenedor tiene acceso directo a la confirmaci√≥n, as√≠ como la capacidad de firmar lanzamientos y publicarlos. La red de confianza de esta nueva clave de firma no estaba bien conectada, lo que podr√≠a haber dado una alerta, pero estaba firmada por el mantenedor anterior y eso fue suficiente para nosotros.

  • Al observar el historial de confirmaciones, hubo una avalancha de confirmaciones entre la √ļltima versi√≥n 5.5 beta y la versi√≥n 5.6.0 en un corto per√≠odo de tiempo por parte de ese nuevo mantenedor; no viene a trav√©s de una solicitud de extracci√≥n y no hay una revisi√≥n o discusi√≥n obvia al respecto. Esto fue inmediatamente preocupante. Normalmente los proyectos no hacen eso justo antes de un nuevo lanzamiento importante. La revisi√≥n de cada confirmaci√≥n mostr√≥ inmediatamente que se estaban confirmando y actualizando archivos de prueba extra√Īos en 5.6.1, y que no ten√≠an las actualizaciones correspondientes en el marco de prueba o en el c√≥digo del proyecto, por lo que estaban "no utilizados". Normalmente, los archivos de prueba se confirman junto con una correcci√≥n de c√≥digo en la misma confirmaci√≥n, o con una referencia a un problema anterior o una confirmaci√≥n que aborda el caso de prueba. Para un mantenedor experimentado de un proyecto upstream, esto parec√≠a un gran descuido. Los mensajes de confirmaci√≥n eran algo plausibles pero realmente no ten√≠an sentido, especialmente al comparar las (peque√Īas) diferencias entre 5.6.0 y 5.6.1.

 Una investigaci√≥n m√°s profunda condujo a encontrar la "etapa cero" integrada en el sistema de construcci√≥n y con eso pudimos atravesar las capas de ofuscaci√≥n para desenredar la segunda y tercera etapa. En cuesti√≥n de minutos, nos qued√≥ claro que se hab√≠a invertido un esfuerzo muy importante en desarrollarlo. No fue obra de un solo desarrollador en una tarde lluviosa de domingo. Adem√°s, la segunda etapa insinu√≥ que se trataba de una puerta trasera dirigida espec√≠ficamente a entornos espec√≠ficos, compilaciones de paquetes Debian o RPM que utilizan GCC y glibc. Un usuario normal que construye desde la fuente, ya sea desde el tarball con puerta trasera o desde git, nunca se habr√≠a visto afectado. Esto hizo saltar las alarmas. Entonces, antes de continuar con la ingenier√≠a inversa, evaluamos el impacto.

Durante un tiempo, openSUSE no ha estado usando XZ para la compresión de nuestros paquetes rpm de distribución; Nos cambiamos a Zstd hace un tiempo. Sin embargo, XZ se usa ampliamente en la distribución, entre muchas otras cosas para descomprimir las fuentes de nuestro compilador GCC que usamos para construir todo lo demás en la distribución. Verificamos y vimos que la versión XZ presuntamente maliciosa se estaba utilizando para crear nuestro compilador activo openSUSE GCC, que se utiliza en todas las demás versiones de la distribución. El peor escenario en el que pensar aquí es que el XZ malicioso estaba modificando el descomprimido de las fuentes de compilación del compilador GCC y tenemos un compilador del sistema que ya no era confiable. Aunque tenemos comprobaciones de firmas en las fuentes (y tenemos copias seguras de cada fuente de entrada que alguna vez utilizamos en cualquier lugar en un almacén confiable), no tenemos comprobaciones de si las fuentes descomprimidas son en realidad las fuentes cuyas firmas se verificaron antes de descomprimirlas.

Entonces, incluso sin m√°s informaci√≥n sobre la puerta trasera, entendimos que el peor de los impactos podr√≠a ser desastroso. Entonces comenzamos a identificar proyectos, productos y distribuciones afectados. Afortunadamente esa lista result√≥ ser bastante peque√Īa. Se form√≥ un equipo ad hoc para encargarse de la eliminaci√≥n de la puerta trasera.

Eliminación inicial de la puerta trasera para nuestros usuarios

openSUSE Tumbleweed incluye un canal de actualizaci√≥n de emergencia que podemos usar para recuperarnos de regresiones fatales en las instant√°neas normales de Tumbleweed. Estos son extremadamente raros gracias a nuestro proceso de pruebas automatizadas, pero suceden. Inyectamos una degradaci√≥n de XZ en ese canal de actualizaci√≥n de emergencia y comenzamos a crear una versi√≥n provisional de openSUSE que eliminaba la actualizaci√≥n maliciosa de XZ. Sin embargo, debido a la naturaleza desconocida de la puerta trasera ofuscada, est√°bamos planeando con la peor suposici√≥n. Comenzamos a recopilar cu√°ntos paquetes se crearon y publicaron con la compilaci√≥n del compilador GCC sospechoso dentro del entorno de compilaci√≥n. Era una lista muy grande. Adem√°s, entender la reversi√≥n del c√≥digo objeto de puerta trasera maliciosa en Ghidra nos llevar√≠a un par de horas m√°s. Despu√©s de una breve sincronizaci√≥n, decidimos optar por la ruta segura y desechar todos los paquetes que se crearon con XZ/GCC potencialmente malicioso y comenzamos a reconstruirlos todos solo con paquetes que proven√≠an de una copia de seguridad segura, para restaurar la integridad de nuestro distribuci√≥n lo m√°s r√°pido posible. openSUSE prueba regularmente este "modo de arranque" como parte del desarrollo de nuestra distribuci√≥n y se basa en la automatizaci√≥n de reconstrucci√≥n proporcionada por Open Build Service, por lo que no fue mucho trabajo humano. Fue simplemente mucha carga para nuestro cl√ļster de compilaci√≥n. Tuvimos un par de horas de espera por delante, lo que permiti√≥ un an√°lisis m√°s detallado de la puerta trasera.

An√°lisis de la puerta trasera.

El análisis del código objeto resultó requerir mucho tiempo. Si bien la segunda etapa que verificó las condiciones de compilación correctas (si es una compilación de distribución, si tiene el entorno de compilación esperado, etc.) fue fácil de decodificar y nos ayudó a comprender el impacto potencial, inicialmente no nos quedó muy claro qué estaba funcionando el código objeto ofuscado que se inyectó durante la compilación.

Al usar Ghidra, pudimos recuperar un c√≥digo C algo legible a partir del c√≥digo de m√°quina inyectado, por lo que comenzamos a intentar descifrar el rompecabezas. Uno de los primeros hallazgos fue detectar el punto de entrada en la _get_cpuid funci√≥n que formaba parte del manejo de IFUNC. Simplemente buscar en Google esta combinaci√≥n de palabras llev√≥ a una discusi√≥n ascendente, a la desactivaci√≥n de ifunc en el proyecto oss fuzz y a un interesante informe de error en la comunidad Fedora donde se informaron problemas de Valgrind con XZ 5.6.0 y aparentemente el ascendente los estaba solucionando mediante la actualizaci√≥n. cosas no relacionadas, incluidos "los archivos de prueba" en el repositorio. No solo hubo confirmaciones en el repositorio, sino tambi√©n comunicaci√≥n enga√Īosa sobre el problema directamente relacionado con esas confirmaciones, lo que hizo obvio que no est√°bamos encontrando un accidente desafortunado por parte de un mantenedor inocente que podr√≠a haber sido pirateado, sino una acci√≥n planificada por el actual. mantenedor aguas arriba. En caso de que las alarmas no fueran lo suficientemente fuertes ya, esto duplic√≥ su nivel de ruido.

Preparaci√≥n para la divulgaci√≥n p√ļblica

Combinando todo lo que hemos aprendido hasta ahora, el panorama se volvi√≥ m√°s claro. Alguien hab√≠a pasado a√Īos de preparaci√≥n para sentar las bases, construir una buena reputaci√≥n como mantenedor, hacerse cargo del proyecto y luego eligi√≥ un momento que era una ventana cr√≠tica para varios proyectos de distribuci√≥n y tambi√©n en medio del A√Īo Nuevo Lunar. como otros d√≠as festivos para lanzar una nueva versi√≥n con nuevas caracter√≠sticas y una puerta trasera ofuscada que estaba bien dise√Īada para apuntar solo a distribuciones espec√≠ficas, es decir, aquellas que usan GCC, Binutils, Glibc con RPM o procesos de compilaci√≥n de Debian en x86_64.

Con todo eso en mente, nos dimos cuenta de que va a haber mucha cobertura p√ļblica sobre esto. Estar√° en las noticias durante d√≠as o semanas. Entonces comenzamos una nueva l√≠nea de trabajo para prepararnos para eso con los equipos de comunicaciones.

Revelaci√≥n p√ļblica

En el momento de la divulgaci√≥n p√ļblica, todos los flujos de trabajo ya se hab√≠an completado. Identificamos la lista de productos afectados y ya hab√≠amos publicado todas las actualizaciones para todos los afectados. La comunicaci√≥n estaba lista para publicarse en l√≠nea y enviarse a las partes pertinentes. Todo eso fue posible porque muchas personas hicieron todo lo posible, dejaron todo lo dem√°s a un lado para reaccionar oportunamente y con mucho compromiso para garantizar que no nos hayamos perdido ni pasado por alto nada; todo ello mientras ya hab√≠a comenzado un largo fin de semana festivo. Felicitaciones a todos los que trabajaron d√≠a y noche para prepararse para esto.

Héroe de la historia

Que no haya sucedido nada peor es s√≥lo gracias a Andr√©s Freund, un desarrollador de la comunidad PostgreSQL que no se salt√≥ una extra√Īa regresi√≥n en el rendimiento de los inicios de sesi√≥n SSH en su instalaci√≥n inestable de Debian recientemente actualizada. Otro testimonio de que no dejar pasar algo que todos los dem√°s probablemente habr√≠an ignorado durante los siguientes meses o a√Īos es lo que hace que un h√©roe sea un h√©roe.

Sin embargo, confiar en h√©roes no es una estrategia sostenible y confiable. Entonces, para el futuro, todos debemos aprender de lo sucedido y convertirnos en un gran equipo de peque√Īos h√©roes.

TLDR de lo que pasó

Se abus√≥ de las distribuciones de Linux para ofrecer una puerta trasera a sus usuarios. Cu√°l era el prop√≥sito exacto de la puerta trasera a√ļn es una especulaci√≥n. Todo podr√≠a provenir de un individuo que quisiera vender acceso a abundante potencia inform√°tica a trav√©s de m√°quinas virtuales alojadas en la nube p√ļblica que tienen un puerto ssh vulnerable abierto al p√ļblico. Este es el extremo del espectro, bastante improbable, pero a√ļn posible. El otro extremo del espectro es una empresa que vende puertas traseras a actores estatales que las utilizan para acceder de forma remota y encubierta a cualquier m√°quina Linux. Aunque se cometieron errores, casi logr√≥ ese objetivo. ¿D√≥nde est√° la verdad? Es necesario identificar y analizar m√°s evidencia al respecto.

Es hora de mirar hacia adelante

Después de esta mirada cercana detrás de las cortinas de lo que sucedió a finales de marzo, el resto de esta publicación cambia a mirar hacia adelante.

Ley de Linus y las distribuciones

Con suficientes ojos, todos los errores son superficiales ”. En las comunidades de c√≥digo abierto, esto se cita mucho como una de las razones por las que se puede confiar en el c√≥digo abierto. Para los proyectos de c√≥digo abierto que est√°n atrayendo suficiente atenci√≥n de contribuyentes suficientemente capacitados, esta “ley” probablemente tenga al menos cierto peso. Sin embargo, de Heartbleed aprendimos, por ejemplo, que estas condiciones previas no se cumplen universalmente. Hay muchos proyectos que son absolutamente esenciales y, sin embargo, se consideran aburridos y no logran atraer a muchos mantenedores o contribuyentes, y aquellos que est√°n en el proyecto ya est√°n enterrados bajo una pila de trabajo y realmente no pueden dedicar un esfuerzo significativo a mejorar. nuevos miembros.

La puerta trasera XZ fue dise√Īada para apuntar √ļnicamente a distribuciones. En primer lugar, por las comprobaciones previas que ejecutaba la puerta trasera antes de desplegarse, pero tambi√©n porque las condiciones necesarias para la implantaci√≥n s√≥lo exist√≠an aguas abajo en estas distribuciones. Debian, as√≠ como otras distribuciones afectadas, como openSUSE, incluyen una cantidad significativa de parches exclusivos para proyectos esenciales de c√≥digo abierto, como en este caso OpenSSH. En retrospectiva, ese deber√≠a ser otro aprendizaje a nivel de Heartbleed para el trabajo de las distribuciones. Estos parches construyeron los pasos esenciales para integrar la puerta trasera y no tienen el escrutinio que probablemente habr√≠an recibido por parte de los respectivos encargados de mantenimiento. Ya sea que conf√≠es en Linus Law o no, ni siquiera se le dio la oportunidad de intervenir aqu√≠. Upstream no fall√≥ en los usuarios, las distribuciones fallaron en upstream y sus usuarios aqu√≠.

El código abierto y sus comunidades

Ser capaz de inspeccionar el c√≥digo fuente de software de c√≥digo abierto brinda a la comunidad una ventaja inmejorable sobre las alternativas patentadas de un solo proveedor. Sin embargo, auditar el c√≥digo fuente requiere mucho tiempo y, a menudo, requiere expertos en seguridad y dominios con mucha experiencia. Las distribuciones comerciales deber√≠an y est√°n jugando un papel importante en esto; todav√≠a no han identificado esto. En ese sentido, el proyecto XZ fue el punto ciego perfecto sobre c√≥mo se suele asignar el esfuerzo a las auditor√≠as de seguridad. Muy profundamente anidado e importante para cada distribuci√≥n debido a razones no obvias, y en el estado de un solo mantenedor y muy pocos contribuyentes o revisores durante a√Īos. No es el nuevo y brillante proyecto de c√≥digo abierto nativo de la nube o el nuevo y sofisticado proyecto de c√≥digo abierto que atrae a miles de desarrolladores o investigadores de seguridad y, sin embargo, es igualmente importante para la integridad y seguridad de la inform√°tica moderna. Si algo hay que aprender aqu√≠ es que los criterios de selecci√≥n sobre d√≥nde centrarse deben ajustarse con estos aprendizajes.

Además, otros ya han enfatizado que el vector de ataque inicial no fue técnico. No era un tarball arcaico. El ataque inicial real fue ingeniería social y utilizó comportamientos tóxicos en las comunidades. Esto es real y no sólo en este caso afecta a los mantenedores existentes de proyectos de código abierto. Se han contado muchas historias en las que el estrés o el agotamiento de los mantenedores estaban relacionados con participantes tóxicos en las comunidades del proyecto. Aunque creo que las distribuciones no son parte de esas actividades, no estamos preparados para evitar que estas cosas sucedan. Los desarrolladores de la distribución se centran en sus problemas y en sus usuarios y, debido a su tiempo limitado, corren el riesgo de descuidar a las comunidades de código abierto (upstream). Esta es otra cosa que debemos tener en cuenta.

Se han fundado iniciativas como CHAOSS y la Open Source Security Foundation porque, de lo contrario, ser√≠a muy f√°cil pasar por alto estas situaciones. Proporcionan un servicio esencial para analizar el “factor bus” o el “factor de colusi√≥n” de cu√°ntos actores se necesitan para subvertir un proyecto y as√≠ permitir que otros se concentren en dirigir la ayuda hacia donde m√°s importa.

El costo de la libertad

FLOSS no tiene que ver con el costo ni con el libre uso, sino con la libertad de inspeccionar y (re)usar. ¿Cu√°l es el costo de esa libertad? En el mundo propietario, el software se paga. En el c√≥digo abierto, esta libertad necesita recibir el reconocimiento que merece y debe ser valorada. Cuando alguien se refiere a la puerta trasera XZ como un incidente de seguridad de la cadena de suministro de software, esa no es la imagen completa. Una cadena de suministro de software ser√≠a aquella donde hay un proveedor en un extremo. Pero los proyectos y las comunidades de c√≥digo abierto no son proveedores hoy en d√≠a. No tienen ning√ļn contrato legalmente vinculante con ninguno de sus consumidores y no hay intercambio de dinero involucrado. Existe una comunidad, de distintos tama√Īos, que contribuye y ayuda, ya sea como voluntarios o como trabajadores remunerados. La mayor√≠a de los proyectos no reciben suficiente dinero.

Como pensamiento abierto: ¿deber√≠an las distribuciones desarrollar y gestionar activamente su cadena de suministro y tratar a “sus proveedores” como proveedores reales con t√©rminos y condiciones mutuos legalmente vinculantes y compensaciones acordadas?

La Secure Web of Trust es la nueva seguridad de la cadena de suministro

En este incidente en particular, se utilizaron archivos comprimidos firmados para publicar el iniciador de la puerta trasera. Se han dicho muchas cosas sobre eso. Necesitamos darnos cuenta de que esto es una distracci√≥n. Una trampa. En t√©rminos de tama√Īo del c√≥digo, el 99,9% de la puerta trasera estaba en el repositorio de c√≥digo fuente. El lanzador en el tarball deb√≠a limitar la exposici√≥n de la puerta trasera solo a las v√≠ctimas previstas, t√©cnicamente no era necesario para nada ni para nada. Habr√≠a sido igualmente f√°cil de incrustar e igualmente dif√≠cil de detectar, ya que el resto del 0,1% tambi√©n se habr√≠a comprometido dentro del repositorio de c√≥digo del proyecto, s√≥lo que de una manera ligeramente diferente.

Para la mayor√≠a de los dem√°s escenarios de ataque imaginables, los artefactos de lanzamiento firmados proporcionan cualidades importantes. Cumplen con la expectativa de enviar √ļnicamente lo que se considera listo para enviar. Proporcionan una cadena verificable de forma independiente hasta el origen (el “Proveedor”). Sin embargo, cada distribuci√≥n comienza con esta primera parte verificable de la cadena y luego se suma a la parte superior. A menudo (o mientras tanto casi siempre) tambi√©n con una forma transparente de verificar esos cambios (en forma de procedimientos conformes a SLSA), todo de forma aislada. ¿Qu√© tan confiables son esas cadenas inconexas? Actualmente, las distribuciones ocasionalmente reutilizan parches iguales o similares adem√°s de las versiones de proyectos anteriores, pero por lo dem√°s, en su mayor parte funcionan de forma aislada y rara vez colaboran activamente. La pieza esencial del parche downstream que activ√≥ la puerta trasera existi√≥ durante casi 10 a√Īos en las distribuciones, pero no se ha visto en upstream.

Reconocemos que la puerta trasera del XZ est√° construida de forma inteligente. Sin embargo, tuvo sorprendentes fallas en la ejecuci√≥n. Quien est√© interesado en incorporar m√°s puertas traseras habr√° aprendido de la amplia cobertura p√ļblica de todo lo que sali√≥ mal. Estos errores han sido se√Īalados, publicados y aprendidos de ellos. Hemos brindado a los actores detr√°s de esta puerta trasera capacitaci√≥n gratuita para futuros ataques. Es hora de que las distribuciones tambi√©n aprendan de esto y tambi√©n reciban lecciones de capacitaci√≥n. Necesitamos colaborar activamente y construir una red de confianza s√≥lida y confiable con proyectos de c√≥digo abierto y entre nosotros para estar preparados para manejar los inevitables desaf√≠os futuros que vendr√°n. ¡Construyamos juntos una red segura de confianza!.

Articulo original de openSUSE en ingles.