IoT: The Rise of the Machines (Guest Diary)

IoT: The Rise of the Machines (Guest Diary)
[This is a guest diary submitted by Xavier Mertens] Our houses and offices are more and more infested by electronic devices embedding a real computer with an operating system and storage. They are connected to network resources for remote management, statistics or data polling. This is called the "Internet of Things" or "IoT". My home network is hardened and any new (unknown) device connected to it receives an IP address from a specific range which has no connectivity with other hosts or the Internet but its packets are logged. The goal is to detect suspicious activity like data leaks or unexpected firmware updates. The last toy I bought yesterday is a Smart Plug from Supra-Electronics. This device allows you to control a power plug via your mobile device and calculate the energy consumption with nice stats. I had a very good opportunity to buy one for a very low price (25€). Let's see what's inside.... The documentation mentions a setup procedure and management via a mobile device (with a free app for IOS or Android) but the first reflex is to scan the box. Interesting, a webserver as well as a telnet server are waiting for packets. Let's try common credentials like admin/admin and... `$ telnet 192.168.254.225 Trying 192.168.254.225... Connected to 192.168.254.225. Escape character is '^]'. (none) login: admin Password: BusyBox v1.12.1 (2014-07-31 06:32:52 CEST) built-in shell (ash) Enter 'help' for a list of built-in commands. #` Immediately after the boot sequence, the device started to try to communicate with remote hosts: Amongst DNS requests and NTP synchronization, a lot of traffic was generated to different IP addresses over UDP/10001. The same packet being sent to different hosts. The payload was a block of 60 bytes: I was not able to decode the content of this payload, please comment if you recognize some patterns. The device also performs a regular connectivity check via a single ICMP ECHO packet sent to www.google.com (every 5 mins). This network traffic is generated by the process called RDTServer: # ps PID USER VSZ STAT COMMAND 1 admin 1400 S init 2 admin 0 SWN [ksoftirqd/0] 3 admin 0 SW< [events/0] 4 admin 0 SW< [khelper] 5 admin 0 SW< [kthread] 6 admin 0 SW< [kblockd/0] 7 admin 0 SW< [kswapd0] 8 admin 0 SW [pdflush] 9 admin 0 SW [pdflush] 10 admin 0 SW< [aio/0] 11 admin 0 SW [mtdblockd] 18 admin 1084 S nvram_daemon 19 admin 1612 S goahead 20 admin 872 R RDTServer 24 admin 1400 R telnetd 26 admin 872 S RDTServer 27 admin 872 S RDTServer 33 admin 872 S RDTServer 34 admin 872 S RDTServer 35 admin 872 S RDTServer 36 admin 872 S RDTServer 53 admin 1400 S /bin/sh 238 admin 0 SW [RtmpCmdQTask] 239 admin 0 SW [RtmpWscTask] 366 admin 1400 S -sh 505 admin 1400 R ps 678 admin 1400 S udhcpd /etc/udhcpd.conf 1116 admin 1396 S udhcpc -i apcli0 -s /sbin/udhcpc.sh -p /var/run/udhcp 1192 admin 872 S RDTServer 1207 admin 772 S ntpclient -s -c 0 -h ntp.belnet.be -i 86400 # I grabbed a copy of the RDTServer binary (Mips) and using the "strings" command against the file revealed interesting stuff. The IP addresses used were found in the binary: 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 Seeing packets sent to China is often suspicious! The domain name iotcplatform.com belongs to ThroughTek, a company specialized in IoT and M2M ("Machine to Machine") connection platforms: Domain Name: IOTCPLATFORM.COM Registry Domain ID: 1665166563_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.godaddy.com Registrar URL: http://www.godaddy.com Update Date: 2014-07-09T11:44:15Z Creation Date: 2011-07-04T08:50:36Z Registrar Registration Expiration Date: 2016-07-04T08:50:36Z Registrar: GoDaddy.com, LLC Registrar IANA ID: 146 Registrar Abuse Contact Email: abuse@godaddy.com Registrar Abuse Contact Phone: +1.480-624-2505 Registry Registrant ID: Registrant Name: Charles Kao Registrant Organization: Registrant Street: 4F., No.221, Chongyang Rd., Registrant City: Taipei Registrant State/Province: Nangang District Registrant Postal Code: 11573 Registrant Country: Taiwan Registrant Phone: +886.886226535111 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: justin_yeh@tutk.com In fact, the IOTC platform is a service developed by ThoughTek to establish P2P communications between devices. I read the documentation provided with the device as well as all the website pages and there is no mention of this service. Manufacturers should include some technical documentation about the network requirements (ex: to download firmware updates). In this case, it's not a major security issue but this story enforces what we already know (and be afraid) about IoT: those devices have weak configuration and they lack of visibility/documentation about their behavior. Take care when connecting them on your network. A best practice is to inspect the traffic they generate once online (DNS requests, HTTP(S) request or any other protocol). -- "If the enemy leaves a door open, you must rush in." - Sun Tzu PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x42D006FD51AD7F2C I will be teaching next: Defending Web Applications Security Essentials - SANS San Francisco Spring 2020	Johannes 3693 Posts ISC Handler
Subscribe	Jan 12th 2015 4 years ago
After a brief look at this product (and similar things), I'm inclined to disagree with: "In this case, it's not a major security issue..." Poor/weak default configuration + Internet connection + mobile apps + remote control + electricity supply This spells "trouble" to me, if only from an availability perspective. Might only be mildly annoying if your TV is switched off at random, but slightly more worrying if your home dialysis machine is...	Peter Bance 9 Posts
Quote	Jan 12th 2015 4 years ago
It could become an issue indeed but this kind of device looks definitively not reliable to handle business critical power supplies! I'm currently investigating the solution developed by ThoughtTek... I'm sure that the system has weaknesses! /x	Xme 491 Posts ISC Handler
Quote	Jan 12th 2015 4 years ago
Could be EXTREMELY worrying! Many years ago (early 1980's) I was involved in early work on energy management and "smart home" stuff. I pointed out that if an attacker could gain control over the server that sent commands to the devices in a locality, he could synchronously turn MANY devices on and off together, creating an electrical surge that would DoS the electrical system. If such an attach were coordinated to occur in many localities at once, it could bring down a large part of the national electrical grid. The response from management? "Don't tell anybody." So if these devices are being surrepticiously controlled from an potential agressor nation (China), all they have to do is sell enough of them (making money all the while) until they have critical mass, then launch an attack. This is a case of a p[hysical Trojan Hourse, only it is not a gift; the victim pays for it.	Moriah 133 Posts
Quote	Jan 13th 2015 4 years ago
Interesting article. I own a nest but I have blocked its access to the internet. so basically its useless for all the cool online control. I'm curious to know what is the software you are using to view the logs of your device in the attached screenshot?	XORed 2 Posts
Quote	Jan 13th 2015 4 years ago
To my eye, that looks like Kibana, so he's probably running an ELK (Elasticsearch/Logstash/Kibana) stack with a parser written to eat firewall logs and drop them in ElasticSearch, then visualizing with Kibana. I've been meaning to do that for my pfsense logs at home for a while, but it's hard to find the time.	Mark 2 Posts
Quote	Jan 17th 2015 4 years ago
Hello, Take a look on my git, we've find lot of thing about this plug : https://github.com/supermat/SmartPlug You can find others information here : http://www.dealabs.com/bons-plans/prise-wifi-/85521?page=49 Its in french. The china access is probably for the "cloud" access. Without any router configuration, the plug can be Turn on or off in 3G network With the iOS/androïd application.	Mark 1 Posts
Quote	Feb 13th 2015 4 years ago
I recently bought a QIHAN Dvr, Chineese brand obviously. I noticed 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. This is not connected to ddns or something like that becaouse everything 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.	Mark 1 Posts
Quote	Oct 24th 2016 3 years ago

[This is a guest diary submitted by Xavier Mertens]

Our houses and offices are more and more infested by electronic devices embedding a real computer with an operating system and storage. They are connected to network resources for remote management, statistics or data polling. This is called the "Internet of Things" or "IoT". My home network is hardened and any new (unknown) device connected to it receives an IP address from a specific range which has no connectivity with other hosts or the Internet but its packets are logged. The goal is to detect suspicious activity like data leaks or unexpected firmware updates. The last toy I bought yesterday is a Smart Plug from Supra-Electronics. This device allows you to control a power plug via your mobile device and calculate the energy consumption with nice stats. I had a very good opportunity to buy one for a very low price (25€). Let's see what's inside....

The documentation mentions a setup procedure and management via a mobile device (with a free app for IOS or Android) but the first reflex is to scan the box. Interesting, a webserver as well as a telnet server are waiting for packets. Let's try common credentials like admin/admin and...

$ telnet 192.168.254.225 Trying 192.168.254.225... Connected to 192.168.254.225. Escape character is '^]'. (none) login: admin Password: BusyBox v1.12.1 (2014-07-31 06:32:52 CEST) built-in shell (ash) Enter 'help' for a list of built-in commands. #

Immediately after the boot sequence, the device started to try to communicate with remote hosts:

Amongst DNS requests and NTP synchronization, a lot of traffic was generated to different IP addresses over UDP/10001. The same packet being sent to different hosts. The payload was a block of 60 bytes:

I was not able to decode the content of this payload, please comment if you recognize some patterns. The device also performs a regular connectivity check via a single ICMP ECHO packet sent to www.google.com (every 5 mins). This network traffic is generated by the process called RDTServer:

# ps PID USER VSZ STAT COMMAND 1 admin 1400 S init 2 admin 0 SWN [ksoftirqd/0] 3 admin 0 SW< [events/0] 4 admin 0 SW< [khelper] 5 admin 0 SW< [kthread] 6 admin 0 SW< [kblockd/0] 7 admin 0 SW< [kswapd0] 8 admin 0 SW [pdflush] 9 admin 0 SW [pdflush] 10 admin 0 SW< [aio/0] 11 admin 0 SW [mtdblockd] 18 admin 1084 S nvram_daemon 19 admin 1612 S goahead 20 admin 872 R RDTServer 24 admin 1400 R telnetd 26 admin 872 S RDTServer 27 admin 872 S RDTServer 33 admin 872 S RDTServer 34 admin 872 S RDTServer 35 admin 872 S RDTServer 36 admin 872 S RDTServer 53 admin 1400 S /bin/sh 238 admin 0 SW [RtmpCmdQTask] 239 admin 0 SW [RtmpWscTask] 366 admin 1400 S -sh 505 admin 1400 R ps 678 admin 1400 S udhcpd /etc/udhcpd.conf 1116 admin 1396 S udhcpc -i apcli0 -s /sbin/udhcpc.sh -p /var/run/udhcp 1192 admin 872 S RDTServer 1207 admin 772 S ntpclient -s -c 0 -h ntp.belnet.be -i 86400 #

I grabbed a copy of the RDTServer binary (Mips) and using the "strings" command against the file revealed interesting stuff. The IP addresses used were found in the binary:

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

Seeing packets sent to China is often suspicious! The domain name iotcplatform.com belongs to ThroughTek, a company specialized in IoT and M2M ("Machine to Machine") connection platforms:

Domain Name: IOTCPLATFORM.COM Registry Domain ID: 1665166563_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.godaddy.com Registrar URL: http://www.godaddy.com Update Date: 2014-07-09T11:44:15Z Creation Date: 2011-07-04T08:50:36Z Registrar Registration Expiration Date: 2016-07-04T08:50:36Z Registrar: GoDaddy.com, LLC Registrar IANA ID: 146 Registrar Abuse Contact Email: abuse@godaddy.com Registrar Abuse Contact Phone: +1.480-624-2505 Registry Registrant ID: Registrant Name: Charles Kao Registrant Organization: Registrant Street: 4F., No.221, Chongyang Rd., Registrant City: Taipei Registrant State/Province: Nangang District Registrant Postal Code: 11573 Registrant Country: Taiwan Registrant Phone: +886.886226535111 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: justin_yeh@tutk.com

In fact, the IOTC platform is a service developed by ThoughTek to establish P2P communications between devices. I read the documentation provided with the device as well as all the website pages and there is no mention of this service. Manufacturers should include some technical documentation about the network requirements (ex: to download firmware updates). In this case, it's not a major security issue but this story enforces what we already know (and be afraid) about IoT: those devices have weak configuration and they lack of visibility/documentation about their behavior. Take care when connecting them on your network. A best practice is to inspect the traffic they generate once online (DNS requests, HTTP(S) request or any other protocol).

--
"If the enemy leaves a door open, you must rush in." - Sun Tzu
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x42D006FD51AD7F2C

I will be teaching next: Defending Web Applications Security Essentials - SANS San Francisco Spring 2020

Johannes

3693 Posts
ISC Handler

After a brief look at this product (and similar things), I'm inclined to disagree with:

"In this case, it's not a major security issue..."

Poor/weak default configuration + Internet connection + mobile apps + remote control + electricity supply

This spells "trouble" to me, if only from an availability perspective. Might only be mildly annoying if your TV is switched off at random, but slightly more worrying if your home dialysis machine is...

Peter Bance

9 Posts

It could become an issue indeed but this kind of device looks definitively not reliable to handle business critical power supplies!
I'm currently investigating the solution developed by ThoughtTek... I'm sure that the system has weaknesses!

/x

Xme

491 Posts
ISC Handler

Could be *EXTREMELY* worrying!

Many years ago (early 1980's) I was involved in early work on energy management and "smart home" stuff. I pointed out that if an attacker could gain control over the server that sent commands to the devices in a locality, he could synchronously turn *MANY* devices on and off together, creating an electrical surge that would DoS the electrical system. If such an attach were coordinated to occur in many localities at once, it could bring down a large part of the national electrical grid. The response from management? "Don't tell anybody."

So if these devices are being surrepticiously controlled from an potential agressor nation (China), all they have to do is sell enough of them (making money all the while) until they have critical mass, then launch an attack. This is a case of a p[hysical Trojan Hourse, only it is not a gift; the victim pays for it.

Moriah

133 Posts

Interesting article.

I own a nest but I have blocked its access to the internet. so basically its useless for all the cool online control. I'm curious to know what is the software you are using to view the logs of your device in the attached screenshot?

XORed

2 Posts

To my eye, that looks like Kibana, so he's probably running an ELK (Elasticsearch/Logstash/Kibana) stack with a parser written to eat firewall logs and drop them in ElasticSearch, then visualizing with Kibana.

I've been meaning to do that for my pfsense logs at home for a while, but it's hard to find the time.

Mark

2 Posts

Hello,

Take a look on my git, we've find lot of thing about this plug :

https://github.com/supermat/SmartPlug

You can find others information here :
http://www.dealabs.com/bons-plans/prise-wifi-/85521?page=49

Its in french.

The china access is probably for the "cloud" access. Without any router configuration, the plug can be Turn on or off in 3G network With the iOS/androïd application.

Mark
1 Posts

I recently bought a QIHAN Dvr, Chineese brand obviously. I noticed 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. This is not connected to ddns or something like that becaouse everything 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.

Mark
1 Posts