DEV Community

Cover image for 7 Urgent Digiever DS-2105 Pro KEV Lessons
Pentest Testing Corp
Pentest Testing Corp

Posted on

7 Urgent Digiever DS-2105 Pro KEV Lessons

#devops #networking #iot #cybersecurity

7 Urgent Digiever DS-2105 Pro KEV Lessons SMBs Can Apply Today

Your CCTV NVR isn’t “just a camera box.” It’s a Linux server with storage, a web UI, network services, and (often) remote access enabled. When Digiever DS-2105 Pro landed in CISA’s Known Exploited Vulnerabilities (KEV) catalog as CVE-2023-52163, it reinforced a reality SMBs learn the hard way: non-IT devices become botnet footholds fast.

This post turns that KEV incident into an actionable IoT patch hygiene program you can run with a small team and a realistic budget—plus copy/paste scripts to inventory, segment, and monitor your CCTV/NVR fleet.

7 Urgent Digiever DS-2105 Pro KEV Lessons

What happened (and why it matters)

CVE-2023-52163 impacts Digiever DS-2105 Pro and is associated with missing authorization / command injection risk via a CGI endpoint commonly referenced as time_tzsetup.cgi. In other words: a management path can be abused to run commands, which is exactly what botnet operators want—quiet compute, persistent access, and an on-ramp to the rest of your network.

The core lesson: if an NVR is reachable and unmanaged, it will be found—and it will be used.

Lesson 1) NVRs get owned because they’re exposed, forgotten, and flat-networked

Common exposure patterns

  • Port-forwarding “just for remote viewing” (web UI / RTSP / vendor ports)
  • UPnP silently punching holes in the router
  • Default admin paths living forever (or shared creds across sites)
  • No VLANs (NVR sits next to laptops, POS, file servers)

“Find it fast” checks (safe, defensive)

Create a simple target list (IPs of known sites or subnets you own) and run a focused scan.

# Quick discovery of typical NVR/CCTV services (adjust to your environment)
nmap -sS -sV -Pn --open \
  -p 80,443,554,8000,8080,8443,9000,37777,34567 \
  192.168.0.0/16 -oA cctv_nvr_discovery
Enter fullscreen mode Exit fullscreen mode

If you have a mixed environment and want speed:

# Fast port sweep, then validate with nmap (defensive inventory)
masscan 192.168.0.0/16 -p80,443,554,8000,8080,8443 --rate 5000 -oG masscan_nvr.gnmap
awk '/Ports:/{print $2}' masscan_nvr.gnmap | sort -u > nvr_hosts.txt
nmap -iL nvr_hosts.txt -sV -Pn -p80,443,554,8000,8080,8443 -oA nvr_validate
Enter fullscreen mode Exit fullscreen mode

Lesson 2) Operationalize KEV like a “drop-everything” signal for IoT too

Most SMB patch workflows prioritize Windows/macOS and “real servers,” while IoT/OT gets a monthly routine—if any. KEV flips that: when a device class hits KEV, treat it as an emergency change.

Minimum viable KEV workflow (SMB-friendly)

  1. Owner identified (facilities, IT, MSP) for each IoT class (NVRs, cameras, access control)
  2. SLA policy
  • Monthly firmware window (routine)

  • Emergency workflow: 48–72 hours for KEV items

    1. Compensating controls if patching is blocked

  • isolate

  • remove WAN exposure

  • restrict admin access

  • increase monitoring

    1. If no fix exists: retire/replace (yes, it’s painful—still cheaper than incident response)

Turn KEV into a local “match + alert”

Maintain a local file (CSV/YAML) of your IoT inventory and match against a downloaded KEV list (kept in your internal repo).

iot_assets.yaml

- asset_id: cctv-nvr-01
  vendor: Digiever
  model: DS-2105 Pro
  ip: 10.60.10.20
  location: HQ - Server Closet
  owner: facilities@company
  vlan: CCTV
  firmware: "3.1.0.71-11"
  internet_exposed: false
  patch_sla_days: 30
Enter fullscreen mode Exit fullscreen mode

kev_match.py (matches locally stored KEV JSON/CSV export)

import json
import yaml

KEV_FILE = "kev_catalog.json"      # store locally from your process
ASSETS_FILE = "iot_assets.yaml"

with open(KEV_FILE, "r", encoding="utf-8") as f:
    kev = json.load(f)

with open(ASSETS_FILE, "r", encoding="utf-8") as f:
    assets = yaml.safe_load(f)

def norm(s: str) -> str:
    return (s or "").strip().lower()

hits = []
for a in assets:
    for item in kev.get("vulnerabilities", []):
        vendor = norm(item.get("vendorProject"))
        product = norm(item.get("product"))
        cve = item.get("cveID")
        if norm(a.get("vendor")) in vendor and norm(a.get("model")) in product:
            hits.append((a["asset_id"], a["vendor"], a["model"], cve, item.get("dateAdded"), item.get("dueDate")))

if hits:
    print("KEV MATCHES FOUND:")
    for h in hits:
        print(f"- {h[0]}: {h[1]} {h[2]} => {h[3]} (added {h[4]}, due {h[5]})")
else:
    print("No KEV matches for current inventory.")
Enter fullscreen mode Exit fullscreen mode

Lesson 3) First-day fixes: isolate, block WAN, kill UPnP, lock admin

If you do nothing else today, do these.

A) Put NVRs on a dedicated CCTV VLAN

Target state:

  • NVR + cameras live in CCTV VLAN
  • No lateral movement from CCTV VLAN to corporate VLAN
  • Corporate VLAN can view NVR (if required), but only via specific ports

Example: Linux router / firewall using nftables 

# Example variables
CCTV_NET="10.60.10.0/24"
CORP_NET="10.10.0.0/16"
NVR_IP="10.60.10.20"

# Default drop from CCTV -> Corp
nft add rule inet filter forward ip saddr $CCTV_NET ip daddr $CORP_NET drop

# Allow Corp users to access NVR web UI (adjust ports)
nft add rule inet filter forward ip saddr $CORP_NET ip daddr $NVR_IP tcp dport {80,443} accept

# Allow NVR to reach only NTP/DNS (recommended: point to internal services)
DNS_IP="10.10.0.53"
NTP_IP="10.10.0.123"
nft add rule inet filter forward ip saddr $NVR_IP ip daddr $DNS_IP udp dport 53 accept
nft add rule inet filter forward ip saddr $NVR_IP ip daddr $NTP_IP udp dport 123 accept
nft add rule inet filter forward ip saddr $NVR_IP drop
Enter fullscreen mode Exit fullscreen mode

B) Block inbound WAN access (no port forwards)

If you must allow remote viewing, prefer VPN into an admin network, then access the NVR internally.

Quick check: find risky port forwards on a Linux gateway 

iptables -t nat -S | grep -E 'DNAT|REDIRECT' || true
Enter fullscreen mode Exit fullscreen mode

C) Disable UPnP at the router

UPnP turns “we didn’t expose it” into “it’s exposed anyway.”

If you run OpenWrt:

# Disable miniupnpd
/etc/init.d/miniupnpd stop
/etc/init.d/miniupnpd disable
uci set upnpd.config.enabled='0'
uci commit upnpd
Enter fullscreen mode Exit fullscreen mode

D) Lock down admin access

  • unique admin creds per site/device
  • MFA where supported (many NVRs don’t—compensate with network controls)
  • allowlist admin UI to admin VLAN only

Example: restrict NVR UI on a reverse proxy

# /etc/nginx/conf.d/nvr-admin.conf
server {
  listen 443 ssl;
  server_name nvr-admin.internal;

  allow 10.99.0.0/24;  # admin VPN/VLAN
  deny all;

  location / {
    proxy_pass http://10.60.10.20;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
  }
}
Enter fullscreen mode Exit fullscreen mode

Lesson 4) “IoT CMDB lite”: inventory + owners + patch SLAs

You don’t need a full CMDB to beat botnets. You need:

  • Asset ID
  • Vendor/model
  • Firmware/version
  • Owner
  • Network zone (VLAN/subnet)
  • Internet exposure (true/false)
  • Patch SLA

Keep it in Git (audit-friendly)

Store iot_assets.yaml in a private repo. Every change is a timestamped record.

SLA drift checker (quick win) 

# sla_check.py
import yaml
from datetime import datetime, timedelta

with open("iot_assets.yaml","r",encoding="utf-8") as f:
    assets = yaml.safe_load(f)

today = datetime.utcnow().date()
for a in assets:
    last = a.get("last_patch_date")  # e.g., "2025-12-10"
    sla = int(a.get("patch_sla_days", 30))
    if not last:
        print(f"[MISSING] {a['asset_id']} has no last_patch_date")
        continue
    last_dt = datetime.strptime(last, "%Y-%m-%d").date()
    if last_dt + timedelta(days=sla) < today:
        print(f"[OVERDUE] {a['asset_id']} ({a['vendor']} {a['model']}) last patched {last_dt} SLA {sla}d")
Enter fullscreen mode Exit fullscreen mode

Lesson 5) Detection on a budget: log what you can, watch what matters

Even without a full SIEM, you can catch botnet-like behavior.

What to watch (high signal)

  • DNS spikes from CCTV VLAN
  • New outbound destinations from NVR subnet
  • Repeated outbound connection attempts (beaconing)
  • Unexpected outbound ports (e.g., 4444, 6667, high random TCP)

Quick-and-cheap: firewall logging + daily review 

# Log new outbound connections from CCTV subnet (iptables example)
CCTV_NET="10.60.10.0/24"
iptables -A FORWARD -s $CCTV_NET -m conntrack --ctstate NEW \
  -j LOG --log-prefix "CCTV-NEW " --log-level 4
Enter fullscreen mode Exit fullscreen mode

Parse logs into a daily “top talkers” report:

# Example for syslog-formatted logs
grep "CCTV-NEW" /var/log/syslog | awk '{print $(NF-2)}' | sort | uniq -c | sort -nr | head
Enter fullscreen mode Exit fullscreen mode

Optional: passive check for weird destinations 

# Capture short sample from CCTV VLAN (run on gateway/mirror port)
tcpdump -ni eth0 net 10.60.10.0/24 -c 2000 -w cctv_sample.pcap
Enter fullscreen mode Exit fullscreen mode

Free Website Vulnerability Scanner tool by Pentest Testing Corp

Screenshot of the free tools webpage where you can access security assessment tools.Screenshot of the free tools webpage where you can access security assessment tools.

Lesson 6) Compliance angle: turn controls into audit evidence

Auditors (and insurers) don’t want “we think it’s fine.” They want proof.

Evidence pack (simple structure) 

evidence/
  01_inventory/
    iot_assets.yaml
    export_iot_assets.csv
  02_network/
    vlan_diagram.png
    firewall_rules_before.txt
    firewall_rules_after.txt
  03_patch/
    patch_schedule.md
    emergency_workflow.md
    change_tickets/
  04_monitoring/
    dns_baseline.png
    firewall_alert_examples.txt
Enter fullscreen mode Exit fullscreen mode

Generate a tamper-evident manifest:

cd evidence
find . -type f -maxdepth 3 -print0 | sort -z | xargs -0 sha256sum > MANIFEST.sha256
Enter fullscreen mode Exit fullscreen mode

Sample report screenshot by our tool to check Website Vulnerability

Sample vulnerability assessment report generated with our free tool, providing insights into possible vulnerabilities.Sample vulnerability assessment report generated with our free tool, providing insights into possible vulnerabilities.

Lesson 7) Know when to bring experts in (and what to scope)

If any of these are true, it’s time for a scoped validation:

  • you inherited a messy CCTV/IoT environment
  • you suspect old port forwards / unknown remote access paths
  • segmentation changes are high-risk (retail, healthcare, multi-site ops)
  • you need an audit-ready report (insurance, SOC 2, ISO 27001, PCI, HIPAA)

A focused engagement should validate:

  • segmentation correctness (no accidental bypass)
  • remote admin/viewing paths (VPN/jump host, no hidden exposures)
  • credential hygiene and monitoring coverage
  • “blast radius” if an NVR is compromised

If you need an audit-friendly plan to reduce IoT and network risk, start at https://www.pentesttesting.com/.
For formal gap mapping, use https://www.pentesttesting.com/risk-assessment-services/ and remediation support at https://www.pentesttesting.com/remediation-services/.

Where our services fit (relevant links)

If your IoT/NVR project overlaps broader security work, these are commonly paired:

Related reading from our blog (recent)

Top comments (0)