As I mentioned in another post, I work in InfoSec and thought it would be useful to have a dedicated threat focused on ideas to improve the Smartthings platform as well as mobile App Security. @pstuart already did a good job capturing some below.
We need 2 factor authentication, yesterday.
We need a better api for developers to leverage to handle authentication and authorization for their apps.
We need a web interface to manage users and to revoke integrations with 3rd parties.
We should have configurable login expirations for the mobile app. iOs should support the fingerprint sensor.
I have a whole list on what Smartthings should be doing on the backend, but that is not really for a public discussion. I would like to see Smartthings expose a little bit more about what they are doing to keep our data safe.
IOS isnt the only platform with a fingerprint sensor. New android devices are including them. Plus android does have some pseudo secure biometrics as well.
But seriously, every st hub should come with a preloaded barking dog mp3 that can be streaming locally to any music device on the network.
Thanks for starting this topic! It’s great timing as we’re a few days from posting an updated abstract about our security practices. Expect that before the end of the week. We’re also planning on sharing a more in depth review after our upcoming product launches.
2 Likes
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
6
Ok adding to my own topic… I would like the ability to provide authorization to use various things(sensors) or applications at a more atomic level, similar to how you authorize third party apps to use some of your devices. I do not need full role based security, as I will never have enough users that its all that inconvenient to check a bunch of boxes.
Probably would like the idea of being able to create temp users that expire. Maybe even guest access as well.
Obviously this is for various use cases that we all live. Kids might have some access that wife and I don’t. Family members, guests, household employees, etc.
Given that SmartThings is so focused on enabling IoT in the home, this chapter focuses on evaluating the security in the design of their products. It is important to identify companies like SmartThings and analyze what good and bad design principles at work.
In the current situation, a malicious entity can use the password reset feature (Figure 4-9) to reset a victim’s SmartThings password. All the attacker needs is temporary access to the target’s email account, which can be gained by stealing a mobile device that belongs to the SmartThings user and capturing the resetted password (Figure 4-11) just by using the user’s preconfigured email client on the mobile device.
Another issue of concern is the longevity (18,250 days!) of the access_token discussed earlier. Since 18,250 days equals approximately 50 years, a potential attacker has five decades to try to obtain the access_token and reuse it to launch commands using the graph.api.smartthings.com service.
A malicious person who knows of your cell phone number and knows that you rely on SmartThings products to remotely ensure the safety of your family could abuse this situation to cause you to leave a particular location (such as your office) and head home to check up on your family because you received a SMS from the SmartThings short code.
This one is a bit of a red herring. You know what else would give an intruder access to a users home if they had physical access to it? Keys. And Keys don’t have a lock screen. My phone requires a thumbprint to unlock. It would be easier to just break a window. Most home burglaries don’t involve mission impossible tech and planning.
Could spoof the local hospital and call and say your [son,daughter,wife,mother] was in car accident.
Lot’s of fud in those excerpts. The only valid point might be the long expiry of the token, but even then cutting the power is easier that waiting 50 years to crack a code.
The goal of security analysis is to poke holes in the existing design and implementation, not to judge how likely or unlikely a particular security flaw is to be exploited. Following your logic, no one should bother installing security patches since the chances that hackers will target your system are very low.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
13
I think that all vulnerability analysis should also include, probability and scenario analysis, though they can be delineated in the report.
The SmartThings lack of credential revoke on the mobile App, for example, can best be described in terms of scenarios (eg, stolen phone or password lent to a guest…) so that users can mitigate the risk with behavior modification.
Physical security companies frequently report the most likely ways to enter your home, the most targeted items for theft, how to look less vulnerable, etc. All useful information.
No. He pointed out that there was an ssl cert vulnerability and it was, reported, patched, disclosed. That was a real world example.
The example with the phone is pure FUD. What he points out as a security flaw, I see as extended security. If someone can take my phone, there is a very good chance they could take my keys too. What are they more likely to use to get into my house? Keys can be taken, copied, abused, etc. You can probably even find a book on lock picking at your local library. All an attack needs:
My Phone
My Email
Knowledge That I use SmartThings
Or
Key to my house
Brick
Bolt Cutters
Yes. But a user losing his or her phone is not flaw in smartthings. A user not having a lockscreen is not an “internet of things” abuse. The last example he gave about using the text notification feature was completely absurd. What does it have to do with smartthings? I could send fake texts to anyone about anything. Social Engineering is not a bug in the software it’s a bug in human beings.
Again, arguing what’s easier or “more likely” is pointless. The vulnerability either exist or not. And if it exists it’s just a matter of time before it will be exploited. You’re assuming that the only threat is a physical break-in when in fact there’re much more creative ways to exploit the access to SmartThings hub as a backdoor into your LAN.
But a user losing his or her phone is not flaw in smart things.
No, its not. However, the reasons the lock screens exist in the first place is because phone makers realize that people do lose their phones and its better to have extra security measures in place rather then blaming users for losing their phones. As @tgauchat pointed out, an unauthorized user who gains access to your SmartThing account cannot be locked out even if you change your password from the IDE or from another mobile device.
The last example he gave about using the text notification feature was completely absurd. What does it have to do with smartthings? I could send fake texts to anyone about anything.
You can not spoof the originating number of the text message. His point is that using SmartThings text message service, one can send text messages to anyone and they will appear to come from SmartThings (i.e. their short number). I don’t know of any other IoT service that has unrestricted text message service. IFTTT, for example, allows sending SMS to your verified number only.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
16
Frankly, I try to view these security reviews or audits in the most positive and optimistic way possible: They are an opportunity for the vendor to fix stuff!
Yet, as we know, unfortunately and realistically, it is very difficult to be optimistic that SmartThings will address these concerns in a reasonable time frame. You’re quite correct that SmartThings could implement a basic SMS recipient number verification system. Take a couple weeks development and testing of one engineer, as best I can estimate … so triple that for good measure… 6 weeks?
Will you take bets that it won’t be added for at least…6 months?
So… back to positivism … These reports are worth sharing as they give users / Customers a chance to mitigate the risk to the extent they can. For example, though the probability is low, people should be aware that they may receive unsolicited or malicious SMS from the SmartThings system and respond accordingly. Perhaps they will choose to never use SMS in their own SmartApps so that they can block the SmartThings SMS text number entirely.
Absolutely! The author makes a point that SmartThings security is better than others. Nevertheless, the flaws that he pointed out should not be dismissed as “fud” or “red herring”.
Yes you can. All it takes is access to one of the many virtual PBX services. You can spoof any telephone number you want. Again. That’s not even relevant. I don’t have the short number memorized. I doubt the average user has it memorized either. I was making a point about social engineering. You don’t have to have all of the details, just enough details so that it seems plausible. But with number spoofing I can call you and make it appear that I am calling you from a local hospital, or the police department.
That is something that should be addressed. But this only works assuming that they have your phone, it’s unlocked, and you don’t have a phone with the service that allows you to do a remote lock/wipe when you lose it. If you wipe the phone the token is gone.
Unless they are. The actual flaws I acknowledged and I think they should be fixed. Some of the things he uses as examples are just purely hypothetical and highly unlikely.
I didn’t do it with st though.