Build Misconfiguration: External Ant Dependency Repository

Este script Ant build depende de fontes externas, o que pode permitir que um invasor insira um código mal-intencionado no produto final ou assuma o controle da máquina de build.

No universo de desenvolvimento Java, existem várias ferramentas para auxiliar no gerenciamento de dependências: os sistemas de compilação Apache Ant e Apache Maven incluem ambos uma funcionalidade projetada especificamente para ajudar a gerenciar dependências, enquanto o Apache Ivy foi desenvolvido explicitamente como um gerenciador de dependências. Embora existam diferenças em seus comportamentos, essas ferramentas compartilham a funcionalidade comum de baixar automaticamente as dependências externas especificadas no processo de compilação em tempo de compilação. Isso torna mais fácil para o desenvolvedor B construir softwares da mesma maneira que o desenvolvedor A. Os desenvolvedores apenas armazenam informações de dependências no arquivo de compilação, o que significa que cada desenvolvedor e engenheiro de compilação tem uma maneira consistente de obter dependências, compilar o código e implantá-lo sem os aborrecimentos envolvidos no gerenciamento de dependências manual. Os exemplos a seguir ilustram como o Ivy, o Ant e o Maven podem ser usados para gerenciar dependências externas como parte de um processo de compilação.

Os desenvolvedores especificam dependências externas em um destino Ant usando uma tarefa <get>, que recupera a dependência especificada pelo URL correspondente. Essa abordagem é funcionalmente equivalente ao cenário em que um desenvolvedor documenta cada dependência externa como um artefato incluído no projeto de software, mas é mais desejável porque automatiza a recuperação e incorporação das dependências quando um build é executado.

Exemplo 1: O seguinte trecho de um arquivo de configuração Ant build.xml mostra uma referência típica a uma dependência externa:

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

Dois tipos distintos de cenários de ataque afetam esses sistemas: Um invasor pode comprometer o servidor que hospeda a dependência ou comprometer o servidor DNS que a máquina de build usa para redirecionar as solicitações de nome de host do servidor que hospeda a dependência para uma máquina controlada pelo invasor. Ambos os cenários resultam no invasor conquistando a capacidade de injetar uma versão mal-intencionada de uma dependência em um build em execução em uma máquina não comprometida de outra forma.

Independentemente do vetor de ataque usado para entregar a dependência Trojan, esses cenários compartilham o elemento comum de que o sistema de build aceita cegamente o binário mal-intencionado e o inclui no build. Como o sistema de build não tem recursos para rejeitar o binário mal-intencionado e os mecanismos de segurança existentes, como revisão de código, geralmente se concentram em códigos desenvolvidos internamente em vez de dependências externas, esse tipo de ataque tem uma grande possibilidade de passar despercebido à medida que se espalha pelo ambiente de desenvolvimento e possivelmente de produção.

Embora haja algum risco de uma dependência comprometida ser introduzida em um processo de build manual, a tendência dos sistemas de build automatizados de recuperar a dependência de uma fonte externa cada vez que o sistema de compilação é executado em um novo ambiente aumenta muito a janela de oportunidade para um atacante. Um invasor precisa apenas comprometer o servidor de dependência ou o servidor DNS durante uma das muitas vezes em que a dependência é recuperada para comprometer a máquina na qual o build está ocorrendo.