🔥 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
O Splunk lançou atualizações de segurança para solucionar uma falha crítica de segurança no Splunk Enterprise que poderia ser explorada para conduzir operações de arquivos não autenticados e até mesmo execução remota de código.
A vulnerabilidade, rastreada como CVE-2026-20253, é classificada como 9,8 no sistema de pontuação CVSS.
“Nas versões do Splunk Enterprise abaixo de 10.2.4 e 10.0.7, um usuário não autenticado pode criar ou truncar arquivos arbitrários por meio de um endpoint de serviço secundário do PostgreSQL”, disse o Splunk em um alerta esta semana.
“A vulnerabilidade existe porque o endpoint de serviço secundário do PostgreSQL não possui controles de autenticação, permitindo que qualquer usuário acessível pela rede invoque operações de arquivo sem credenciais.”
O problema foi resolvido nas seguintes versões -
Splunk Enterprise 10.0.0 a 10.0.6 - Corrigido em 10.0.7
Splunk Enterprise 10.2.0 a 10.2.3 - Corrigido em 10.2.4
Splunk Enterprise 10.4 - Não afetado
A Splunk, que faz parte da Cisco, disse que o Splunk Cloud não é afetado pela vulnerabilidade, pois os sidecars do Postgres não são usados no produto.
Do que se trata a falha
Na sexta-feira, o watchTowr Labs divulgou detalhes técnicos adicionais do CVE-2026-20253, afirmando que ele poderia ser explorado para obter execução remota de código pré-autenticado em sistemas suscetíveis por meio dos endpoints “/v1/postgres/recovery/backup” e “/v1/postgres/recovery/restore”.
A cadeia de ataque funciona da seguinte forma -
Conecte-se a um banco de dados controlado pelo invasor e despeje seu conteúdo em um arquivo arbitrário usando o endpoint /backup
Carregue o dump do banco de dados controlado pelo invasor na instância local do PostgreSQL usando o endpoint /restore incluindo um argumento "passfile" que especifica o caminho para um arquivo ".pgpass" ("/opt/splunk/var/packages/data/postgres/.pgpass") contendo a senha para o usuário "postgres_admin"
As consultas SQL definidas no dump do banco de dados serão executadas pela instância PostgreSQL do Splunk
Um invasor pode aproveitar essa fraqueza para definir uma nova função que usa lo_export – uma função usada para extrair um BLOB do banco de dados e salvá-lo como um arquivo no sistema de arquivos – para gravar conteúdo controlado pelo invasor em um arquivo, após o qual a função é executada durante o processo de restauração.
“Neste ponto, podemos autenticar, restaurar o SQL controlado pelo invasor e interagir com o banco de dados local”, disseram os pesquisadores de segurança Piotr Bazydlo e Yordan Ganchev. "Assim que pudemos restaurar o SQL controlado pelo invasor na instância local do PostgreSQL, rapidamente montamos um modelo de despejo de banco de dados que nos forneceu uma gravação de arquivo controlada."
Armado com uma primitiva de gravação de arquivo arbitrária no sistema de arquivos Splunk, um invasor pode escalar ainda mais para a execução remota de código, substituindo um script Python que o Splunk executa com frequência (por exemplo, "/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py") para incluir a carga maliciosa.
Toda a sequência de ações está abaixo -
Crie um banco de dados e configure-o de forma que um usuário possa autenticar sem senha e conceder permissões suficientes para invocar funções como lo_export
Use o endpoint /backup para descartar um dump do banco de dados remoto no sistema de arquivos Splunk
Use o endpoint /restore para carregar o dump malicioso do banco de dados, acionar a execução da função maliciosa durante o processo de restauração e gravar um script Python controlado pelo invasor no sistema de arquivos Splunk
Embora não haja evidências de que a falha esteja sendo explorada em estado selvagem, a disponibilidade dos detalhes da exploração pode ser suficiente para levar os atores da ameaça a desencadear tentativas oportunistas. É essencial que os usuários ajam rapidamente para aplicar as correções para permanecerem protegidos.
A vulnerabilidade, rastreada como CVE-2026-20253, é classificada como 9,8 no sistema de pontuação CVSS.
“Nas versões do Splunk Enterprise abaixo de 10.2.4 e 10.0.7, um usuário não autenticado pode criar ou truncar arquivos arbitrários por meio de um endpoint de serviço secundário do PostgreSQL”, disse o Splunk em um alerta esta semana.
“A vulnerabilidade existe porque o endpoint de serviço secundário do PostgreSQL não possui controles de autenticação, permitindo que qualquer usuário acessível pela rede invoque operações de arquivo sem credenciais.”
O problema foi resolvido nas seguintes versões -
Splunk Enterprise 10.0.0 a 10.0.6 - Corrigido em 10.0.7
Splunk Enterprise 10.2.0 a 10.2.3 - Corrigido em 10.2.4
Splunk Enterprise 10.4 - Não afetado
A Splunk, que faz parte da Cisco, disse que o Splunk Cloud não é afetado pela vulnerabilidade, pois os sidecars do Postgres não são usados no produto.
Do que se trata a falha
Na sexta-feira, o watchTowr Labs divulgou detalhes técnicos adicionais do CVE-2026-20253, afirmando que ele poderia ser explorado para obter execução remota de código pré-autenticado em sistemas suscetíveis por meio dos endpoints “/v1/postgres/recovery/backup” e “/v1/postgres/recovery/restore”.
A cadeia de ataque funciona da seguinte forma -
Conecte-se a um banco de dados controlado pelo invasor e despeje seu conteúdo em um arquivo arbitrário usando o endpoint /backup
Carregue o dump do banco de dados controlado pelo invasor na instância local do PostgreSQL usando o endpoint /restore incluindo um argumento "passfile" que especifica o caminho para um arquivo ".pgpass" ("/opt/splunk/var/packages/data/postgres/.pgpass") contendo a senha para o usuário "postgres_admin"
As consultas SQL definidas no dump do banco de dados serão executadas pela instância PostgreSQL do Splunk
Um invasor pode aproveitar essa fraqueza para definir uma nova função que usa lo_export – uma função usada para extrair um BLOB do banco de dados e salvá-lo como um arquivo no sistema de arquivos – para gravar conteúdo controlado pelo invasor em um arquivo, após o qual a função é executada durante o processo de restauração.
“Neste ponto, podemos autenticar, restaurar o SQL controlado pelo invasor e interagir com o banco de dados local”, disseram os pesquisadores de segurança Piotr Bazydlo e Yordan Ganchev. "Assim que pudemos restaurar o SQL controlado pelo invasor na instância local do PostgreSQL, rapidamente montamos um modelo de despejo de banco de dados que nos forneceu uma gravação de arquivo controlada."
Armado com uma primitiva de gravação de arquivo arbitrária no sistema de arquivos Splunk, um invasor pode escalar ainda mais para a execução remota de código, substituindo um script Python que o Splunk executa com frequência (por exemplo, "/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py") para incluir a carga maliciosa.
Toda a sequência de ações está abaixo -
Crie um banco de dados e configure-o de forma que um usuário possa autenticar sem senha e conceder permissões suficientes para invocar funções como lo_export
Use o endpoint /backup para descartar um dump do banco de dados remoto no sistema de arquivos Splunk
Use o endpoint /restore para carregar o dump malicioso do banco de dados, acionar a execução da função maliciosa durante o processo de restauração e gravar um script Python controlado pelo invasor no sistema de arquivos Splunk
Embora não haja evidências de que a falha esteja sendo explorada em estado selvagem, a disponibilidade dos detalhes da exploração pode ser suficiente para levar os atores da ameaça a desencadear tentativas oportunistas. É essencial que os usuários ajam rapidamente para aplicar as correções para permanecerem protegidos.
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #falha #crítica #do #splunk #enterprise #permite #que #invasores #executem #código #sem #autenticação
🎉 Obrigado por acompanhar, até a próxima notícia!
Postar um comentário