Critical Vulnerabilities In Hikvision Hik-Connect, Hikvision Hides From Public

IPVM discovered vulnerabilities that allowed taking over any Hik-Connect user's account simply by listening to network traffic.

Hikvision failed to encrypt logs, plus exposed a critical login token, which allowed an attacker to take over the Hik-Connect account. Hikvision fixed it but refused to publicly disclose it despite IPVM asking them repeatedly to do so.

For full technical details, see IPVM Research Report: Hik-Connect 5 App / JWT Vulnerabilities Analyzed.

Risk / Danger

Hik-Connect 5 was first released in the middle of the last year, which implies this vulnerability has been public for nearly a year and perhaps longer (if this was included in earlier versions).

The danger of the vulnerabilities is that it allows for a passive approach for an attacker, to listen to network traffic on, for example, Public Wi-Fi Hotspots or Corporate networks with firewalls with HTTP packet inspection.

Further, an attacker is able to view the victim's login details when the victim connects and logs into Hik-Connect cloud normally, and does not involve a malicious link or actively engaging with the victim.

However, if a Hik-Connect user only logged into Hik-Connect servers over a cellular connection, or secure home Wi-Fi, the danger of an external attacker listening to that network traffic is significantly lower.

See full details of the vulnerability: Hik-Connect 5 App / JWT Vulnerabilities Analyzed

Refuse To Disclose

Hikvision has refused to create a CVE or send any type of public disclosure.

IPVM reported the vulnerability to Hikvision on May 1, 2023, and Hikvision HSRC confirmed the receipt of the IPVM report the same day. We requested feedback on May 4, 2023, to which Hikvision acknowledged the vulnerability on May 5, 2023, and told IPVM that the issue has been identified and a fix is being developed.

We asked Hikvision on May 7, 2023, IPVM about creating a CVE but they ignored the question:

The issue has been fixed on the cloud server (APP not need to be updated).

Thank you again for letting us know your finding.

IPVM asked again on May 8, 2023, if Hikvision will assign a CVE to the found vulnerability, and if they will not, what is the reason for not assigning a CVE, Hikvision replied on May 10, 2023, saying that the rules do not require them to since this does not require customers to take action:

We will evaluate this cloud service configuration issue according to CVE CNA Rules

7.4.4 CNAs MAY assign a CVE ID to a vulnerability if:

1、The product or service is owned by the CVE Numbering Authority (CNA)

2、The product or service is not customer controlled, and

3、The vulnerability requires customer or peer action to resolve

Best Wishes!

Finally, Hikvision confirmed that they refused to create a CVE on May 19th after we asked them 2 more times:

Since this issue has been resolved and it does not require any customer or peer action to resolve, per the CVE Rules, Hikvision has chosen to not create a CVE.

Thank you again for working with us to identify and resolve this issue.

Last year, IPVM found a vulnerability impacting certain Hikvision firmware versions with Hikvision also refusing to file a CVE for that.

Hikvision Using CVE Count for Marketing

Choosing not to assign works strongly in Hikvision's favor, and is particularly troubling because Hikvision has also compared its own CVE count to other surveillance companies.

In 2021, Ex-Hikvision CSO, Fred Streefland (incorrectly) touted Hikvision's "serious" cybersecurity focus, based on its CVE count:

Since the foundation of Hikvision (2001), ONLY 15 vulnerabilities (CVEs) have been detected in the Hikvision devices, so if you compare this number this with other vendors, then you must admit that Hikvision takes cyber security very seriously;

He specifically countered an Axis Communications employee:

please compare the numbers of vulnerabilities (CVEs) between Axis and Hikvision and you might come to different conclusion!

While Axis has been transparent with its public disclosures, Hikvision continues to demonstrate a lack of ethical public disclosure of vulnerabilities.

Hikvision's Own Vulnerability Disclosure Recommendations Not Followed

A November 2022 Hikvision US blog post emphasized the importance of "developing a systematic program to manage vulnerability disclosure", though they are not following the program in this case:

The basic structure of a vulnerability management program includes these three elements:

1. Discover the vulnerability
2. Report it to the vendor
3. Coordinate public disclosure of the vulnerability with a patch

The process begins with the discovery of a vulnerability. Malicious threat actors and ethical security researchers are constantly looking for vulnerabilities in popular software. Hackers seek to exploit these vulnerabilities for personal and financial gain. Ethical researchers seek to have these vulnerabilities fixed. Typically, when a security researcher discovers a vulnerability in a product, they will alert the software vendor who owns and manages that product. The researcher then works with the vendor to identify the vulnerability, mitigate it by creating a patch, and test it to ensure that the patch fixes the vulnerability. Once that is completed, we move into the public disclosure component of the process. [Empasis added]

Further Hikvision's own Understanding Vulnerabilities White Paper (IPVM Report) states:

Outlook

In the short term, Hikvision is helping itself to deceive regulators around the world about its cybersecurity issues by hiding them, but long term, this hurts Hikvision's users and the public. We encourage Hikvision to be transparent and attempt to win the public's trust.