Puerta trasera en XZ Utils que casi sucede la semana pasada, Internet esquivó un importante ataque de un estado-nación que habría tenido repercusiones catastróficas en materia de ciberseguridad en todo el mundo. Es una catástrofe que no ocurrió, por lo que no recibirá mucha atención, pero debería recibirla. Hay una moraleja importante en la historia del ataque y su descubrimiento: la seguridad de Internet global depende de innumerables piezas oscuras de software escritas y mantenidas por voluntarios aún más oscuros, no remunerados, distraídos y, a veces, vulnerables. Es una situación insostenible y que está siendo explotada por actores maliciosos. Sin embargo, se está haciendo muy poco para remediarlo. A los programadores no les gusta hacer trabajo extra. Si pueden encontrar código ya escrito que haga lo que quieren, lo utilizarán en lugar de recrear la funcionalidad. Estos repositorios de código, llamados bibliotecas, están alojados en sitios como GitHub. Hay bibliotecas para todo: mostrar objetos en 3D, revisar la ortografía, realizar matemáticas complejas, administrar un carrito de compras de comercio electrónico, mover archivos por Internet, todo. Las bibliotecas son esenciales para la programación moderna; son los componentes básicos de un software complejo. La modularidad que proporcionan hace que los proyectos de software sean manejables. Todo lo que utiliza contiene docenas de estas bibliotecas: algunas comerciales, otras de código abierto y de libre acceso. Son esenciales para la funcionalidad del software terminado. Y a su seguridad. Probablemente nunca hayas oído hablar de una biblioteca de código abierto llamada XZ Utils, pero se encuentra en cientos de millones de computadoras. Probablemente esté en el tuyo. Ciertamente, está en cualquier red corporativa u organizacional que utilice. Es una biblioteca disponible gratuitamente que realiza compresión de datos. Es importante, de la misma manera que cientos de otras bibliotecas oscuras similares son importantes. Muchas bibliotecas de código abierto, como XZ Utils, son mantenidas por voluntarios. En el caso de XZ Utils, se trata de una persona, llamada Lasse Collin. Ha estado a cargo de XZ Utils desde que lo escribió en 2009. Y, al menos en 2022, ha tenido algunos «problemas de salud mental a largo plazo». (Para ser claros, él no tiene la culpa de esta historia. Se trata de un problema de sistemas). A partir de al menos 2021, Collin fue un objetivo personal. No sabemos por quién, pero tenemos nombres de cuentas: Jia Tan, Jigar Kumar, Dennis Ens. No son nombres reales. Presionaron a Collin para que transfiriera el control de XZ Utils. A principios de 2023 lo consiguieron. Tan pasó el año incorporando lentamente una puerta trasera en XZ Utils: deshabilitando sistemas que podrían descubrir sus acciones, sentando las bases y finalmente agregando la puerta trasera completa a principios de este año. El 25 de marzo, Hans Jansen, otro nombre falso, intentó impulsar a los distintos sistemas Unix a actualizarse a la nueva versión de XZ Utils. Y todos estaban preparados para hacerlo. Es una actualización de rutina. En el lapso de unas pocas semanas, habría sido parte tanto de Debian como de Red Hat Linux, que se ejecutan en la gran mayoría de servidores de Internet. Pero el 29 de marzo, otro voluntario no remunerado, Andrés Freund (una persona real que trabaja para Microsoft pero que hacía esto en su tiempo libre) notó algo extraño acerca de cuánto procesamiento estaba haciendo la nueva versión de XZ Utils. Es el tipo de cosas que fácilmente podrían pasarse por alto y aún más fácilmente ignorarse. Pero por alguna razón, Freund localizó la rareza y descubrió la puerta trasera. Es una obra magistral. Afecta al protocolo de inicio de sesión remoto SSH, básicamente agregando una funcionalidad oculta que requiere una clave específica para habilitarse. Alguien con esa clave puede usar el SSH con puerta trasera para cargar y ejecutar un fragmento de código arbitrario en la máquina de destino. SSH se ejecuta como root, por lo que ese código podría haber hecho cualquier cosa. Deje que su imaginación vuele. Esto no es algo que un hacker simplemente invente. Esta puerta trasera es el resultado de un esfuerzo de ingeniería de años. Las formas en que el código evade la detección en su forma fuente, cómo permanece inactivo e indetectable hasta que se activa, y su inmenso poder y flexibilidad dan crédito a la suposición ampliamente extendida de que un Estado-nación importante está detrás de esto. Si no se hubiera descubierto, probablemente habría acabado en todos los ordenadores y servidores de Internet. Aunque no está claro si la puerta trasera habría afectado a Windows y Mac, habría funcionado en Linux. ¿Recuerda en 2020, cuando Rusia colocó una puerta trasera en SolarWinds que afectó a 14.000 redes? Eso parecía mucho, pero habría sido mucho más dañino. Y nuevamente, la catástrofe se evitó sólo porque un voluntario se topó con ella. Y fue posible, en primer lugar, sólo porque el primer voluntario no remunerado, alguien que resulta ser un único punto de falla para la seguridad nacional, fue personalmente atacado y explotado por un actor extranjero. Ésta no es forma de gestionar la infraestructura nacional crítica. Y sin embargo, aquí estamos. Este fue un ataque a nuestra cadena de suministro de software. Este ataque subvirtió las dependencias de software. El ataque de SolarWinds tuvo como objetivo el proceso de actualización. Otros ataques tienen como objetivo el diseño, desarrollo e implementación de sistemas. Estos ataques son cada vez más comunes y eficaces, y también son cada vez más el arma preferida de los Estados-nación. Es imposible contar cuántos de estos puntos únicos de falla se encuentran en nuestros sistemas informáticos. Y no hay manera de saber cuántos de los mantenedores no remunerados y no apreciados de bibliotecas de software críticas son vulnerables a la presión. (Nuevamente, no los culpe. Culpe a la industria que está feliz de explotar su trabajo no remunerado). O cuántos más han creado accidentalmente vulnerabilidades explotables. ¿Cuántos otros intentos de coerción están en curso? ¿Una docena? ¿Un centenar? Parece imposible que la operación de XZ Utils fuera un caso único. Las soluciones son difíciles. Prohibir el código abierto no funcionará; Precisamente porque XZ Utils es de código abierto, un ingeniero descubrió el problema a tiempo. Prohibir bibliotecas de software tampoco funcionará; El software moderno no puede funcionar sin ellos. Durante años, los ingenieros de seguridad han estado impulsando algo llamado “lista de materiales de software”: una especie de lista de ingredientes para que cuando uno de estos paquetes se vea comprometido, los propietarios de la red al menos sepan si son vulnerables. La industria odia esta idea y ha estado luchando contra ella durante años, pero tal vez la tendencia esté cambiando. El problema fundamental es que a las empresas tecnológicas no les gusta gastar dinero extra, incluso más de lo que a los programadores les desagrada hacer trabajo extra. Si existe software gratuito, lo utilizarán y no realizarán muchas pruebas de seguridad internas. Un desarrollo de software más sencillo equivale a menores costos y a más ganancias. La economía de mercado recompensa este tipo de inseguridad. Necesitamos algunas formas sostenibles de financiar proyectos de código abierto que se conviertan de facto en infraestructura crítica. La vergüenza pública puede ayudar aquí. La Open Source Security Foundation (OSSF), fundada en 2022 después de que se descubriera otra vulnerabilidad crítica en una biblioteca de código abierto, Log4j, aborda este problema. Las grandes empresas de tecnología prometieron 30 millones de dólares en financiación después de la vulnerabilidad crítica de la cadena de suministro de Log4j, pero nunca cumplieron. Y todavía están felices de hacer uso de toda esta mano de obra y recursos gratuitos, como indica una anécdota reciente de Microsoft. Las empresas que se benefician de estas bibliotecas de acceso gratuito deben dar un paso al frente, y el gobierno puede obligarlas a hacerlo. Hay mucha tecnología que podría aplicarse a este problema, si las corporaciones estuvieran dispuestas a gastar el dinero. Los pasivos ayudarán. La iniciativa “seguro por diseño” de la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) ayudará, y CISA finalmente se está asociando con OSSF en este problema. Ciertamente, la seguridad de estas bibliotecas debe ser parte de cualquier iniciativa gubernamental amplia de ciberseguridad. Esta vez tuvimos mucha suerte, pero tal vez podamos aprender de la catástrofe que no ocurrió. Al igual que la red eléctrica, la red de comunicaciones y los sistemas de transporte, la cadena de suministro de software es una infraestructura crítica, parte de la seguridad nacional y vulnerable a ataques extranjeros. El gobierno estadounidense debe reconocer esto como un problema de seguridad nacional y empezar a tratarlo como tal. Este ensayo apareció originalmente en Lawfare. Etiquetas: puertas traseras, ciberseguridad, economía de la seguridad, piratería informática, Linux, malware, código abierto, ingeniería social, SSH Publicado el 11 de abril de 2024 a las 7:01 a. m. • 28 comentarios
