SmartThings Firewalling - Serious Security Concerns

General Discussion
,
1

A few weeks ago, my ST Hub went offline. I suspected that the problem was that they changed servers. I’ve been through multiple hours of chat plus a bunch of email, resulting in me concluding that it is impossible to secure this device.

A very basic firewall rule I run for all of my devices is that by default they have no access to the Internet outside my house. I then create rules to open connections to specific host/port combinations to permit each device to talk to authorized servers.

This is done to protect against a specific case (which has happened to me):

  • Machine gets cracked
  • Cracker installs a program to establish, say, a remote ssh session to their local machine.
  • Attacks continue, now originating from a trusted IP address within the local network.

The problem is that the hub talks to all kinds of different IP addresses and there seems to be no way to determine if they are legitimate. When I requested a list of authorized IP addresses, I got this response from ST support:

We do not have a list of IP addresses to send you simply because that is outside of our abilities.

This is frightening. ST does not know what IP addresses their hub is authorized to talk to? Note that support did give me a list of authorized machines/ports (dc.connect.smartthings.com and fw.dc.connect.smartthings.com) but my hub attempts to establish connections to other servers. For reference, here is what I saw the hub attempt to connect to over one night:

  • 13.58.204.216.443:
  • 18.217.232.95.443:
  • 18.218.224.116.443:
  • 18.221.183.104.443:
  • 18.221.204.40.443:
  • 18.222.90.87.443:
  • 34.196.63.11.443:
  • 54.210.184.216.443:

This casual approach to security is inexcusable. This is not “Enterprise level security”, this is basic firewalling.

Hoping that someone on ST staff will take the time to actually address this (the information should be published on a web page that users can refer to).

2

That can’t be right. They’ve got to have a load balancer that has a single address, plus their own routers and dns servers that handle their internal address schema. And within that schema, there has to be a clear bank of IP addresses that are referenced.

There’s no way they’d let their server scheme be all over the map… right??

3

Not necessarily. You can have multiple IP Addresses for a DNS host record. That was how load balancing happened before load balancers.

1 Like
4

I would assume your internal network is secure (so nobody can mess with your DNS). Wouldn’t be safe to trust the hostname with all of the IP’s it connects to?

5

All the ip addresses above are amazonaws.com - United States - Amazon Technologies Inc. and ST is using their servers so it’s fair to ask the question but at the same time. They probably don’t want to give you an endless list of Amazon addresses either.

3 Likes
6

One would think that doing a DNS lookup on the servers they specify as “legal” would work. What is suspicious is that the hub had firewall rules that worked just fine for weeks, then, suddenly, it dropped offline and never came back.

This is suggestive of something “bad” happening, and is what prompted me to investigate. It’s disturbing that the company itself does not know what servers they are using.

@Glen_King - You would think so. But it appears that the hub does, indeed, go to assorted IP addresses. Note that it’s not using my DNS servers, nor does it appear to be using any other DNS servers. All I see is traffic on port 443 to blocked IP addresses. That change.

@kahilzinger - True. But it does not seem to be doing DNS.

@kamran - I do. These addresses are not associated with the hostnames they specified. Hence the concern.

@Navat604 - The hubs should only be communicating with a known set of hostnames or IP addresses. ST does not know what these are. This suggests a security hole.

The IP addresses they claim are valid are:

dc.connect.smartthings.com. 249 IN CNAME deviceconn-na01useast1-ext-1580938476.us-east-1.elb.amazonaws.com.
deviceconn-na01useast1-ext-1580938476.us-east-1.elb.amazonaws.com. 9 IN A 54.88.162.144
deviceconn-na01useast1-ext-1580938476.us-east-1.elb.amazonaws.com. 9 IN A 52.7.238.228
deviceconn-na01useast1-ext-1580938476.us-east-1.elb.amazonaws.com. 9 IN A 34.232.248.148

and

fw.dc.connect.smartthings.com. 299 IN CNAME deviceconnfw-na01useast1-ext-40406787.us-east-1.elb.amazonaws.com.
deviceconnfw-na01useast1-ext-40406787.us-east-1.elb.amazonaws.com. 59 IN A 54.164.10.194
deviceconnfw-na01useast1-ext-40406787.us-east-1.elb.amazonaws.com. 59 IN A 34.206.134.96

All of which are permitted outbound through my firewall.

7

They are probably tied into Amazon and have no control over what servers are in use. If you are really worried about it, create a DHCP reservation for the hub and then allow it outbound https connections to everywhere. You are only going to cause yourself a lot of headaches and grief trying to lock it down to only specific IP Addresses. You won’t be able to account for ISP changes, expansion, changes, removals, etc. unless you are constantly running a packet tracer and addressing it after the fact.

As a firewall administrator, you are seriously taking it way past what would be practical.

I have a separate VLAN for IOT and do not allow it to communicate with my other ones…just the Internet.

5 Likes
8

@kahilzinger - I run a bunch (?9?) of WiFi nets around the house, two of them are dedicated to IOT. Every device that I know that enters my house gets a fixed IP address with associated firewall rules. Guests have their own dedicated WiFi network and set of rules. The problem is that this hub needs to talk to the cloud, making it an attack vector. I’m looking at connecting it to my alarm system with konnected, once my boards show up. So I’m concerned. I have figured out what they are doing - it’s very disturbing. There are a number of points along the way here that lend themselves to attacks.
While I’m not going to mention any specific details in a public forum, I’ll suggest that people consider what would happen if any one of these steps was compromised by replying with a rogue server (about 10 minutes work if you’re taking your time) and a compromised SSL key.

I spent tonite doing some digging. There are 4 nameservers for the SmartThings cloud:

   ns-1275.awsdns-31.org
   ns-1610.awsdns-09.co.uk
   ns-442.awsdns-55.com
   ns-779.awsdns-33.net

Rather than any one of these answering a DNS lookup with all addresses, it appears that they are doing some sort of traffic shaping depending on which server answers a users DNS query.

Unlike what is quoted by support, there are a number of machines that are required for the hub to function. Since there’s no good way to query one DNS server and retreive all IP addresses for a host, it’s messy.

fw-update.smartthings.com

This appears to be where the hub goes to check for firmware updates (but see below). Not mentioned by support. Depending on which DNS server is queried, you may get either address:

34.196.63.11
54.210.184.216

fw-update2.smartthings.com
Because doing all firmware updates using a single server is too secure, they open another one. Also not mentioned by support. This can be any of three addresses:

52.86.9.83
52.203.133.187
54.175.108.94

dc.connect.smartthings.com
This address is mentioned by support. DNS returns that it is a CNAME for:
deviceconn-na01useast1-ext-1580938476.us-east-1.elb.amazonaws.com.
Which can be one of the following 3 IP addresses:

    34.232.248.148
    52.7.238.228
    54.88.162.144

> dc-na04-useast2.connect.smartthings.com

Now we are wandering into the murk. It appears that the cloud is returning different hosts to connect to, depending on where in the world it thinks you are (VPNs can make this impossible). So a user in California is likely to get a different server to talk to here. I’d be concerned that this would be a good hijack point. I’m also guessing that my hub dropped offline because they changed this server address (hint: you should never do that).

dc-na04-useast2.connect.smartthings.com

is a CNAME for

deviceconn-na04useast2-ext-2125534906.us-east-2.elb.amazonaws.com
Which can be one of the following 3 IP addresses:

18.220.178.159
13.58.204.216
18.221.204.40

If as I suspect, this server changes based on geographic location, other IP addresses would apply.

Permitting all of these outbound exclusively on port 443 brought my hub back online.

This is insane. Multiple exploit points and hard for the end user to secure. No easy way for the user to verify security (and no, “trust us” is not good enough), over the last 25 years, I’ve seen all kinds of Internet exploits. This is not the way to solve this problem, this is a hack.

A few court cases where these vendors become liable for houses being burgled will change their attitude. But I don’t want to be one of the test cases.

9

You really believe that lawsuits are in the best interest of this young industry?

Doesn’t anybody read the Terms of Service?

THE SERVICES (AND ALL PRODUCTS, SOFTWARE, SERVICES, INFORMATION AND CONTENT) ARE PROVIDED ON AN “AS-IS” BASIS, WITHOUT WARRANTIES OR ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR THAT USE OF THE FOREGOING WILL BE UNINTERRUPTED OR ERROR-FREE. SOME STATES DO NOT ALLOW LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY LASTS, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. Limitation of Liability. TO THE FULLEST EXTENT ALLOWED BY APPLICABLE LAW, UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, TORT, CONTRACT, STRICT LIABILITY, OR OTHERWISE) SHALL SMARTTHINGS BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR (A) ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY KIND, INCLUDING DAMAGES FOR LOST PROFITS, LOSS OF GOODWILL, WORK STOPPAGE, ACCURACY OF RESULTS, OR FAILURE OR MALFUNCTION OF ANY DEVICE CONNECTED TO THE SERVICES, OR (B) ANY AMOUNT, IN THE AGGREGATE, IN EXCESS OF THE GREATER OF (I) $100 OR (II) THE AMOUNTS PAID BY YOU TO SMARTTHINGS IN CONNECTION WITH THE SERVICES IN THE TWELVE (12) MONTH PERIOD PRECEDING THIS APPLICABLE CLAIM, OR (III) ANY MATTER BEYOND OUR REASONABLE CONTROL. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF CERTAIN DAMAGES, SO THE ABOVE LIMITATION AND EXCLUSIONS MAY NOT APPLY TO YOU.

Risk of Loss; Insurance. YOU ACKNOWLEDGE AND AGREE THAT YOUR USE OF THE SERVICES (INCLUDING, WITHOUT LIMITATION, USING THE SERVICES TO SECURE OR OTHERWISE CONTROL ACCESS TO ANY REAL OR PERSONAL PROPERTY) IS SOLELY AT YOUR OWN RISK, AND THAT YOU ACCEPT RESPONSIBILITY FOR ALL LOSSES, DAMAGES AND EXPENSES ARISING OUT OF SUCH USE. SMARTTHINGS IS NOT AN INSURER. YOU ARE RESPONSIBLE FOR MAINTAINING INSURANCE COVERING ALL LOSS, DAMAGE OR EXPENSE, WHETHER FOR PROPERTY DAMAGE, PERSONAL INJURY (INCLUDING DEATH), ECONOMIC LOSSES OR ANY OTHER FORM OF LOSS, DAMAGE OR EXPENSE ARISING OUT OF OR FROM (I) THESE TERMS, OR (II) THE SERVICES.

1 Like
10

He obviously doesn’t. I ran into that same prevalent attitude last week during Arlo’s outage. It truly is amazing that people don’t get it.

I’m not sure what the OP’s agenda is here, but resolving a dozen or more IP’s for a particular service is neither sloppy, nor poor security practice. It’s DNS round-robin, and it’s a very legitimate way to distribute load and redundancy across a cluster of servers, even entire data centers.

This is a cloud service, we all knew that going in. You cannot reasonably expect the manufacturer of a consumer system, who offers no SLA, to publish that kind of information. It offers zero benefit to their target audience.

Perhaps the OP should look at Hubitat where everything is local. Then again, there are almost no cloud-based integrations with that system, which may suit his needs well.

5 Likes
11

Admittedly, this discussion is way above my head, technically speaking.

But I think this should be obvious to anyone. The OP appears to have unreasonable expectations regarding the type of support the tier 1 techs that staff the ST support desk should provide to him.

4 Likes
12

Look if you are going to this extreme, then maybe a $100 home automation system isn’t the best choice for you as far as home security goes.

Curious how you put a fixed IP on a device you cannot administer its IP Address because it has no administration page you can access. You must be using DHCP reservation.

There is a reason they call something like this the “cloud”. The reason is that there is no definition. Things change all the time. IP Addresses are going to get added/changed/deleted and there is zero you can do about it and complaining on a forum isn’t going to change that. If you want control, then you need 100% of it to run locally. That is not how this system works.

How much time did you waste on something you have no control over? Are you going to be continuously monitoring every DNS zone SmartThings employs? I mean it stops as soon as you hit “amazonaws.com”. It hits 3rd party at that point and then you have to monitor all of Amazon and then it can spread out from there.

You have to look at your attack surface. What are you hoping to prevent? From what I can see, SmartThings only communicates by IP to the cloud. Locally, it is Z-Wave and Zigbee, which are Layer-2 protocols. The SmartThings hub is the gateway. And it is the Samsung cloud that communicates with the 3rd party systems, such as Nest, Ecobee, IFTTT, Ring, Amazon, Google, etc., not the actual hub, so all that is going on outside of your hub. If I wanted to attack SmartThings, that is where I would focus my attacks, not someone’s house that may or may not have SmartThings. I am pretty sure you are not hosting a static IP at your home and if you are, great, but it does not gain you much.

If you wanted to insure that the SmartThings hub could not communicate by IP with any other device, you would put it on a /30 network with only its default gateway on the same network. It could not get outside its network. There is no WiFi in it. Put it on a /30 network and there are no other devices on the wired side it can communicate with if it ever were compromised to the point of doing IP and port scans.

If you want to minimize https traffic, then limit your source ports to above tcp/1023. That is what I check on source ports for devices wanting to hit anything on our network. That takes care of the exploits that modify source ports to easily leave your target’s network.

And then you have to think about https traffic, itself. It is SSL based. That is tcp/443. So it does not look like anything is going in and out clear text. SmartThings is only going to add the root certificates that it uses with the device. I highly doubt that it has a comprehensive list of root certs in it outside of what is required by the product and it is not going to click through any certificate errors like an end user would. There is a finite amount of memory and non-volatile RAM in it. So, an attacker would have to get a signed certificate for Amazon or SmartThings to exploit the https communication by the certificate signing authority, which I doubt that said signing authority would want to jeopardize its business and losing customers, like Amazon and SmartThings, just so someone could hack into your home network.

That takes care of the electronic side. The only other thing to worry about is the physical access into your house.

If you are that worried about it, do not install locks that can be remotely unlocked. Go back to a key. You cannot electronically compromise them. And then, the person trying to gain access is going to have to be on your property, anyway. Why not use a sledge hammer through a window or break the door down?

And @tgauchat is 100% right. The Terms of Service indemnifies SmartThings from any legal course you could take so you are pretty much up a creek even if anything should happen.

So, I maintain, that the juice is not worth the squeeze. You are complaining about something you cannot control and will not be able to control and if this is a problem for you that you cannot get over, then this is not the product for you.

10 Likes
13

My house can be unlocked via ST but I don’t worry too much about it as it is way easier to just kick the door in.

At 1.20 of the video you will see how super easy it is to enter a typical home…

Also, I wonder how many houses actually have cell backup for their alarms… and in most houses around here the wires for telephone, cable, internet are all easily accessible on the side of the house so it is very easy to cut them. For that reason I installed a structured wiring box on the inside wall in my garage, pulled in all the wires that once were dangling outside (what a crude building method!), added a conduit through the wall, added an electrical box with conduit going to ATT’s ONT (fiber termination box) and installed “jumper cables” (ethernet and DC power) between the structured wiring panel and the outside. If anything is cut, it will take me a few minutes to fix it. This system will also make it a tiny bit harder for them to cut wires and above all it protects the wires from the Texas sun.

Below are a couple pictures taken before final touches were done (securing conduit to wall, repairing wall, and improving wiring in panel… that was just to get it up and running asap.

IMG_20140818_192753
IMG_20140818_192753.jpg3096×4128 2.13 MB
IMG_20140823_160723
IMG_20140823_160723.jpg2063×1547 2.18 MB

ANYWAY, back to FIREWALLS…

I have a Ubiquity Unifi based network and was wondering whether I should invest any time in securing my IOT system. I read of people putting devices on a separate VLAN, adding firewall rules (such as the thread above), etc but I believe the risk of being hacked is so small that I wonder whether I would end up complicating things more than necessary. WAF is already damaged by constant ST and Alexa issues so I don’t want to add another thing that will just add to it. Even if they hacked in… all they could do is turn stuff on or off… likely not a big incentive for hackers. Again, I believe most thieves would rather kick in a door than hack into a house to gracefully unlock it…

Can anyone tell me why I should put all IOT stuff on its own VLAN for example? Why would I want to limit where my IOT stuff connects to? If I were worried about privacy, I’d have to ensure Alexa in each room only sends what it hears to Amazon and not elsewhere but it just seems overkill. I am not advocating for NO security but before I embark in it I just want to be sure it makes sense for the regular “Joe”… If you are protecting a multi-million dollar mansion and you are an obvious target for criminals then I understand the concerns but I am neither…

3 Likes
14

Nice job.

As far as putting it on its own VLAN, I would. IOT devices, such as cameras, refrigerators, and the like that communicate on IP, have been used to launch DDOS attacks or as jumping points to get to an internal computer. It is for that reason that I do have an isolated SSID and VLAN for IOT devices that can only communicate directly with the Internet and none of the other VLANs on my internal network.

I did find that I had to move my Logitech Harmony Hub to the same VLAN as my cellphone and computers in order to use my computer to program it or use my phone to control my television. I am not happy about that but it seems as if they communicate over Layer-2 with the hub and that integration with SmartThings and Amazon Alexa are the only things that work over the cloud. In SmartThings, when you use your phone to communicate with your hub, you are actually going to the cloud and the cloud is going back to your hub. It adds delay but I think would be better for Logitech Harmony so I do not have to expose my internal devices to any security vulnerabilities it has.

15

I was considering putting my 7 Hikvision IP cameras on their own VLAN but concerns on being able to access them from anywhere, and from any device, led me not to (yet). Those are my primary concern given some of those are inside the house… also, it appears it might reduce network traffic congestion on my network but I haven’t figured out yet whether the data those 7 wired cameras generate is going to all devices or just those that subscribe to the RTSP streams. I have not figured out how to use multicast yet either.

I’ll study VLANs more to see if I can adopt them for my setup without causing issues such as the Harmony example you made.

16

As far as accessing them outside of the VLAN, just don’t add a default gateway and they will never traverse outside of their own network. If they only communicate between your DVR and themselves, and you only look at your DVR locally, then you are fine.

If you want to look at your DVR remotely, just put the default gateway on it and then you can do that. If you want to limit it to just your house, then, depending on your router, you might be able to create routing rules. Refer to your documentation or hire someone about doing that.

As far as traffic, connecting them to a network switch over a hub is better. You probably cannot even get hubs, anymore. Network switches only connect source and destination ports together as traffic goes through them so if your camera is transmitting on port 1, and your DVR is port 10, then the traffic is going from port 1 to port 10. Ports 2-9 will not see it. Also, with switches, you can get Power Over Ethernet (PoE) which is nice if your cameras support PoE, then your switch powers the cameras and you put a UPS on your switch to make sure they stay up during a power outage.

I am pretty sure you would be using a DVR to record the cameras in your situation. Make sure it has the fastest port and if you are going between multiple switches, make sure you are using your faster ports for uplinks. Typically, though, 100MB is perfectly fine unless you are recording at very high resolution and have many cameras recording at the same time. If you are doing that, then disk space would also be a concern. It really depends on how much bandwidth each stream uses. The greater the resolution, the more bandwidth required.

I know I recommend cameras that only send traffic if motion is detected…unless you want 8 hours of coverage of a chair sitting on the floor. By recording only when their is movement, then you lower your DVR space requirements and traffic needs. Plus, you don’t have a lot of Fast Forwarding to do if something does happen to try and find it.

Hubs, like WiFi, are shared media technologies which means only one device on them can “talk” at a time.

Think of hubs/WiFi as a crowded room full of people. You can only understand what is being said if one person talks at a time. The minute people try to talk over him or her, you have to stop everyone and start talking again and those who want to talk have to wait until the others are done (if you want to be polite).

Think of a network switch as those people off into their own cubicals with telephones connecting each other. If two people want to talk to each other, they pick up the phone and talk and while they are talking, two other people can be having their own conversations going. Your camera and DVR can be running while you are browsing the web with your Internet router.

1 Like
17

I remember the Ethernet hub days… but forgot that switches don’t blindly forward traffic to all ports. My cameras are all wired to a 24 port POE managed switch and I am using a QNAP 12TB NAS as my DVR but I’d like to get a dedicated one once I figure out what to buy that can handle my cameras and doesn’t cost a fortune. My cameras are a minimum of 3MP and up to 5MP, but soon I will be upgrading a few to 8MP. I tend to let them record all the time even though it resulted in a lot of hunting for the snippet I needed in the few cases I had to do so. This is better than missing the relevant moment because the camera started recording too late (which happened a few times before I changed strategy).

The cameras are on the 24 port POE switch and the NAS is on the 24 port switch in the media room, along with Hue, ST, Chamberlain, etc, home automation devices. I already have 3 CAT6a and 1 fiber drops between the main 24 port POE switch and the media room so I am planning on aggregating 2 CAT6a drops to double the bandwidth between the main switch and the NAS. I plan on doing the same with my office (and my PC) so that I can backup to my NAS much faster and to reduce the impact of the IP Cameras streaming to it 24/7.

The images below show the gear and the topology with clients hidden from view. All devices shown, except the main switch and one 8 port switch are POE powered. However, all of the network is under a UPS so I may be in the dark but I have internet!! :smiley: My home automation gear is also under a UPS but that has limited benefits as most of the items controlled require power.

From an electrical hardware/electrical perspective I think I have already done what you suggest. Now I need to investigate how to secure my network and my home automation gear from malicious attacks. One option I am considering is the adoption of a PFSENSE based firewall but I do not want to put it between my router and the main switch given it apparently slows down the throughput to a few hundred megabits (on affordable models). An alternative might be to create a secure network for devices I want to protect that links to the main network through a Pfsense firewall. This would allow me to keep my 1Gbps ISP speed where I want it (at the cost of less security) and to protect devices that do not need the extra bandwidth or require heightened security (ie devices used by kids). For now it is just an idea based on a scan of Pfsense based firewall appliances… I could not find any that were affordable and that had 1Gbps throughput. While Ubiquity is adding a lot of Firewall features to their “US Security Gateway - 4 port” (my router), if I enable them, my overall throughput decreases significantly. I hope they will release a more powerful router in a similar price range as my current one that can handle the bandwidth with the added security features. Their only alternative at the moment is $1k just for the router.

image

image
image.jpg631×839 87.3 KB

1 Like