A empresa Google apresentou o framework SLSA (Supply-chain Levels for Software Artifacts), que reúne a experiência existente na proteção da infraestrutura de desenvolvimento contra ataques que ocorrem nas etapas de escrita de código, teste, compilação e distribuição do produto.
Os processos de desenvolvimento estão se tornando cada vez mais complexos e dependentes de ferramentas externas, criando condições favoráveis para o avanço de ataques que não se concentram na identificação e exploração de vulnerabilidades no produto final, mas sim na comprometimento do próprio processo de desenvolvimento (ataques de 'supply chain', geralmente direcionados a implementar alterações maliciosas no processo de escrita de código, substituir componentes e dependências distribuídas).
O framework considera 8 tipos de ataques relacionados a ameaças de inserção de alterações maliciosas na fase de desenvolvimento de código, compilação, teste e distribuição do produto.
- A. Inclusão no código-fonte de alterações que contêm backdoors ou erros ocultos que levam a vulnerabilidades.
Exemplo de ataque: 'Hypocrite Commits' — tentativa de promover patches com vulnerabilidades no núcleo do Linux.
Método de proteção proposto: revisão independente de cada alteração por dois desenvolvedores.
- B. Comprometimento da plataforma de gerenciamento de código-fonte.
Exemplo de ataque: inserção de commits maliciosos com backdoor no repositório Git do projeto PHP após vazamento de senhas dos desenvolvedores.
Método de proteção proposto: aumentar a segurança da plataforma de gerenciamento de código (no caso do PHP, o ataque foi realizado através de uma interface HTTPS pouco utilizada, que permitia enviar alterações ao fazer login com senha sem verificação de chave SSH, sendo que um método de hash de senhas pouco confiável, o MD5, foi utilizado).
- C. Fazer alterações na etapa de transferência de código para o sistema de compilação ou integração contínua (código que não corresponde ao repositório está sendo compilado).
Exemplo de ataque: injeção de um backdoor no Webmin alterando a infraestrutura de compilação, levando ao uso de arquivos de código diferentes dos arquivos no repositório.
Método de proteção proposto: verificação de integridade e identificação da fonte de recebimento do código no sistema de compilação. servidor.
- D. Comprometimento da plataforma de compilação.
Exemplo de ataque: ataque SolarWinds, onde durante a fase de compilação foi possibilitada a inserção de um backdoor no produto SolarWinds Orion.
Método de proteção sugerido: implementação de medidas de segurança avançadas na plataforma de montagem.
- E. Promoção de código malicioso através de dependências de baixa qualidade.
Exemplo de ataque: injeção de um backdoor em uma biblioteca popular chamada event-stream, através da adição de uma dependência inofensiva, que posteriormente incluía código malicioso em uma das atualizações dessa dependência (a alteração maliciosa não foi refletida no repositório git, mas estava presente apenas no pacote MNP final).
Método de proteção sugerido: aplicação recursiva dos requisitos SLSA a todas as dependências (no caso de event-stream, a verificação teria revelado a construção de código que não correspondia ao conteúdo do repositório Git principal).
- F. Carregamento de artefatos que não foram criados no sistema CI/CD.
Exemplo de ataque: adição de código malicioso no script CodeCov, permitindo que atacantes extraíssem informações armazenadas nos ambientes dos sistemas de integração contínua dos clientes.
Método de proteção sugerido: controle da fonte e integridade dos artefatos (no caso do CodeCov, poderia ter sido identificado que o script Bash Uploader fornecido pelo site codecov.io não correspondia ao código do repositório do projeto).
- G. Comprometimento do repositório de pacotes.
Exemplo de ataque: pesquisadores conseguiram implantar espelhos de alguns repositórios de pacotes populares com o objetivo de disseminar pacotes maliciosos através deles.
Método de proteção sugerido: Verificação de que os artefatos distribuídos foram construídos a partir dos fontes declarados.
- H. Confusão do usuário para instalar o pacote errado.
Exemplo de ataque: utilização de typosquatting (NPM, RubyGems, PyPI) para listar repositórios de pacotes semelhantes a aplicativos populares (por exemplo, coffe-script ao invés de coffee-script).
Para bloquear as ameaças identificadas, o SLSA propõe um conjunto de recomendações, bem como ferramentas para automação da criação de metadados para auditoria. O SLSA generaliza métodos de ataque padrão e introduz o conceito de níveis de proteção. Cada nível impõe requisitos específicos à infraestrutura, permitindo garantir a integridade dos artefatos utilizados no desenvolvimento. Quanto maior o nível de SLSA suportado, mais medidas de proteção estão implementadas e melhor a infraestrutura está protegida contra ataques comuns.
- SLSA 1 — exige que o processo de construção seja totalmente automatizado e gere metadados (‘proveniência’) sobre como os artefatos são coletados, incluindo informações sobre os textos originais, dependências e o processo de construção (para GitHub Actions, um exemplo de gerador de metadados para auditoria foi proposto). O SLSA 1 não inclui elementos de proteção contra alterações maliciosas, mas identifica de forma simples o código e fornece metadados para gerenciar vulnerabilidades e análise de riscos.
- SLSA 2 — expande o primeiro nível com a exigência de uso de sistemas de controle de versão e serviços de construção que geram metadados autenticados. A aplicação do SLSA 2 permite rastrear a proveniência do código e evita alterações não autorizadas no código, caso serviços de construção confiáveis sejam utilizados.
- SLSA 3 — confirma que os textos originais e a plataforma de construção atendem aos requisitos dos padrões que garantem a possibilidade de auditoria do código e a integridade dos metadados fornecidos. Supõe-se que auditores possam certificar plataformas em conformidade com os requisitos dos padrões.
- SLSA 4 — o nível mais alto, complementando os níveis anteriores com os seguintes requisitos:
- Revisão obrigatória de todas as alterações por dois desenvolvedores diferentes.
- Todos os passos de construção, código e dependências devem ser completamente declarados, todas as dependências devem ser extraídas e verificadas separadamente, e o processo de construção deve ser realizado sem acesso à rede.
- A aplicação do processo de construção repetível — a possibilidade de repetir o processo de construção por conta própria e garantir que o arquivo executável seja construído a partir dos textos originais fornecidos.
Fonte: opennet.ru
