Remote Code Execution via XMeye P2P Cloud in Xiongmai IP Cameras, NVRs and DVRs
SEC Consult also published a blog post regarding the identified security issues with further background information:
"Xiong-who?! And Why We Care"
Vendor description
"Hangzhou Xiongmai Technology Co., Ltd concentrates on security surveillance, Video intelligent research and development. We devote ourselves to providing good products, technical services for manufacturers, wholesaler and service provider, in order to offer better experience for our customers. We are global leading providers in security video products and technology. Established from 2009, many years development, the headquarter of XM locate in Yinhu Innovation Center, Fuyang district, Hangzhou now. Total registered capital reach to 60 million.
Now we owns nearly 2000 employees including a strong R&D team (more than 300 experienced engineers)."
Source: http://www.xiongmaitech.com/en/index.php/about/company/18
Business recommendation
SEC Consult has identified highly critical vulnerabilities in Xiongmai products and the "XMeye P2P Cloud" feature which is being used in many 3rd party OEM devices as well.
The vendor does not provide proper mitigations and hence it is recommended not to use any products associated with the XMeye P2P Cloud until all of the identified security issues have been fixed and a thorough security analysis has been performed by professionals.
Vulnerability overview/description
1) Predictable XMEye Cloud IDs (CVE-2018-17915)
All Xiongmai devices come with a feature called "XMeye P2P Cloud". It is a proprietary, UDP-based protocol that allows users to access their IP cameras or NVRs/DVRs via the internet. The feature is enabled by default, no setup by the user is required.
The device initiates and keeps a connection to a Xiongmai cloud server. All connections between clients and the devices are established via Xiongmai cloud servers. This approach allows users to connect to devices that are behind firewalls, NATed etc.
The unique, per-device identifier is the cloud ID. It is a 16 character long hexadecimal string (e.g. f7e708f21de0fde0). Anyone who knows the device identifier and the admin credentials can establish a connection to a device using the XMEye apps (Android, iOS) or a "VMS" desktop application.
The Cloud ID may be unique, but it is not random. It is derived (at boot time) from the device MAC address using a few simple operations (see get_sn_from_mac()) below.
An attacker can enumerate potential MACs/cloud IDs and find valid ones. Then use the weak default credentials to log in. This allows the attacker to watch the video feed, change the device configuration and possibly gain remote code execution using other vulnerabilities. The XMEye functionality allows an attacker to attack devices that are behind firewalls, NATed networks etc.
MAC addresses have a well defined structure: 3-octet OUI (Vendor) + 3-octet NIC ID OUIs are assigned by the IEEE. Interestingly Xiongmai does not own an OUI, but instead uses the OUIs of other companies.
The following OUIs are used by Xiongmai devices (OUIs based on internet research, scanning, company names based on https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries):
001210 WideRay Corp 001211 Protechna Herbst GmbH & Co. KG 001212 PLUS Corporation 001213 Metrohm AG 001214 Koenig & Bauer AG 001215 iStor Networks, Inc. 001216 ICP Internet Communication Payment AG 001217 Cisco-Linksys, LLC 001218 ARUZE Corporation 003E0B - Not assigned
We developed a cloud ID scanner that queries the Xiongmai cloud server. The responses indicate if there is a device online that uses the given cloud ID, plus provide the IP of a Xiongmai Cloud hop server that is geographically close to the device. One query is one UDP packet.
We scanned 0.02% of the devices (random choice) in each OUI range (16 Million devices per range) and extrapolated the results.
OUI: 001210; IDs checked 3,365; Devices online 3; Success rate: 0.1%; extrapolated devices online: 14,957 OUI: 001211; IDs checked 3,363; Devices online 9; Success rate: 0.3%; extrapolated devices online: 44,898 OUI: 001212; IDs checked 3,351; Devices online 492; Success rate: 14.7%; extrapolated devices online: 2,463,261 OUI: 001213; IDs checked 3,402; Devices online 218; Success rate: 6.4%; extrapolated devices online: 1,075,083 OUI: 001214; IDs checked 3,440; Devices online 67; Success rate: 1.9%; extrapolated devices online: 326,765 OUI: 001215; IDs checked 3,347; Devices online 255; Success rate: 7.6%; extrapolated devices online: 1,278,216 OUI: 001216; IDs checked 3,377; Devices online 448; Success rate: 13.3%; extrapolated devices online: 2,225,701 OUI: 001217; IDs checked 3,315; Devices online 286; Success rate: 8.6%; extrapolated devices online: 1,447,446 OUI: 001218; IDs checked 3,196; Devices online 1; Success rate: 0.0%; extrapolated devices online: 5,249 OUI: 003E0B; IDs checked 4,224; Devices online 21; Success rate: 0.5%; extrapolated devices online: 83,409
We estimate that there are about 9 Million devices online in the given OUI ranges.
The responses from the cloud server allow us to estimate the geographic distribution of the devices:
Hop server location: CN; extrapolated devices 5,438,757 Hop server location: DE; extrapolated devices 1,319,845 Hop server location: JP; extrapolated devices 577,743 Hop server location: SG; extrapolated devices 697,276 Hop server location: TR; extrapolated devices 189,260 Hop server location: US; extrapolated devices 742,101
We assume the hop server locations serve devices on the same continent.
2) Default admin password
The devices include an empty password for the admin user account which has the highest privileges on the devices and allows attackers to view the video feed or change the configuration.
3) Insecure default credentials for user "default" (CVE-2018-17919)
In the default configuration, the user account "default" exists on the device. The purpose of this user is not documented.
These user credentials can be used to log in to a device via the XMEye cloud (checked via custom client using the Xiongmai NetSDK).
This user seems to at least have permissions to access video feeds (more investigation required!).
4) Multiple unencrypted communication channels (CVE-2018-1791
All device communication is not encrypted. This includes the XMeye service and firmware update communication.
- An attacker can eavesdrop on video feeds or steal XMeye login credentials to get control over the device.
- An attacker can also impersonate the update server and offer malicious firmware updates.
5) Firmware update integrity not checked
Firmware updates are not signed. It is possible to create a firmware update file that contains malicious code (CWE-494). This is either possible by modifying the filesystems contained in a firmware update or modifying the "InstallDesc" file in a firmware update file. The "InstallDesc" is a text file that contains commands that are executed during the update.
Combining the vulnerabilities makes a very powerful attack, "The worst case scenario":
- Attacker exploits Predictable XMEye Cloud IDs to get list of valid IDs.
- Attacker exploits Insecure default credentials for user "admin" and possibly user "default", to get access to devices via the XMEye cloud.
- Attacker changes the DNS configuration of the devices to impersonate the update server "upgrade.secu100.net".
- Attacker sets up fake firmware update webserver.
- Attacker creates firmware updates containing malicious code. Imagination is the limit here, could be a Mirai-like agent or something focused on lateral movement in the target environment (local network of the organization using the devices).
- Attacker performs a firmware update on devices via the XMEye cloud API command
H264_DVR_Upgrade_Cloud()(custom client using the Xiongmai NetSDK). The malicious firmware update is persisted on the devices. If the attacker desires, it cannot be removed by rebooting the device.
Proof of concept
1) Predictable XMEye Cloud IDs (CVE-2018-17915)
The Python code to derive the cloud ID from the MAC address of the device has been removed from this advisory.
2) Default admin password
The default username and password is admin:[BLANK].
3) Insecure default credentials for user "default" (CVE-2018-17919)
The credentials for the hardcoded user "default" are "tluafed"
4) Multiple unencrypted communication channels (CVE-2018-17917)
No proof of concept available for this advisory.
5) Firmware update integrity not checked
The following "InstallDesc" contents would launch an arbitrary command, in this case starting the telnet daemon.
"UpgradeCommand" : [ { "Command" : "Shell", "Script" : "/bin/busybox telnetd" }, Vulnerable / tested versions
Xiongmai acts as an OEM. Various vendors sell branded devices with Xiongmai hardware/firmware inside. More information can be found in the blog post: "Xiong-Who?! And Why We Care"
Vendor contact timeline
| 2018-03-15: | Contacting ICS-CERT for coordination support. |
| 2018-03-26: | ICS-CERT assigns ICS-VU-638768 for this case. |
| 2018-05-04: | ICS-CERT provides answer from Xiongmai, the vendor argues that SEC Consult tested the "old" firmware/devices. Furthermore, per default user passwords need to be changed upon first login since 2016. They informed their key customers to update to the latest firmware & change default passwords. |
| 2018-05-07 | SEC Consult anwser: we verified that we are running the latest firmware versions and they are affected. Furthermore, there is no password change request implemented. |
| 2018-05-15 | SEC Consult sends further/newly identified vulnerabilities to ICS-CERT for Xiongmai, describing worst case scenario, asking to inform FTC about this case. |
| 2018-05-15 | ICS-CERT: Xiongmai is very slow in responding, and requests for affected firmware versions have been sent to them already. |
| 2018-05-25 | Asking ICS-CERT for a status update. |
| 2018-05-29 | ICS-CERT: small update from Xiongmai received: –Vendor Response– Regarding the device information from Researcher, it is our "old" model and "old" firmware version, that's why there is no more update. Even for DVR model it is already discontinued, therefore we will work a new "latest" version based on current baseline version, for those Researcher's devices specially. –End Vendor Response– Xiongmai also said they will provide version numbers for fixed & vulnerable versions, but no answer. |
| 2018-06-04 | ICS-CERT: Xiongmai provided a firmware update for our test devices. |
| 2018-06-11 | SEC Consult: tested firmware "SimpGeneral_General_AHB7804R-ELS_V4.02.R11.Nat.OnvifC.20180525.bin" There are no apparent changes, it uses the same cloud ID, the admin password is still empty and there are no warnings to change the password (checked via web interface and VMS software) |
| 2018-06-15 | ICS-CERT: received an update from Xiongmai as to why the firmware did not seem to fix anything: –Vendor Response– After check the message we believe there is some misunderstanding on IE operation due to the Plug-in ( or called as ActiveX ) issues, As currently this ActiveX technology even is quite an "ancient" technology but still widely used in most of Video Surveillance products. The issues that Researcher have met, it is due to his PC still have "old" plug-in installed, and with new update of firmware we provided, The camera and NVR already have functions but his PC with "old" plug-in, it is like using same "old" computer to connect new devices, that's why he still didn't see anything new. So the solution is quite simple, just delete and uninstall "old" Plug-in, and then install new one from devices with new version. Please kindly check attached file, we have some instructions and steps, on how to renew this ActiveX, please help to forward to this Researcher and we believe he could understand the reason, and he could recheck about the new firmware we had sent. –End Vendor Response– |
| 2018-06-18 | SEC Consult: the ActiveX controls are unrelated to any of the issues we reported. For the sake of completeness, SEC Consult tested it anyways and all the security issues are still not fixed. Raising doubts that the vendor understands the impact. |
| 2018-06-21 | ICS-CERT: concurs with our opinion and if Xiongmai does not fix the issues we will have to publish. Xiongmai did not yet react to the additional findings reported on 2018-05-15. |
| 2018-07-24 | ICS-CERT: Xiongmai provided "improved" instructions to help ensure the forced password change happens. |
| 2018-07-27 | SEC Consult: the default admin password is just a small subset of the identified critical issues. Intention to publish end of September. Asking further questions to Xiongmai:
|
| 2018-08-01 | ICS-CERT: questions & deadline have been passed to Xiongmai. Possibility of contacting CNCERT/CC. |
| 2018-09-04 | ICS-CERT: Still waiting for a response from Xiongmai. CNCERT/CC has responded. |
| 2018-09-24 | SEC Consult: Asking for a status update. Proposed release date 8th October Recommendations are to stop using the devices, other workarounds are not effective. |
| 2018-09-27 | ICS-CERT: CNCERT/CC only replied with generic email response. ICS-CERT proposes Tuesday or Thursday for releases. Decided for the 9th October. |
| 2018-10-04 | Informing CERT-Bund and CERT.at about the security issues and release. |
| 2018-10-09 | Coordinated release of security advisory. |
Solution
The vendor did not provide proper mitigations and solution attempts since ICS-CERT contacted them back in March 2018.
SEC Consult advises not to use the products of Xiongmai and any 3rd party OEM device associated with the XMeye cloud feature.
Workaround
There are no workarounds available as the devices are connected via the cloud, the usual recommendations changing default passwords, strict firewalling and network segmentation unfortunately do not mitigate the whole range of discovered issues.
Advisory URL
https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html
EOF Stefan Viehböck / @2018
Contact our local offices.
No comments:
Post a Comment