[Chet] bought an electricity monitor from OWL, specifically because it was open and easy to hack on at him within the confines of his home network. Yay! Unfortunately, it also appears to be easy to hack read outside of his home network too, due to what appears to be extraordinarily sloppy security practices.
The short version of the security vulnerability is that the OWL energy monitors seem to be sending out their data to servers at OWL, and this data is then accessible over plain HTTP (not HTTPS) and with the following API: http://beta.owlintuition.com/api/electricity/history_overview.php?user=&nowl=&clientdate=. Not so bad, right? They are requiring username and password, plus the ID number of the device. Maybe someone could intercept your request and read your meter remotely, because it’s not encrypting the transaction?
Nope. Much worse. [Chet] discovered that the username and password fields appear not to be checked, and the ID number is the device’s MAC address which makes is very easy to guess at other device IDs. [Chet] tried 256 MACs out, and got 122 responses with valid data. Oh my!
Take this as a friendly reminder and a cautionary tale. If you’re running any IoT devices, it’s probably worth listening to what they’re saying and noting to whom they’re saying it, because every time you send your data off to “the cloud” you’re trusting someone else to have done their homework. It is not a given that they will have.
If you think that’s bad, my power company forces me to use a metering system that’s even more secure.
Anyone can walk up to the side of my house – with no special equipment of hacking knowledge – and read right off the meter how much power I have used.
Haha.
But it doesn’t give a time specific log that tells them when you are at home and when you are away, in case they need to go into your house and check your thermostat, or TV…
or place you at the scene of a crime
But, as you said, that requires someone to be physically present at your house to read it. And, it doesn’t potentially open other security holes via the device.
If you can tie energy usage to an actual physical address, it’s very easy to use this to monitor if someone is on vacation or see when they’re regularly out at work. After that step, burglary becomes a lot, lot easier :(
Well, just fire up the reactor in the basement and no one will ever know when your home or not….
This is the problem I see and it applies to any utility. You don’t need any fancy analytics to determine when a house is empty. Granted the data available via that api doesn’t give instantaneous usage onlu historic totals etc. The instantaneous usage is sent to the app via an xmpp stream, something I’m not overly familiar with and haven’t snagged the data from it yet.
I think you are overestimating the technical skills of your typical house burglar.
You’re assuming that the ones that get caught represent the “typical” burglar. Only the stupid and unlucky get caught.
Smart gets caught too, just not as frequently. They get cocky, and greedy.
i had to laugh when I read the bit about the api not being encrypted.
who is this suspicious character carrying out these sniffing attacks?
the whole energy usage thing is pretty stupid anyway, every time I see an American complain about wireless electric meters they show you the meter and its on the outside of the house! its not even in a box? anyone could walk up or look through a scope and read off your meter. I’m sure there are actual concerns about smart meter where they charge you differently or whatever but how much energy you use is hardly a state secret.
the subdomain is beta, is there anything in the manual or documentation warning about this?
leaving out the authentication is probably a blessing if there isn’t any control on retries.
I wonder if anyone has contacted the company for a statement?
of course anyone with any actual concern about their privacy would either avoid this kind of thing entirely or believe themselves competent enough to lock it down properly. being surprised by things like this is like buying something from a chinese bulk ebay shop and being surprised when its shit.
The problem is not a single point of metadata, it’s that when you have a lot of metadata … you can correlate. It’s easy to see shared energy usage patterns. You could see which people are dating (energy usage moves from one to the other meter) or go on holidays together, or which people work at the same company.
This might seem far-fetched, but it’s not hard to imagine a power company supplying all of their customers with such a device, not only resulting in much less effort for them to check your meters but also resulting in a significant amount of metadata to those who are able to access it, legitimately or not.
This! A i said in another comment, what can be done WILL be done at some point and laws are only pieces of paper (and can be changed anyway). It’s really not difficult to connect some databases and run some programms today…
Exactly. Even publicly available metadata can lead to interesting results once you have a knowledgeable machine-learning/data-mining professional handle it.
Some other scenarios I could imagine:
– You can deduct where an meter resides by correlating energy usage with weather patterns
– You can deduct a change in employment status from changes in regular energy usage patterns
This might seem fuzzy, but the more metadata, the clearer the picture becomes.
Case in point: At 33c3 we had a talk from somebody discovering internal company structures about a major German online magazine, just by archiving and data-mining publishing dates and authors of online articles he was able to deduct internal teams and personal relationships.
This is part of the larger issue of data leaking. The problem is that each instance seems trivial but it’s the combined effect that should have us worried – far more collectively than we do now. Hacking your IoT network to stop it from phoning home only gives a false sense of having done something. What we need is a broader plan to deal with this threat.
Get rid of everyone else. Problem solved.*
*tongue in cheek.
Interesting on how this project counts as a complete fail (which it is), but THIS is”tidy” when it not only monitors your temperature, but can SET the temperature in your house without encryption at all.
Here’s a note from the souliss repo:
“As per design is assumed that you should run your Souliss network in a secure and trusted network, this because by default Souliss doesn’t carry security mechanism at network level. ”
People complain when commercial IoT products don’t use proper security, but somehow we praise DIY products that don’t do security at all.
It’s just not that hard, go get WolfSSL or MbedTLS (or one of the several other small SSL stacks), compile it and use it for free in your non commercial products.
(Yes, WolfSSL fits on the ESP8266. I bet MbedTLS does so also.)
I’d rather have no security at all, and be informed of it, than have “security” that turns out to have been full of holes.
I just read it now so I’m no expert, but the Souliss repo page seems to be pretty straight-up about what your options are for building in security — there is none, so keep it inside your home network and only VPN/SSH in.
Yes, it’s single point of failure and not defense in depth and all that stuff. But it’s also a home automation system, not Fort Knox. If someone is inside your WiFi, you’ve got worse problems than them setting your thermostat.
It is a crappy implementation for their server for certain. However, whilst you can guess MAC addresses, you’ve got no way of knowing who actually owns that monitor or where it even is. If somebody malicious has gotten into your house, found your OWL energy monitor, read the MAC address, typed it into this broken server API and then started graphing your usage to determine occupancy then you’ve got bigger issues already. The most reasonable attack would be to buy an OWL monitor and send it to your victim so you’d know the MAC address beforehand. It is a bit far fetched for burglars to do this and law enforcement or governments have better ways to monitor you anyway.
I think you’re right. OTOH, if they’re doing something this dumb, who knows what else they’re doing wrong?
How do we know it’s them doing something dumb and not that they decided that security wasn’t an issue after the fact, due to the reasons that [GotNoTime] laid out. The product could have already been built but they decided it would be easier to eliminate the extra security check at the server instead of updating the devices.
Hmm. Yes. That is a good point. I was assuming it was because they’re inept with the server end. It could be possible that they’ve just shipped a million devices with broken authentication and the “fix” was just to disable the username + password check entirely! Yuck.
What if the hacker can learn the IP address from the service? There are many reverse geo locating services out there. An address plus account data does turn into something useful for an attacker.
I think the major point is missed when purchasing IOT devices. The owner of the OWL wanted something that would work within their network. So why didn’t they shut down all internet access to the device. I have a separate DMZ for all my IOT devices. They can’t talk to the internet. All information they need from the internet is queried with a raspberry pi in my normal lan, then the IOT Controller kicks off an SCP job to retrieve the parsed files from the pi that queried the data. This OWL device would not have any internet access in my setup and the attempts to phone home would be stopped and logged by the firewall.
Insecurity trends exist on each level. For example wireless mbus with it’s aes encryption is probably a good standard, it even requires you to start your encrypted block with something random or atleast curent time. Good in practice until energy or water companies tell installators that their keys are too difficult to set in field and they need something more simple. So installators install key “0000…” in all their meters.
Are meter data encrypted? Yep
Are energy companies happy? Yep
Is this encryption effective? Nope.