O que há no container? Análise de vulnerabilidades, riscos e proteção com o Kaspersky Container Security e o assistente de IA KIRA

Introdução

A conteinerização usando o Docker se tornou firmemente estabelecida nos padrões modernos de desenvolvimento, aumentando significativamente a velocidade e a conveniência da implementação de vários serviços. Os desenvolvedores geralmente usam imagens do Docker prontas, fazendo apenas alterações mínimas. O maior repositório de imagens de container é o serviço Docker Hub.

A infraestrutura hospedada em container é um alvo atraente para os invasores. No mínimo, um container comprometido pode ser usado em ataques DDoS, para mineração de criptomoedas ou como proxy de tráfego. A lista de ameaças não termina aí: assim que um invasor obtém o controle de um container, ele pode roubar ou destruir dados diretamente dele, acessar containeres vizinhos ou até mesmo tentar escapar do container, comprometendo toda a rede corporativa.

Ao mesmo tempo, a infraestrutura dentro dos contêineres costuma ser atualizada com menos frequência e pode conter versões de software desatualizadas e vulneráveis. Ao implementar imagens de terceiros ou modificá-las para um ambiente específico, é fácil cometer erros de configuração que podem ser explorados pelos invasores. Devido às características arquitetônicas dos containeres, os desenvolvedores geralmente enfrentam restrições ao preparar imagens; para superá-las, podem recorrer a soluções inseguras encontradas na Internet.

Em outras palavras, a infraestrutura em container pode ser tanto o alvo mais simples quanto o mais lucrativo de explorar. Portanto, sua segurança requer atenção redobrada. Para minimizar o risco de ataques bem-sucedidos à infraestrutura de containeres, é essencial verificar as imagens finais do Docker, incluindo todas as camadas subjacentes, quanto a vulnerabilidades e erros de configuração. A maneira mais fácil de fazer isso é analisando o Dockerfile; no entanto, sua inspeção nem sempre é possível. Além disso, ele normalmente define como criar camadas sobre uma imagem base de um repositório externo, cuja confiabilidade não pode ser garantida.

Resultados da análise de imagem no Kaspersky Container Security

Para ajudar os usuários a identificar configurações inseguras e possíveis vulnerabilidades associadas a elas, adicionamos nosso assistente de IA ao Kaspersky Container Security. O KIRA (o nome do assistente) usa inteligência artificial para analisar a imagem e identificar possíveis problemas e fornecer recomendações sobre como corrigi-los.

Como parte desse estudo, solicitamos ao KIRA que analisasse várias imagens populares da comunidade e, mais adiante neste artigo, mostraremos os resultados.

Vulnerabilidades de software e comprometimento de fontes de atualização

Um dos principais problemas de segurança ao usar imagens pré-criadas é que elas não são atualizadas em tempo hábil pelos desenvolvedores. Uma imagem do Docker é, por sua própria natureza, um instantâneo de uma distribuição Linux específica depois que pacotes foram instalados nela. No entanto, na maioria dos casos, ela não recebe atualizações de segurança por conta própria, ao contrário dos servidores Linux tradicionais, em que essas atualizações são instaladas automaticamente por serviços especializados, como unattended-upgrades em distribuições baseadas em Debian e dnf-automatic em distribuições baseadas em RedHat.

Para aplicar atualizações a uma imagem do Docker, ela deve ser reconstruída e reimplementada. Muitas vezes, esse processo não é automatizado e algumas atualizações exigem esforço adicional para verificar se funcionam corretamente, modificar configurações ao atualizar para novas versões de software e assim por diante. Como resultado, muitas imagens populares não recebem atualizações oportunas, o que aumenta bastante os riscos associados ao seu uso.

Uma imagem que estava segura no momento da criação acumula vulnerabilidades à medida que são descobertas nos pacotes instalados nela, o que, com o tempo, aumenta significativamente as chances de um ataque bem-sucedido ao container.

Versões vulneráveis de aplicações da Web e serviços de rede acessíveis pela Internet acabam se tornando alvos de várias campanhas maliciosas. Por exemplo, apenas um dia após a descoberta da vulnerabilidade CVE-2025-55182 nos componentes do servidor React, nossos honeypots registraram várias tentativas de ataque relacionadas a essa vulnerabilidade. Ela foi utilizada por operadores de muitas campanhas maliciosas, desde mineradores de criptomoedas clássicos até variantes do Mirai e do Gafgyt. Os invasores estão sempre adicionando novos métodos de disseminação e podem usar dezenas de exploits que exploram várias vulnerabilidades e erros de configuração em serviços populares. Muitas vezes, as mesmas vulnerabilidades são usadas em mecanismos de autopropagação de hosts já comprometidos. Por exemplo, em uma campanha maliciosa para espalhar o minerador Dero, os invasores usam containeres infectados para procurar e infectar novos alvos automaticamente.

Além das vulnerabilidades que podem ser exploradas de forma remota, os invasores estão rapidamente adicionando vulnerabilidades locais ao seu arsenal, usando-as para obter privilégios de root e escapar do container: na campanha de malware Kinsing, os invasores usaram a CVE-2023-4911 (Looney Tunables) para elevar privilégios, e na campanha perfctl, a vulnerabilidade CVE-2021-4034 (PwnKit) foi usada para a mesma finalidade. O acesso obtido foi usado para instalar um rootkit que oculta a presença de perfctl no sistema.

Para avaliar a situação das vulnerabilidades não corrigidas em containeres, coletamos uma amostra aleatória de 100 imagens, que incluíam várias soluções populares com de 10.000 a 1 milhão de downloads no DockerHub. Nas 64 imagens que verificamos, encontramos versões de software desatualizadas com vulnerabilidades críticas. Por exemplo, algumas imagens continham a vulnerabilidade CVE-2025-49844 no servidor Redis, levando ao RCE ao explorar uma vulnerabilidade no analisador Lua; a vulnerabilidade CVE-2026-24061 atual no nginx, que em algumas configurações leva à falha do processo do servidor e, com o ASLR desativado, novamente, ao RCE; as vulnerabilidades CVE-2025-32463 no sudo e CVE-2023-4911 na glibc, permitindo que um invasor obtenha privilégios de root com acesso local. Além disso, apenas uma em cada dez imagens do Docker da amostra analisada está totalmente atualizada.

As 10 principais vulnerabilidades críticas com PoCs/exploits disponíveis, conforme mostrado no painel do Kaspersky Container Security

É importante observar que nem todas as vulnerabilidades descobertas podem ser exploradas diretamente pelos invasores. Um risco prático surge quando o aplicativo ou a biblioteca vulnerável está realmente em uso e são atendidas as condições necessárias para a exploração, que variam bastante conforme a vulnerabilidade. No entanto, as atualizações não devem ser ignoradas, pois o risco de exploração de vulnerabilidades, tanto individualmente quanto em várias combinações, não pode ser previsto em cada caso específico, e mesmo vulnerabilidades que parecem inofensivas à primeira vista podem representar um sério risco de comprometimento.

Um número recorde de vulnerabilidades em uma única imagem

No entanto, as atualizações frequentes têm uma desvantagem. Cada reconstrução que baixa novos pacotes de repositórios de origem apresenta um risco adicional de ataque à cadeia de suprimentos: uma dependência comprometida ou uma imagem de base modificada podem injetar silenciosamente código malicioso no seu ambiente justamente por meio de uma atualização. Durante a análise das imagens da amostra, não encontramos nenhum sinal de ataques à cadeia de suprimentos. Porém, em março de 2026, ocorreu um incidente de cadeia de suprimentos nos projetos Trivy e LiteLLM. No caso do Trivy, o arquivo infectado foi injetado diretamente na imagem do container nos repositórios oficiais.

Detecção de software potencialmente malicioso usando uma das imagens como exemplo

Isso leva a um impasse: atualizações pouco frequentes deixam vulnerabilidades conhecidas sem correção na imagem, enquanto atualizações frequentes aumentam o risco de comprometimento da cadeia de suprimentos. Portanto, para proteger sua infraestrutura, é preciso não apenas atualizar regularmente as imagens de base, mas também adotar uma abordagem mais abrangente, especificamente fixando as dependências em versões reconhecidamente seguras e verificando as imagens resultantes quanto a malware após a atualização.

Vulnerabilidades de configuração

Até mesmo um container com uma imagem totalmente atualizada pode ser comprometido se for configurado de forma incorreta. Incorporar chaves e segredos na imagem, desativar a autenticação em serviços de rede, usar senhas padrão e definir permissões inseguras de acesso a arquivos: tudo isso pode ser explorado pelos invasores de uma forma ou de outra para atingir seus objetivos.

Configurações de imagem inseguras detectadas pelo KCS com base em regras

A situação é agravada pelo fato de que erros podem ser introduzidos pelos autores da imagem original, o que torna sua detecção mais difícil, pois isso requer a análise de cada camada e do comando que a gerou. Assim como acontece com as vulnerabilidades, nem todo erro de configuração leva a um comprometimento: tudo depende da função do container, de sua acessibilidade pela rede e de muitos outros fatores. Mas o próprio uso de configurações inseguras, mais cedo ou mais tarde, fará com que surjam erros nas imagens, cujas consequências serão significativamente mais perigosas.

As regras padrão costumam ser insuficientes para analisar configurações problemáticas. Para compreender melhor o contexto e avaliar os riscos potenciais, pode-se usar ferramentas de IA. Mais adiante nesta seção, examinaremos exemplos de configurações inseguras comuns que descobrimos ao analisar imagens públicas do Docker Hub, juntamente com as descrições dos problemas e os métodos de mitigação de riscos fornecidos pelo assistente de IA KIRA.

Exemplo de análise de container usando o KIRA

Tratamento inseguro de credenciais

Uso de senhas padrão

Em alguns casos, os containeres podem usar senhas padrão definidas por meio de variáveis de ambiente ou diretamente no Dockerfile. Se essas senhas não forem substituídas, os invasores poderão acessar o aplicativo usando a senha padrão.

De acordo com a análise do KIRA, a senha do usuário é armazenada em texto simples no histórico de camadas da imagem. Qualquer pessoa que obtenha acesso à imagem, seja por meio de um registro público, um ambiente de build comprometido ou outros meios, poderá extrair a senha. Se o SSH ou outra forma de acesso interativo estiver ativado no container, isso poderá levar ao comprometimento completo e permitir que os invasores se movam lateralmente dentro da infraestrutura.

As senhas podem estar presentes nas variáveis de ambiente. Considere o seguinte snippet do Dockerfile:

Neste exemplo, a variável de ambiente PKP_DB_PASSWORD está definida como changeMePlease. Se o usuário esquecer de alterá-la, o aplicativo usará a senha que pode ser obtida do Dockerfile.

Vejamos outra imagem:

Para esta imagem, o Dockerfile especifica que a senha do administrador está gravada diretamente na diretiva ENV e permanece nos metadados da imagem (histórico de camadas, docker inspect). Qualquer pessoa que obtenha acesso à imagem (registro, cache de build) poderá extrair esse segredo e comprometer a conta.

Para eliminar esses riscos, certifique-se de que nenhuma senha seja especificada no Dockerfile. Se a autenticação for necessária, você poderá usar mecanismos do orquestrador (segredos) ou gerar uma senha temporária ao iniciar o container por meio do script de ponto de entrada, sem salvá-la nas camadas. Também recomendamos usar mecanismos para transmitir segredos com segurança durante a execução (segredos do Docker, segredos do Kubernetes) ou, como último recurso, transmiti-los por meio do --secret durante a compilação com o BuildKit, mas, sob nenhuma circunstância, eles devem ser deixados na imagem final.

Transmissão de senhas por meio de argumentos de comando

Em alguns casos, as senhas podem ser expostas ao serem transmitidas por meio de argumentos de linha de comando, pois eles são visíveis para todos os usuários no sistema:

No exemplo fornecido, a senha de superusuário do MySQL é transmitida para o comando healthcheck em texto simples, tornando-a visível ao visualizar a lista de processos (ps aux), em logs de auditoria e em sistemas de monitoramento. Se um invasor obtiver acesso de leitura aos processos ou logs do container, ele poderá extrair a senha e obter o controle total do banco de dados.

Para corrigir esse problema, a healthcheck deve usar uma conexão local por meio de um socket Unix com autenticação padrão (se o plug-in auth_socket estiver configurado para root) ou criar um usuário dedicado com privilégios mínimos (por exemplo, somente USAGE), sem uma senha ou com uma senha transmitida por um arquivo seguro (--defaults-file com permissões restritas). Você também pode usar a variável de ambiente MYSQL_PWD para autenticação da verificação de integridade, mas ela permanecerá visível em /proc.

Escalonamento de privilégios no container

Um dos vetores mais comuns para o comprometimento inicial de sistemas Linux é o RCE (execução remota de código) em aplicações da Web e serviços de rede. Normalmente, esses serviços têm privilégios mínimos, o que dificulta as ações subsequentes dos invasores, como fazer dump de credenciais, cobrir rastros, tentar escapar do container, entre outras.

A situação piora bastante se um invasor obtiver privilégios de root, pois isso permite que ele controle todos os processos no container, oculte sua atividade e use métodos para escapar do container. Por exemplo, eles podem comprometer o host se o container for privilegiado, um socket do Docker estiver montado dentro dele ou existirem outras configurações inseguras e vulnerabilidades que não podem ser exploradas com privilégios de um usuário comum.

Da mesma forma, isso facilita ataques de rede contra containeres vizinhos, o orquestrador e vários serviços internos, tornando esse erro de configuração um possível elo na cadeia de comprometimento de toda a rede.

Ataques ao sudo

Um dos métodos mais simples de escalonamento de privilégios é executar comandos arbitrários como root usando sudo sem inserir uma senha. Considere o seguinte exemplo:

A análise dessa configuração usando o KIRA destaca imediatamente o problema principal: ao instalar o pacote sudo e definir NOPASSWD: ALL para o usuário solr, o usuário viola gravemente o princípio do privilégio mínimo. A plataforma Solr não requer privilégios tão amplos para ser executada em um container; na verdade, esses privilégios facilitam o escalonamento para root.

Em outro exemplo de uma configuração insegura, os privilégios NOPASSWD:ALL são concedidos a um usuário do banco de dados PostgreSQL, o que representa um enfraquecimento direto e grave da política de controle de acesso. Se um invasor conseguir executar código em nome do usuário postgres, por meio de uma vulnerabilidade em um serviço de rede, uma injeção de SQL ou do comprometimento de um dos processos, ele será capaz de executar qualquer comando imediatamente e sem restrições em nome do usuário root. Isso significa que todo o container será executado como root.

Para reduzir o risco, recomendamos remover essa diretiva. Os comandos necessários que exigem privilégios devem ser delegados caso a caso por meio do sudoers, com especificação explícita dos executáveis e parâmetros permitidos, usando NOPASSWD somente como último recurso e para utilitários específicos.

Nosso assistente de IA KIRA pode identificar configurações inseguras ainda mais complexas, como permitir o uso do sudo sem senha por todo o grupo sudo, modificando as regras existentes.

O risco neste exemplo é que o comando substitui as declarações padrão que exigem autenticação pela execução sem senha de todos os comandos para qualquer usuário que pertença ao grupo sudo, podendo incluir o postgres, caso seja atribuído a esse grupo. Isso expande a superfície de ataque para todos os membros do grupo, transformando cada um deles em um possível ponto de escalonamento instantâneo de privilégios.

Para reduzir os riscos, recomendamos não modificar a política global do sudoers, manter o requisito de senha padrão ou usar um mecanismo de escalonamento mais seguro, como o gosu, para executar um processo específico em nome de outro usuário sem conceder privilégios permanentes.

Permissões de arquivo inseguras

Outro vetor comum para o escalonamento de privilégios é o uso de permissões de arquivos e diretórios configurados de forma insegura. Na maioria das vezes, por conveniência, os autores de imagens de container usam permissões 777, que permitem que qualquer pessoa, incluindo usuários sem privilégios, crie e exclua arquivos livremente, além de modificar seu conteúdo. Isso pode levar tanto ao escalonamento de privilégios quanto à possibilidade de um invasor sem privilégios excluir ou modificar logs, entre outras consequências indesejáveis.

Considere o seguinte comando:

O risco é que os diretórios que contêm arquivos binários e scripts se tornem graváveis por qualquer usuário do container. Isso permite que um invasor com poucos privilégios substitua os utilitários incluídos no cargo ou adicione novos executáveis maliciosos. Quando essas ferramentas são posteriormente invocadas, especialmente como usuário root ou por meio do sudo, o código do invasor será executado com os privilégios herdados do processo de chamada, levando diretamente a um escalonamento de privilégios local.

Para reduzir os riscos, você pode definir as permissões mínimas necessárias: chmod 0755 para diretórios e chmod 0755/0644 para os arquivos correspondentes. O proprietário deve ser root, e somente ele deve ter permissão de escrita. Não use chmod 777 em nenhum caminho do sistema.

Ausência de verificações de integridade

Baixar software sem verificar sua integridade pode deixar a infraestrutura vulnerável à adulteração de software.

Por exemplo, esse risco pode surgir ao baixar uma distribuição por meio de HTTP:

Usar HTTP sem verificar a integridade do arquivo comprimido cria condições para um ataque man-in-the-middle durante a fase de criação da imagem. Um invasor que controla o canal de comunicação ou o DNS pode substituir o arquivo comprimido por conteúdo malicioso, o que pode comprometer o container e todo o ambiente em que ele é executado.

Para reduzir os riscos, você pode configurar conexões a recursos da Web para usarem somente HTTPS, se o recurso for compatível com esse protocolo. Você também pode baixar o arquivo comprimido sem extraí-lo, comparar sua soma de verificação (SHA256) com a soma de verificação de uma fonte confiável e somente então extraí-lo. É aconselhável armazenar o arquivo comprimido verificado em um repositório interno de artefatos para evitar downloads diretos da rede.

Ainda assim, poderá ocorrer um ataque MitM mesmo se a verificação do certificado estiver desativada:

A ausência da verificação do certificado TLS permite que um invasor que controle o segmento de rede substitua o arquivo comprimido ZIP baixado por conteúdo malicioso. Como o arquivo comprimido contém código PHP que será executado pelo servidor Web, o comprometimento durante a fase de criação resultará na implementação de um backdoor ou em vazamento de dados.

Para reduzir os riscos, remova a flag --no-check-certificate; após o download, calcule o hash SHA256 do arquivo comprimido e verifique-o em relação a um valor de referência conhecido (a página da versão ou um repositório local de hashes confiáveis). Além disso, considere usar uma versão fixa (tag) em vez do branch 7.2-dev, que é flutuante.

Conclusão

Os containeres do Docker se tornaram um meio muito popular de implementação de software, e os invasores não ignoram essa tendência. Eles estão adicionando vulnerabilidades de software e erros de configuração ao seu arsenal e realizando ataques às cadeias de suprimentos. Eles podem comprometer a infraestrutura de container para uma ampla variedade de finalidades, desde a mineração de criptomoedas até a criptografia de dados para exigir um resgate ou o roubo de informações críticas para a empresa.

Nossa pesquisa descobriu que 64 em cada 100 imagens de container para aplicações populares contêm software com vulnerabilidades críticas e apenas 10% estão totalmente atualizadas. Também identificamos várias configurações inseguras, incluindo senhas armazenadas em texto simples nos Dockerfiles e privilégios excessivos concedidos a usuários e processos.

Para detectar e prevenir essas ameaças, é essencial seguir as medidas de segurança à risca: auditar as configurações de imagens, gerenciar com segurança os segredos usados em imagens, aplicar atualizações de segurança em tempo hábil, verificar o conteúdo das imagens quanto a malware a cada atualização e seguir as melhores práticas do setor para aumentar a segurança.

Essa abordagem requer soluções especializadas desenvolvidas para atender às características específicas dos ambientes de container. O Kaspersky Container Security garante a segurança de aplicações em container em todos os estágios do seu ciclo de vida, desde o desenvolvimento até a operação. O produto protege os processos de negócios de uma organização, ajuda a garantir a conformidade com os padrões do setor e os regulamentos de segurança e permite a implementação de práticas seguras de desenvolvimento de software.