Este es el cuarto episodio del serie de mensajes sobre componentes maliciosos, donde presentamos el xygeni enfoque para manejar esta amenaza, como parte de nuestra cobertura para Open Source Security.
Vimos que el exceso de confianza en los componentes de código abierto de origen incierto es aprovechado por malhechores de todo tipo para generar un comportamiento inesperado que se ejecuta en las máquinas de los desarrolladores. CI/CD sistemas, o incrustado en el software de la organización víctima, para que se transmita a los clientes de la organización. Analizamos en episodio 2 los ataques que utilizan registros públicos para entregar malware y lo que hemos aprendido después de observar cómo operan los malos actores, y en el anterior episodio 3 Se examinaron los controles que funcionan (y los que fallan) contra esta amenaza.
Ahora es el momento de examinar nuestra manera de abordar el problema. En este episodio presentamos cuál es la estrategia que seguimos en Xygeni para nuestra Alerta temprana de malware (MEW) sistema. Cómo funciona este sistema de múltiples etapas en tiempo real cuando se lanza una nueva versión del paquete, cómo se captura la evidencia de diferentes fuentes, cómo se realiza la clasificación, qué criterios de clasificación seguimos y por qué aún se necesita algún análisis manual para confirmar la naturaleza. de un candidato a paquete malicioso. También explicaremos cómo estamos ayudando a NPM, GitHub, PyPI y otras infraestructuras clave en los ecosistemas de código abierto a reducir el tiempo de permanencia del malware.
El proceso de pipeline
Xygeni Malware Early Warning (MEW) procesa continuamente componentes, ya sean paquetes tar para bibliotecas y marcos para ecosistemas de programación compatibles como JavaScript/Node o Python, imágenes de contenedores Docker/OCI o extensiones y complementos para herramientas como IDE o CI/CD sistemas. Dichos componentes se publican en registros públicos con diferentes niveles de verificación por parte de los usuarios.
La siguiente es una vista esquemática de cómo funciona el sistema:
El proceso de descubridor El proceso obtiene el feed de los eventos de publicación. Un evento de publicación es la creación de una nueva versión de un componente nuevo o existente. Como los registros populares no proporcionan un mecanismo de publicación-suscripción para los consumidores interesados, esto a menudo se hace consultando el registro para detectar eventos recientes. Un excelente proyecto de la OSSF, feeds de paquetes, El apoyo registros populares como PyPI o Maven Central, y proporcionan una interfaz unificada basada en feeds. En MEW agregamos algunas implementaciones específicas que reducen el tiempo de espera, por ejemplo con una réplica de la base de datos CouchDB utilizada por NPM que está sincronizada con la base de datos del registro público.
En Xygeni contamos con un inventario[ 1 ] de todos los componentes (directa o indirectamente) utilizados por el software de nuestros clientes. Las coordenadas de los componentes de los clientes se envían periódicamente a MEW para priorizar los análisis: los componentes utilizados por nuestros clientes se procesan antes. La prioridad también se basa en la reputación del editor y la criticidad del componente, por lo que también se priorizan los componentes que provienen de editores con baja reputación.
El proceso de analizadores luego consuma los componentes pendientes en la cola de prioridad. Cuando se selecciona una versión de componente para su análisis, su archivo tar se descarga del registro. Tenga en cuenta que se analiza el componente binario empaquetado: la mayoría de los componentes de código abierto generalmente provienen de un repositorio de código abierto, a menudo en github.com, que se usa solo como contexto, y el malware siempre se busca en el paquete tar del componente porque los actores de amenazas sistemáticamente mienten sobre las fuentes que afirman haber utilizado para construir el componente tarball que publican.
Desde la perspectiva del usuario
Te escucho pensar: ¿Cómo puedo beneficiarme al conocer tempranamente la versión de un paquete malicioso? en el episodio "Anatomía de los paquetes maliciosos: ¿cuáles son las tendencias?" Vimos que el tiempo total de permanencia está en el rango de días, mientras que la primera notificación de MEW a los clientes que utilizan el componente afectado está en el rango de minutos. Con una simple barandilla[ 2 ] puedes bloquear la compilación (hay dos niveles de alerta, uno completamente automatizado cuando el motor concluye que hay malware potencial y una notificación posterior cuando nuestro equipo de seguridad confirma mediante inspección manual la presencia de malware). Esperar hasta que el registro confirme el malware y lo elimine del registro suele ser demasiado tarde debido a la larga ventana de exposición.
La organización puede utilizar una barrera de seguridad que verifique si hay algún componente con potencial malware (en cualquiera de los dos niveles de alerta) o, vía API, saber rápidamente si alguna de las dependencias directas o indirectas de un proyecto de software está utilizando un componente malicioso.
Cómo funciona MEW: detalles internos
El núcleo: motor de detección de malware
El analizador utiliza diferentes detectores para capturar pruebas de irregularidades. Los detectores combinan análisis estático, análisis de capacidades y análisis de contexto.[ 3 ], como se describe en la publicación anterior de esta serie.
En Xygeni contamos con un equipo de ingeniería con una larga experiencia en análisis estático, y esta es la principal diferencia con otras soluciones anti-malware. Tenga en cuenta que, para algunos ecosistemas, el tarball empaquetado contiene código fuente (por ejemplo, código JavaScript o TypeScript para paquetes NPM, fuentes Python para paquetes PyPI) o código compilado lo suficientemente cercano al código fuente para el análisis estático (por ejemplo, código de bytes en archivos JAR para Maven). . Para otros, como las imágenes de contenedores, los ejecutables binarios son comunes, por lo que la técnica utilizada es la inferencia de capacidades, junto con la detección de malware convencional basada en reglas YARA y firmas de malware.
Tenga en cuenta que las tecnologías simples como expresiones regulares o firmas no son apropiadas para detectar comportamientos maliciosos. Imagine detectar un cuentagotas o un descargador: algún código o binario se encuentra en el paquete o se descarga desde un dominio externo, no relacionado con el componente (podría ser uno de un gran lista de dominios comprados por el actor de amenazas[ 4 ], o un dominio legítimo para evadir la detección). Luego, ese código se ejecuta usando una de las funciones para eso. El código se puede transformar para ocultar la URL de descarga o la función utilizada para ejecutar el código descargado. Se necesita un análisis completo del flujo de datos para detectarlo, utilizando toda la maquinaria de análisis estático o una ejecución en espacio aislado (si realmente se cumplen las condiciones para que se ejecute un comportamiento malicioso) podría detectarlo en el caso general.
Los actores de amenazas siguen las mismas técnicas y se diseñaron e implementaron detectores para ellos. También hay algunos pasos de preprocesamiento, por ejemplo para eliminar la ofuscación, que a menudo son necesarios para descubrir el comportamiento oculto.
Agregar contexto
Algunos detectores utilizan información de contexto. Por ejemplo, una discrepancia entre la versión en el registro del componente y la etiqueta/versión en el repositorio de GitHub asociado constituye una fuerte evidencia de que quizás un mal actor obtuvo credenciales de publicación para el registro pero no para el repositorio de GitHub. Ataques como el que afecta al proveedor de billeteras criptográficas Libro mayor podría detectarse fácilmente por este desajuste.
A puntuación de malicia (MS) se calcula a partir de los hallazgos de los detectores ejecutados, en función de la solidez de la evidencia capturada. No todos los hallazgos son iguales y el orden de ejecución es relevante.
Reputación de usuarios y componentes
¡No todos los desarrolladores de código abierto son iguales!
A un desarrollador de buena reputación se le puede secuestrar su cuenta NPM (esto sucede incluso con personas conscientes de la seguridad) y se puede publicar malware usando esa cuenta. Obviamente, la reputación debería caer abruptamente y solo recuperar la gloria pasada cuando se recupere la cuenta secuestrada y el desarrollador corrija las condiciones que llevaron a la apropiación de la cuenta. La reputación es difícil de ganar, pero se puede perder en un instante.
En MEW, hemos implementado un sistema integral de gestión de la reputación para recompensar el comportamiento positivo y penalizar las actividades sospechosas. Este sistema comienza con nuevos usuarios en una postura neutral y ajusta su reputación en función de sus actividades en curso.
La reputación de un usuario mejora a través de acciones positivas como mantener cuentas activas en las redes sociales, permitir la autenticación multifactor, contribuir regularmente a proyectos y firmar. commits con claves verificables. Por el contrario, la reputación se deteriora debido a acciones hostiles como publicar malware, utilizar direcciones de correo electrónico desechables o no firmar. commits, o exhibiendo patrones inusuales en las contribuciones.
El objetivo principal de nuestro sistema es garantizar un entorno seguro y confiable. Lo logra ajustando dinámicamente la reputación de los usuarios en función de varios factores, respetando al mismo tiempo las preocupaciones de privacidad y las limitaciones de los diferentes registros.
Se calcula una puntuación de reputación interna para el usuario (uniéndose al registro y a la cuenta de github cuando sea posible), y junto con la puntuación de malicia utilizada durante la clasificación del componente bajo análisis, y para calificar mejor quién está bajo la publicación del componente.
Se encontraron pruebas de comportamiento malicioso. ¿Así que lo que? El proceso de revisión manual
El clasificador actual establece la versión del componente analizado en una de las categorías "malicioso confirmado", "probablemente malicioso", "alto riesgo", "bajo riesgo" o "no malicioso" según los umbrales de las puntuaciones que condensan los hallazgos y la reputación del usuario/componente. Una clasificación en categorías de “alto riesgo” o “probablemente malicioso” activa la revisión manual y la primera notificación. La categoría "maliciosa confirmada" se establece después de una revisión manual o cuando la evidencia coincide con la misma evidencia de una versión anterior que se confirmó como maliciosa.
Cuando existe evidencia suficiente de un posible comportamiento malicioso, se emite una primera alerta (alerta de cuarentena) a las organizaciones afectadas. Como se mencionó anteriormente, eso puede bloquear la instalación o compilación de software que depende del componente en cuarentena.
Eso crea un problema en el MEW interno. dashboard para que los analistas de seguridad puedan iniciar el proceso de revisión manual del componente. El equipo cuenta con herramientas especializadas (sandbox, desofuscadores, distribución para investigación de malware, herramientas de informes de malware) para evaluar rápidamente la naturaleza de la versión del componente bajo investigación. La mayor parte del malware (“las anchoas” o componentes maliciosos poco sofisticados) se revisa
El resultado de la revisión concluye en cualquiera de los dos casos. seguras, por lo que el motor de análisis automático encontró un falso positivo que se utiliza como retroalimentación para que el clasificador de aprendizaje automático aprenda el patrón; o confirmado malicioso, por lo que el componente se divulga responsablemente como malicioso en el registro público, luego del proceso de informe. Se envía una segunda notificación a las organizaciones afectadas, que a su vez pueden sacar el componente de la cuarentena o bloquearlo definitivamente del proceso de actualización de su versión o del firewall del componente utilizado en su registro interno.
Esta configuración nos permite analizar decenas de miles de nuevas versiones diariamente e identificar las decenas que probablemente sean maliciosas, que luego revisamos manualmente. Recuerde del episodio anterior que uno entre diez mil es la tasa de componentes maliciosos que vemos actualmente en la naturaleza.
Informar al Registro
Descubrimos que la mayoría de los registros públicos, una de las columnas vertebrales de la infraestructura de código abierto, proporcionan mecanismos bastante limitados para informar problemas de seguridad y, en particular, componentes maliciosos. Estamos luchando por mejorar la organización subyacente del proceso de presentación de informes. Normalmente recibimos como máximo un correo electrónico de respuesta del equipo de seguridad del registro que confirma que el componente se eliminó del registro.
A veces se abusa del registro, infringiendo sus condiciones de uso, pero sin provocar un comportamiento malicioso en el software entregado. Esto también se informa al registro, pero no se notifica a las organizaciones para limitar el ruido.
Trabajo futuro
Actualmente hay muchas mejoras en la hoja de ruta. En primer lugar, un Portal público para el estado de los componentes del sistema operativo., particularmente relacionado con las pruebas encontradas de posible malicia, se encuentra actualmente en desarrollo. Esto pretende ser una modesta contribución a la comunidad de código abierto. Manténganse al tanto.
Otro desarrollo en curso es una mejora clasificador de aprendizaje automáticoMEW aprenderá de clasificaciones anteriores. El vector de hallazgos de los detectores del motor, junto con la puntuación de malicia y la puntuación de reputación derivadas, tanto del componente como del editor («la evidencia encontrada»), se utiliza como entrada para un sistema de aprendizaje automático que actualiza el modelo del clasificador. La variable de salida es simplemente si el registro confirmó si el componente era malicioso. Esto se conoce como «el Oráculo» y ayudará con una pre...cisCalificador electrónico, diseñado para ser sólido (alta capacidad de recuperación, es decir, no perder componentes maliciosos) pero con menos falsos positivos (no informar componentes seguros como maliciosos).
A puntuación de criticidad se agregará por criterios de priorización, además de pertenecer al conjunto de dependencias de los clientes y la baja reputación del editor. Está claro que los proyectos con más influencia e importancia deben considerarse antes para su análisis. No reinventaremos la rueda aquí y seguiremos el Puntuación de criticidad del proyecto de código abierto.
Se está desarrollando soporte para ecosistemas adicionales. En la hoja de ruta se encuentran tecnologías y herramientas generalizadas como PHP o complementos de Jenkins.
También estamos explorando si la IA podría ayudar al proceso de revisión manual para agilizar el análisis de los pocos componentes maliciosos más sofisticados.
En la próxima y última entrega de esta serie, “Explotación del código abierto: qué esperar de los malos”, nos centraremos en las últimas formas que están adoptando los adversarios para hacer que los ataques sean más sigilosos, más difíciles de detectar, más dirigidos a industrias específicas y más rentables. ¿Se realizarán ataques de ransomware utilizando este vehículo? ¿Cómo aprovechan los malos las herramientas de inteligencia artificial para generar malware más sofisticado? ¿Están en riesgo los principales proyectos populares? Esto tiene como objetivo dar a los lectores una idea de esta carrera armamentista y de qué esperar a corto plazo (segunda mitad de 2024) y mediano plazo (2025).
Concluiremos con algunas reflexiones sobre qué pequeños pasos podría dar la comunidad sin cambiar demasiado la apertura del mundo del código abierto. Por ejemplo, un mecanismo más eficiente para reportar malware a los registros públicos y compartir evidencia de componentes potencialmente maliciosos con los registros y la comunidad sería un pequeño paso en la dirección correcta hacia el objetivo de cerrar las puertas a los actores de amenazas.
El malware en los componentes de código abierto no debería alterar los enormes beneficios que la comunidad de código abierto ha aportado a nuestra sociedad.
- [ 1 ] Nuestro escáner detecta componentes de código abierto a los que hacen referencia los proyectos de software analizados, por lo que se conoce el gráfico de dependencia completo y actualizado, al menos para los proyectos que se analizan periódicamente. Xygeni OSS expone una API que los clientes también pueden usar durante la inclusión en la lista blanca de un componente de interés, incluida información sobre vulnerabilidades y evidencia maliciosa.
- [ 2 ] Una barandilla puede romper la construcción si se detecta una condición que coincida con problemas de seguridad. Los hallazgos de seguridad, como una vulnerabilidad crítica y alcanzable o el uso de un componente en cuarentena, podrían considerarse lo suficientemente graves como para interrumpir la compilación del software afectado.
- [ 3 ]Nuestros analistas de seguridad ejecutan el componente o sus scripts de instalación en un entorno aislado cuando es necesario. Sin embargo, MEW no realiza análisis dinámico, principalmente porque el comportamiento malicioso no siempre se realiza en ataques dirigidos y debido a la lógica de evasión que los actores de amenazas utilizan para evadir el análisis dinámico.
- [ 4 ] Esta técnica recibió un nombre, Algoritmos de Generación de Dominios Registrados o RDGA, y nuevos actores de amenazas como los llamados Conejo revólver invirtió hasta 1 millón de dólares en 500 dominios, lo que demuestra lo rentable que es la industria del ciberdelito.
