Onde estão todas as violações de contêineres?

Como os agentes de ameaças atacarão e utilizarão contêineres? Esta é uma questão em que penso constantemente. Trabalho nesta área há mais de duas décadas e sinto que deveria ter uma resposta. Mas eu não.

Em vez disso, tenho muitas ideias diferentes, nenhuma das quais posso realmente identificar como correta. Parte dessa indecisão se deve a todo o tempo que passei aprendendo sobre segurança no mundo “legado”. Os contêineres realmente não possuem um análogo. Claro, as máquinas virtuais (VMs) são frequentemente confundidas com contêineres, mas nunca foram capazes de escalar como contêineres. Eles também são usados ​​para finalidades completamente diferentes dos contêineres. Demorei um pouco para ajustar meu pensamento e entender onde os contêineres realmente se encaixam na superfície de ataque.

Os exemplos públicos de ataques contra ambientes contentorizados são muito limitados. As violações quase sempre estão relacionadas à criptografia, que são ataques graves, mas quem responde a incidentes em mim as considera desanimadoras. Outro ponto em comum é que eles são principalmente o resultado de uma configuração incorreta, seja no Kubernetes ou em uma conta na nuvem. A combinação dos motivos e das táticas não tem sido muito inspiradora até agora.

O Caminho Antigo

As vulnerabilidades de execução remota de código (RCE) têm sido a principal preocupação na segurança de computadores há muito tempo. Eles ainda estão, mas como essa forma de pensar se aplica aos contêineres? É fácil passar imediatamente para o RCE como a ameaça principal, mas não parece ser a maneira correta de abordar os contêineres. Por um lado, os contêineres costumam ter vida muito curta – 44% dos contêineres duram menos de cinco minutos – então um intruso teria que ser rápido.

Essa abordagem também pressupõe que o contêiner esteja exposto à Internet. Certamente alguns contêineres são configurados dessa forma, mas geralmente são muito simples e usam tecnologias bem testadas, como o NGINX. Pode haver zero-day para essas aplicações, mas elas seriam extremamente valiosas e difíceis de encontrar. Minha experiência me mostrou que muitos contêineres são usados ​​internamente e não se conectam diretamente à Internet. O cenário RCE fica muito mais difícil nesse caso. Eu deveria mencionar log4j, embora esses tipos de vulnerabilidades tenham o potencial de serem exploradas remotamente, mesmo que o sistema vulnerável não esteja no limite.

O novo caminho

Se o RCE não é a maior ameaça que os contêineres enfrentam, então o que é? Os contêineres estão no radar dos agentes de ameaças? Sim, os contêineres e sua infraestrutura de suporte são importantes demais para serem ignorados. O software de orquestração de contêineres permitiu que cargas de trabalho em contêineres fossem dimensionadas para números inimagináveis. A tendência de uso também está aumentando, então você pode ter certeza de que eles serão um alvo. Eles simplesmente não podem ser considerados servidores que você acessa por meio de vulnerabilidades RCE.

Em vez disso, o inverso é realmente verdadeiro. Em vez de atacar os contêineres de fora para dentro, eles precisam ser atacados de dentro para fora. Isto é essencialmente o que os ataques à cadeia de abastecimento fazem. A cadeia de suprimentos é um vetor de ataque extremamente eficaz contra contêineres quando você começa a entender como eles são construídos. Um contêiner começa com um arquivo de definição, como o Dockerfile, que define tudo o que estará no contêiner quando ele for executado. Uma vez construída, ela é transformada em uma imagem, e essa imagem é o que pode ser transformada em uma carga de trabalho inúmeras vezes. Se algo nesse arquivo de definição for comprometido, todas as cargas de trabalho executadas serão comprometidas.

Os contêineres são frequentemente, mas nem sempre, criados especificamente com um aplicativo que faz algo e sai. Esses aplicativos podem ser quase qualquer coisa — o importante a entender é o quanto é construído usando bibliotecas, sejam elas de código fechado ou de código aberto, escritas por outras pessoas. O GitHub tem milhões de projetos e esse não é o único repositório de código que existe. Como vimos com a SolarWinds, o código fechado também é vulnerável a ataques à cadeia de abastecimento.

Um ataque à cadeia de suprimentos é uma ótima maneira para os agentes da ameaça entrarem no ambiente de contêiner de um alvo. Eles podem até permitir que a infraestrutura do cliente dimensione o ataque se o comprometimento passar despercebido. Este tipo de cenário já está a acontecer, como vimos com o Violação do Codecov. Mas é difícil de detectar devido ao quão novo tudo isto é e como o nosso pensamento ainda está enraizado nos problemas do passado.

Como avançar

Tal como acontece com a solução da maioria dos problemas, a visibilidade geralmente é um ótimo ponto de partida. É difícil consertar o que você não pode ver. Para proteger seus contêineres, você precisa ter visibilidade dos próprios contêineres, bem como de todo o pipeline que os constrói. O gerenciamento de vulnerabilidades é um tipo de visibilidade que deve ser integrado ao pipeline de construção. Eu também incluiria outras ferramentas de análise estática, como aquelas que procuram segredos vazados. Como não é possível prever a aparência de um ataque à cadeia de suprimentos, o monitoramento do tempo de execução torna-se crítico para que você saiba exatamente o que seus contêineres estão fazendo.