shinycolumn/cve-2025-56799# Vulnerabilidade de Injeção de Comandos do Sistema Operacional via Agendador de Limpeza de Cache no Aplicativo Desktop Reolink
O Aplicativo Desktop da Reolink (versão 8.18.12) contém uma vulnerabilidade de injeção de comandos do sistema operacional no recurso do agendador de limpeza de cache (coverCacheClearScheduler). O aplicativo constrói um comando de shell do SO usando um caminho de pasta temporária lido de um arquivo de configuração localizado em . Como esse valor de caminho não possui sanitização adequada de entrada, um atacante pode manipulá-lo para injetar comandos arbitrários do SO.
%LOCALAPPDATA%Essa vulnerabilidade é acionada pelo agendador, que é executado automaticamente todos os dias às 3:00 da manhã, proporcionando ao atacante persistência no sistema. Além disso, o comando injetado é executado como parte do processo legítimo e com assinatura digital Reolink.exe, o que concede furtividade ao evadir a detecção de soluções de segurança.
O aplicativo inicializa um agendador para ser executado todos os dias às 3:00 da manhã:
{
key: "clearCoverCacheRegularly",
value: function () {
if (this.coverCacheClearScheduler) {
var e = new Date(),
t = new Date(
e.getFullYear(),
e.getMonth(),
e.getDate(),
3,
0,
0,
).getTime();
(e.getTime() > t &&
(t = new Date(
e.getFullYear(),
e.getMonth(),
e.getDate() + 1,
3,
0,
0,
).getTime()),
this.coverCacheClearScheduler.add({
id: this.clearCoverCacheTaskId,
name: "clearCoverCache",
unit: r.ETaskUnit.DAY,
interval: 1,
args: !1,
execute: this.removeCoverCacheDir,
nextTime: t,
isInExact: !0,
}),
this.coverCacheClearScheduler.start());
}
},
}
A função executada pelo agendador constrói uma string de comando de shell usando a seguinte lógica:
p(
"darwin" === process.platform
? "rm -rf ".concat(t)
: "rd /s /q ".concat(t),
function (t) {
//...
No Windows, o comando resultante é:
rd /s /q %LOCALAPPDATA%\Temp\reolink\<TEMP_FOLDER>\playback-covers
No macOS, o comando resultante é:
rm -rf ~/Library/Caches/reolink/<TEMP_FOLDER>/playback-covers
Como <TEMP_FOLDER> não é sanitizado adequadamente, um atacante pode injetar comandos adicionais por meio da manipulação do nome da pasta, levando à execução de comandos:
rd /s /q %LOCALAPPDATA%\Temp\reolink\& <COMMAND> &\playback-covers
rm -rf ~/Library/Caches/reolink/& <COMMAND>; echo /playback-covers
Acionar o ataque requer modificação local de arquivos, o que exige outra vulnerabilidade, execução de malware ou acesso físico ao sistema.
Embora o acionamento inicial seja relativamente difícil, o ataque é altamente eficaz uma vez bem-sucedido, pois fornece persistência ao reexecutar o payload automaticamente todas as manhãs às 3:00. Essa persistência é ainda mais aprimorada pela natureza do aplicativo como uma ferramenta de segurança física, que geralmente permanece em execução 24 horas por dia, 7 dias por semana. Ele também suporta um recurso de 'iniciar na inicialização', garantindo que o payload sobreviva a reinicializações.
Além disso, o atacante obtém furtividade significativa. O comando é executado como parte do processo confiável e com assinatura digital Reolink.exe, tornando-o altamente eficaz para contornar soluções de EDR e de listagem de aplicativos permitidos. Esta é uma técnica clássica de Living Off the Land (LOTL).
O ataque pode ser executado rodando poc.py, que modifica o arquivo de configuração local. Isso é possível encadeando outras vulnerabilidades relacionadas à criptografia insuficiente (CVE-2025-56801 e CVE-2025-56802), que são usadas para descriptografar e re-criptografar o arquivo de configuração.
Normalmente, o payload só seria acionado às 3:00 da manhã. No entanto, como o aplicativo não utiliza empacotamento ASAR, o código pode ser corrigido para acionar a vulnerabilidade imediatamente para fins de demonstração.
O resultado da execução é o seguinte:
Para mais detalhes, consulte CVE-2025-56801 para a Vulnerabilidade de Geração de IV AES-CFB e CVE-2025-56802 para a Vulnerabilidade de Geração e Gerenciamento de Chave AES-CFB.
Para resolver fundamentalmente essa vulnerabilidade de injeção de comandos do SO, você deve evitar incluir diretamente valores lidos de fontes externas não confiáveis, como arquivos de configuração do usuário, em strings de comando de shell do SO. A solução recomendada é substituir o uso de comandos de shell como rd ou rm por APIs nativas que tratam o caminho como dados puros, não como um comando, como fs.rm() do Node.js. Esse método elimina completamente essa classe de vulnerabilidade.
Se a construção de um comando de shell for absolutamente inevitável, uma lógica defensiva deve ser implementada para validar rigorosamente e sanitizar ou escapar todos os caracteres especiais que possam causar injeção de comandos, como &, | e ;.