
Уязвимость локального обхода аутентификации в настольном приложении Reolink
Настольное приложение Reolink (версия 8.18.12) содержит уязвимость локального обхода аутентификации в функции экрана блокировки. Исходный код приложения не упакован в архив ASAR, что оставляет критически важную логику аутентификации, такую как проверка пароля, открытой в виде обычного текста в клиентских JavaScript-файлах. Простого изменения логики в этом открытом коде достаточно, чтобы нейтрализовать проверку пароля и обойти экран блокировки.
Пароль экрана блокировки хранится и извлекается с помощью JavaScript-кода в локальном пакете ресурсов, а именно:
%LOCALAPPDATA%\Programs\Reolink\resources\app\~node_modules_sharp_vendor_Sync_recursive_versions_json_~private_main_index_ts.js
Соответствующий код регистрирует обработчик для команды get_settings_lock_screen_password, который возвращает сохранённый пароль из свойства a.settingsManager.lockScreenPassword:
this.registerCommonCmd(
"get_settings_lock_screen_password",
"",
R(function () {
return N(this, function (e) {
return [2, a.settingsManager.lockScreenPassword];
});
}),
);
Поскольку эта логика полностью resides на стороне клиента, злоумышленник может изменить возвращаемое значение на "" (пустую строку), фактически обойдя экран блокировки:
return [2, ""];
После изменения и сохранения этого файла приложение будет считать, что экран блокировки не имеет пароля, тем самым предоставляя доступ без какой-либо аутентификации.
Эта уязвимость позволяет любому локальному злоумышленнику с доступом к файловой системе обойти аутентификацию на уровне приложения и получить полный доступ к интерфейсу и настройкам приложения.
Поскольку пароль не проверяется ни по какому внешнему источнику и доступен через изменяемый JavaScript, этот экран блокировки не обеспечивает реальной защиты.
С содержимым кода можно манипулировать, запустив poc.py.
На следующем скриншоте показан экран блокировки приложения Reolink до применения патча, с включённым запросом пароля:
На следующем скриншоте показано приложение после применения патча и перезапуска, без отображения запроса пароля:

Код приложения должен быть упакован в архив ASAR, а при запуске должна быть реализована процедура проверки целостности, например проверка хэш-значения или подписи файла ASAR. Любое приложение, которое было изменено, должно быть заблокировано для выполнения.
Критически важная логика аутентификации, такая как проверка пароля экрана блокировки, должна обрабатываться в нативном бинарном коде, который сложнее изменить, а не в JavaScript, где это возможно, или обрабатываться через взаимодействие с серверной стороной.