
Vulnerabilidad de omisión de autenticación local en la aplicación de escritorio de Reolink
La aplicación de escritorio de Reolink (versión 8.18.12) contiene una vulnerabilidad de omisión de autenticación local en su función de pantalla de bloqueo. El código fuente de la aplicación no está empaquetado en un archivo ASAR, lo que deja la lógica de autenticación crítica, como la verificación de contraseña, expuesta en texto plano dentro de los archivos JavaScript del lado del cliente. Simplemente modificar la lógica en este código expuesto es suficiente para neutralizar la comprobación de contraseña y omitir la pantalla de bloqueo.
La contraseña de la pantalla de bloqueo se almacena y se recupera mediante código JavaScript en el paquete de recursos local, específicamente:
%LOCALAPPDATA%\Programs\Reolink\resources\app\~node_modules_sharp_vendor_Sync_recursive_versions_json_~private_main_index_ts.js
El código relevante registra un controlador para el comando get_settings_lock_screen_password, que devuelve la contraseña almacenada de la propiedad a.settingsManager.lockScreenPassword:
this.registerCommonCmd(
"get_settings_lock_screen_password",
"",
R(function () {
return N(this, function (e) {
return [2, a.settingsManager.lockScreenPassword];
});
}),
);
Dado que esta lógica reside completamente en el lado del cliente, un atacante puede modificar el valor de retorno a "" (una cadena vacía), omitiendo efectivamente la pantalla de bloqueo:
return [2, ""];
Después de modificar y guardar este archivo, la aplicación tratará la pantalla de bloqueo como si no tuviera contraseña, otorgando así acceso sin ninguna autenticación.
Esta vulnerabilidad permite que cualquier atacante local con acceso al sistema de archivos omita la autenticación a nivel de aplicación y obtenga acceso completo a la interfaz y la configuración de la aplicación.
Dado que la contraseña no se valida contra ninguna fuente externa y está expuesta mediante JavaScript modificable, esta pantalla de bloqueo no ofrece protección real.
El contenido del código puede ser manipulado ejecutando poc.py.
La siguiente captura de pantalla muestra la pantalla de bloqueo de la aplicación Reolink antes del parche, con una solicitud de contraseña habilitada:
La siguiente captura de pantalla muestra la aplicación después de aplicar el parche y reiniciarla, sin que se muestre ninguna solicitud de contraseña:

El código de la aplicación debe empaquetarse en un archivo ASAR, y debe implementarse un proceso de verificación de integridad, como comprobar el valor hash o la firma del archivo ASAR, al iniciar. Cualquier aplicación que haya sido manipulada debe bloquearse para que no se ejecute.
La lógica de autenticación crítica, como la verificación de contraseña de la pantalla de bloqueo, debe manejarse dentro del código binario nativo, que es más difícil de manipular, en lugar de en JavaScript, siempre que sea posible, o procesarse mediante comunicación del lado del servidor.