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.