[Was: TP-Link issues resolved (kind of)] Can I prevent my IOT devices, once compromised, to access my primary network ?

Thu May 28 05:46:52 EDT 2020

Thanks to all who responded, thanks, shane, for sharing a situation whereby the Vera had an uncivilised behaviour. Even with the Vera alone on its VLAN, I will maintain my configuration,  

The Firewall (the DSL Modem) rules on my pfsense firewall are intended to disallow any packet to pass from the IOT LAN to te Guest LAN or to the main LAN. They are described below. These rules are to be read bottom to top: 

Menu: Firewall / Rules / IoT devices 

Allow IoT devices' DNS to SG-1000's IoT devices' router address [TCP/UDP on port 53 and 853-DNS and TLSDNS] This last rule is not entirely done: it is limited, so far, to port 53 (port of destination). 

Block packets to all modem-routers (alias of all my network devices like the modem-router of my iSP facing the WAN and my Airport wifi access points. 

Block packets to all IPs on the firewall (This firewall), wan, lan, opt, etc. (this SG-1000)

Block packets to Guests (Guests net)

Block packets to LAN (LAN net)

Allow all IoT devices' packets anywhere (IPv4+IPv6)  

(Implicit) Otherwise block all IoT devices' packets (not active) 

As in any firewall, the last rule is implicit, I have restated it here for the clarity.

HTH 

— 
Jean-Pierre

> Le 21 mai 2020 à 17:31, James Sentman <james at sentman.com> a écrit :
> 
> It’s a complex topic, but one that I am learning more about all the time as I continue to create things like the wifi 1-wire sensor host IOT device and have to take security of such things seriously. There have been exploits of IOT devices and even regular commercial routers that have created holes in peoples networks or loaded all sorts of malware onto them. 
> 
> Separate wires are secure unless the devices themselves can be hacked from outside due to a cloud connection issue or some DNS spoofing that makes them look to a different server for their info or something like that. If they only need connection to the internet then it is possible with low level router configuration or a managed switch to limit that separate wire so that it is entirely unreachable from the rest of the local network. That would mean that a hacked webpage with a bunch of javascript code in an add that was used to hack to many routers in the past would not be able to easily see it. Any malicious app running on the rest of your local network would not be able to find the IOT devices. Your local network would still be compromised at that point though so that would also be bad. It could also be that if you don’t fully understand (and I do not fully understand how this actually works in the devices even though I have tried to setup such things and run into the absolutely horrific implementation of such non-standard use cases on even the best commercial routers or even the open source security conscious ones) Your chances of getting this setup correctly are somewhat low. 
> 
> Having 2 subnets on the same physical network, be it wifi or wired or any combination of the 2, is virtually no security at all. You may not be able to ping one from the other, but things like UDP Broadcasts go to the entire subnet in such a case. Indeed this is a feature and not a bug since many IOT type devices will startup on some fictional portion of the subnet, say 192.168.4.0 and yet you can still run the discovery tools from a machine running on 192.168.0.0 and the UDP broadcast packets will be sent and received by all the devices. You can then send configuration info to the one on the temporary subnet and it can restart with the proper settings. This is how the wiznet cards work that I wrote the Mac setup software for. If someone has the ability to send a discovery packet from some device, then they will be able to find any device on the same physical network layer that uses such a system (which is most of them) even without doing anything different in their code or making it any more complex at all. If you’re using a true different subnet like say a 10.0.0 address and a 192.168.0.0 address then that MIGHT be more complicated. I suspect not though. I have not tested that particular case but it might let UDP packets through equally the same. It is my suspicion that it would. Then all I have to do is properly address the next set of UDP packets to the device and it will reach it. Making TCP connections to devices on truly different subnets like that might be more difficult, but there are really not very difficult and mostly standardized ways to create “virtual” interfaces on macs and windows boxes so that you can do exactly this sort of thing. The amount of effort to do it would not be that much, and it definitely is not impossible.
> 
> The other thing to remember about the amount of work it takes to do something like that, someone only has to do it once and put the source out there on the hacker sites and then everyones tool will have it within weeks. So it’s not as if every hacker has to do anything other than link in another library and push an update to your compromised machine.
> 
> Security due to not enough processor time is good for things like breaking good encryption where the government of a reasonable sized nation might have to decide that your encrypted data is worth using up a considerable amount of time on their super computer array to try to do that. They definitely can’t hack all the encrypted data like that ;) I think it’s reasonable to think that they aren’t reading my SSL and HTTPS data across the internet as a matter of course ;) That is probably secure. Just because it’s slightly more difficult to multi-home a Mac temporarily and be able to reach every potential subnet that they got a UDP broadcast response back from is not reasonable security. If they can’t already do this, if it becomes something they want to do it will appear in a very short amount of time.
> 
> As far as multiple-wifi access points it gets even more nebulous. The rest of this information is my understanding of how the things work and not necessarily 100% correct ;) But is a starting point for understanding it. 
> 
> If you create a second wifi network with a separate password and then just plug that into your regular internet router/modem then it will likely be routable between the 2 so there is no added security at all. The new AP will basically be just acting as an extender for the main wifi but with a different name and password. If you setup a second router not in bridge mode but in sharing mode then it will create a completely separate shared address space. The devices on that second network will be able to make outgoing connections to the internet assuming everything else is setup properly, but nothing will be able to punch a hole through the secondary router and suddenly have incoming access enabled. This is a good step, but in order to do such a thing to the router in the first place the device would already have to be compromised somehow. If it is already compromised then keeping it from being able to accept an incoming connection from the internet does you no good because it can still make outgoing connections to the internet to get or do whatever it wants to. It can open one and just keep it open the way most malware does so that the malfactor can send whatever commands they wish at any time no matter how often you reboot or replace your router.
> 
> The one thing this does protect the IOT devices from would be other hacked devices on your local network. So a hacked windows box on your local network would not be able to find and hack the IOT devices. This is a good step but you’d still have a hacked local machine that you’d need to take care of. Best to keep that from happening in the first place ;)  I am not sure that just setting up the “guest” network on a regular router would do this properly as I think it would by default anyway create another routable network that is just bridged to the main network, but that would depend on the specific implementation of the router so is likely to be different with different models. Additionally you would not be able to control the devices using their “apps” or whatever on your phones or other devices that are on your real network since there is no incoming connection to the isolated one. So in order to use them you would have to either log into the cloud or log your iPhone or other device temporarily onto the IOT wifi network. This strikes me as a pain in the neck, but might not be too much of a problem if you have devices you suspect of being susceptible to this.
> 
> Beyond that then there is the question of could a hacked device on one network read the pre shared key of the other one. I think the answer is a definite yes. This is probably beyond the scope of most simple hack attempts, but the interesting thing is that this code is already out there. If you’re on a wifi network, even one with separate keys negotiated for each communication channel which is an enterprise feature, knocking one offline and then recording the 4 way handshake to record the nonce for the individual encryption is trivially easy now. It’s actually very complex, but once the code existed it’s in everything now. I believe you can even do it with wireshark. Adding it to a hacker tool would be trivially easy. Both windows and the Mac have programming hooks to switch networks. If a hacker wanted to scan nearby wifi networks (and they do this I believe I read about it) thats trivial. You have logged into that separate network so the password is in your keychain which is probably unlocked, or the software can just keep trying until you unlock your keychain for some other reason, and then they can switch over to it and then read all the traffic to them, contact them directly and anything else.
> 
> The real security is for devices to not accept direct uploads of unverifiable firmware. 
> 
> The rest of this is really theater. It might be secure today for some devices, it will not be secure in the future as the tools continue to advance. 
> 
> Any device that allows uploading of unsigned or unverifiable firmware without needing physical access to the device is a potential problem. For the 1-wire wifi host kits the ESP8266 chip in them has it built into the bootloader the ability to sign a firmware file. Once I’ve uploaded the first signed binary to it then it will not accept an upload of an unsigned one. So unless someone steals my private key it will just throw an error if something tries to upload firmware not signed with my key. No security theater no wondering if things will change in the future. The device will not load unsigned firmware. I keep it open to your own reloading later by not locking the chip from physical access. If you wish to upload your own firmware to the board at some point in the future you just need a standard programming rig for the chips and you can overwrite my signed firmware so it’s not locked out, just locked out from other the air uploads or downloads.
> 
> The newer boards that I am currently woodshedding the firware for are based on the ESP32 chip and they have not moved the signing capability into that bootloader yet so another method of keeping them secure is necessary. Since the boards already have their “setup” button on them there is an option to require physical access to the device in order to upload firmware, or even to make any other settings changes if you wish. This is more of a pain and as soon as the bootloader for them matures a bit and has that feature I will enable it, but for now when you want to upload new firmware you will have to go to the device and physically press the button on it just like when setting up a phillips hue hub or something like that. This way I protect it from being hacked from the network. There is no practical way I can protect it from someone just controlling the dimmer outputs on it from a hacked machine. It might be worth while to create a table of allowed hosts for control. But even so, if it’s your laptop or your XTension machine that gets malware on it, or is loading a hacked web page, then that will be coming from one of the allowed hosts so while it might reduce the number of hacked machines that could possibly do it it won’t actually solve the problem. This is, I think, one reason that few of these companies implement a local control protocol but force it to go to the cloud. Their device can make an outgoing connection to the cloud and then your control app can too and then their servers can forward commands from one to the other and no incoming or listening is required on the local devices. They simply disallow it entirely. I have no interest in doing that for most of these devices but it may still be necessary in the future. 
> 
> 
> This is too much rambling to go back and proof read ;) So please excuse my typos :) 
> 
> 
> 
>> On May 20, 2020, at 4:49 PM, Philip Pedersen <ppederse at speakeasy.org <mailto:ppederse at speakeasy.org>> wrote:
>> 
>> Steve Gibson went further using a Ubiquiti EdgeRouter and managed switches. See 
>> https://www.grc.com/sn/files/ubiquiti_home_network.pdf <https://www.grc.com/sn/files/ubiquiti_home_network.pdf>
>> 
>> The reasons to segregate IOT devices are that they are notorious for having multiple security vulnerabilities, mostly won’t be patched without manual intervention even if patches are available, and have no protection against someone who can get physical access to them.  Mcafee did a nice job looking at the WiFi enabled garage door opener from Chamberlain, as an example. See  https://www.mcafee.com/blogs/other-blogs/mcafee-labs/we-be-jammin-bypassing-chamberlain-myq-garage-doors/ <https://www.mcafee.com/blogs/other-blogs/mcafee-labs/we-be-jammin-bypassing-chamberlain-myq-garage-doors/> 
>> 
>> With a separate network for your IOT devices, it makes it harder to compromise stuff on your home network, but not impossible. It would take a hack that would use multiple vulnerabilities on different devices. Let’s say there’s an authentication bypass vulnerability in the Vera that allows someone to login to your Vera through the Vera cloud. An attacker could use this access to change the code in the Vera to then craft a special webpage that would compromise the Safari browser on your Xtension machine the next time you logged in to the Vera’s web interface. Safari would then download malware specified on the webpage to fully compromise your Xtension machine and, ultimately, your entire house network. 
>> 
>> The above is a lot of work and takes a lot of time. I wouldn’t expect there to be a high probability that it would happen to any of us on this list unless one of us is targeted by a state actor with the resources to do it. However, since the  one-step compromise of IOT devices is so much easier, i.e. less cost to do the hack and thus more probable, it makes sense to segregate them.  Note that you also don’t know if the cheap IOT device isn’t phoning home to the manufacturer with your information. 
>> 
>> The setup for a segregated network would include routing rules for each IOT device specifying what it could connect to on the Internet and to the internal network. In a lot of cases, the PC on the internal network makes the connection, so there’s no access from the IOT device to the internal network.  That limits the probability of compromise since it requires an active step from the internal machine. 
>> 
>> The setup for a segregated network configuration is complex and needs some ongoing maintenance as well.  You really have to consider the probability and cost of compromise, i.e, the risks, versus the cost to you of adding and maintaining the security controls to mitigate the risks. I personally think segregating untrusted IOT devices on a separate network, limiting access from them to the Internet and to your internal networks, and only allowing known MAC addresses to connect to your networks goes a long way to protect your information and is probably more than sufficient for most non-commercial users. I also wouldn’t enable any WiFi devices that allow physical access to your house or garage. 
>> 
>> Phil
>> 
>> Sent from my iPad
>> 
>>> On May 20, 2020, at 1:17 PM, Michel Angelo <michel_angelo at me.com <mailto:michel_angelo at me.com>> wrote:
>>> 
>>> On 19 may 2020 at 22:54, James Sentman <james at sentman.com <mailto:james at sentman.com>> wrote :
>>> 
>>>> There are those among us (who shall remain nameless but some responded to this thread ;) who maintain 2 (or more!) separate subnets on the same physical medium. Some thinking it gives more security or something, but it’s all on the same wire so anyone can read it if they have hacked your machines. It will take about 3 minutes longer for them to hack you if that is your goal ;)
>>> 
>>> This is, I believe, a new thread:
>>> 
>>> Internet of things (« IOT ») devices are believed to contain enough hardware and software to become prime targes for hackers willing to use them with malicious intent, say to compromise my primary computer. Example of hackable devices are smart bulbs connected to the internet. I have always heard the same recommendation: protect these IOT devices from access from the WAN and, as a protection against the situation where matters would go horribly wrong, deny them any unsolicited access to your primary resources. Network isolations is a recommended method to this end (see « three dumb routers » and follow-up advice by Steve Gibson of GRC <https://pcper.com/2016/08/steve-gibsons-three-router-solution-to-iot-insecurity/ <https://pcper.com/2016/08/steve-gibsons-three-router-solution-to-iot-insecurity/>>). The original solution was with physically separated networks (separate wires), the next solution uses Virtual Lans where packets are tagged and the wires or wifi channels are the same. 
>>> 
>>> In the setup I described, I use a separate VLAN for IOT devices. So far, the sole IOT device I have which is connected (to the VLAN) is the Vera. Beyond the Vera, everything is Z-Wave+. 
>>> 
>>> My question is: assuming a hacker succeeds to gain control of the Vera from the outside, directly or through the Z-Wave network, how is he going to pass through (or to avoid) the pfSense firewall and gain access to my primary network ?
>>> 
>>> Is that configuration insecure ? It seems to be but I fail to see how. Thank you for any hint on this. 
>> 
> 
> Thanks,
>  James
> 
> 
> James Sentman                       http://www.PlanetaryGear.org <http://www.planetarygear.org/>		http://MacHomeAutomation.com <http://machomeautomation.com/>
> 
> 
> 
> 
> _______________________________________________
> XTensionList mailing list
> XTensionList at machomeautomation.com <mailto:XTensionList at machomeautomation.com>
> http://mail.machomeautomation.com/mailman/listinfo/xtensionlist <http://mail.machomeautomation.com/mailman/listinfo/xtensionlist>

— 
Michel Angelo
<michel_angelo at me.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.machomeautomation.com/pipermail/xtensionlist/attachments/20200528/13302701/attachment.html>