shinycolumn/cve-2025-56800Vulnerabilidade de Bypass de Autenticação Local no Aplicativo Desktop Reolink
O Aplicativo Desktop Reolink (versão 8.18.12) contém uma vulnerabilidade de bypass de autenticação local no recurso de tela de bloqueio. O código-fonte do aplicativo não é empacotado em um arquivo ASAR, deixando a lógica crítica de autenticação, como a verificação de senha, exposta em texto simples em arquivos JavaScript do lado do cliente. Simplesmente modificar a lógica nesse código exposto é suficiente para neutralizar a verificação de senha e contornar a tela de bloqueio.
A senha da tela de bloqueio é armazenada e recuperada por meio de código JavaScript no pacote de recursos local, especificamente:
%LOCALAPPDATA%\Programs\Reolink\resources\app\~node_modules_sharp_vendor_Sync_recursive_versions_json_~private_main_index_ts.js
O código relevante registra um manipulador para o comando get_settings_lock_screen_password, que retorna a senha armazenada da propriedade a.settingsManager.lockScreenPassword:
this.registerCommonCmd(
"get_settings_lock_screen_password",
"",
R(function () {
return N(this, function (e) {
return [2, a.settingsManager.lockScreenPassword];
});
}),
);
Como essa lógica reside inteiramente no lado do cliente, um atacante pode alterar o valor de retorno para "" (uma string vazia), contornando efetivamente a tela de bloqueio:
return [2, ""];
Após modificar e salvar este arquivo, o aplicativo tratará a tela de bloqueio como se não tivesse senha, concedendo assim acesso sem qualquer autenticação.
Essa vulnerabilidade permite que qualquer atacante local com acesso ao sistema de arquivos contorne a autenticação em nível de aplicativo e obtenha acesso total à interface e às configurações do aplicativo.
Como a senha não é validada contra nenhuma fonte externa e é exposta por meio de JavaScript modificável, essa tela de bloqueio não oferece proteção real.
O conteúdo do código pode ser adulterado executando poc.py.
A captura de tela a seguir mostra a tela de bloqueio do aplicativo Reolink antes da aplicação do patch, com o prompt de senha habilitado:
A captura de tela a seguir mostra o aplicativo após aplicar o patch e reiniciar, sem prompt de senha exibido:
O código do aplicativo deve ser empacotado em um arquivo ASAR, e um processo de verificação de integridade, como verificar o valor de hash ou a assinatura do arquivo ASAR, deve ser implementado na inicialização. Qualquer aplicativo que tenha sido adulterado deve ser bloqueado de ser executado.
A lógica crítica de autenticação, como a verificação de senha da tela de bloqueio, deve ser tratada dentro do código binário nativo, que é mais difícil de adulterar, em vez de em JavaScript, sempre que possível, ou ser processada por meio de comunicação com o servidor.