CVE-2025-55619

Executive Summary

CVE-2025-55619 exposes a critical security flaw in the Reolink desktop application (version 4.54.0.4.20250526). The vendor has hardcoded a static encryption key and initialization vector (IV) within the application binary. An attacker with access to the application (e.g., via reverse engineering, malware on the host, or physical access) can extract these static values. This allows the attacker to decrypt all access tokens and web session tokens stored locally by the application, effectively bypassing authentication and gaining persistent, unauthorized access to the user's Reolink camera system and cloud account.

The vulnerability is rated with a CVSS score of 0.0 in the NVD, but this is likely a placeholder or error. The actual impact is severe, as it compromises the confidentiality and integrity of all stored credentials. The attack complexity is low, requiring only the ability to run a debugger or static analysis tool on the application binary. No user interaction is required beyond the initial installation of the vulnerable software.

Supply Chain & Package Security

This vulnerability is not related to an open-source package manager (NPM, PyPI, Go, Ruby). It is a proprietary desktop application distributed by Reolink. The risk is introduced directly by the vendor's software development lifecycle, not through a compromised dependency.

CVSS Breakdown & Threat Level

While the official CVSS score is listed as 0.0, a more accurate assessment based on the vulnerability's nature is:

• Attack Vector (AV): Local (L) – The attacker must have access to the system running the Reolink application.
• Attack Complexity (AC): Low (L) – The hardcoded key is trivially extractable via static analysis.
• Privileges Required (PR): None (N) – The attacker does not need elevated privileges to read the application binary.
• User Interaction (UI): None (N) – No user action is required for exploitation.
• Scope (S): Changed (C) – The compromised tokens can be used to access resources (cloud account, cameras) beyond the vulnerable component.
• Confidentiality (C): High (H) – All stored tokens are exposed.
• Integrity (I): High (H) – An attacker can use the tokens to modify camera settings or view feeds.
• Availability (A): None (N) – The vulnerability does not directly impact availability.

Calculated Score: 8.8 (High)

Threat Level: Critical. The combination of low attack complexity, no required privileges, and high impact on confidentiality and integrity makes this a high-priority vulnerability for any organization using Reolink software.

Deep Dive & Mechanics

The vulnerability lies in the application's credential storage mechanism. Instead of using a secure, platform-provided key store (e.g., Windows DPAPI, macOS Keychain, Linux Secret Service), the Reolink application implements its own encryption using a hardcoded symmetric key and IV.

Technical Breakdown:

1. Token Generation: When a user logs into the Reolink application, the server issues an access token and a session token. These are typically JSON Web Tokens (JWTs) or similar opaque tokens.
2. Local Storage: The application stores these tokens locally, likely in a configuration file, SQLite database, or the Windows Registry.
3. Encryption: Before writing to disk, the application encrypts the token data using a symmetric cipher (likely AES-256-CBC or similar) with a static key and IV.
4. Hardcoded Values: The encryption key and IV are embedded as string literals or byte arrays within the application's executable (e.g., Reolink.exe or a core DLL).
5. Exploitation: An attacker can use a tool like strings, IDA Pro, Ghidra, or dnSpy to locate the hardcoded key and IV. With these values, they can write a simple script to decrypt any token file found on the system.

Impact: An attacker who gains access to a workstation (e.g., via phishing, malware, or physical access) can:

• Decrypt all stored Reolink tokens.
• Use the tokens to authenticate to the Reolink cloud API.
• View live camera feeds, recorded footage, and camera settings.
• Modify camera configurations (e.g., disable recording, change motion detection zones).
• Potentially pivot to other devices on the local network if the Reolink system has network access.

Vulnerable vs. Patched Code

Since no patch is available, we can only describe the vulnerable code pattern. A secure implementation would use platform-specific APIs to store secrets.

Vulnerable Code (Conceptual C#/C++):

// Hardcoded key and IV - THIS IS THE VULNERABILITY
private static readonly byte[] EncryptionKey = new byte[] { 0x01, 0x02, 0x03, ... }; // 32 bytes
private static readonly byte[] EncryptionIV = new byte[] { 0x0A, 0x0B, 0x0C, ... }; // 16 bytes

public static string EncryptToken(string plainToken)
{
    using (Aes aes = Aes.Create())
    {
        aes.Key = EncryptionKey;
        aes.IV = EncryptionIV;
        ICryptoTransform encryptor = aes.CreateEncryptor(aes.Key, aes.IV);
        // ... encryption logic
    }
}

Patched Code (Conceptual - Secure):

// Use Windows Data Protection API (DPAPI)
public static string EncryptToken(string plainToken)
{
    byte[] plainBytes = Encoding.UTF8.GetBytes(plainToken);
    byte[] encryptedBytes = ProtectedData.Protect(plainBytes, null, DataProtectionScope.CurrentUser);
    return Convert.ToBase64String(encryptedBytes);
}

public static string DecryptToken(string encryptedToken)
{
    byte[] encryptedBytes = Convert.FromBase64String(encryptedToken);
    byte[] plainBytes = ProtectedData.Unprotect(encryptedBytes, null, DataProtectionScope.CurrentUser);
    return Encoding.UTF8.GetString(plainBytes);
}

The patched version uses the operating system's secure key store, which encrypts the data with a key derived from the user's login credentials. This makes it impossible for an attacker without the user's password to decrypt the tokens.

Exploitation & Lab Setup

Red Team (Offensive)

Objective: Extract the hardcoded key/IV and decrypt stored tokens.

Lab Setup:

1. Install Reolink v4.54.0.4.20250526 on a Windows 10/11 VM.
2. Log in to a Reolink account to generate and store tokens.
3. Use a tool like Process Monitor to identify where tokens are stored (e.g., %APPDATA%\Reolink\).

Exploitation Steps:

1. Extract Hardcoded Values: Use strings on the main executable:

   strings Reolink.exe | grep -E "^[A-Za-z0-9+/]{32,}={0,2}$"
   

   Or use a disassembler (e.g., Ghidra) to locate the key and IV in the .rdata section.

2. Locate Token File: The token file is likely named token.dat or session.db. Search for recently modified files in the AppData directory.

3. Decrypt Token: Write a Python script using the extracted key and IV:

   from Crypto.Cipher import AES
   import base64
   
   key = bytes([0x01, 0x02, 0x03, ...])  # Extracted from binary
   iv = bytes([0x0A, 0x0B, 0x0C, ...])   # Extracted from binary
   
   with open("token.dat", "rb") as f:
       encrypted_data = f.read()
   
   cipher = AES.new(key, AES.MODE_CBC, iv)
   decrypted_data = cipher.decrypt(encrypted_data)
   # Remove padding (PKCS7)
   pad_len = decrypted_data[-1]
   token = decrypted_data[:-pad_len].decode('utf-8')
   print(f"Decrypted Token: {token}")
   

4. Use Token: Use the decrypted token to make API calls to the Reolink cloud:

   curl -H "Authorization: Bearer <token>" https://api.reolink.com/v1/cameras
   

Blue Team (Defensive)

Objective: Detect and respond to exploitation of CVE-2025-55619.

Detection Steps:

1. Identify Vulnerable Systems:

   • Inventory all systems running Reolink software.
   • Check version: wmic product where "name like '%Reolink%'" get version
   • Flag any system with version 4.54.0.4.20250526.

2. Monitor for Token Exfiltration:

   • Look for unusual outbound connections to api.reolink.com from non-Reolink processes (e.g., powershell.exe, curl.exe).
   • Monitor for processes reading the token file (token.dat, session.db) that are not the legitimate Reolink process.

3. Harden Endpoints:

   • Apply the principle of least privilege. Users should not be able to read the Reolink application directory if they are not administrators.
   • Use Application Control (e.g., Windows Defender Application Control) to block unauthorized executables from reading the Reolink data directory.

4. Incident Response:

   • If a token is compromised, immediately revoke it via the Reolink web portal.
   • Force a password reset for the affected account.
   • Review camera logs for unauthorized access.

Indicators of Compromise (IOCs)

• File Hashes (SHA-256):
  • Reolink.exe (v4.54.0.4.20250526): [Placeholder - Obtain from vendor]
  • token.dat (encrypted token file): [Placeholder - Varies per user]
• Network Indicators:
  • Destination: api.reolink.com (HTTPS)
  • User-Agent: Any non-standard HTTP client (e.g., curl, python-requests)
• Process Indicators:
  • Unauthorized processes (e.g., python.exe, powershell.exe) reading files in %APPDATA%\Reolink\
• Registry Keys (Windows):
  • HKCU\Software\Reolink\ (may contain token storage path)
• YARA Rule (see Detection Engineering)

Detection Engineering

YARA Rule

rule CVE_2025_55619_Reolink_Hardcoded_Key
{
    meta:
        description = "Detects Reolink application binary with hardcoded encryption key/IV"
        author = "Valters IT"
        date = "2025-05-27"
        hash = "[Placeholder]"
    strings:
        $key1 = { 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 } // Example key bytes
        $key2 = "ReolinkEncryptionKey" ascii wide
        $iv1 = "ReolinkEncryptionIV" ascii wide
    condition:
        uint16(0) == 0x5A4D and // MZ header
        ($key1 or $key2 or $iv1)
}

Sigma Rule

title: Reolink Token File Access by Unauthorized Process
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects non-Reolink processes reading the token storage file.
author: Valters IT
date: 2025/05/27
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|endswith:
            - '\AppData\Roaming\Reolink\token.dat'
            - '\AppData\Roaming\Reolink\session.db'
    filter:
        Image|endswith:
            - '\Reolink.exe'
            - '\ReolinkService.exe'
    condition: selection and not filter
falsepositives:
    - Backup software
    - Antivirus scans
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-55619 Reolink Token Exfiltration"; flow:to_server; content:"Authorization|3a| Bearer"; http_header; pcre:"/Bearer [A-Za-z0-9\-_]{20,}/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate Vulnerable Systems: If possible, disconnect systems running the vulnerable Reolink version from the internet until a patch is applied.
2. Revoke All Tokens: Log in to the Reolink web portal and force a logout of all sessions. This will invalidate any stolen tokens.
3. Change Passwords: Change the password for the Reolink account associated with the vulnerable installation.

Long-Term Fixes:

1. Vendor Patch: Await an official update from Reolink that removes the hardcoded key and uses a secure key storage mechanism (e.g., DPAPI, Keychain).
2. Application Rewrite: The vendor should rewrite the credential storage module to use platform-provided secure storage APIs.
3. Code Review: Reolink should conduct a thorough security code review to identify and eliminate all hardcoded secrets.

Compensating Controls (If Patch is Unavailable):

1. Application Control: Use tools like Windows Defender Application Control (WDAC) or AppLocker to prevent unauthorized processes from reading the Reolink data directory.
2. Endpoint Detection and Response (EDR): Deploy EDR solutions with rules to detect the YARA and Sigma patterns provided above.
3. Network Segmentation: Place Reolink systems on a separate VLAN with strict egress filtering to only allow traffic to necessary Reolink cloud endpoints.
4. User Education: Train users to recognize phishing attempts that could lead to local access and token theft.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Analyst