Tornou-se conhecido recentemente através uma postagem no blog, os resultados das ferramentas de teste para identificar vulnerabilidades nenhum patch e identifica problemas de segurança em imagens isoladas de contêiner do Docker.
O teste mostrou que 4 dos 6 scanners imagens Docker conhecidas tinha vulnerabilidades críticas que permitiu atacar o próprio scanner e executar seu código no sistema, em alguns casos (usando Snyk por exemplo) com privilégios de root.
Para um ataque, um invasor só precisa começar a verificar seu Dockerfile ou manifest.json, que inclui metadados especialmente formatados, ou coloque os arquivos podfile e gradlew dentro da imagem.
Conseguimos preparar protótipos de exploit para sistemas WhiteSource, Snyk, Fossa e âncora.
O pacote Clara, originalmente escrito com a segurança em mente, mostrou a melhor segurança.
Nenhum problema identificado no pacote Trivy e como resultado, concluiu-se que os scanners de contêiner Docker devem ser executados em ambientes isolados ou usados apenas para verificar suas próprias imagens, e também ter cuidado ao conectar tais ferramentas a sistemas automatizados de integração contínua.
Esses scanners fazem coisas complicadas e sujeitas a erros. Eles estão lidando com a janela de encaixe, extraindo camadas / arquivos, interagindo com gerenciadores de pacotes ou analisando formatos diferentes. Defendê-los, enquanto tenta acomodar todos os casos de uso para desenvolvedores, é muito difícil. Vamos ver como as diferentes ferramentas tentam e conseguem fazer isso:
A pontuação de divulgação responsável reflete minha opinião pessoal: acho importante que os fornecedores de software sejam receptivos aos problemas de segurança relatados a eles, sejam honestos e transparentes sobre vulnerabilidades, para garantir que as pessoas que usam seus produtos estejam devidamente informados para tomar decisões sobre a atualização. Isso inclui as principais informações de que uma atualização possui alterações relevantes para a segurança, abrindo um CVE para rastrear e comunicar sobre o problema e, potencialmente, notificar seus clientes. Acho que isso é especialmente razoável supor se o produto for sobre CVE, fornecendo informações sobre vulnerabilidades no software. Além disso, estou tranquilo pela resposta rápida, tempos de correção razoáveis e comunicação aberta com a pessoa que relatou o ataque.
Na FOSSA, Snyk e WhiteSource, a vulnerabilidade foi relacionada com chamada para um gerenciador de pacotes externo para determinar as dependências e permitir que você organize a execução de seu código, especificando os comandos de toque e do sistema nos arquivos gradlew e Podfile.
En Snyk e WhiteSource também encontraram uma vulnerabilidade, associada aos comandos do sistema de inicialização organização que analisou o Dockerfile (por exemplo, no Snyk via Dockefile você pode substituir o utilitário ls (/ bin / ls), causado pelo scanner e no WhiteSurce você pode substituir o código por meio dos argumentos na forma de "echo" ; toque em /tmp/hacked_whitesource_pip;=1.0 '«).
Em Anchore, a vulnerabilidade foi causada pelo uso do utilitário skopeo para trabalhar com imagens docker. A operação foi reduzida para adicionar parâmetros da forma '»os»: «$ (touch hacked_anchore)»' ao arquivo manifest.json, que são substituídos ao chamar skopeo sem um escape adequado (apenas os caracteres «; & <foram removidos > ", Mas a construção" $ () ").
O mesmo autor conduziu um estudo sobre a eficácia da detecção de vulnerabilidade não corrigido via scanners de segurança de contêineres docker e o nível de falsos positivos.
Além do autor argumenta que várias dessas ferramentas usar gerenciadores de pacotes diretamente para resolver dependências. Isso os torna particularmente difíceis de defender. Alguns gerenciadores de dependências possuem arquivos de configuração que permitem a inclusão de código de shell.
Mesmo que essas maneiras simples sejam de alguma forma administradas, ligar para esses gerenciadores de pacotes inevitavelmente significará gastar dinheiro. Isso, para dizer o mínimo, não facilita a defesa do pedido.
Resultados de teste de 73 imagens contendo vulnerabilidades conhecido, bem como uma avaliação da eficácia para determinar a presença de aplicações típicas em imagens (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), pode ser consultado dentro da publicação feita no link a seguir.