Should SmartThings owners be concerned? Are we unknowingly contributing to this? How can we tell if we have been compromised?
For this particular attack, you are most likely to be infected if you have an IP addressable camera and you never changed the default password. This includes Samsung cameras.
See the following article:
The most important thing you can do is to change the default password on everything you own. Power it off. Power back on and immediately change the password.
It is also quite possible that many of the iOT companies hidden administrative account passwords are vulnerable. Some of these administrative accounts are not changeable by the consumer of the iOT device.
Blackhat hackers learn these administrative username and passwords by decoding the iOT’s firmware and posting them on blogs. Hackers can use them to access these internet addressable iOT devices! Not all iOT devices are internet addressable, but a growing number of them are with HTTP web pages for consumer access.
For example. it is theoretically possible that the SmartThings hub has one or more hidden admin accounts and password for Samsung IT to access for firmware updates and other administrative maintenance requirements and that same password might be replicated for 100 of thousand hubs. If a hacker could use these accounts for access and create a dameon to run on the device, it would be likely to help in future Dos attacks.
I don’t know what is happening but just now my system armed itself and all my motion sensors and cameras fired off giving me an intrusion alert. No open/closed sensors affected though. Smae thing happened yesterday afternoon. Maybe the ST ghost has now come to my home. I am wondering if this is due to the attacs, as it just started happening yesterday.
Hide your kids, hide your wife, there coming for you. JK. Your probably just bring effected by the ongoing platform issues. You can email support or just ride out the wave and hopfully your system returns to normal. Using ST as a security system is always trivial, works for some, doesn’t or kinda for the rest. I personally use SHM to monitor my dsc integration and it’s been 100% for me. Most likely because the states being monitored are controlled by a tried, tested and true technology.
Engineer who works on the hub firmware/software here. We haven’t seen any evidence of SmartThings hubs being compromised in this or other attacks and it would surprise me if SmartThings were in the first wave of devices being targeted by hackers for this initial wave since we follow basic security best practices.
From what I have read, most of the attacked devices in this and other recent attacks have been ones attached to the public internet where the system have either had known, unpatched vulnerabilities or default passwords that were never changed (like most defaults).
With that being said, we understand that SmartThings as a system and user’s hubs in particular represent a target for attackers as hubs have access to other devices in a user’s home in addition to being general purpose computing devices connected to the internet. Unlike some of the compromised system’s in the field today, the SmartThings hub is designed to receive (cryptographically signed) updates. This allows us to both deliver new functionality and also to patch security vulnerabilities that we or others discover that affect the SmartThings hub firmware.
Thanks for the explanation @posborne and we are glad that ST is following “basic security practices”…but sometimes those basic security practices are high level and operational level decisions conflict with design and functional needs:
For clarification, are you confirming that for ST that:
- External access to the SmartThings Hub open ports (1900, 5353, etc) can only be performed by SmartThings IT employees and not unauthorized individuals or devices on the same local lan as the hub?
- A hacker cannot access an administrative level account on the ST hub through a fixed default password and install undetectable malware (not the same as a cryptographically signed firmware update?
Hi @kurtsanders, thanks for asking for more detail. I’m happy to oblige.
I’m not sure where you are getting those port numbers from, but here are the ones that are open on the hub at present:
$ nmap -p- 192.168.1.172 PORT STATE SERVICE 8889/tcp open ddi-tcp-2 8890/tcp open ddi-tcp-3 39500/tcp open unknown
These ports are:
- 39500: LAN TCP Notify Port. Connections to this port and data sent are buffered and sent to the cloud to be handled by DTHs/SmartApps. There is no “intelligence” on the hub related to this port today and, as such, the attack surface is small.
- 8889: LAN TLS SHP Notify Port: Same as above but using TLS with a certificate that is used by Samsung digital appliances.
- 8890: LAN TLS TV Notify Port: Same as above but using TLS with a certificaate that is used by Samsung TV.
In addition, we bind to a few multicast ports in order to do SSDP and m-dns discovery of devices. Notably missing from the hub (but probably present on all compromised devices) are services like SSH, Telnet, and HTTP/s.
There is no service that allows entering a password and there are no default passwords. Currently, we apply “package” updates that are deltas on previous images, but in the future we will be moving toward “full image” updates. As part of this, we will be mounting most of the system as read-only and doing a hash on it each boot (for a variety of reasons) – this greatly constricts what an attacker who did actually manage to compromise a system could do without detection (they would most likely need to disable updates, which we would notice).
I’m going to show my lack of security know how here, and perhaps someone can enlighten me.
I kind of assumed that these IoT attacks work against devices if you use port forwarding to expose the device to inbound traffic. This is something people often need to do with CCTV cameras, DVRs etc.
In ST’s case, the hub only has outbound access. Presumably it has to regularly poll the cloud, or maintains an open connection, but it’s not possible for the cloud side of the service to make an inbound connection to the hub.
Obviously all bets are off if your router is compromised, but can anyone explain whether there’s a viable attack vector to devices if you don’t forward inbound ports?
@posborne I also ran a Nmap scan this morning with the latest 7.31 version and got the following response on my V2 Hub when looking at it. I was glad to see that traditional services as your mentioned are inactive, which I agree, are not “Best Security Practices” for production level consumer devices. Also, the mounting of the O/S system disk as read-only and doing a hash on it each boot would be a great means of detecting compromise, if and when the device periodically reboots. Keep up the great work, we consumers appreciate your extra steps to keep our home network uncompromised and the internet from being DoS.
$ sudo nmap -sS -sU -PN 10.0.0.45 Starting Nmap 7.31 ( https://nmap.org ) at 2016-10-23 08:57 EDT Stats: 0:01:36 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan UDP Scan Timing: About 10.53% done; ETC: 09:12 (0:13:10 remaining) Nmap scan report for 10.0.0.45 Host is up (0.0085s latency). Not shown: 1998 closed ports PORT STATE SERVICE 1900/udp open|filtered upnp 5353/udp open|filtered zeroconf MAC Address: D0:52:A8:35:76:B9 (Physical Graph) Nmap done: 1 IP address (1 host up) scanned in 1003.32 seconds
When I run your same NMap scan, I also see these same ports:
$ sudo nmap -p- 10.0.0.45 Starting Nmap 7.31 ( https://nmap.org ) at 2016-10-23 12:41 EDT Nmap scan report for 10.0.0.45 Host is up (0.0044s latency). Not shown: 65532 closed ports PORT STATE SERVICE 8889/tcp open ddi-tcp-2 8890/tcp open ddi-tcp-3 39500/tcp open unknown MAC Address: D0:52:A8:35:76:B9 (Physical Graph) Nmap done: 1 IP address (1 host up) scanned in 66.14 seconds
Thanks for confirming @kurtsanders. Those other UDP ports make sense as part of what the hub implements in order to support device/service discovery on the LAN.
I thought I’d heard that the cloud account pings the hub and that’s what triggers the “hub is off-line” message.
But is that instead just counting the time since the last report in?
There is a “ping” message that can be sent from either the cloud to the device or vice versa but it is not an ICMP ping message. This message (and all others) are sent through a persistent TLS/TCP connection between the cloud and the device. This connection uses a self-signed TLS certificate and also uses CMAC for mutual authentication of device/server. No connections are initiated from cloud -> device (that would be a nightmare with firewalls, etc.).
@posborne Thank you for the reassurance. I was a little worried that my Samsung camera was compromised (it wasn’t a default password).
Xiongmai is recalling the WebCam models that are most vulnerable to being co-opted by a botnet. If your devices are registered, you should get a notification about the recall eventually. Otherwise watch the news for more details as they become available.
Hide your kids?! What for? Watch this: http://youtu.be/UMh9k1Fb2fM
I haven’t seen that video yet, pretty crazy. I was referring to this video. https://m.youtube.com/watch?v=EzNhaLUT520
The story is bad but the brothers video reaction is priceless.
In light of the recent disastrous developments with IOT compromises that have been used to attack large portions of the Internet, I would like ST to provide some technical demonstration of competence that the ST gateway systems and wireless networks are secure. I’m looking for some actual technical evidence, not just reassuring statements. Can someone from ST please numerate the specific technical measures that protect our ST networks?
The majority of the products we support are not internet connected themselves. Technologies like ZigBee and Z-Wave have protocol specific security built in and cannot be used in the types of attacks mentioned in this thread.
We also support some IP connected devices, like Philips Hue. Our platform is able to secure the linkage between our cloud and the SmartThings Hub. We regularly update the firmware on our hubs, and have a review process for adding new devices to our ecosystem.
The hub to cloud communication is secured with strong encryption using the latest version of the TLS stack, strong cipher suites, and layered device specific authentication keying. When required for showing the user the current state of their home, this information is transmitted over a secure and encrypted channel to the SmartThings mobile app.
We also engage with third party security firms who perform penetration testing against the SmartThings Hub and our cloud platform.
See this post for more technical information:
I would like to settle this absurd, completely unfounded fear of catastrophic events once and for all. Just leaving this here. Peace
PS: Watch it to the very end. Then you’ll see the real truth ROTFLMAO