I would not normally be an alarmist, but it is warranted in this case. Ever since I upgraded to version 2.6.7 of the firmware, my Bond device has started attempting to log in to my router over SSH. As a device inside my network, my router software didn’t immediately flag it as a serious threat. But, today the router apparently had enough and alerted me to the potential attack. I have checked through my router logs and exactly once per hour, the Bond device attempts to ssh to my router with the user “admin”. Once I saw the alert, I immediately unplugged the Bond and the SSH attempts have stopped. I see there is new beta firmware available, but I won’t even plug the device back in until I get some kind of response from the Bond team as to why on earth this device would be attempting to access my router over SSH.
Hi Jason,
Thanks for the report. Here’s exactly what is going on.
In the beta v2.x firmware for Bond Bridges with serials starting in A/B, we included a software component which checks the home router password against a list of defaults, similar to how many websites now check your proposed account password against leaked credentials from other sites. The intention is to prevent a class of attacks against smart home devices via insecure routers, which sadly many users have configured in their homes.
This is supposed to run only once per WiFi configuration. The connection attempt each hour was unintended.
Clearly we need to consider how this security feature interacts with threat detection mechanisms such as the one in your router, as well as consider the security expectations of more advanced users.
Would be glad to hear your thoughts on this.
If it successfully logs in, what does it do next? Why is it BOND’s responsibility to find and expose vulnerabilities?
Glad we got your feedback on this during beta! We have disabled this feature and removed from the next firmware release currently under development.
Here’s what we are doing going forward:
-
Any security features like this will be on an opt-in basis, clearly explained during the setup process, and can be disabled/enabled from Bond settings at any time.
-
If the security feature is enabled and Bond detects an insecure network environment, the app will alert the user with an appropriate message, such as “Your router is using a default password, we strongly recommend changing the password.”
We want to get this right, and appreciate your honest feedback as we get V2 ready for launch.
To reply directly to @danmandle’s questions:
If it successfully logs in, what does it do next?
It does not go any further. The intent was to report the vulnerability (but not the credentials) to the user via the Bond app.
Why is it BOND’s responsibility to find and expose vulnerabilities?
When controlling HVAC equipment, it seems that some level of network security awareness is needed. Previously we checked the encryption settings of the WiFi network, warning the user about the weakness of anything but WPA2. This seemed like the next logical step, but clearly we need to rethink that.
in australia attempting to authenticate to anything without actual permission could be found to be a commonwealth offence. recommend not having this occur automatically without users permission and knowledge.
Opt in feature is always the safe bet of you want to try something.
I say just stick with getting the bond to control things and do it well. Can we say, garage door opener? 
Let the ppl who know how to do security, do security
Master of one, not Jack of all trades
Wow that seems really strange it would do this… per hour. And it wasn’t in any release notes for the firmware?
Can’t really imagine any scenario where there would be a plausible excuse for this. Odd…
@larsentim, welcome to the forum.
To clarify, the security component that we included in the beta is from a third-party security vendor, which was supposed to only check for attack attempts against the Bond from other devices. We found out about the router default password “feature” when we forwarded @j4nd3rs0n’s alarming report to our vendor.
Needless to say, we are not happy about this either. But we chose to include this security component in Bond, and so you are right to be dissatisfied with us and we take responsibility for what the Bond firmware is doing, regardless of whether it is the core Bond team implementing a “feature” or an outside vendor.
So, we are removing this component in future firmware beta versions and this has not and will not go into public versions.
And, look, I’ve chosen to promptly and directly answer here… We could have said nothing or blown smoke. I look forward to continuing a culture of open communication with the Bond community.
Thanks for being open and honest and to jump into action and remove the feature this fast. This is a great response to customer feedback. Kudos
I appreciate the open response from the team.
Can you also provide input into why bond uses quite a bit of bandwidth each month. I see 1 GB downloaded and 1.5 GB uploaded in last 30 days (reported from Google Wifi) with very minimal usage of the 4 devices (fans) connected to it.
In comparison, Smartthings used only 670 MB downloaded and 865 MB uploaded in the same time period with way more devices (over 60) that are being used more frequently. Hue used 53 MB downloaded and 552 MB uploaded with about 20 devices connected.
Hmm that does seem to be a bit excessive. Do you have a Snowbird or Zermatt unit? (A/B versus ZZ serial)?
The only thing continuously running is an MQTT connection back to our server, which does a ~1kB ping every 30 seconds as a connection keepalive. That results in ~43MB/month up & down. The Snowbird unit would use somewhat more due to NTP service running, but definitely should not be 1GB!
I’ve opened an internal issue on this side to add a test for this.
I have a Snowbird device. Thanks for the quick response!
@merck I appreciate the detailed response. The most important thing when touching on security is transparency. We are trusting these devices not just to attach to our home network, but to interface with products like fans, fireplaces, AC units, potentially other things that could have a major impact within our homes. Any hint of obfuscation on your part in responding to this would have immediately ended my use of the product and I would not have been quiet about it. You have a good product so far, but please focus on what you are responsible for, your own product and its security. There is no upside for you to discover a vulnerability in someone else’s product (you won’t get credit in a way that would actually help your business), but there is a lot of downside if you get something like this wrong. You never know which security faux pas will get picked up and amplified by the media. Given the heightened sensitivity certain groups have over IoT security, tread very carefully.
This entire thing has certainly been a learning experience for me. It never should have taken my systems as long as they did to notify of the threat. I had too much trust of devices on the inside of my network. This incident has shown me the error of my ways.
@cmhaagen I use pfsense with suricata. To add a little detail to how this looked to my setup, suricata started logging the potential issue after the 2nd hour. But, my settings had this as a low enough threat that it was only getting logged. It wasn’t until it went on long enough for suricata to raise the threat level and actually notify me. I’m not trying to guard against a specific, human-driven attack. If a serious, determined adversary decides for whatever reason to hit you, they will almost certainly get in. What I am trying to guard against is actually what this incident looked like at a glance: an infected IoT device being used as part of a botnet.
Hi Ranga,
Can you open a new thread on the bandwidth usage info? (Also, we need your full BOND serial number. You can either post it in the thread or PM it to me. It’s not sensitive without the associated PIN.)
I’d like to check whether your unit has been repeatedly connecting/disconnecting from the server, which could use a lot of data over the course of the month.