Cómo prevenir paquetes maliciosos y ataques a la cadena de suministro con Snyk

Los paquetes de código abierto desempeñan un papel fundamental en el desarrollo de software moderno y hacen posible el rápido ritmo de desarrollo que vemos a nuestro alrededor. Para un desarrollador que quiere incorporar nuevas funciones a su aplicación, simplemente no tiene sentido reinventar la rueda. ¿Por qué no instalar un paquete que alguien más ya dedicó tiempo a crear y que ofrece exactamente la misma funcionalidad?

Pero la realidad es que los paquetes de código abierto también son un vehículo ideal para distribuir código malicioso en las aplicaciones y socavar la seguridad de la cadena de suministro. La razón es sencilla: son un objetivo fácil y atractivo para los atacantes. Los paquetes se suben a registros sin supervisión de seguridad y se descargan —millones de veces a la semana en el caso de los proyectos populares— en bases de código con casi el mismo nivel de escrutinio.

Registros como npm, PyPI y RubyGems han tenido su buena cuota de paquetes maliciosos en los últimos años, así que no se trata de que un ecosistema sea más vulnerable que otro. Esta es una debilidad de seguridad inherente a la forma en que se crea el software moderno, una debilidad que los equipos de seguridad —y, más importante aún, los desarrolladores— deben reconocer y abordar.

En esta publicación, veremos brevemente cómo se usan los paquetes maliciosos en los ataques a la cadena de suministro de software y cómo Snyk puede ayudar a prevenirlos.

Paquetes maliciosos en los ataques a la cadena de suministro de software

Los ataques a la cadena de suministro de software buscan inyectar código malicioso en un producto de software para comprometer los sistemas dependientes que se encuentran más adelante en la cadena. Sin embargo, estos ataques pueden adoptar distintas formas y tamaños, según el objetivo del ataque y el método específico que se use.

En el ataque a SolarWinds, por ejemplo, los objetivos fueron los procesos de compilación de software y el código fuente. En el reciente ataque a Kaseya, el objetivo fue el software existente. Y cada vez más, los paquetes de código abierto son el objetivo de los ataques. En este tipo de ataque a la cadena de suministro de software, se inyecta código malicioso en un paquete publicado en un repositorio de paquetes (por ejemplo, npm, PyPI o Ruby Gems). Los desarrolladores que confían ciegamente en la autenticidad e integridad de estos paquetes los descargan e instalan sin saberlo, ya sea manualmente o como parte de un proceso de compilación automatizado.

Desde la perspectiva del atacante, este método puede ser muy eficaz. Los paquetes de código abierto se descargan millones de veces al día, por lo que ofrecen un mecanismo de distribución perfecto. El conocido ataque de event-stream de 2018 demuestra el alcance potencial de un ataque a la cadena de suministro de software mediante paquetes maliciosos. En este caso, el atacante primero tomó el control del popular paquete event-stream y luego lo modificó para que dependiera de un paquete malicioso, flatmap-stream. En ese momento, 1,600 paquetes usaban event-stream y se descargaba 1.5 millones de veces a la semana.

¿Cómo se inyecta código malicioso en los paquetes?

Un método de ataque consiste en crear un paquete completamente nuevo que contenga código malicioso. Estos paquetes pueden usar un nombre parecido al de uno existente (typosquatting) o reutilizar el nombre o identificador de un paquete existente que su responsable haya retirado (un exploit de «uso después de liberar»). El segundo método consiste en infectar un paquete existente mediante la inyección de código malicioso en el código fuente, durante la compilación o en el repositorio de paquetes. Basta con que el responsable del proyecto integre un pull request aparentemente inofensivo que contenga el código malicioso. Un tercer método consiste en subir paquetes maliciosos a repositorios alternativos o a réplicas de repositorios.

Una vez que un paquete malicioso llega al árbol de dependencias de un proyecto, hay distintas formas de ejecutar el código malicioso. En muchos casos, se ejecutan scripts de instalación durante la instalación del paquete. En otros, es necesario invocar el código malicioso durante la ejecución.

Cómo mitigar los paquetes maliciosos con Snyk

Entonces, ¿cómo puedes protegerte de los paquetes maliciosos?

Cada ecosistema tiene estrategias específicas para evitar que los paquetes maliciosos se infiltren en tu base de código. Para JavaScript, por ejemplo, detallamos algunas prácticas recomendadas en esta guía rápida. Como solución de seguridad de aplicaciones, Snyk también ofrece varias formas integradas de identificar paquetes maliciosos al inicio del proceso de desarrollo y en las etapas posteriores.

Trasladar la debida diligencia a las etapas iniciales

Trasladar la seguridad de las aplicaciones a las etapas iniciales se ha convertido en una práctica estándar. Los equipos más eficaces automatizan las pruebas de seguridad lo antes posible, incluso en los entornos de desarrollo locales, dentro de sus IDE. Pero la seguridad y el proceso de identificación de paquetes maliciosos también pueden comenzar antes de que escribas tu primera línea de código: durante las etapas de planificación e investigación.

Investigar bien siempre es una buena práctica al decidir qué software incorporar a tu proyecto, pero no siempre es sencillo investigar un paquete específico. En un mundo ideal, los registros de paquetes proporcionarían toda la información necesaria para decidir si instalar o no un paquete, incluido si es seguro. Sin embargo, en realidad, a los registros les falta mucha información sobre el estado y la seguridad de los paquetes.

Snyk Advisor es una herramienta de investigación gratuita en línea que puede ayudarte a decidir qué paquete usar en tus proyectos. Snyk Advisor muestra una puntuación de estado basada en varios factores importantes que debes tener en cuenta al seleccionar un paquete. Por ejemplo, Snyk Advisor analiza el nivel de mantenimiento de un paquete según la frecuencia de las versiones publicadas y la actividad del repositorio. También analiza la popularidad del paquete y la solidez de la comunidad que respalda el proyecto.

Por supuesto, Snyk Advisor también tiene en cuenta el estado de seguridad de un paquete. Los datos de seguridad se basan en Snyk Intel Vulnerability Database e incluyen información sobre si el paquete es malicioso. En el siguiente ejemplo, Snyk Advisor marca el paquete npm lyft-dataset-sdk como malicioso y susceptible de usarse para confundir dependencias: el paquete tiene el mismo nombre que un paquete de Python creado por Lyft, por lo que puede infiltrarse fácilmente en una base de código que tenga definida esta dependencia.

Snyk Vulnerability Database también señala los paquetes maliciosos y puedes usarla como parte de tu proceso de investigación.

En el siguiente ejemplo de typosquatting, un paquete gem llamado auth-client aparece marcado como malicioso. El autor o los autores de este paquete usaron deliberadamente un nombre muy parecido al de paquetes Ruby existentes y seguros (por ejemplo, auth_client, authclient) con la esperanza de que un desarrollador escriba mal el nombre de la dependencia y descargue el paquete troyanizado.

Cómo abordar los paquetes maliciosos en todo el ciclo de vida de desarrollo de software (SDLC)

Incluso con una investigación exhaustiva, los paquetes maliciosos pueden pasar desapercibidos. Las pruebas de seguridad de Snyk se aplican en distintas etapas del SDLC para garantizar que estos paquetes se identifiquen lo antes posible.

En los proyectos de Git que Snyk monitorea, cada nuevo pull request de un desarrollador colaborador se compara con Snyk Vulnerability Database. Si se identifica un paquete malicioso, la prueba de seguridad falla y proporciona información sobre el paquete y el motivo del fallo.

¿Y qué pasa con los paquetes maliciosos que ya están en tu lista de pendientes? Cuando hay cientos o incluso miles de vulnerabilidades, encontrar un problema introducido por un paquete malicioso puede ser una tarea abrumadora, incluso para el equipo con más experiencia.

Snyk también señala los paquetes maliciosos en la interfaz de Snyk. En los proyectos que Snyk monitorea, esta información se tiene en cuenta en la puntuación de prioridad de una vulnerabilidad, junto con otros factores calculados, como la puntuación CVSS de la vulnerabilidad, la disponibilidad de una corrección, si la vulnerabilidad es tendencia en las redes sociales, los exploits conocidos, su antigüedad y si es alcanzable. Esto te ayuda a encontrar, priorizar y corregir rápidamente estos problemas específicos:

Tomar medidas desde el principio

Desde la perspectiva del atacante, la facilidad con la que se suben paquetes a los registros, sin ningún tipo de control de seguridad, sumada a la dependencia cada vez mayor de estos paquetes para mantener un ritmo de desarrollo acelerado, hace que este ataque sea sumamente atractivo.

Esta es una debilidad de seguridad inherente a la forma en que se crean las aplicaciones hoy en día. Para abordarla, los profesionales de desarrollo y seguridad deben poder identificar los paquetes maliciosos desde las primeras etapas de investigación, tanto al seleccionar qué paquete usar como más adelante durante el desarrollo.

Para obtener más información sobre la seguridad de la cadena de suministro de software, haz clic aquí.