PUBLIC - This article does not require an IPVM subscription. Feel free to share.
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.
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.
IPVM is the leading authority on physical security technology, including video, access, weapons detection, and more. Sign up to stay up to date on the latest industry news, investigations, and product updates.
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
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.
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:
Discover the vulnerability
Report it to the vendor
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]
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.
What are the chances of getting the 'Hik-Connect 5 App / JWT Vulnerabilities Analyzed' report released outside of research? This looks like a MinM and considering it is from Bashis I don't doubt the validity. I am more curious on the technical details. Without a CVE I haven't found any other relevant information.
No, the full technical details are Research only. We pay for this ourselves and it requires a lot of skill and time. If you want to support our efforts to make video surveillance more cybersecure and better understand how these products work, please join Research.