Como invadi contêineres Docker explorando vulnerabilidades do ImageMagick

E se eu dissesse que usar imagens Docker vulneráveis pode deixar você sob risco iminente e significativo de uma vulnerabilidade de segurança de injeção de comandos para invadir contêineres Docker que usam essa imagem vulnerável?

Neste artigo, vou mostrar um passo a passo de como invadir contêineres. Vamos explorar uma aplicação web baseada em Node.js que usa uma imagem-base oficial do Docker para Node.js, mas vulnerável.

Invasão de um contêiner com uma imagem vulnerável do Node.js

Para demonstrar essa vulnerabilidade, vou usar uma versão antiga do runtime Node.js com uma aplicação Fastify que redimensiona imagens para um tamanho específico. O redimensionamento é feito pela biblioteca ImageMagick, que oferece uma prática ferramenta de linha de comando chamada convert.

O ImageMagick é um conjunto de ferramentas de linha de comando e vínculos com linguagens de programação, comumente usado em aplicações web para processar imagens, por exemplo, convertendo-as de um formato para outro, redimensionando, cortando e muito mais.

Infelizmente, o ImageMagick já apresentou muitas vulnerabilidades de segurança ao longo dos anos. Uma delas é a famosa vulnerabilidade ImageTragick (CVE-2016-3714). Ela é classificada como validação inadequada de entrada, mas provas de conceito para explorá-la estão disponíveis publicamente desde 2016 e podem permitir a injeção remota de comandos.

Esta é uma história sobre a invasão de contêineres não por falta de boas práticas de segurança nem por dependências vulneráveis das aplicações Node.js, mas por causa de componentes de código aberto de terceiros que podem estar presentes em uma aplicação Node.js baseada em Docker.

A aplicação Node.js

Vamos começar pela imagem Docker que reúne a aplicação Node.js. Para simplificar, vou usar uma configuração de Dockerfile bem enxuta:

1FROM node:6.1.0-wheezy 
2
3RUN mkdir /usr/src/goof
4COPY . /usr/src/goof
5WORKDIR /usr/src/goof
6
7RUN npm update
8RUN npm install
9CMD ["npm", "start"]

Este Dockerfile não segue as diretrizes seguras para criar imagens Docker e foi incluído apenas para simplificar. Confira nosso guia rápido com 10 boas práticas para conteinerizar aplicações web Node.js com Docker e conheça as práticas recomendadas de segurança.

A aplicação web Fastify disponibiliza uma rota **/**upload que aceita o envio de arquivos e executa o processo /usr/bin/convert com a imagem enviada para convertê-la para um tamanho específico. Em seguida, redireciona o usuário para uma página de sucesso.

1fastify.post("/upload", (req, res) => {
2  req.multipart(uploadFileHandler, err => {
3    if (err) {
4      fastify.log.error(err);
5    }
6
7    fastify.log.info("upload completed");
8    fastify.log.info("commencing image resizing");
9
10    child_process.execFile(
11      "/usr/bin/convert",
12      [FILE_OUTPUT, "-resize", "280x150", FILE_RESULT],
13      () => {
14        res.redirect("/result.html");
15      }
16    );
17  });
18});

Na verdade, o código usa uma API segura do Node.js para executar processos, sem permitir a concatenação de strings.

É uma boa prática iniciar shells do sistema e executar processos? Não exatamente — pelo menos, não sem uma boa justificativa. Se esse for um processo worker do Node.js que consome itens de uma fila ou recebe tarefas de um agendador, talvez faça sentido para esse caso de uso.

Mas quem somos nós para julgar, se um caso de uso parecido foi demonstrado ao vivo no evento Google I/O 2017?

Vamos invadir um contêiner Docker

Comecei importando o projeto para o Snyk, que detecta automaticamente os arquivos de manifesto compatíveis. Neste caso, são o package.json da aplicação e o Dockerfile.

Como você pode ver, até mesmo a versão mais recente da imagem Node.js 6 (node:6-stretch) contém, por padrão, 866 vulnerabilidades de segurança. Felizmente, usamos o Snyk, que recomenda várias imagens-base alternativas capazes de melhorar a segurança da aplicação de pelo menos duas maneiras:

1. menos vulnerabilidades, o que reduz a superfície de ataque.

2. imagens-base em que o próprio runtime Node.js não tem vulnerabilidades. Esse é um benefício muito importante, mas que muitas vezes passa despercebido, de seguir as recomendações de imagens-base.

Vamos transformar a vulnerabilidade de segurança ImageTragick, presente na versão do ImageMagick que está na imagem do contêiner, em um ataque de injeção remota de comandos.

A exploração usa arquivos de imagem especialmente criados para contornar a funcionalidade de análise do recurso delegates da biblioteca ImageMagick. Esse recurso executa comandos do sistema associados a instruções dentro do arquivo de imagem. Ao escapar do contexto de entrada esperado, um invasor consegue injetar comandos do sistema.

Este repositório do Git inclui uma prova de conceito para execução remota de comandos. Ela baixa o netcat para obter um shell reverso em distribuições que não incluem o netcat por padrão, como o Debian wheezy.

Veja como é o payload da prova de conceito no arquivo de imagem rce1.jpg:

1push graphic-context
2viewbox 0 0 640 480
3fill 'url(https://127.0.0.0/oops.jpg"|touch "rce1)'
4pop graphic-context

O arquivo de imagem está sob controle do usuário. Assim, um invasor mal-intencionado poderia criar esse payload, que executa um comando compatível com sistemas operacionais do tipo UNIX para criar um arquivo vazio — neste caso, touch rce1.

Depois de criar a imagem do contêiner, podemos executá-la:

1docker run --rm --name rce rce

Nossa aplicação web simples permite enviar um arquivo:

Ao clicar no botão Resize para processar o arquivo rce1.jpg, a injeção de comandos é acionada.

Vamos nos conectar à aplicação que está em execução no contêiner Docker para validar esse ataque. Como podemos ver, um novo arquivo chamado rce1.jpg foi criado no diretório raiz da aplicação Node.js:

Resumo da invasão de contêineres

Você provavelmente não vai se surpreender com a quantidade de vulnerabilidades de segurança presentes em várias imagens Docker. Nós também não, já que observamos vulnerabilidades nas 10 imagens Docker mais populares do Docker Hub, como mostra nosso relatório O estado da segurança do código aberto.

O ataque que demonstramos contorna completamente todas as convenções de programação segura e vai além da segurança do runtime Node.js ou das dependências de módulos de código aberto incluídas na aplicação. Isso reforça a importância de proteger suas imagens Docker. O Snyk foi criado justamente para isso!

Ao destacar vulnerabilidades priorizadas, o Snyk recomenda medidas de correção, como trocar por outras imagens-base:

Se quiser recriar o ataque passo a passo, siga as instruções do README no repositório de código aberto. Ele também explica como realizar um ataque de shell reverso remoto com base nessa vulnerabilidade do ImageTragick.

E agora?

Se os repositórios do seu projeto com aplicações Docker forem públicos ou privados, você pode usar o plano gratuito do Snyk para testar suas imagens Docker e corrigir vulnerabilidades de segurança conhecidas. Aproveite também para analisar e corrigir suas aplicações Node.js!

O Dockerfile apresentado aqui e no repositório de código aberto associado não é recomendado por não seguir práticas de segurança. Em vez disso, confira algumas boas práticas de segurança para Docker nas publicações abaixo:

• 10 boas práticas para conteinerizar aplicações web Node.js com Docker

• 10 boas práticas para criar um contêiner Java com Docker

• O guia de segurança do Snyk e do Docker para desenvolvedores

• Docker para desenvolvedores Node.js: 5 dicas para não comprometer sua segurança