O Docker Hub é o maior e mais popular registro de contêineres do mundo. Pense nele como uma biblioteca ou um repositório central na nuvem, muito parecido com o GitHub, mas focado em imagens Docker.
Uma imagem Docker é um “pacote” pronto que contém tudo o que um aplicativo precisa para funcionar: o código, as bibliotecas, as dependências e as configurações. Em vez de instalar cada um desses componentes separadamente, você usa a imagem, que já tem tudo empacotado.
Seu objetivo principal é facilitar o compartilhamento e a distribuição dessas imagens, funcionando como uma central onde desenvolvedores e empresas podem pesquisar e baixar imagens de sistemas operacionais, linguagens de programação etc, economizando tempo.
Desenvolvedores podem enviar (fazer “push”) suas próprias imagens para o Docker Hub, tanto para uso público quanto para repositórios privados. Isso é fundamental para equipes, pois garante que todos trabalhem com a mesma versão do software em seus ambientes de desenvolvimento, teste e produção.
O Docker Hub ajuda a manter o controle de versão das imagens, permitindo o uso de versões específicas (tags), voltando a versões anteriores se houver algum problema. Também as classifica em categorias - oficiais, verificadas, da comunidade - auxiliando na escolha das que são confiáveis.
Entendendo o texto no contexto
A “backdoor” do XZ Utils foi uma das vulnerabilidades mais sérias descobertas no ecossistema Linux. A seguir, uma explicação detalhada sobre o que foi esse ataque, como ele funcionou e suas consequências.
Também conhecida como “CVE-2024-3094”, foi inserida nas versões 5.6.0 e 5.6.1 da biblioteca de compressão de dados “XZ Utils”, um componente fundamental usado para comprimir e descomprimir arquivos.
O ataque foi um exemplo sofisticado e de longo prazo de “ataque de cadeia de suprimentos”, orquestrado por um indivíduo ou grupo que, durante dois anos, atuou sob o nome “Jia Tan”. Eles se tornaram um colaborador ativo e confiável no projeto XZ Utils.
Após ganhar a confiança da comunidade, Jia Tan injetou um código malicioso e ofuscado no código-fonte do XZ Utils, interceptando e modificando o comportamento do SSH (Secure Shell), protocolo para acesso remoto a servidores.
Quando o XZ Utils era usado num sistema com o OpenSSH, era ativado e permitia acesso remoto a pessoas mal intencionadas, contornando a segurança do SSH e ganhando acesso total ao servidor.
Como o XZ Utils é amplamente usado, a backdoor rapidamente se espalhou para as versões de teste e desenvolvimento de grandes distribuições Debian, Fedora, Arch Linux e OpenSUSE, mas não contaminou as estáveis, usadas em produção.
Sua descoberta foi quase acidental. Um engenheiro de software da Microsoft, Andres Freund, notou um comportamento estranho no uso da CPU em seu sistema Linux durante uma atualização. Após investigação minuciosa, encontrou o código malicioso.
A descoberta foi comunicada à comunidade em 29 de março de 2024, gerando um esforço imediato e global para reverter as alterações e remover as versões comprometidas dos repositórios.
Mas ninguém se banha no mesmo rio duas vezes…
Logo após a descoberta do backdoor, pesquisadores de segurança se uniram para entender a dimensão do ataque. Passado mais de um ano, novas descobertas mostram que a vulnerabilidade ainda está presente em lugares inesperados.
Pesquisadores da empresa de segurança “Binarly” encontraram 12 imagens oficiais do Debian contaminadas, disponíveis há mais de 15 meses. A maioria delas foi criada em 11 de março de 2024, quando o backdoor estava ativo. As imagens afetadas incluem diferentes versões do Debian, como unstable, testing e trixie.
A empresa também identificou outras 35 imagens construídas com base nas comprometidas, tornando o problema ainda maior. Como ela só investigou os contêineres do Debian, o mesmo problema pode existir nos de outras distribuições.
A Binarly alertou os mantenedores do Debian sobre as imagens infectadas e pediu a sua remoção. A equipe do Debian, no entanto, recusou o pedido, alegando que os contêineres são muito antigos e não representam um perigo real.
O Debian argumenta que as imagens comprometidas eram apenas versões de desenvolvimento e não deveriam ser usadas em sistemas de produção. Eles acreditam que os usuários devem sempre utilizar as versões mais recentes e seguras dos contêineres.
Embora a empresa concorde em parte com o Debian, ainda alerta para os riscos em se manter imagens vulneráveis no repositório, demonstrando como ataques na cadeia de suprimentos podem persistir em sistemas de contêineres por mais tempo do que o esperado.