🔥 Fique por dentro das novidades mais quentes do momento! 🔥
A notícia que você procurava está aqui!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Pesquisadores de segurança cibernética da Wiz divulgaram uma nova vulnerabilidade de injeção de fluxo de trabalho do GitHub Actions no repositório público snowflakedb/snowflake-connector-net do Snowflake que, segundo eles, poderia ser explorada por meio de um problema criado no GitHub para executar comandos em um fluxo de trabalho contendo credenciais internas do Jira.
O problema estava presente em .github/workflows/jira_issue.yml, que foi executado quando um problema público foi aberto e expôs JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN à mesma etapa do fluxo de trabalho. A fraqueza estava confinada à automação de CI/CD do repositório, sem identificação de nenhuma versão afetada do Snowflake Connector para .NET.
O fluxo de trabalho inseriu o título do problema controlado pelo invasor e os valores do corpo diretamente em um bloco run: do shell. Ele também verificou github.event.pull_request.user.login mesmo que o evento fosse um problema, o que significa que a propriedade de pull request referenciada não existia.
O GitHub diz: "Se você tentar desreferenciar uma propriedade inexistente, ela será avaliada como uma string vazia." Nesse caso, a comparação com whitesource-for-github-com[bot] não impediu que um problema comum chegasse ao trabalho.
Wiz disse que seu sistema Red Agent explorou a injeção durante testes de segurança autorizados depois que a primeira carga resultou em um erro de sintaxe do shell e o sistema mudou sua abordagem. Os pesquisadores disseram que posteriormente receberam um retorno de chamada fora de banda do executor GitHub Actions e obtiveram o token da API Jira usado pelo fluxo de trabalho.
O token, de acordo com Wiz, pertencia a qa@snowflake.net e permitia acesso de leitura aos projetos do Jira que cobriam engenharia, conformidade de segurança e rastreamento de recompensas de bugs em snowflakecomputing.atlassian.net. As permissões subjacentes do JIRA, a execução do fluxo de trabalho e os registros de auditoria não são públicos.
Wiz disse que relatou o problema ao Snowflake por meio do HackerOne em 23 de junho de 2026, sob o relatório #3819931. O Snowflake mesclou uma correção naquele dia na solicitação pull nº 1402, substituindo a expansão direta da expressão do GitHub por variáveis de ambiente que são passadas para o jq como argumentos.
O fluxo de trabalho vulnerável atingiu a ramificação padrão cinco dias antes, em 18 de junho, quando a solicitação pull nº 1218 foi mesclada. O tratamento corrigido permanece na ramificação mestre do repositório.
Snowflake disse em comunicado reproduzido por Wiz que “nossa investigação não encontrou nenhuma evidência de acesso não autorizado”. Wiz disse que o token Jira foi alternado em 24 de junho e que a análise do Snowflake não encontrou nenhum uso externo não relacionado dele durante a janela de exposição de cinco dias. Os registros de auditoria subjacentes do Snowflake não foram tornados públicos.
Wiz descreveu a falha como resultante de uma alteração do GitHub Copilot Autofix, embora o histórico subjacente do GitHub não estabeleça o Copilot como o autor do código jira_issue.yml vulnerável. O commit explícito de coautoria do Copilot, 6d0e2fa, alterou jira_close.yml, enquanto o refatorador inseguro jira_issue.yml aparece em um commit separado de 25 de agosto de 2025, 094038e, atribuído pelo GitHub a sfc-gh-hpathak.
Ambas as mudanças foram posteriormente incorporadas ao commit de squash merge 4a1b8ce de 18 de junho, que lista o Copilot Autofix entre seus coautores. O histórico de commits, portanto, confirma a participação do Copilot na solicitação pull nº 1218, mas não a autoria das linhas vulneráveis.
O GitHub documentou essa classe de injeção de fluxo de trabalho em julho de 2025, alertando contra a expansão de dados de problemas não confiáveis diretamente dentro dos blocos run: e recomendando o uso de variáveis de ambiente intermediárias.
Em 17 de agosto de 2026, nenhuma entrada de catálogo CVE, pontuação CVSS ou vulnerabilidades conhecidas exploradas (KEV) CISA foi localizada para o problema, e nenhuma atualização de versão do conector vinculada a ele foi identificada. A interpolação vulnerável não está mais presente no master, e o material primário disponível não estabelece exploração maliciosa em estado selvagem ou comprometimento do cliente.
O problema estava presente em .github/workflows/jira_issue.yml, que foi executado quando um problema público foi aberto e expôs JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN à mesma etapa do fluxo de trabalho. A fraqueza estava confinada à automação de CI/CD do repositório, sem identificação de nenhuma versão afetada do Snowflake Connector para .NET.
O fluxo de trabalho inseriu o título do problema controlado pelo invasor e os valores do corpo diretamente em um bloco run: do shell. Ele também verificou github.event.pull_request.user.login mesmo que o evento fosse um problema, o que significa que a propriedade de pull request referenciada não existia.
O GitHub diz: "Se você tentar desreferenciar uma propriedade inexistente, ela será avaliada como uma string vazia." Nesse caso, a comparação com whitesource-for-github-com[bot] não impediu que um problema comum chegasse ao trabalho.
Wiz disse que seu sistema Red Agent explorou a injeção durante testes de segurança autorizados depois que a primeira carga resultou em um erro de sintaxe do shell e o sistema mudou sua abordagem. Os pesquisadores disseram que posteriormente receberam um retorno de chamada fora de banda do executor GitHub Actions e obtiveram o token da API Jira usado pelo fluxo de trabalho.
O token, de acordo com Wiz, pertencia a qa@snowflake.net e permitia acesso de leitura aos projetos do Jira que cobriam engenharia, conformidade de segurança e rastreamento de recompensas de bugs em snowflakecomputing.atlassian.net. As permissões subjacentes do JIRA, a execução do fluxo de trabalho e os registros de auditoria não são públicos.
Wiz disse que relatou o problema ao Snowflake por meio do HackerOne em 23 de junho de 2026, sob o relatório #3819931. O Snowflake mesclou uma correção naquele dia na solicitação pull nº 1402, substituindo a expansão direta da expressão do GitHub por variáveis de ambiente que são passadas para o jq como argumentos.
O fluxo de trabalho vulnerável atingiu a ramificação padrão cinco dias antes, em 18 de junho, quando a solicitação pull nº 1218 foi mesclada. O tratamento corrigido permanece na ramificação mestre do repositório.
Snowflake disse em comunicado reproduzido por Wiz que “nossa investigação não encontrou nenhuma evidência de acesso não autorizado”. Wiz disse que o token Jira foi alternado em 24 de junho e que a análise do Snowflake não encontrou nenhum uso externo não relacionado dele durante a janela de exposição de cinco dias. Os registros de auditoria subjacentes do Snowflake não foram tornados públicos.
Wiz descreveu a falha como resultante de uma alteração do GitHub Copilot Autofix, embora o histórico subjacente do GitHub não estabeleça o Copilot como o autor do código jira_issue.yml vulnerável. O commit explícito de coautoria do Copilot, 6d0e2fa, alterou jira_close.yml, enquanto o refatorador inseguro jira_issue.yml aparece em um commit separado de 25 de agosto de 2025, 094038e, atribuído pelo GitHub a sfc-gh-hpathak.
Ambas as mudanças foram posteriormente incorporadas ao commit de squash merge 4a1b8ce de 18 de junho, que lista o Copilot Autofix entre seus coautores. O histórico de commits, portanto, confirma a participação do Copilot na solicitação pull nº 1218, mas não a autoria das linhas vulneráveis.
O GitHub documentou essa classe de injeção de fluxo de trabalho em julho de 2025, alertando contra a expansão de dados de problemas não confiáveis diretamente dentro dos blocos run: e recomendando o uso de variáveis de ambiente intermediárias.
Em 17 de agosto de 2026, nenhuma entrada de catálogo CVE, pontuação CVSS ou vulnerabilidades conhecidas exploradas (KEV) CISA foi localizada para o problema, e nenhuma atualização de versão do conector vinculada a ele foi identificada. A interpolação vulnerável não está mais presente no master, e o material primário disponível não estabelece exploração maliciosa em estado selvagem ou comprometimento do cliente.
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #falha #de #ações #do #snowflake #github #permite #que #problemas #elaborados #acionem #injeção #de #comando
⚡ Fique ligado: novidades e promoções em breve por aqui! ⚡
Postar um comentário