0 
0 Como os agentes de ameaças atacarão e utilizarão os contêineres? Essa é uma pergunta que penso constantemente. Trabalho nessa á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 segurança no mundo “legado”. Os contêineres não têm realmente um analógico. Claro, as máquinas virtuais (VMs) geralmente são confundidas com contêineres, mas nunca foram capazes de escalar como contêineres. Eles também são usados para propósitos completamente diferentes dos contêineres. Demorou 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 conteinerizados são muito limitados. As violações quase sempre estão relacionadas à criptomineração, que são ataques sérios, mas o que responde a incidentes em mim as considera decepcionantes. Outra semelhança é 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 foi muito inspiradora até agora.
A Velha Maneira
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 são, mas como essa maneira de pensar se aplica aos contêineres? É fácil pular imediatamente para o RCE como a principal ameaça, mas não parece ser a maneira correta de abordar os contêineres. Por um lado, os contêineres geralmente duram muito pouco – 44% dos contêineres vivem 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 maneira, mas geralmente são muito simples e usam tecnologias bem testadas, como NGINX. Pode haver zero dias para esses aplicativos, mas eles seriam extremamente valiosos 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. Devo mencionar o Log4j , embora esses tipos de vulnerabilidades tenham o potencial de serem explorados remotamente, mesmo que o sistema vulnerável não esteja no limite.
O Novo Caminho
Se o RCE não é a maior ameaça enfrentada pelos contêineres, 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 muito importantes 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 que eles serão um alvo. Eles simplesmente não podem ser considerados como 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. Isso é essencialmente o que os ataques da cadeia de suprimentos 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 Dockerfile, que define tudo o que estará no contêiner quando ele for executado. Ele é transformado em uma imagem uma vez construído, e essa imagem é o que pode ser transformado em uma carga de trabalho inúmeras vezes. Se alguma coisa nesse arquivo de definição for comprometida, todas as cargas de trabalho executadas serão comprometidas.
Os contêineres geralmente, mas nem sempre, são criados especificamente com um aplicativo que faz algo e sai. Esses aplicativos podem ser quase qualquer coisa – o importante é entender o quanto é construído usando bibliotecas, sejam 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 disponível. Como vimos com a SolarWinds, o código fechado também é vulnerável a ataques à cadeia de suprimentos.
Um ataque à cadeia de suprimentos é uma ótima maneira de os agentes de ameaças entrarem no ambiente de contêiner de um alvo. Eles podem até permitir que a infraestrutura do cliente dimensione seu ataque para eles se o comprometimento passar despercebido. Esse tipo de cenário já está se desenrolando, como vimos com a violação do Codecov . Mas é difícil de detectar devido ao quão novo tudo isso é e como nosso pensamento ainda está enraizado nos problemas do passado.
Um caminho a seguir
Assim como na correçã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 compilação. Eu também incluiria outras ferramentas de análise estática, como aquelas que procuram segredos vazados para isso também. Como a aparência de um ataque à cadeia de suprimentos não pode ser prevista, o monitoramento do tempo de execução se torna fundamental para que você saiba exatamente o que seus contêineres estão fazendo.
FONTE: DARK READING