Lecciones aprendidas del hackeo de la cadena de suministro de SolarWinds | Desarrolladores


En una reciente Fundación Linux entrada en el blog titulado “Prevención de ataques a la cadena de suministro como SolarWinds”, el director de seguridad de la cadena de suministro de código abierto de la fundación, David A. Wheeler, insistió firmemente en la necesidad de que los desarrolladores de software adopten las recomendaciones de seguridad de la LF para evitar ataques aún peores a la seguridad de los datos corporativos y gubernamentales en a raíz de la rampante violación de datos.

La publicación de Wheeler es oportuna y está llena de información que dificulta a los piratas informáticos explotar los sistemas futuros de los que todos dependemos. Incluye 11 recomendaciones de la Fundación Linux que incluyen cómo las organizaciones pueden fortalecer sus entornos de compilación contra los atacantes, la necesidad de comenzar a cambiar hacia la implementación y luego requerir compilaciones reproducibles verificadas, y la práctica de cambiar herramientas e interfaces para que las vulnerabilidades no intencionales sean menos probables.

Según Wheeler, SolarWinds cumplió con algunas de las medidas defensivas de la fundación. Ninguno de ellos impidió el exitoso ataque SolarWinds, dijo. Se necesita más refuerzo del software.

El producto de software SolarWinds Orion es propietario. Entonces, ¿cómo pueden los métodos de codificación de código abierto ayudar a crear una mejor seguridad?

SolarWinds siguió algunas prácticas deficientes, como el uso del protocolo FTP inseguro y la revelación pública de contraseñas, lo que puede haber hecho que estos ataques sean especialmente fáciles, ofreció Wheeler en su blog de la Fundación Linux.

“La brecha de SolarWinds no proporcionó a los profesionales de TI nuevos conocimientos técnicos, pero proporcionó una nueva urgencia para contrarrestar ese tipo de ataque”, dijo a LinuxInsider.

Los ciberataques suelen explotar vulnerabilidades no intencionales en el código. La mayoría de los otros ataques, al menos en software de código abierto, involucran una táctica llamada typosquatting. Este enfoque crea código malicioso con un nombre intencionalmente similar a un programa real, explicó.

La brecha de SolarWinds hizo algo diferente. Subvirtió un entorno de construcción, que hasta este momento ha sido un tipo de ataque menos común, señaló.

“Menos profesionales de la seguridad se han centrado en contrarrestar este tipo de ataque. Eso puede cambiar en el futuro, especialmente porque casi todas las medidas de seguridad típicas no contrarrestan este tipo de ataque”, dijo.

El golpe en el asalto de SolarWinds

Numerosas agencias gubernamentales de EE. UU. Y muchas organizaciones privadas que utilizan el software SolarWinds Orion se vieron gravemente comprometidas. Este fue un conjunto muy peligroso de compromisos de la cadena de suministro del que la comunidad de tecnología de la información y la comunidad de código abierto deben aprender y tomar medidas, según la Fundación Linux.

La Agencia Federal de Seguridad de Infraestructura y Ciberseguridad (CISA) emitió la Directiva de Emergencia 21-01 declarando que Orion estaba siendo explotado, tenía un alto potencial de compromiso y tenía un impacto grave en organizaciones enteras cuando se veía comprometido. Mientras más personas miran, peores cosas encuentran. Wheeler cree que se identificó un segundo y tercer compromiso de malware en Orion.

La plataforma Orion es una plataforma de gestión y supervisión de infraestructura escalable. Ayuda a los departamentos de TI a simplificar la administración para entornos locales, híbridos y de software como servicio (SaaS).

Los investigadores encontraron un malware llamado Sunspot que vigilaba el servidor de compilación en busca de comandos de compilación. Cuando encontró tales comandos, el malware reemplazó silenciosamente los archivos de código fuente dentro de la aplicación Orion con archivos que cargaban el malware Sunburst.

El compromiso de Sunspot de SolarWinds Orion no es el primer ejemplo de este tipo de ataques. Aún así, demostró cuán peligrosos pueden ser cuando comprometen software ampliamente utilizado, señaló Wheeler.

Análisis en profundidad

Dada la magnitud del hack de SolarWinds, LinuxInsider le pidió a Wheeler que profundizara en cómo los estándares de seguridad de la cadena de suministro podrían beneficiarse de las últimas recomendaciones de la Fundación Linux.

LinuxInsider: ¿La violación de SolarWinds habría sido menos posible si el software fuera de código abierto?

David A. Wheeler: La naturaleza de código cerrado probablemente hizo que la brecha fuera más difícil de detectar, pero todo el software es vulnerable a este tipo de ataque. Los desarrolladores de software modifican el código fuente para mantener el software. Los usuarios de software suelen instalar paquetes de software que se generaron a partir del código fuente. La conversión del código fuente en un paquete ejecutable se denomina “compilación” y la compilación se ejecuta en algún “entorno de compilación”.

En este caso, un atacante subvirtió el entorno de compilación, por lo que el código fuente visto por los desarrolladores estaba bien, pero el paquete de software final instalado se cambió sin saberlo.

OSS es mucho más fácil de volver a ejecutar una compilación que puede detectar subversiones. El código fuente cercano ha agregado desafíos técnicos y legales para detectarlos. OSS tiene una ventaja potencial, pero los desarrolladores deben actuar para aprovechar ese potencial.

¿Qué pudo haber evitado la intrusión?

Rodador: La mejor manera es algo llamado construcción reproducible verificada o construcción determinista. Este es un proceso que produce exactamente los mismos resultados a partir de entradas idénticas, incluso cuando lo ejecutan diferentes organizaciones. Ha sido verificado por organizaciones independientes. Hace que la subversión del código sea mucho más difícil porque un atacante tiene que subvertir varias organizaciones independientes, e incluso si eso sucede, la detección posterior es mucho más fácil. Otras técnicas son mucho más débiles.

Estos atacantes parecen haber contado con los recursos necesarios. Es peligroso depender de que un atacante nunca tenga éxito. En teoría, examinar paquetes construidos puede encontrar problemas, pero la escala de los programas del mundo real hace que dicho análisis sea costoso y, a menudo, los problemas se pasarán por alto. El problema finalmente se encontró mediante el monitoreo, pero en este caso, causó un daño extenso antes de la detección.

Una construcción reproducible verificada es similar a una auditoría financiera en la que un auditor financiero determina si un resultado es correcto. El problema esencial de SolarWinds era que ningún proceso independiente verificó que el resultado de la compilación fuera correcto.

¿Qué tan práctico es para la industria del software adoptar esta recomendación de LF?

Rodador: Algunos proyectos ya tienen compilaciones reproducibles, por lo que es posible hacerlo. El proyecto de compilaciones reproducibles ha creado una versión modificada de Debian GNU / Linux (específicamente de bullseye) donde más del 90 por ciento de los paquetes son reproducibles. Sin embargo, en la práctica, llevará tiempo para muchos proyectos de OSS e incluso más para muchos proyectos de código cerrado.

Históricamente, nadie verificaba si las compilaciones eran reproducibles, por lo que los proyectos han acumulado muchas construcciones que hacen que las compilaciones sean irreproducibles. No existen obstáculos técnicos fundamentales; sólo hay que encontrar y cambiar una gran cantidad de pequeñas cosas. La combinación de todos esos pequeños cambios requiere un esfuerzo significativo en proyectos más grandes.

El software de código cerrado tiene desafíos adicionales, tanto técnicos como legales. A diferencia de OSS, el software de código cerrado normalmente no está diseñado para ser reconstruido por otros. Los desarrolladores de software de código cerrado deberán invertir un esfuerzo significativo para que otros puedan reconstruirlo. Además, sus modelos comerciales generalmente dependen de restricciones legales sobre quién tiene acceso al código fuente.

Lo que podría ser necesario son acuerdos contractuales especiales para compartir código que no se habían hecho antes. Pero si bien es más difícil hacer esto con el software de código cerrado, estos desafíos son superables.

¿Qué llevará su adopción?

Rodador: ¡Demanda del cliente! Siempre que los clientes acepten bondadosamente cajas negras y productos sin compilaciones reproducibles verificadas, los desarrolladores no tienen ninguna razón para cambiar.

Se está produciendo un lento alejamiento de las verdaderas cajas negras. Los clientes a menudo dicen que no necesitan saber cómo funciona algo, pero las verdaderas cajas negras significan que los clientes están asumiendo una cantidad desconocida de riesgo. Muchos proveedores de software de código cerrado (como Microsoft) ahora tienen mecanismos para proporcionar al menos cierta visibilidad del código fuente para ayudar a los clientes a gestionar mejor sus riesgos. El software de código abierto, por supuesto, permite que cualquiera pueda ver el código.

Estamos en un punto interesante para las construcciones reproducibles. Hasta ahora, algunos proyectos han trabajado en ello, incluso sin una demanda obvia de los clientes. Agregue esa demanda y se producirá un rápido aumento en su disponibilidad.

¿Cuánto impacto tuvo la práctica de código abierto de reutilizar código?

Rodador: No está claro para el público exactamente cómo se infringió el entorno de construcción de SolarWinds. Sabemos que era un sistema Windows. En un gran sentido, no importa. Las defensas pueden ser muy buenas, pero no es prudente asumir que un sistema nunca puede ser violado. Una buena seguridad implica no solo una buena prevención, sino también la detección y la recuperación.

También se violarán los entornos de construcción futuros. Deberíamos intentar endurecer los entornos de construcción contra los ataques, pero también deberíamos desarrollar mecanismos de detección y recuperación para que cualquier infracción no provoque el daño que esta infracción causó.

¿Qué tan viable es instituir una lista de materiales de software (SBOM) para prevenir la typosquatting como sugirió la LF?

Rodador: Los SBOM pueden ayudar a contrarrestar la typosquatting. Es fácil para los desarrolladores mirar un nombre y leer lo que esperan que diga, no lo que realmente dice. Los SBOM brindan visibilidad a otros, incluidos los clientes, de lo que contiene un componente, al igual que las listas de ingredientes alimentarios explican lo que contienen nuestros alimentos. Con una lista, otros pueden buscar componentes sospechosos, incluidos nombres que son similares pero no idénticos a los nombres esperados.

Como dijo el juez asociado de la Corte Suprema Louis Brandeis, “la publicidad se elogia con justicia como un remedio para las enfermedades sociales e industriales. Se dice que la luz del sol es el mejor de los desinfectantes …”


Jack M. Germain ha sido reportero de ECT News Network desde 2003. Sus principales áreas de enfoque son TI empresarial, Linux y tecnologías de código abierto. Es un crítico estimado de distribuciones de Linux y otro software de código abierto. Además, Jack cubre ampliamente temas de privacidad y tecnología empresarial, así como desarrollos en comercio electrónico y electrónica de consumo. Envíe un correo electrónico a Jack.

.



Source link