GH Actions - Cache Poisoning
Cache Poisoning
Usar a ação Git action/cache em qualquer lugar no CI executará dois passos: um passo ocorrerá durante o processo de execução quando for chamado e o outro ocorrerá após o workflow (se a ação de execução retornar um cache-miss).
Ação de execução – é usada para procurar e recuperar o cache. A busca é feita usando a chave de cache, com o resultado sendo um cache-hit (sucesso, dados encontrados no cache) ou cache-miss. Se encontrado, os arquivos e diretórios são recuperados do cache para uso ativo. Se o resultado for cache-miss, os arquivos e diretórios desejados são baixados como se fosse a primeira vez que são chamados.
Ação pós workflow – usada para salvar o cache. Se o resultado da chamada de cache na ação de execução retornar um cache-miss, essa ação salvará o estado atual dos diretórios que queremos armazenar em cache com a chave fornecida. Essa ação acontece automaticamente e não precisa ser explicitamente chamada.
Restrições de acesso fornecem isolamento de cache e segurança criando um limite lógico entre diferentes branches (por exemplo: um cache criado para a branch Feature-A [com a base principal] não seria acessível a um pull request para a branch Feature-B [com a base principal]).
A ação de cache primeiro procura por cache hits para uma chave e restaura chaves no branch que contém a execução do workflow. Se não houver hits no branch atual, a ação de cache procura pela chave e restaura chaves no branch pai e branches upstream.
O acesso a um cache é limitado por branch (atual e pai), significando que o acesso é fornecido a todos os workflows através das execuções do branch mencionado.
Outra nota importante é que o GitHub não permite modificações uma vez que as entradas são enviadas – entradas de cache são registros somente leitura.
Usamos um exemplo de CI que incluía dois workflows. Este exemplo mostra como um ataque pode pivotar de um workflow de baixa permissão para um de alta permissão.
Workflow de unit-test executando ferramentas de teste unitário e cobertura de código. Supomos que uma das ferramentas seja maliciosa ou vulnerável à execução remota de código. O workflow não precisa usar a ação Git action/cache. Qualquer workflow pode acessar o cache.
Workflow de release constrói e libera o artefato da aplicação. Este workflow usa um cache para otimizar o uso das dependências do Golang.
O workflow de unit-test usa uma ação maliciosa que adiciona uma entrada de cache com conteúdo malicioso alterando uma biblioteca de logging do Golang (go.uber.org/zap@v1) para adicionar a string 'BAD library' à descrição do artefato da aplicação.
Em seguida, o workflow de release usa essa entrada de cache envenenada. Como resultado, o código malicioso é injetado no binário Golang construído e na imagem. O cache permanece envenenado até que a chave de entrada seja descartada (geralmente acionada por atualizações de dependência). O mesmo cache envenenado afetará qualquer outro workflow, execução e branch filho que use a mesma chave de cache.
No teste que realizamos, conseguimos injetar a string 'BAD library' na descrição da imagem:
Isso foi na versão 0.4.1. Em seguida, atualizamos a tag e reconstruímos a imagem várias vezes, e observamos que 'Bad library' permaneceu na descrição.
Esta técnica foi retirada de https://scribesecurity.com/blog/github-cache-poisoning/
Última actualización
