Infraestruturas modernas dependem universalmente de containerização para implantar aplicações, escalar serviços e construir plataformas em nuvem. No entanto, à medida que os containers crescem em popularidade, cresce também o interesse de atores maliciosos. Ataques em ambientes de container evoluíram para cenários completos de múltiplas etapas envolvendo compromissos de cadeia de suprimentos, roubo de segredos do Kubernetes e tentativas de escape de container.
Princípios de containerização e riscos
Um container é um ambiente de execução de código isolado, projetado para particionar recursos para que as aplicações possam rodar corretamente e independentemente. Diferente de uma máquina virtual, um container usa o único kernel subjacente do sistema operacional hospedeiro. Comprometer um container pode ajudar atacantes a alcançar seus objetivos no próprio sistema hospedeiro.
Os vetores de ataque primários incluem explorar vulnerabilidades no sistema hospedeiro e componentes de runtime, atividade maliciosa dentro de um container comprometido, escape de container seguido por comprometimento do hospedeiro, exploração de configurações incorretas e APIs de orquestração inseguras, e ataques à cadeia de suprimentos.
Vetores de ataque atuais e exploração de vulnerabilidades
Vulnerabilidades que afetam o kernel Linux ou componentes de runtime permanecem críticas quando exploradas de dentro de um container. Exemplos incluem CVE-2019-5736 no runC, que permitia execução de código arbitrário no hospedeiro, e CVE-2022-0492, uma vulnerabilidade crítica do kernel Linux que permitia escape de container.
O CVE-2024-21626 é uma vulnerabilidade crítica no runC que permitia acesso ao sistema de arquivos do hospedeiro e, em cenários específicos, escape completo de container. A causa raiz foi o manuseio inadequado de descritores de arquivo e diretório de trabalho atual.
Escapes de container e configurações privilegiadas
Uma das configurações mais perigosas é executar um container com a flag --privileged. Neste modo, o container é concedido todas as capacidades Linux, acesso direto a dispositivos do hospedeiro e capacidade de interagir com interfaces de kernel. Um container configurado assim virtualmente deixa de ser um ambiente isolado.
CAP_SYS_ADMIN é considerada uma das capacidades Linux mais perigosas no contexto de segurança de container. Ela permite montar sistemas de arquivos, interagir com mecanismos cgroups e modificar parâmetros de kernel. CAP_SYS_MODULE fornece acesso direto ao carregamento de módulos de kernel, permitindo manipulação do comportamento do sistema operacional inteiro.
Exploração de APIs de orquestração
Um dos vetores de ataque mais perigosos é a exploração de APIs de gerenciamento de container mal configuradas. A API do Docker, API do Kubernetes e API do kubelet são projetadas para iniciar containers, modificar configurações e executar comandos. Quando mal configuradas, essas interfaces tornam-se um ponto de falha para todo o ambiente.
Um exemplo notório é uma API do Docker exposta. Se o daemon do Docker for acessível via TCP sem TLS ou autenticação, um atacante pode interagir remotamente com o sistema hospedeiro com permissões equivalentes a um administrador local.
Ataques à cadeia de suprimentos e imagens contaminadas
Este enfoque foca em comprometer componentes antes de serem lançados no ambiente de runtime. Um cenário comum envolve ataques que contaminam imagens de container. Atores maliciosos frequentemente publicam imagens contaminadas que se disfarçam de serviços populares. Uma vez que um container como esse é lançado, o atacante ganha capacidade de executar seu próprio código dentro do ambiente confiável da organização.
Sistemas de implantação CI/CD de container são entre os alvos mais frequentes. Após ganhar acesso a um sistema CI/CD, um atacante pode modificar silenciosamente as etapas de construção da imagem Docker, injetando lógica maliciosa diretamente no pipeline.
Recomendações de segurança para ambientes containerizados
A segurança de ambientes containerizados requer uma abordagem que abranja proteção do hospedeiro, controle de acesso estrito no orquestrador, minimização de capacidades de container e validação abrangente de toda a cadeia de suprimentos. Auditoria de configuração, proteção de runtime e monitoramento de atividade são essenciais.