Security implications

Up front: I'm not suggesting an evil plot or anything, I'm just raising this as an issue of concern.

Unlike routers and modems, which are widely scrutinised (or not so scrutinised), the Flukso sort of flies under the radar.

So, there is this device that I just bought, and I like it very much because it helps me to save money. The device sits on my LAN and talks to the Internet. Because it sits on my LAN, it sees every packet that goes across that LAN. Moreover, the device can do anything it likes, such as finding open ports on machines on my internal network. (Like most people, I do not tightly secure devices that are behind my firewall.)

From what I've read, the Flukso's firmware can be updated over the net too (which is something that most other network appliances won't do without user intervention). So, just theoretically, I could spend a lot of effort examining the Flukso, see whether I can find a way to update the firmware myself, and go ahead and do that to every Flukso on the Internet. Presto, instant perfect backdoor.

As far as I can see, this raises two issues:

One: I need to trust Flukso.

No problem, I do. I implicitly trust the manufacturer of absolutely every device that can connect to my network. (I don't believe in evil conspiracies.)

Two: I need to trust Flukso that the firmware update mechanism is secure enough that a third party cannot subvert it and install their own firmware.

That second point is much like the issue with UPnP routers. Every time I add a device that connects to my own network and can respond to incoming requests from the outside world, I'm not only trusting that the company who sold me the device has good intentions, but also trusting that the same company is competent enough to ensure that no-one in the entire world can subvert the software they have installed on the device.

As a software engineer and network programmer with nearly 30 years experience, I think I can safely claim that making such a guarantee is damn near impossible.

Any thoughts on this from Flukso?

The remote firmware update is extremely convenient, and I can see why Flukso wants such a thing. But the potential consequences of having this go wrong are extremely serious.

What guarantee do I have that no-one (absolutely no-one), will be able to subvert the protocol that updates the firmware, or subvert one of Flukso's servers and substitute a firmware image of their own making?

Cheers,

Michi.

gebhardm's picture

Hmmm, I must admit that I didn't care so far; but two things from my FLM experience:
1) The FLM does IMHO no update by itself; the upgrade at least for both my FLMs was posted as an option in the device's section of this site for me to actively trigger - but I must admit that I am not too deep in the openWRT stuff to judge what is in its capabilities... (but the code is there, so anyone may take a look, what by itself would be a matter of trust as so all openWRT devices may be harmed)
2) Communication to the FLM is by https, so even when every packet reaches the FLM, does it necessarily have to care on non-fitting certificate data?! (how trustworthy is https?!)
So, I do not see too much of trouble; there are certain routers out there that may represent an even larger risk...
But the master of all FLMs may give his advice on this...
Best regards
Markus

michi's picture

OK, maybe I'm living under the wrong assumption then. From browsing the forum, I got the impression that is possible to trigger a firmware update from the Flukso end. If that is not the case, the concern obviously is lessened.

HTTPS is as strong as the encryption it uses, and as trustworthy as the certificates it relies on. If someone can subvert a certificate, HTTPS can be man-in-the-middled quite easily. Schools do this quite routinely by installing certificates on student machines that point at a proxy through which all traffic is routed and, therefore, can be monitored.

Michi.

cimm's picture

You raise some valid points but don't you exaggerate just a little bit? I mean, probably one could hack the FLM and use it for an evil plot but why would you?

First, the you don't have to trust Flukso, the company that is. The firmware is open sourced and freely available on github, you are welcome to go over it and modify it as you want. I heard someone who pushes the collected data to its own server instead of Flukso's. By doing so the Flukso doesn't even need to access the internet and you could completely shield it from the outside world.

Secondly, hacking the Flukso would probably a tedious job with little gain. Sure, you can do it but wouldn't it be more profitable to try to hack some old Windows XP machines on these networks? I mean, how many FLM are there? I guess it would be more profitable hacking PC's or routers instead of the Flukso devices. But you are right, this doesn't mean that we don't have to care about security.

Personally I am more concerned sharing my data on the Flukso network. You can publicly share your data (as you can see on the website) which goes one step to far for me. I am afraid it would be too easy to see if someone is at home or to detect patterns in a household (e.g. every monday evening there is no water, gas or electricity used between 6 and 7 PM so one could assume no one is at home). Luckily you don't have to share your data if you don't want to.

michi's picture

Thanks for the comments. I agree that the Flukso is a "small target", compared with finding a zero-day vulnerability in something like Windows. On the other hand, hackers will exploit any entry point they can find, particularly when it gets them onto the internal network, even if there are few devices to attack. That's because, once on the internal network, it is typically trivial to compromise more machines that then can be used for serious work in a botnet.

As far as keeping consumption data private, I agree, that's probably a really good idea. It is trivial to find the location of a PV system on pvoutput.org. (I can browse a Google map and, in many cases, people have entered the exact location of their system instead of just a generic location, such as the suburb.) If can see consumption data, I can immediately tell when people are at home.

So, if I'm a burglar looking for rich pickings, I can look for systems in affluent suburbs that have conspicuously low consumption…

Michi.

the_roggy's picture

Always fun to think about conspiracy theories :-).

1) Conspiracy by the manufacturer: I only live about 20 km from his HQ... so if any of you is hacked... let me know, than I'll go pie in his mailbox the same day. I think that should amply cover the first risk.
2) Conspiracy of a FLM-hating hacker. This one is a bit tougher... but I sincirely think that any hacker targeting FLM's is really hopeless. Every day they there are new reports about security problems in java, flash, IE,... These products are used by millions of users, and the bugs are even described on the internet: you don't even need to look for the errors yourself! So why would anyone put any effort in hacking a device with only a few hundred users...

So... I hope the manufacturer thinks about security once in a while (and I think he does, because we have the "mixed content problem" because www.flukso.net is using https ;-))... but even if he doesn't... the risks I am facing for having java enabled are still a magnitude higher.

michi's picture

I agree that there are bigger and better targets out there. Windows, Java, UPnP, Flash, Acrobat, Word, etc., etc. And I'm not about to disconnect my shiny new Flukso because of a (most likely very low) probability that it might get hacked.

I raised this mainly as a general concern, because it's something we need to think about more and more as we add more automation to our homes. I'm rapidly getting to the point where I'm about to lose count of all the things that are connected to my network. Several computers, printers, router, modem, wireless access points, mobile phones, tablets, wireless backup, guests connecting while they are at my place…

Each and every one of those presents a potential attack vector. There was a recent issue with Samsung printers being vulnerable, for example.

Like the Flukso, a Samsung printer is probably a "small target". But that doesn't mean that hackers won't go for it. The printer itself isn't so interesting, but what it can lead to is. If nothing else, the printer could be turned into a network sniffer, for example. Or use it to probe for open ports on devices on the internal network that are more interesting, such as a PC. From there, it's only a small step to install a key logger or some such. The same considerations apply to the Flukso.

So, I think arguments along the lines of "the Flukso is small fry and, therefore, it doesn't need bullet-proof security" are dangerous, IMO. That just trivialises the problem without addressing it.

One thing I really would like to know is whether (or not) it is possible for the Flukso firmware to be updated "under remote control" from Flukso. If so, that's a highly vulnerable point and should be addressed. For example, the web interface could present a dialog that informs me when a firmware update is ready. It could also present me with Flukso's certificate, so I can check whether it's genuine, and it could show me an MD5 checksum of the install package, which I can compare against a list of checksums for each firmware version on the Flukso site. Still not perfect, but it would make it much harder for an attacker to exploit a Flukso as an entry point into my internal network.

If silent firmware update is currently possible, I think I should be given the option of turning that off at least. I understand why such a feature is ultra-desirable from Flukso's point of view, but it isn't necessarily desirable from the user's point of view.

Cheers,

Michi.

bazzle's picture

Thanks Michi

Good points IMO
However 'small' the risk a risk all the same.

Bazzle

the_roggy's picture

Yes... it is ofcourse always better to have a "safe" product... and an opt-out of automatic updates might lower some risks...

But then again.... I never heard of update servers being "hijacked" so a malware version would be installed instead of the ligitimate (but I didn't look for cases), and having older versions of software is in general a very big risk...
This is why all security-sensitive software (chrome, java, IE,...) explicitly has automatic updates...

icarus75's picture

Very nice discussion guys. Here are some points from my side:
1/ Any protocol or key mechanism can be subverted given enough resources in man power and computing power.
2/ Acknowledging point 1, to me it's a matter of striking a sound balance between security and features/ease of use. A telling example can be found in this forum post. What I wanted to achieve by disabling the local REST API by default is to prevent any intruder on your local network from gaining free access to your sensor readings. What people demand is features that work straight out-of-the-box. No fiddling with settings in the configuration interface, RTFM'ing or validating certificates. It should just work! TM
3/ I'm with Linus on this one (except for some of the expletives): "To me, security is important. But it's no less important than everything *else* that is also important!"
4/ Fluksometers are never silently updated. The user has to initiate the update for each FLM.
5/ If this does not satisfy your security requirements you can always uncheck the 'Report measurements to the Flukso platform' on the local sensor page. After that, the FLM will never call home again. Ever.
6/ For security reasons, I've now hot-wired my mailbox. Any liquid spilling on the metal lid will cause excruciating pains and 3rd degree burns in places you'd rather keep intact.

Cheers
/Bart

michi's picture

Hi Bart,

thanks for your reply!

OK, that clears it up. With a firmware update under remote control being impossible, there is no real concern remaining.

Roggy, if the need ever arises and you need to deal with Bart's mailbox, I think you had better use a water pistol :)

Michi.

the_roggy's picture

:-)

tintar's picture

you guys are awesome and hilarious. my work is in telco forensic security so I get paranoid-for-good-reason, and so had many of the same concerns Michi brought up. thanks Bart for the reassurances, that did make me feel better.

bazzle's picture

I raised a concern in the past that a users network name, security used and password are all on the flm. This gave me concerns at the time that 'IF" someone could get there your service may be compromised.

Bazzle

michi's picture

Well, the same is true for absolutely every device that connects to your wifi network. Basically, you rely on physical security of the Flukso. If someone can get their hands on the Flukso and connect to its ethernet port, all bets are off. But without this, the Flukso is secure because it won't divulge these details over its network interfaces.

Michi.

icarus75's picture

This commit will allow you to disable remote firmware upgrades on the Fluksometer. It will be rolled into the next firmware release and will be made available through a remote upgrade.

mr_thingy's picture

I mean, probably one could hack the FLM and use it for an evil plot but why would you?

To own the rest of the network from the FLM. The question isn't so much "why would you" but "would you"? The security of most embedded devices is terrible, and the rest are even worse than that, so you can pretty much assume that anything on your network that isn't a general-purpose PC or equivalent is going to have awful security Given that, attackers are going to go for the lowest-hanging fruit with the widest installed base. That means primarily warkitting your router (installing custom firmware with, uhh, supplemental functionality) and then to a lesser extent going after printers. Oh, and the occasional Siemens PLC :-). Anything else is too exotic for anyone to bother unless it's a very targeted attack.

In terms of trading off convenience for security, I think the FLM does a pretty good job. If you're really worried about it, drop it into its own VLAN or whatever equivalent your router gives you, so it can see the web site it posts to but nothing else.

khan123's picture

IMHO, once entered and working wireless password should not be displayed in plain text in GUI.

Fred.'s picture

It would be nice if we could use a self signed (or a real) certificate on the flukso.