Author

Stefan Viehbock

Risk

[

Security Risk Critical

]

0day-ID

0day-ID-31295

Category

remote exploits

Date add

10-10-2018

CVE

CVE-2018-17915
CVE-2018-17917
CVE-2018-17919

Platform

linux

=======================================================================
              title: Remote Code Execution via XMeye P2P Cloud
            product: Xiongmai IP Cameras, NVRs and DVRs
                     incl. 3rd party OEM devices
 vulnerable version: see below
      fixed version: -
         CVE number: CVE-2018-17915, CVE-2018-17917, CVE-2018-17919
             impact: Critical
           homepage: http://www.xiongmaitech.com/en/
              found: 2018-03-05
                 by: Stefan ViehbAPck (Office Vienna)
                     SEC Consult Vulnerability Lab

                     An integrated part of SEC Consult
                     Europe | Asia | North America

                     https://www.sec-consult.com

=======================================================================

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 [1]):
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.

[1] https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries


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 [2]).

This user seems to at least have permissions to access video feeds (more
investigation required!).


4) Multiple unencrypted communication channels (CVE-2018-17917)
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":
a) Attacker exploits Predictable XMEye Cloud IDs to get list of valid IDs.
b) Attacker exploits Insecure default credentials for user "admin" and
   possibly user "default", to get access to devices via the XMEye cloud.
c) Attacker changes the DNS configuration of the devices to impersonate
   the update server "upgrade.secu100.net".
d) Attacker sets up fake firmware update webserver.
e) 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).
f) Attacker performs a firmware update on devices via the XMEye cloud API
   command H264_DVR_Upgrade_Cloud() (custom client using the Xiongmai NetSDK
   [2]). The malicious firmware update is persisted on the devices. If the
   attacker desires, it cannot be removed by rebooting the device.

[2] http://www.xiongmaitech.com/service/down_detail/83/185.html


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 products:
-----------------------------
Xiongmai acts as an OEM. Various vendors sell branded devices with Xiongmai
hardware/firmware inside.

More information can be found in the blog post: https://r.sec-consult.com/xmeye


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:
            - What devices are affected by the vulnerabilities?
            - What is the plan/timeline to fix the issues?
            - Are there issues that will not be fixed? Why?
            - Are there devices that will not receive fixes for the
              vulnerabilities? Which ones?
            - Will the updates be rolled out automatically or are manual steps by
              the user required?
            - Will Xiongmai publish a public warning/advisory on their website?
            - Will Xiongmai inform their OEM customers about the vulnerabilities
              so they can inform end users?
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.

#  0day.today [2024-12-23]  #