GH Actions - Cache Poisoning
Para mais detalhes, confira o post original https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
A ação do Git action/cache introduz um mecanismo de cache no processo de Integração Contínua (CI), abrangendo duas etapas críticas:
Executar Ação: Esta etapa envolve a busca e recuperação de dados em cache durante a execução do CI. A busca utiliza uma chave de cache única, resultando em dois desfechos:
Cache-hit: Os dados solicitados são encontrados no cache e, consequentemente, recuperados para uso imediato.
Cache-miss: Nenhum dado correspondente é encontrado no cache, levando a um novo download dos arquivos e diretórios necessários, semelhante a uma solicitação pela primeira vez.
Ação Pós-Workflow: Esta etapa é dedicada ao cache de dados após o workflow do CI. Especificamente, se ocorrer um cache-miss durante a ação de execução, o estado atual dos diretórios especificados é armazenado em cache usando a chave fornecida. Este processo é automatizado e não requer invocação explícita.
Medidas de Segurança: Isolamento de Cache e Restrições de Acesso
Para manter a segurança e garantir o isolamento do cache, são aplicadas restrições de acesso, criando uma separação lógica entre diferentes branches. Por exemplo, um cache criado para a branch Feature-A (com base na branch principal) será inacessível para um pull request da branch Feature-B (também baseada na branch principal).
A ação de cache segue uma ordem de busca específica:
Primeiro, busca hits de cache dentro da mesma branch que a execução do workflow.
Se não for bem-sucedido, estende a busca para a branch pai e outras branches upstream.
Importante, o acesso ao cache é restrito por branch, estendendo-se a todos os workflows e execuções de uma branch específica. Além disso, o GitHub impõe uma política de somente leitura para as entradas de cache uma vez criadas, proibindo quaisquer modificações.
Implicação no Mundo Real: De um Ataque de Workflow de Baixa a Alta Permissão
Um cenário ilustrativo de CI demonstra como um atacante pode aproveitar o cache poisoning para escalar privilégios de um workflow de baixa permissão para um de alta permissão:
O workflow Unit-test, responsável por executar testes unitários e ferramentas de cobertura de código, presume-se que utilize uma ferramenta comprometida ou vulnerável. Este workflow utiliza a ação do Git action/cache, tornando o cache acessível a qualquer workflow.
O workflow Release, encarregado de construir e liberar o artefato da aplicação, otimiza suas operações armazenando em cache as dependências do Golang.
Neste cenário, o workflow de teste unitário introduz uma entrada de cache maliciosa substituindo uma biblioteca de logging legítima do Golang (`go
Last updated
