
AES-CFB Key Generation and Management Vulnerability in Reolink Desktop Application
The Reolink Desktop Application (version 8.18.12) uses the AES-CFB algorithm to encrypt configuration files and other sensitive data.
However, the encryption key is handled in an insecure manner, which allows attackers to easily decrypt the protected configuration data.
The Reolink application stores user configuration and other sensitive information at the following path:
%APPDATA%\reolink\<UUID>.json
<UUID> has this format: 424e044d-aa27-4e59-873a-26b9f16be9ad
This configuration file is encrypted using AES-CFB, and the AES key used for decryption is derived through the following process:
Open the file located at the following path:
%APPDATA%\com.reolink.app.client
The file contains data in JSON format, for example:
{
"data": "+lWlitlpr9vBiG71RCJYoPSJKVnUgGVbgu4v9W6K3N0kzgLv9HEQpqVi2fMnHdb7iWhYgb5KeRhYb6IPVWRR4kxTcwTDfQmMOvFWLuqHPRJBt9ozPSo4TYDXzjBN0YAW",
"__internal__": {
"migrations": {
"version": "8.18.12"
}
}
}
The application uses MD5("com.reolink.app").upper() as the primary AES key, and bcswebapp1234567 as the IV. The encrypted string (data) is base64-decoded and then decrypted. The decrypted string has this format: 59083200-3875-4f67-a067-d953286114a0
The final key is MD5("<DECRYPTED_STRING>").upper().encode(), and the IV remains the same (bcswebapp1234567). This is used to decrypt the configuration file, <UUID>.json.
By executing poc.py, you can get the final key before it is MD5 hashed (in the format 59083200-3875-4f67-a067-d953286114a0) and the contents of the configuration file.
A hash of a hard-coded static string, such as com.reolink.app, should not be used as the primary key.
Additionally, keys should not be stored in a predictable local file, such as in %APPDATA%. Strong, validated secure keystores provided by the operating system, such as Windows DPAPI or macOS Keychain, must be used to protect all sensitive credentials.