CVE-2023-41928

Executive Summary

CVE-2023-41928 is a cryptographic weakness affecting Kiloview P1/P2 video devices. The device's remote TLS server accepts deprecated TLS protocol versions, exposing management and media-control traffic to downgrade, interception, and decryption attacks. The NVD has rated this vulnerability CVSS 5.3 (Medium), and no public exploit, PoC, or in-the-wild exploitation evidence has been reported.

Technical Analysis

The CNA title — "Remote server offers deprecated TLS protocol in Kiloview P1/P2 devices" — characterizes this issue as a server-side protocol negotiation weakness. The NVD description confirms that the device "is observed to accept deprecated TLS protocols," increasing the risk of cryptographic weaknesses.

The vulnerability mechanism lies in the TLS handshake. When a client connects to the device's remote server, the server selects the highest mutually supported protocol version. A server that continues to accept SSLv3, TLS 1.0, and/or TLS 1.1 allows clients (including malicious ones) to negotiate a session below the recommended minimum of TLS 1.2. This is a classic instance of CWE-757: Selection of Less-Secure Algorithm During Negotiation. The NVD entry does not assign a CWE, and no affected version range, specific endpoint, or configuration parameter is disclosed in the public description.

The deprecated protocol families are associated with well-documented cryptographic weaknesses: SSLv3 is vulnerable to the POODLE padding-oracle attack (CVE-2014-3566); TLS 1.0 and TLS 1.1 support cipher suites and modes (CBC, RC4, 3DES) that enable BEAST, Lucky13, and other plaintext-recovery techniques. Because the NVD description is sparse, the precise cipher suite configuration of the Kiloview P1/P2 devices is not publicly documented. However, the mere acceptance of deprecated TLS versions makes the session weaker than a TLS 1.2+ session, regardless of the specific cipher negotiated.

The attack surface is the device's network-facing TLS service, reachable from the local network or from the Internet if the management interface is exposed. An on-path adversary can actively downgrade the connection by stripping or modifying the offered protocol versions in the ClientHello; a passive adversary can benefit from the weaker cryptography to recover session keys or plaintext in offline attacks. Insufficient technical detail is available for code-level analysis; the vulnerability is best understood at the protocol-negotiation class level.

Exploitation Scenarios

No public PoC or exploit code is available for CVE-2023-41928; the attack chain below is inferred from the vulnerability class (deprecated TLS protocol acceptance) and the device profile.

1. Reconnaissance/target identification — An attacker locates Kiloview P1/P2 devices via Internet-wide scanning (e.g., Shodan using the dorks listed in METADATA) or by probing the local network for devices whose remote TLS service responds to handshake probes. The attacker enumerates supported protocol versions using standard TLS scanning tools that request SSLv3, TLS 1.0, or TLS 1.1 and observe whether the server agrees to negotiate.

2. Triggering the flaw — The attacker initiates a TLS handshake offering a deprecated version (for example, SSLv3 or TLS 1.0). The Kiloview device, accepting deprecated protocols, responds with a ServerHello selecting one of those versions. If the attacker is on-path between a legitimate client and the device, they can strip the client's highest supported version from the ClientHello, forcing both parties to fall back to a deprecated version.

3. Payload/execution at the class level — No malicious payload is required; the weakness is in the negotiation logic. After downgrading, the attacker applies known cryptanalytic techniques against the deprecated protocol family (e.g., padding-oracle or CBC-mode attacks) to recover plaintext, or captures ciphertext for offline key recovery. The attacker can also inject or modify traffic if the weak protocol permits it.

4. Post-exploitation impact — Recovered plaintext may include device credentials, configuration commands, or video-stream control data. An attacker who obtains administrative credentials could take over the device, alter its configuration, redirect video streams, or pivot into the broader video-surveillance network. In a CCTV/remote-broadcast environment, this can result in loss of confidentiality and availability of the video infrastructure.

Impact Assessment

The NVD assigns a CVSS base score of 5.3 (Medium); the vector string is not published, so specific subscore values cannot be derived. The EPSS score is 0.00133 (3.3rd percentile of exploited CVEs), indicating that real-world exploitation is currently rare. The CVE is not listed in the CISA KEV catalog, and no known threat-actor campaigns or exploit-in-the-wild evidence exists.

The primary security impact is on the confidentiality of traffic transiting the Kiloview P1/P2 remote server. In typical deployments, these devices are used in video transport and remote-production workflows, where an attacker with network visibility could eavesdrop on management sessions or video control channels. Because the flaw concerns protocol acceptance rather than memory corruption or authentication bypass, the immediate blast radius is limited to the device itself and the network segment it serves. However, compromised video encoders are attractive footholds in OT/broadcast environments, and a successful downgrade of a management session could lead to full administrative compromise.

Given the absence of a published CVSS vector, the Medium rating likely reflects the moderate confidentiality impact and the attacker requirement of network position (on-path or passive observation) rather than remote unauthenticated code execution.

Detection Guidance

Detection of CVE-2023-41928 is best performed at the network layer, where TLS protocol versions are observable in handshake metadata. The rules below are heuristic and require tuning to the local asset inventory: alerting on any deprecated TLS usage in the environment will generate false positives from legacy clients. Restrict these rules to traffic to/from known Kiloview P1/P2 device IP addresses where possible.

Sigma Rule

Sigma rule detecting deprecated TLS protocol versions recorded in Zeek SSL logs (adjust field names for your log pipeline):

title: Deprecated TLS Protocol Negotiation - Kiloview P1/P2
id: 4f2b9a1e-6c2d-4a9b-b3d7-8a1c2e3f4a5b
status: experimental
description: Detects SSLv3/TLSv1.0/TLSv1.1 negotiation, associated with CVE-2023-41928
logsource:
  product: zeek
  service: ssl
detection:
  selection:
    version:
      - 'SSLv3'
      - 'TLSv10'
      - 'TLSv11'
  condition: selection
fields:
  - id.orig_h
  - id.resp_h
  - id.resp_p
  - server_name
  - version
falsepositives:
  - Legacy clients and monitoring tools in the environment
  - TLS scanners performing compliance checks
level: medium

YARA Rule

YARA rule for static analysis of firmware images or configuration dumps that reference deprecated TLS protocol identifiers:

rule CVE_2023_41928_Kiloview_Deprecated_TLS
{
    meta:
        author = "Valters IT"
        description = "Detects artifacts referencing deprecated TLS/SSL protocol strings in Kiloview P1/P2 firmware or configs"
        cve = "2023-41928"
        date = "2025-05-01"
    strings:
        $a = "SSLv3" ascii wide
        $b = "TLSv1.0" ascii wide
        $c = "TLSv1.1" ascii wide
        $d = "PROTOCOL_TLSv1" ascii wide
    condition:
        filesize < 50MB and (2 of ($a, $b, $c, $d))
}

Suricata IDS Rule

Suricata rules alerting on TLS handshakes that negotiate deprecated protocol versions. One rule per version is required, as the tls.version keyword matches a single value:

# Alert on SSLv3 negotiation
alert tls $HOME_NET any -> any any (msg:"CVE-2023-41928 - Kiloview P1/P2 SSLv3 negotiation"; tls.version:"SSLv3"; classtype:policy-violation; threshold: type both, track by_dst, seconds 360, count 3; sid:2023419281; rev:1;)

# Alert on TLS 1.0 negotiation
alert tls $HOME_NET any -> any any (msg:"CVE-2023-41928 - Kiloview P1/P2 TLSv1.0 negotiation"; tls.version:"TLSv1"; classtype:policy-violation; threshold: type both, track by_dst, seconds 360, count 3; sid:2023419282; rev:1;)

# Alert on TLS 1.1 negotiation
alert tls $HOME_NET any -> any any (msg:"CVE-2023-41928 - Kiloview P1/P2 TLSv1.1 negotiation"; tls.version:"TLSv1.1"; classtype:policy-violation; threshold: type both, track by_dst, seconds 360, count 3; sid:2023419283; rev:1;)

Elastic Detection

EQL query for Elastic Security. Adapt field names to your ECS/Zeek mapping; the example assumes network.protocol and tls.version fields:

network where network.protocol == "tls" and tls.version in ("SSLv3", "TLSv1.0", "TLSv1.1")
// Add a filter to constrain to Kiloview asset IPs:
// and destination.ip in (10.10.0.0/24)

Splunk SPL Query

Splunk query against Zeek SSL logs (sourcetype bro:ssl:json or zeek:ssl:json). Adjust version field values to match your sourcetype (TLSv10, TLSv11, SSLv3 are Zeek conventions):

index=netsec sourcetype="bro:ssl:json"
  version IN ("SSLv3", "TLSv10", "TLSv11")
  NOT dest_ip IN (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
| stats count by src_ip, dest_ip, dest_port, version
| where count >= 3
| sort - count

If a Kiloview asset list is maintained, replace the RFC1918 filter with dest_ip IN (kiloview_assets.csv) or a lookup macro kiloview_assets.

Wazuh OSSEC Rule

Local Wazuh rule for alerting on syslog/sensor events that mention deprecated TLS versions. Add to /var/ossec/etc/rules/local_rules.xml:

<group name="tls-policy,">
  <rule id="100928" level="8" frequency="1">
    <decoded_as>syslog</decoded_as>
    <regex>(TLSv1\.0|TLSv1\.1|SSLv3)</regex>
    <description>CVE-2023-41928: Deprecated TLS protocol negotiation observed on Kiloview P1/P2 device</description>
    <group>weak_crypto,</group>
  </rule>
</group>

This rule assumes a network sensor or device log emits TLS version information; tune the regex to match your log format.

Mitigation & Patch Guidance

Patch confidence for CVE-2023-41928 is 2/4 (CLAIMED): only the CNA states that a patch exists, no firmware version or advisory URL has been released, and the claim is not independently confirmed.

1. Immediate mitigations

• Restrict access to the Kiloview P1/P2 remote management service using firewall/ACL rules; block Internet exposure unless strictly required.
• If the device configuration exposes a TLS version setting, enforce a minimum of TLS 1.2 and disable SSLv3/TLS 1.0/TLS 1.1.
• Place devices on a dedicated VLAN segmented from general corporate traffic and video-endpoint networks.
• Require a VPN or encrypted tunnel for all remote management sessions.

2. Patch/upgrade steps

• Contact Kiloview support to confirm whether a patched firmware exists for the affected P1/P2 devices and to obtain the updated build.
• Because the CNA patch claim is unconfirmed, do not assume a fix exists; verify the firmware version after upgrade and perform a TLS version scan to confirm deprecated protocols are rejected.
• Plan a maintenance window for the firmware upgrade, as video devices may experience downtime.

3. Long-term hardening

• Establish a regular TLS configuration audit (e.g., using TLS scanning tools) for all network-exposed devices.
• Rotate all credentials associated with the devices after upgrading.
• Maintain an asset inventory of video/broadcast devices and monitor them for unauthorized handshake activity.
• Track the CVE and CNA advisory for updates; request disclosure of the patched version range.

References

1. NVD Entry — https://nvd.nist.gov/vuln/detail/CVE-2023-41928
2. CVE.org Record — https://www.cve.org/CVERecord?id=CVE-2023-41928
3. CNA Title (kiloview P1/P2): "Remote server offers deprecated TLS protocol in Kiloview P1/P2 devices" — no public advisory URL available as of this report.
4. CISA Known Exploited Vulnerabilities (KEV) Catalog — CVE-2023-41928 is NOT listed; no in-the-wild exploitation evidence has been reported.
5. No known threat-actor campaigns, public PoC, exploit code, or Nuclei templates are associated with this CVE as of the date of this report.