Seguridad

Lecciones aprendidas del hackeo de la cadena de suministro de SolarWinds

en la reciente Fundación Linux entrada en el blog David A. Wheeler, director de seguridad de la cadena de suministro de fuente abierta en la Fundación, titulado «Prevención de ataques a la cadena de suministro como SolarWinds», insiste en que los desarrolladores de software sigan los consejos de seguridad de LF para evitar ataques más graves a la seguridad de datos gubernamentales y corporativos en medio de la rampante violación de datos .

La publicación de Wheeler es oportuna y está llena de información, lo que dificulta que los piratas informáticos exploten los sistemas del futuro de los que todos dependemos. Hizo 11 recomendaciones de la Fundación Linux, incluida la forma en que las organizaciones pueden fortalecer sus entornos de compilación para defenderse de los atacantes, la necesidad de comenzar a implementar y requerir compilaciones reproducibles verificadas y cambiar herramientas e interfaces para reducir la probabilidad de vulnerabilidades accidentales.

Según Wheeler, SolarWinds se topó con algunas de las defensas de la Fundación. Ninguno de ellos evitó un ataque exitoso de SolarWinds, dijo. Se requiere más refuerzo de software.

Los productos de software de SolarWinds Orion son propietarios. Entonces, ¿cómo pueden los métodos de codificación de fuente abierta ayudar a crear una mejor seguridad?

En su blog de la Fundación Linux, Wheeler señaló que SolarWinds siguió algunas prácticas deficientes, como el uso de un protocolo FTP inseguro y la filtración pública de contraseñas, lo que podría haber hecho que estos ataques fueran particularmente fáciles.

«La vulnerabilidad de SolarWinds no proporciona nuevos conocimientos técnicos para los profesionales de TI, pero proporciona un nuevo nivel de urgencia para combatir este ataque», dijo a LinuxInsider.

Los ataques cibernéticos a menudo explotan vulnerabilidades no intencionales en el código. La mayoría de los otros ataques, al menos en el software de código abierto, involucran una táctica llamada phishing. Explicó que este método crea intencionalmente un código malicioso con un nombre similar al del programa real.

El exploit de SolarWinds hizo algo diferente. Señaló que alteró el entorno de construcción, que hasta ahora ha sido un ataque menos común.

«Muy pocos expertos en seguridad se concentran en lidiar con este ataque. Esto puede cambiar en el futuro, especialmente porque casi todas las medidas de seguridad típicas no pueden proteger contra este ataque», dijo.

El golpe en el ataque de SolarWinds

Muchas agencias gubernamentales de EE. UU. y muchas organizaciones privadas que usaban el software SolarWinds Orion se vieron gravemente comprometidas.Este es un conjunto muy peligroso de compromisos en la cadena de suministro del que la tecnología de la información y las comunidades de código abierto deben aprender y actuar, según Fundación Linux.

Agencia Federal de Seguridad Cibernética y Seguridad de la Infraestructura (CISA) emitió la Directiva de emergencia 21-01 anunciando que Orion está siendo explotado, tiene un alto potencial de daño y, cuando se ve comprometido, puede tener efectos graves en toda la organización. Cuanta más gente mira, peor se encuentra. Wheeler cree que la segunda y la tercera intrusión de malware se encontraron en Orion.

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

Los investigadores descubrieron un malware llamado Sunspot que supervisa los servidores de compilación para los comandos de compilación. Cuando encuentra dicho comando, el malware reemplaza silenciosamente los archivos de código fuente en la aplicación Orion con archivos que cargan el malware Sunburst.

El ataque de Sunspot a SolarWinds Orion no fue el primer ejemplo de tal ataque. Aún así, señala Wheeler, es un testimonio de lo peligrosos que pueden ser cuando rompen software ampliamente utilizado.

Análisis en profundidad

Dada la escala del ataque 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: ¿Sería menos probable la vulnerabilidad de SolarWinds si el software fuera de código abierto?

David A. Wheeler: La naturaleza de código cerrado puede hacer que las vulnerabilidades sean más difíciles de encontrar, pero todo el software es vulnerable a este ataque. Los desarrolladores de software modifican el código fuente para mantener el software. Los usuarios de software suelen instalar paquetes generados 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, el atacante compromete el entorno de construcción, por lo que el código fuente que ve el desarrollador es bueno, pero el paquete final instalado se modifica sin saberlo.

OSS hace que sea más fácil volver a ejecutar compilaciones que pueden detectar subversiones. Cerrar el código fuente aumenta los desafíos técnicos y legales para detectarlos. OSS tiene beneficios potenciales, pero los desarrolladores deben tomar medidas para aprovechar este potencial.

¿Qué puede detener la intrusión?

Rodador: El mejor enfoque es algo llamado compilación reproducible verificada o compilación determinista. Es un proceso que produce exactamente el mismo resultado a partir de la misma entrada, incluso cuando lo ejecutan diferentes organizaciones. Ha sido verificado por una organización independiente. Hace que la subversión del código sea más difícil porque los atacantes tienen que subvertir múltiples organizaciones independientes, e incluso si eso sucede, la detección es mucho más fácil más adelante. Otras tecnologías son mucho más débiles.

Estos atacantes parecen tener buenos recursos. Es peligroso confiar en un atacante que nunca tendrá éxito. En teoría, examinar el paquete construido puede revelar problemas, pero la escala del programa real hace que este análisis sea costoso y, a menudo, no detecte problemas. El problema finalmente se descubrió a través del monitoreo, pero en este caso, causó daños generalizados antes de que se descubriera.

Una construcción reproducible validada es similar a una auditoría financiera, donde el auditor financiero determina si los resultados son correctos. El problema fundamental con SolarWinds es que no existe un proceso independiente para verificar que los resultados de la compilación sean correctos.

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

Rodador: Algunos proyectos ya tienen compilaciones reproducibles, por lo que es posible. El Proyecto de compilación reproducible crea versiones modificadas de Debian GNU/Linux (específicamente, Bullseye) en las que más del 90 % de los paquetes son reproducibles. Sin embargo, en la práctica, muchos proyectos de OSS toman tiempo y muchos proyectos de código cerrado toman más tiempo.

Históricamente, nadie verificó la reproducibilidad de la compilación, por lo que los proyectos acumularon muchas construcciones que hicieron que la compilación no fuera reproducible. No existen barreras técnicas fundamentales; solo hay un montón de pequeñas cosas que necesitan ser descubiertas y cambiadas. La combinación de todos estos pequeños cambios requiere un gran esfuerzo en un proyecto más grande.

El software de código cerrado presenta desafíos adicionales, tanto desde el punto de vista técnico como legal. A diferencia del OSS, el software de código cerrado generalmente no está diseñado para ser reconstruido por otros. Un desarrollador de software de código cerrado deberá esforzarse mucho para que otros puedan reconstruirlo. Además, su modelo de negocio a menudo depende de las restricciones legales sobre quién puede acceder al código fuente.

Lo que puede ser necesario es un acuerdo contractual especial para compartir código que no se haya hecho antes. Pero si bien esto es más difícil de hacer con el software de código cerrado, estos desafíos se pueden superar.

¿Qué llevará su adopción?

Rodador: necesidades del cliente! Mientras los clientes acepten amablemente las cajas negras y los productos sin compilaciones reproducibles probadas, los desarrolladores no tienen motivos para cambiar.

se está alejando lentamente de la verdadera caja negra. Los clientes a menudo dicen que no necesitan saber cómo funciona algo, pero una verdadera caja negra significa que los clientes están asumiendo riesgos desconocidos. Muchos proveedores de software de código cerrado (como Microsoft) ahora cuentan con mecanismos para proporcionar al menos algo de visibilidad del código fuente para ayudar a los clientes a administrar mejor su riesgo. Por supuesto, el software de código abierto permite que cualquier persona vea el código.

Estamos en un punto interesante para las construcciones reproducibles. Hasta el momento, algunos proyectos ya están en marcha, aunque no existe una necesidad aparente por parte del cliente. Junto con esta demanda, su disponibilidad aumentará rápidamente.

¿Qué tan influyente es la práctica de código abierto de reutilizar el código?

Rodador: El público no sabe cómo se comprometió el entorno de construcción de SolarWinds. Sabemos que este es un sistema Windows. En términos generales, no importa. Las defensas pueden ser muy buenas, pero no es prudente suponer que el sistema nunca se verá comprometido. Una buena seguridad incluye no solo una buena prevención, sino también detección y recuperación.

Los entornos de construcción futuros también se romperán. Debemos tratar de fortalecer el entorno de construcción contra los ataques, pero también debemos desarrollar mecanismos de detección y recuperación para que cualquier infracción no cause el daño que causó.

¿Qué tan factible es desarrollar una Lista de materiales de software (SBOM) para prevenir el phishing, como sugiere el LF?

Rodador: SBOM puede ayudar a combatir el phishing. Es fácil para los desarrolladores mirar un nombre y leer lo que esperan que diga, no lo que realmente dice. SBOM proporciona a otros, incluidos los clientes, visibilidad de lo que se incluye en un componente, de forma muy parecida a como una lista de ingredientes alimentarios explica lo que hay en nuestra comida. Usando la lista, otros pueden buscar componentes sospechosos, incluidos nombres que son similares pero no iguales a los esperados.

Como dijo el juez asociado de la Corte Suprema Louis Brandeis: «La propaganda es reconocida como un remedio para las enfermedades sociales e industriales. Se dice que la luz del sol es el mejor desinfectante…»

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba