Build Misconfiguration: External Ivy Dependency Repository

Este script de compilación de Ant se basa en orígenes externos, lo que podría permitir a un atacante insertar código malintencionado en el producto final o tomar el control de la máquina de compilación.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

En Ivy, en lugar de enumerar las direcciones URL explícitas de las que recuperar las dependencias, los desarrolladores especifican los nombres y las versiones de las dependencias, e Ivy se basa en su configuración subyacente para identificar los servidores de los que recuperar las dependencias. Para los componentes de uso común, esta medida evita que el desarrollador tenga que investigar las ubicaciones de las dependencias.

Ejemplo 1: El siguiente extracto de un archivo ivy.xml de Ivy muestra cómo un desarrollador puede especificar múltiples dependencias externas usando su nombre y versión:

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.