How would you do a heating controller, IOT client, securely?

[nctnico]

The context is that an IOT box should always be a client, behind NAT, and never a server, especially not on an open port.

The problem is if you want it remotely accessible. There are many such products.

This has been done for decades (I used to do one in the 1980s which was accessed over a phone line modem, so the security was a) knowing the phone # and b) knowing the password) but how do people do it nowadays?

With a central server where ET can phone home to.

You need to take a step back when designing a system that needs to be secure. Security is more than just throwing encryption onto a communication channel and call it a day. Good security starts with 3 basic pillars: Authorisation, Authentification and Accounting. The last one is the most interesting and probably the most difficult one to implement right; Accounting means monitoring how a device is used and whether the usage patterns fit with what is expected. Note that none of the pillars prescribes using encryption of some sort! That is a choice made later on when making the system's design.

Take an NFC card which has a credit balance on it as an example. Through accounting you can keep track of how much money was deposited onto the card and how much is withdrawn. If more is withdrawn than deposited, you know somebody is cheating.

When done right, one of the 3 pillars can break completely without affecting the security of the system.

[peter-h]

I agree; eavesdropping is actually a very low risk in this application where a client is "phoning home to". So encryption / authentication is not the #1 thing. Especially as anybody can buy one of these devices, and extract any keys (or certificates) from it.

But any corporate customer will demand "privacy" etc regardless of relevance. And TLS is a "standard".

[zilp]

I agree; eavesdropping is actually a very low risk in this application where a client is "phoning home to".

No, it isn't.

So encryption / authentication is not the #1 thing. Especially as anybody can buy one of these devices, and extract any keys (or certificates) from it.

You keep demonstrating that you have no idea what you are talking about.

Seriously, why did you even start this thread, asking for advice on how to implement things securely, when all your replies so far are "well, yeah, but who cares about security, and also, I know all of this better than experts in the field anyhow"?

[nctnico]

I agree; eavesdropping is actually a very low risk in this application where a client is "phoning home to".

No, it isn't.

Why not? What is secret about messages specifying the temperature setpoint and what the actual temperature is?

[zilp]

I agree; eavesdropping is actually a very low risk in this application where a client is "phoning home to".

No, it isn't.

Why not? What is secret about messages specifying the temperature setpoint and what the actual temperature is?

The addresses, ports, and sequence numbers, because those allow you to inject messages into the connection, and thus, for example, change the set point. Specific attack scenarios obviously depend on protocol details.

(If you are talking about "a protocol that protects against everything but eavesdropping", i.e., a protocol that authenticates the endpoints and provides message integrity, but doesn't provide secrecy, then you might be technically correct that that might be low risk, depending on the specific information that is being transmitted ... but then, do you think that that is anywhere close to what peter-h meant, given his obviously rather limited understanding of cryptography?)

[madires]

Maybe the OP could list the security requirements as a starting point for a more productive discussion.

[peter-h]

I mentioned a heating controller.

So you can talk about the security requirements for that.

Think about who would want to do around trashing heating controllers. Especially if they are all behind NAT so can't be casually discovered with a port sniffer. This is not like the old "AXIS IP camera on an open port, exposing an HTTP server" which could be discovered with google

[zilp]

I mentioned a heating controller.

So you can talk about the security requirements for that.

For one: That barely says anything about specific scurity requirements.

But also: I did, you dismissed it all as irrelevant because you know better anyway, so what's the point?

Think about who would want to do around trashing heating controllers.

The assumption that this is only about "trashing heating controllers" is already the first mistake.

Insecure IoT devices (depending on the specific vulnerabilities, obviously) can be used as proxies to execute attacks against other people, including for sending packets for DoS floods, they can be used to spy on the network they are connected to, they can be used to attack other devices on the network they are connected to.

Insecure IoT devices that are attached to/integrated with industrial control style systems (i.e., systems that control significant energy flows rather than just information) further are at risk for manipulation that causes malfunction in a way that causes property damage of surrounding/attached infrastructure or even injury, and for being used to generate destabilizing or even destructive load patterns on the energy supply system (think heat pumps with 9 kW resistive backup heat, if you have a million of those in a country, you can use that to generate a 9 GW load change--if needed, repeat that every 30 seconds, alternating between on and off, and I would be very surprised if the grid stayed up ... really, you could call yourself lucky if the grid just turned off without damaging large numbers of devices with overvoltage).

Which of those matter to your specific application? Well, that largely is a matter of economics. As I said, if it's a one-off project, probably none of it really matters, because noone is going to invest any effort into trying to compromise that one system for basically no gain. If you have an installed base of a few million, your device becomes way more interesting as a target. Also depends on the value of the targets themselves, of course.

Especially if they are all behind NAT so can't be casually discovered with a port sniffer.

For one, you keep repeating this term. It's not a thing.

But also ... you are just continuing to demonstrate your lack of clue when you keep going on about how NAT prevents easy dscovery of your device via port scanning, without ever even addressing any other attack vectors that can be used to discover your devices. Just because you can't think of any other way to find devices, doesn't mean that people who do such things for a living can't either. And that's completely ignoring the fact that NAT doesn't even necessarily prevent port scanning ...

Just because you haven't ever heard of ARP spoofing or DNS spoofing, doesn't mean that attackers haven't either.

This is not like the old "AXIS IP camera on an open port, exposing an HTTP server" which could be discovered with google

I mean, that is kinda trivially true. But it's also a very low bar, isn't it? I mean, that you can't find vulnerable devices with a simple google search doesn't imply that therefore, there is only negligible risk of exploitation, does it?

Obviously the server is a weak point, since it is likely to either contain a database of the units sold (for validation or firmware OTA update purposes), or if malicious code could be installed on it, such a database would eventually be compiled.

... or an attack could simply be executed via that server. Or an attacker could just rent a server with the same hoster and hope they get one on the same broadcast domain as yours and then do an ARP spoofing attack on your server to find all the devices. Or ... whatever.

The real point here is that you obviously have no idea as to how these systems can be attacked, but you still are very confident that you can dismiss all suggested security precautions as unnecessary because you can't think of a way to attack them, or you imagine that it must be extraordinarily difficult to do these things that you aren't familiar with.

[Siwastaja]

I mentioned a heating controller.

Heating controller, when widely deployed, opens up a possibility for hybrid warfare operation, e.g. by depriving people of heat. HOPEFULLY the product has a physical bypass switch, documented and obvious to end user; but even then, heating controller would be used when people are not present e.g. are on vacation, or the controller is at their second home; in such cases, lack of heating for prolonged time can cause pipes bursting, and if it's the very same product offering monitoring, then it's trivial to fake the temperature and power consumption readings so that everything appears to be right.

Another attack vector is to turn every electric heating available ON at the very same second during highest consumption moment, in an attempt to make the grid collapse. Not relevant if you have sold a thousand; very relevant after you have sold 100 000 and sold your customers as demand control to the grid operator and promised they are OFF during that very hour.

Now for something which purely monitors, the risks are smaller, but anything that controls need higher level of scrutiny.

[Nominal Animal]

Now for something which purely monitors, the risks are smaller

Actually, systematic burglaries where a team goes through a neighborhood hitting a few houses in just a few minutes each, often monitor their targets for a few days beforehand to make sure when they'll be vacant.  Having remote access to heating system statistics would make that a lot easier.
(Here in Finland, this is most typical for summer cottages raided by eastern european burglar teams just outside the main holiday seasons.  Domestic burglaries often specifically target weapons.)

I personally do consider any IoT system that can be used to easily access occupancy information a serious, serious security risk.
Vandalism, or maliciously changing the controls, may actually be a smaller practical risk than burglary profiling.

[zilp]

Now for something which purely monitors, the risks are smaller, but anything that controls need higher level of scrutiny.

I think it is important to be explicit: It's about possibilities, not about intentions. I.e., the relevant criterion here is not whether something is intended to only be used for monitoring, but whether it in fact can only be used for monitoring.

Like, if the system just hooks into the interface bus of the heating system (like, what usually the control panel is connected to) and effectively allows unrestricted access to that bus to a remote server, then it doesn't matter if this is only intended for reading sensor values, when you can in fact send messages to the bus that allow you to change any setting of the system.

Part of proper IT security is to restrict privileges at interfaces such that the user of that intrface can not do more than what is actually necessary. So, in the case of a pure monitoring system, for example, one useful approach would be to have one component that somehow extracts any relevant values from the heating system and then just continuously transmits them over a low-complexity unidirectional, ideally galvanically isolated, interface (think: tx-only UART), with that link plus some current-limited power supply being the only thing that connects the heating system itself to the circuit that is interfacing things to the internet. This way, even if the internet intrface part gets compltely compromised, the heating system still keeps doing its job unaffected.

[Nominal Animal]

Part of proper IT security is to restrict privileges at interfaces such that the user of that interface can not do more than what is actually necessary.

Yup: privilege separation, and specifically the principle of least privilege.

Modularising the system is an effective way, like I described in my suggestion earlier in this thread.  For example, you might have two buses: a control bus, and a monitoring bus, both using some plain serial protocol, perhaps I²C/SMBus or just plain UARTs.  The main device handles the heater control, and will work with the current settings even without any control or monitor modules.  Internally, the monitoring bus can be restricted to request (two-way comms) or stream (one-way comms) the statistics, whereas the control bus can change settings and request statistics (to avoid the case where a module would need to be connected to both buses).
This way, a monitoring module cannot, even if cracked/hacked, modify the settings on the heater control device.

Consider the case where you have a single embedded processor handling both heater controls and an IP/TCP stack, and how difficult it is to ensure the heater control logic is never starved of resources, even when bombarded by fake TLS connection attempts (where each handshake can take a significant fraction of a second of calculation time).  You'll basically need an RTOS or dedicated cores to get that done.  In a modular design, you only need to make sure that you handle the communication bus messages only when the heater logic allows; and since these are simple state variable requests and change requests, they can be processed in known maximum time, with pretty straightforward code.  This is why I personally prefer to split complicated devices to multiple microcontrollers, and in systems programming (mostly Linux), heavily rely on process-based privilege separation.

One of my favourite security-related rants is how both Apache and Nginx implement suEXEC fundamentally incorrectly.  It would be much better to run script interpreters that refuse to interpret scripts owned by the user they run as, because that would eliminate all script-drop attacks.  Also, because of the possible security implications in scripting in e.g. SVG files, it would be best to use a separate subdomain (virtual host) for user uploads.  But, because that means each site would need at least two DNS entries and several user accounts and groups, it is "too complicated" to the implementors of hosting control panels like Plesk who just do not understand the security scheme or privilege separation in general at all, and WordPress etc. developers believe their code should be able to rewrite ("update") itself, this is never done.  It is technically easy and simple, but the humans involved just don't want to do it.

[peter-h]

I still don't get how, if say you sold 100k of some box, which is a client which calls up some server, and they are all installed behind a standard NAT router, can somebody discover all these?

It's no good repeating that NAT is insecure blah blah. Obviously NAT won't give you protection if that server is penetrated, but that's a different discussion.

Intuitively I am sure somebody here is pulling my leg (or just doing the standard "internet security lecture" bit) because if it was possible, all PCs, laptops, even phones, would be unusable. But obviously they are not unusable, most are not on botsnets. AFAICT the normal attack is done by the owner downloading a trojan (from an infected website, or by receiving an infected email) and unfortunately those attacks have been very easy.

Oh and BTW I've just remember another way to do this kind of separation exercise: use email I have a system running (not related to anything discussed here) which polls a POP box every 5 mins for incoming emails, acts on stuff in the emails, and then emails certain data to certain recipients. Pretty bloody hard to work out how to penetrate that computer... Especially as the program polling the POP box is custom written, not MS Outlook or similar which has known exploits.

[zilp]

I still don't get how, if say you sold 100k of some box, which is a client which calls up some server, and they are all installed behind a standard NAT router, can somebody discover all these?

All of them? Maybe not. Many of them? Possibly. That depends a lot on implementation details and details of the specific NATs in place.

And I have already mentioned some possible attack vectors before, like Websites in browsers on the inside of the NAT or apps on phones on the inside of the NAT, or just guessing NAT state. Another option could be DNS poisoning.

It's no good repeating that NAT is insecure blah blah. Obviously NAT won't give you protection if that server is penetrated, but that's a different discussion.

Except it isn't really a different discussion, because good security practices help against either. If you build a monitoring-only thing the way I described above, say, then that prevents damage to the heating system regardless what way an attacker were to use to compromise the internet interface.

Intuitively I am sure somebody here is pulling my leg (or just doing the standard "internet security lecture" bit) because if it was possible, all PCs, laptops, even phones, would be unusable. But obviously they are not unusable, most are not on botsnets.

Except ... the only reason why they are not unusable is because they are nowadays largely doing exactly the things that you seem to dismiss as unnecessary!?

I mean, don't you remember the time when pretty much all Windows PCs operated by normal users had viruses on them and were participating in some botnet or another?!

That changed because vendors started caring about security at least to some degree, deployed TLS everywhere, changed code standards, did a ton of fuzzing, security audits, and fixed the vulnerabilities they found, implemented mitigations like ASLR, non-executable data pages, stack canaries, what have you ... a ton of work that makes it relatively difficult to compromise current systems.

And also, just recently, two router-botnets were taken down:

https://www.securityweek.com/us-gov-disrupts-soho-router-botnet-used-by-chinese-apt-volt-typhoon/

https://www.securityweek.com/fbi-dismantles-ubiquiti-router-botnet-controlled-by-russian-cyberspies/

Oh, and also, attackers don't have any incentive to make their victims' systems unusable. If their business is to use your router to DDos other people, being detected would hurt their business. If they are spying on you, it would undermine their goal if they made things unusable for you, when that would likely motivate you to fix the problem.

Also mind you that a lot of security depends on fixing vulnerabilities as they are being found. Requirements are very different if you expect your system to stay secure without updates for 20 years of lifetime, say. And if you want to be able to do OTA updates, then that brings its own challenges with regards to securing that update system.

AFAICT the normal attack is done by the owner downloading a trojan (from an infected website, or by receiving an infected email) and unfortunately those attacks have been very easy.

Well, that is one common attack vector, yes, but certainly not the only one. And also, that's just a matter of economics. As long as that is easier to achieve some goal, that's what attackers do. But if your product is supposed to last 20 years, say, you have to be prepared for when those easier attack vectors get shut down, so you don't end up surprised that some vulnerability in your system is now the easiest way in.

Oh and BTW I've just remember another way to do this kind of separation exercise: use email I have a system running (not related to anything discussed here) which polls a POP box every 5 mins for incoming emails, acts on stuff in the emails, and then emails certain data to certain recipients. Pretty bloody hard to work out how to penetrate that computer... Especially as the program polling the POP box is custom written, not MS Outlook or similar which has known exploits.

No, that isn't hard, if the attacker has a copy of the code, which you can assume they have if the product with the code inside is a thing you can buy.

[peter-h]

like Websites in browsers on the inside of the NAT

How would this work? The whole world is browsing websites behind NAT.

or apps on phones on the inside of the NAT

How would this work? The whole world is running apps on phones, either behind their own NAT (home wifi) or (more often) behind the telco's NAT.

or just guessing NAT state

How would this work? The NAT router opens an incoming channel only from the external IP which was accessed when the channel got opened. If this wasn't the case, with a typical NAT channel open for 180 secs from end of data, most NAT routers would be wide open, which they obviously are not. You would have to guess that the user is browsing e.g. microsoft.com and then you could send in a packet from microsoft.com's IP (actually M$ will have servers on many IPs, for load sharing reasons, so you would have to send in loads of packets all in one go) which is malformed to exploit something on the inside.

Another option could be DNS poisoning.

So now you would need to poison microsoft.com's DNS. Yeah, that must be really trivial I mean, somebody is doing this every day, which is why every time I go to microsoft.com I get a p0rn site...

OK, one could do a bit of social engineering and induce the user to go to a website whose server you control, but how would you do it with 100k users, or even 0.01% of those 100k? You won't know who they are...

because they are nowadays largely doing exactly the things that you seem to dismiss as unnecessary!?

Which is what? They are people behind NAT browsing websites and running apps on phones!!

don't you remember the time when pretty much all Windows PCs operated by normal users had viruses on them and were participating in some botnet or another?!

There was never such time. "Pretty much all"?? People caught viruses off emails / M$ Outlook, by going to infected websites, etc. Not because somebody hit them by NAT penetration. The general infection situation was greatly reduced by

- ISPs covering the domestic market filtering emails with executable attachments
- email filtering gradually getting better
- browsers having better security / fewer back doors (definitely nothing to do with https)
- email clients having fewer back doors
- email clients having a default config whereby 3rd party image links are not followed
- web servers becoming harder to compromise (various measures) so infected websites became rare

I read your Ubiquiti botnet article. Yeah, if you install some app or device which opens an incoming hole in your domestic router, then people can discover that and go in there. But that isn't "penetrating NAT". It opens a means of placing a potentially malformed packet on the user's internal LAN, so it is a similar thing to the above guessing that the user is browsing a known website. But in the vast majority of cases nothing is going to respond to that packet. So you are stacking a low probability on top of another low probability.

There are billions of devices on the internet. Sure you can hit something somewhere, but I still want to know how you are going to hit those 100k heating controllers.

You are pulling my leg, moving the goalposts, and pulling my leg again.

I still want to know how I am going to hit 100k heating controllers, when they are behind normal boring domestic-router NAT.

[zilp]

like Websites in browsers on the inside of the NAT

How would this work? The whole world is browsing websites behind NAT.

Hu? Yeah, that's why it works?!

That works by somehow making the user open a website that contains Javascript code that then can use browser APIs to access your LAN.

or apps on phones on the inside of the NAT

How would this work? The whole world is running apps on phones, either behind their own NAT (home wifi) or (more often) behind the telco's NAT.

Hu? Yeah, that's why it works?!

That works by distributing an app (say, a free game) that contains code that then can access your LAN.

or just guessing NAT state

How would this work? The NAT router opens an incoming channel only from the external IP which was accessed when the channel got opened. If this wasn't the case, with a typical NAT channel open for 180 secs from end of data, most NAT routers would be wide open, which they obviously are not. You would have to guess that the user is browsing e.g. microsoft.com and then you could send in a packet from microsoft.com's IP (actually M$ will have servers on many IPs, for load sharing reasons, so you would have to send in loads of packets all in one go) which is malformed to exploit something on the inside.

... which is all completely irrelevant for a heating controller that potentially connects to exactly one IP address, and that potentially keeps the connection open indefinitely to allow the server pushing config changes whenever the user changes a setting through their app or whatever.

The point being that you depend on a lot of details of how the specific NAT works and of how exactly your TCP stack works, and of how your specific application uses TCP, to even have that security.

Another option could be DNS poisoning.

So now you would need to poison microsoft.com's DNS. Yeah, that must be really trivial I mean, somebody is doing this every day, which is why every time I go to microsoft.com I get a p0rn site...

Yeah, I get it, you have an urge to demonstrate your cluelessness.

First of all, you obviously don't understand how a DNS poisoning attack works.

But also ... no, one reason why you don't get a porn site is because they use TLS and HSTS, with HSTS preload. And because attackers know that that is the case. So, they know that a DNS poisoning attack wouldn't gain them anything useful anyway. So they have no incentive to even try.

And also ... attackers don't present you with porn sites. How did you get this idea that the goal of attackers is to annoy you, rather than to abuse you without you noticing?

OK, one could do a bit of social engineering and induce the user to go to a website whose server you control, but how would you do it with 100k users, or even 0.01% of those 100k? You won't know who they are...

By putting your JS code on an ad network that will distribute it for you for a small fee, for example.

because they are nowadays largely doing exactly the things that you seem to dismiss as unnecessary!?

Which is what? They are people behind NAT browsing websites and running apps on phones!!

Hu? Yeah?!? Your point being?

don't you remember the time when pretty much all Windows PCs operated by normal users had viruses on them and were participating in some botnet or another?!

There was never such time. "Pretty much all"?? People caught viruses off emails / M$ Outlook, by going to infected websites, etc. Not because somebody hit them by NAT penetration.

The thing is that those aren't mutually exclusive. Yes, people caught viruses via email. But what you don't seem to realize is that that is in fact a method for penetrating NAT. Those same viruses at times then used their position on one machine behind the NAT in order to attack other machines on the same LAN. "Penetrating NAT" doesn't need to come in the form of sending packets fro the outside through the NAT, it can just as well come in the form of gaining access to the ability to send packets on the LAN via protocols/applications that can communicate freely through the NAT.

The general infection situation was greatly reduced by

- ISPs covering the domestic market filtering emails with executable attachments
- email filtering gradually getting better
- browsers having better security / fewer back doors (definitely nothing to do with https)

... except that that totally had to do with https. See prevention of successful attacks via DNS poisoning above, for example.

- email clients having fewer back doors
- email clients having a default config whereby 3rd party image links are not followed
- web servers becoming harder to compromise (various measures) so infected websites became rare

Did you notice how none of that is: Because they deemed "being a client behind NAT" good enough?

I read your Ubiquiti botnet article. Yeah, if you install some app or device which opens an incoming hole in your domestic router, then people can discover that and go in there. But that isn't "penetrating NAT". It opens a means of placing a potentially malformed packet on the user's internal LAN, so it is a similar thing to the above guessing that the user is browsing a known website. But in the vast majority of cases nothing is going to respond to that packet. So you are stacking a low probability on top of another low probability.

For one, I think you misunderstood the point that I was making, namely, that devices do get compromised in order to turn them into botnets, and that this is not just a hypothetical scenario.

But also: Yes, of course that is also a method of penetrating NAT, in that this is a way in which the security that NAT potentially provides can be undermined, and is undermined in practice, and thus, if you care about security, this is one data point that suggests that relying on NAT for security is not a good idea.

And do you maybe not realize that attacks of that sort are automated? That there isn't some hacker sitting at a computer "hacking your heating controller", but rather just some exploit payload that can be deployed to potentially hundreds of thousands of compromised devices that are part of a botnet in order to have them all look for your heating controller on their respective local network, for example?

There are billions of devices on the internet. Sure you can hit something somewhere, but I still want to know how you are going to hit those 100k heating controllers.

You are pulling my leg, moving the goalposts, and pulling my leg again.

I still want to know how I am going to hit 100k heating controllers, when they are behind normal boring domestic-router NAT.

That obviously depends on how exactly that thing is implemented?

You need to understand that security best practices are not about only doing what is absolutely necessary in order to hopefully be secure. Security best practices are about methods that reliably deliver security, without too many fragile assumptions about other systems. You seem to expect me to explain in detail how exactly I would exploit your hypothetical heating controller, which obviously is a nonsensical thing to ask, given that the thing doesn't even exist yet, in order to then go "ah, see, you haven't shown me how exactly to exploit this system, therefore, it's secure" ... and that is a nonsensical conclusion.

Security best practice is to build any system that interfaces with public networks in such a way that it does not trust the network. There are many reasons why that is best practice, some of them have been mentioned in this thread. But the general idea is to minimize fragile assumptions. Just as you always do with good engineering. You don't put fuses where you have proven that a circuit is likely to burn your house down. You put fuses everywhere. Because they are (relatively) easy, and they are very reliable. Most fuses never blow. Many fuses protect circuits that are so well designed that you could in principle prove that the fuse will never blow. You put in a fuse anyway, because it is much easier to be confident that a fuse will blow than that you didn't fail to consider some failure condition.

You are constantly asking me to prove how I would make your circuit blow the fuse, which is mostly besides the point. I have shown you various ways in which your assumptions are fragile. And if you want to do reliable security engineering, that should be the clue to you to not rely on those fragile assumptions and to put in fuses regardless.

[Siwastaja]

Day after day, I'm more and more sure peter-h must be an artistic troll account, just like treez and nctnico. Doesn't matter though, interesting stuff.

[madires]

Another option could be DNS poisoning.

So now you would need to poison microsoft.com's DNS. Yeah, that must be really trivial I mean, somebody is doing this every day, which is why every time I go to microsoft.com I get a p0rn site...

OK, one could do a bit of social engineering and induce the user to go to a website whose server you control, but how would you do it with 100k users, or even 0.01% of those 100k? You won't know who they are...

For example, there were cases of mass-compromised SOHO routers returning wrong IP addresses on DNS lookups for well known websites. The IP addresses pointed to servers which injected ads.

[nctnico]

The thing is that those aren't mutually exclusive. Yes, people caught viruses via email. But what you don't seem to realize is that that is in fact a method for penetrating NAT. Those same viruses at times then used their position on one machine behind the NAT in order to attack other machines on the same LAN. "Penetrating NAT" doesn't need to come in the form of sending packets fro the outside through the NAT, it can just as well come in the form of gaining access to the ability to send packets on the LAN via protocols/applications that can communicate freely through the NAT.

Agreed. And let's not forget hacking the Wifi router which sits on almost every local network nowadays in order to gain acces to the network.

The bottom line is that you can't trust the network your device is connected to whether it is behind a NAT or not. In some cases the threat may even come from the local network. Think about the situation where the heating controller is also used for billing OR the device is bought by somebody with the intention to find the weak spots.

[globoy]

I've just been lurking on this thread but as someone who is now often being asked to design internet connected embedded systems I have to say what zilp has been posting is both educational and bracing.  It is helpful.  Thanks zilp.

I keep having this mental image that creating these devices is like running drunk and naked into a minefield.

One problem I see are clients who don't fully appreciate this and don't want to spend the money (for example I shouldn't be the authority on security for the device - someone is an actual authority should help us).  I get it though.  This stuff is hard and hard to explain to non-technical people (hell, hard for someone like me to fully understand). 

This has all been driven home by the fact I just got hacked.  I have one of those "one-off" DIY systems monitoring a second home, and after running for six years it just got owned by someone.  I had to ask a neighbor to go over and unplug it.  Now I have to figure out an even more secure mechanism to access that house.

[peter-h]

somehow making the user open a website

Yeah, 100k users

there were cases of mass-compromised SOHO routers returning wrong IP addresses on DNS lookups for well known websites. The IP addresses pointed to servers which injected ads.

Possible, but I still want to know how you are going to hit these 100k heating controllers.

This has all been driven home by the fact I just got hacked.  I have one of those "one-off" DIY systems monitoring a second home, and after running for six years it just got owned by someone.  I had to ask a neighbor to go over and unplug it.  Now I have to figure out an even more secure mechanism to access that house.

The architecture would be interesting.

[Siwastaja]

This has all been driven home by the fact I just got hacked.  I have one of those "one-off" DIY systems monitoring a second home, and after running for six years it just got owned by someone.  I had to ask a neighbor to go over and unplug it.  Now I have to figure out an even more secure mechanism to access that house.

Do you have any idea, even guess, what happened? Would be pretty educational to hear. The reason I ask is while we can surf sites that list common vulnerabilities, we don't hear how one-offs or small systems get compromised. And one of peter-h's (false) assumptions seems something along the lines that "if you are small enough, the hackers won't invest the time in hacking you", which is, in my opinion, lacking the fact that all of this is probably automated. So how did your one-off system got A) discovered and B) hacked?

[Siwastaja]

somehow making the user open a website

That part is easy-peasy. All you have to do is to mass send email from "peter-heater support" <any_email@goes.com>, and Gmail and other bullshit email clients will "helpfully" combine your scam email in the same thread with actual emails, making users not suspect anything. The email can be something trivial like "your heat controller has been offline, please follow the link to check the current status". >80% will just click the link.

[peter-h]

So how did your one-off system got A) discovered and B) hacked?

Prob on an open port, and got sniffed.

Unless he is paying a subscription, or running a VPN, this is 100% certain.

[zilp]

somehow making the user open a website

Yeah, 100k users

Yeah, ad networks have more than 100k "users" even.

there were cases of mass-compromised SOHO routers returning wrong IP addresses on DNS lookups for well known websites. The IP addresses pointed to servers which injected ads.

Possible, but I still want to know how you are going to hit these 100k heating controllers.

By returning a manipulated address for the "cloud server" that the heating controller connects to.