This afternoon I took the opportunity of being in work at a weekend to install a monitoring bridge between one of my customer LANs and their Managed Broadband service. The managed broadband provider doesn’t give any insight into the traffic flowing through their CISCO router and I found a spare ALIX box sitting around that would be perfect to install between the LAN and the CISCO to bridge and monitor the cable.
This will give me insight into which machines on the LAN are using the most bandwidth at any given time and also allow me my own firewalling (don’t get me started on how insecure the managed, double-NAT, broadband service is. A formal complaint that is currently going through bureaucracy to get remedied).
However the first thing I noticed while tcpdumping was the CCTV DVR system making a lot of requests and, some, to a host in China!
The customer uses a Swann DVR9-4200 with “Build No.”: “build 1113”.
![91425H[1]](https://thecomputerperson.files.wordpress.com/2015/05/91425h1.jpg)
Traffic looks a bit like this – constantly:
Ironically the first IP I chucked into Google / whois was “61.188.37.216”:
inetnum: 61.188.0.0 – 61.188.255.255
netname: CHINANET-SC
descr: CHINANET Sichuan province network
descr: China Telecom
descr: A12,Xin-Jie-Kou-Wai Street
descr: Beijing 100088
country: CN
admin-c: CH93-AP
tech-c: XS16-AP
Which was more than worrying.
The next I searched was “46.137.188.54”, which resolves to an Amazon AWS / Cloud Computing system. This time when the search was twinned with the word “Infection” it came out with a SANS Internet Storm Center article (The SANS Institute is a private U.S. company that specializes in information security and cybersecurity training.).
This article is by someone who bought a Smart Plug from Supra-Electronics. They were clearly interested in how the device worked and also noticed their device sending information to some of the same IP addresses that the Swann DVR is sending packets to in my captures. His discoveries are here:
IP FQDN NetName Country 50.19.254.134 m1.iotcplatform.com AMAZON-EC2-8 US 122.248.234.207 m2.iotcplatform.com AMAZON-EC2-SG Singapore 46.137.188.54 m3.iotcplatform.com AMAZON-EU-AWS Ireland 122.226.84.253 JINHUA-MEIDIYA-LTD China 61.188.37.216 CHINANET-SC China 220.181.111.147 CHINANET-IDC-BJ China 120.24.59.150 m4.iotcplatform.com ALISOFT China 114.215.137.159 m5.iotcplatform.com ALISOFT China 175.41.238.100 AMAZON-AP-RESOURCES-JP Japan
All the same IPs were also present in my packet captures from the Swann DVR.
Luckily the article on the SANS site references some hostnames, The domain relating to the IPs is IOTCPLATFORM.COM. I’m not sure how the SANS guy got hold of the host names because the DVR, in my case, didn’t send any DNS requests.
This domain doesn’t appear much on Google, a few DVR exe files seem to use it (results on VirusTotal) and an Android application does too. The website at http://www.IOTCPLATFORM.COM is just a GoDaddy holding page.
The SANS article and whois then link to ThoughTek who apparently provide p2p style communication between devices. This is likely to allow roaming users to connect to the DVR without having to fiddle about knowing the device IP or having to port forward.
However – the IOTCPlatform site should at least explain what their connections / hosts do!
The DVR should explain that it will make requests to a 3rd party even if you don’t use their “find my device using it’s QRCode” function!
For the moment I’ve just removed the default gateway from the DVR so it isn’t sitting there flapping around sending whatever data it wants to some random 3rd party.
Some other people have also grumbled about this but were harder to find on the internet. QNAP NAS devices also might do similar.
thecomputerperson 
I just posted the following on another IP cam forum. Thought you might be interested. BTW, one of the IP addresses leads us to China as well.
I and several other users of Foscam IP cams are having the same problem. I have several of the cameras but the new models are having the issue of establishing sessions to servers all over the world. Foscam tech support has provided responses from implement port filtering to solve the problem to turn off all P2P, DDNS, and so on services. They admitted the problem. Turning off all of the services does not solve the issue.
I turned on router port filtering for port 10001 and that solved the WAN connection session problems, but the cameras keep sending requests to the router which are rejected now. Other people are seeing the issue on other ports too. As soon as filtering is turned off the cameras flood the network with remote sessions causing excessive router RAM usage and virus warning messages. This issue has been opened at least three times on Foscam’s forum under different thread names. Here is the latest for your review:
http://foscam.us/forum/foscam-dialing-out-to-suspect-hosts-t17699.html#p69889
My thread name is Drooler.
Any idea who we might contact in the press to raise public awareness of this issue. I sure would not want a baby cam to be sending back live video to some pedophile in some overseas country. Some of the people on the forum have trapped the data packet information being sent to remote servers.
Pingback: This is Why People Fear the ‘Internet of Things’ | Dennis Nadeau Complaint Blog
Pingback: This is Why People Fear the 'Internet of Things' - Krebs on Security - Go Internet
Pingback: This is Why People Fear the ‘Internet of Things’ – Krebs on Security | Gadget Power Up
Pingback: This is Why People Fear the ‘Internet of Things’ – Krebs on Security | best laptop depot
Thank you – we appreciate you for writing this article and raising awareness for security issues with the Internet-of-Things.
ThroughTek works with device manufacturers and technology brands to establish secure and direct communications between devices, to enable direct data transfer without storing data, while minimizing exposure of devices. A common misconception about P2P is it means for downloading and file sharing for illegal use and copy right infringement. However, in our case, this actually reduces the risk and provides a more secure way for data transfer. Our core technology especially becomes crucial when handling IP Camera and surveillance devices, as we are able to deliver video streaming securely from camera devices directly to smartphones.
As a standard, we include encryption to secure communication with the device and authentication for access control to validate identity and to determine permissible interactions. As well, we continue to work with IoT partners to handle data transmission security and communication from hub to cloud.
As the concept of connecting things is slowly being adopted, it is important that industry leaders in the IoT space prioritize to increase overall understanding. It will take time to holistically look at the entire ecosystem and identify ways to improve IoT security.
We are glad to see that the public involved in discussions, and we take your feedback seriously as an opportunity for future improvements. Please send us a note if you have more questions or feel free to send us an email directly mkt@tutk.com.
ThroughTek
Pingback: Krebs, Brian – This is Why People Fear the ‘Internet of Things’ – 20160218 | Let Snowden In
I recently bought a QIHAN Dvr, cnineese brand obviously. I noticea a very suspicious outgoing traffic from the Dvr to the following IPs – 188.213.172.33 – Italy, ARUBA-NET, Aruba S.p.A. – Dedicate server Farm2, 101.200.83.161 – China, ALISOFT, Aliyun Computing Co., LTD and 203.195.157.36 – Beijing, China, TencentCloud, Tencent cloud computing (Beijing) Co., Ltd.
This is at lest a little disturbing and suspicious. I blocked this ips at my router’s side using iptables and voila, no more unwanted connections. This is not connected to ddns or something like that becaouse everything else works fine. There are a lot of huge security vulnerabilities in these dvr, staring from activex which is used for web management, weak passwords and who knows what else.
Add another one to this list.. android app: iMiniCam.
I discovered my phone generating outbound udp packets in the 10000 port range to a variety of servers:
47.88.3.6 (alibaba.com)
47.88.9.191 (alibaba.com)
54.200.199.150 (amazon.com)
83.50.55.6 (telefonica.es)
120.27.7.78 (alisoft – china)
112.124.40.254 (alisoft – china)
The app has a background service sending packets roughly every second. So, this is happening continuously even when the app isn’t running. The payload looks to be a guid – with some other bytes I can’t decypher. Response packets include the same guid and additional ip addresses. The odd thing is these packets are being sent out the gprs network and not wifi. Perhaps it’s a programming mistake just grabbing the first interface, but feels more like botnet activity.
Add as well “Cloud-Link” App, running on a Qnap-Turbo Station NAS:
54.225.148.181
61.188.37.216
46.137.188.54
Pingback: ловим китайских шпионов | Amin 's Blog
I investigate “BSP-Security” cctv-camera (relabeled hikvision) and also found suspicious traffic to IP 101.200.83.161 and 203.195.157.36, also attempts to dns lookup domain lbs1.goolink.org was found.
All checkboxes related to cloud servers set off.
Swann NVR8-8580 is contacting multiple hosts in China multiple times per second:
114.215.137.159:10240
120.24.59.150:10240
61.188.37.216:10240
Pingback: C'est pourquoi les gens craignent l'"Internet des objets" - Breach Trace