The cost of "security"

[Kjelt]

That is however quite a stretch; first you get past one box and then you need to exploit back doors in another box.

The whole point IIRC is that none of your homenetwork equipment should be reachable from the internet.
Better still close all ports for outside traffic.
But a lot of people want to control some of their stuff (NAS, camera's, home automation) from outside, and there it goes wrong.
If one of those devices are compromised the hacker is on your home network.

To prevent that there is something called a DMZ, you actually can do this yourself when using two routers with their own DHCP server.
The first router is connected to the WAN and the network it provides is the DMZ, on that network (for instance 192.168.1.x)  you attach your 3rd party devices with the risk of them being hacked.
The second router on that first network will have its own DHCP server and the second network is your home network (for instance 192.168.2.x).
Ofcourse the whole security is based on the second router, if that is not updated and compromised your still vulnerable.

And no I have no pretentions, the real good hackers can get to you, one way or the other, but you have to make it too much trouble for them to do it and they will pick your neighbour, just as with real burglars

[ve7xen]

Thanks. I did wonder if an attack on NAT must involve getting into it during the 180 secs of the open channel.

It depends what you mean by 'attack'. Since NAT is not a security feature, it doesn't have a defined security intent, and what you consider an 'attack' can also be considered normal behaviour. You probably won't be able to perform a 3-way handshake and open your own TCP session to the target, but if you can predict most of the 5-tuple of an open connection (e.g. api.yourdomain.com port 443 destination and you already know the target's IP) and fuzz the rest you can probably get packets inside without too much trouble. At that point your 'security' comes down to the functional mechanisms of TCP (again, not intended to be security features), and how diligent the micro's implementation is about checking them and what it does when it receives invalid ones. It might be enough to simply get a packet to the exploitable stack, regardless of the headers, if you can trigger a buffer overflow or something, or maybe the sequence error handling code is the part that's a problem in the first place.

How 'secure' a NAT implementation is to this kind of shenanigans is down to the implementation, but the point is that NA(P)T is network address translation, it's not a security mechanism and provides no security guarantees - it's an address translation mechanism as the name implies. The fact that it provides a modicum of security is just a side effect of the fact that (in the home router context) it is many-to-one, so there's no sensible default behaviour when you get packets on the 'one' side other than to discard. In many cases your NAT box also includes a firewall, of course, and it might not even tell you this.

That is however quite a stretch; first you get past one box and then you need to exploit back doors in another box.

A stretch for whom? This is the kind of exploit that's too 'costly' to do en masse, but that's not much of a stretch at all in a targeted attack, it's pretty trivial to execute. Is it likely one of your customers gets attacked in this way? I guess it depends who your customers are and what the exploit offers an attacker. If you sell enough units and the exploit is juicy enough, that cost equation just might flip, and that's when someone adds it to a botnet drone and millions of devices get compromised over night.

Are people going to bother finding or attacking an exploit like this in a device that sold 10,000 units? Almost certainly not, but are we talking about actual security here, or security through obscurity? The idea that you're secure because nobody is attacking you says nothing about the security of your product at all.

Assuming the firewall has no back doors... A friend used to work at Cisco and even they used to regularly patch back doors in their 5 digit priced boxes.

Good security is layered. The failure of one layer shouldn't compromise the whole system, and if nothing else, it's one more layer to attack on the way in. Hence why you still need good internal security even if you have a strong perimeter. FWIW though Cisco's software quality is trash, I'd definitely not hold them up as a security poster child.

[ve7xen]

Whether NAT is a "firewall" or not, if an IOT box is behind NAT, it can't be hacked, but it can go out to access some server. Or you can access it via a VPN terminating in the NAT router.

IMHO there are actually multiple things to consider that drive the requirements:
1) Malicious acts (making the device do something it is not supposed to do -including not working-)
2) Privacy requirements (make sure third parties can't collect data)
3) Tampering with data to get some (financial) gain

The "CIA Triad" - confidentiality, integrity, and availability.

[madires]

TLS 1.3 != QUIC or HTTP/3

The report you quote is all about HTTP/3, that's a whole chunk of (IMHO unnecessary) extra code for an IoT device that's simply looking for secure data transfer.

Simply ignore HTTP/3 (uses QUIC and TLS 1.3) and focus on TLS 1.3. The message is that some countries/orgs don't like TLS 1.3.

[2N3055]

... and the answer to the Q is?

You didn't read the article I posted, did you?

For your convenience:

"While it is true that stateful ingress IPv4 NAT will reject externally initiated TCP traffic, that does not mean that an external host cannot in certain situations send traffic to internal hosts or use other methods to circumvent the NAT. In fact, most network-based attacks assume this as a requirement of the compromise.

There are several ways to accomplish this circumvention, all of which can be prevented by a firewall. First, an attacker can either use a targeted or a sweep attack to send traffic to ports that are open in the NAT device’s state table. The purpose of this attack could be to create a denial-of-service (DoS) by invalidating an existing session on the host or NAT state table, to footprint an internal network, or to inject a malware payload into a third party’s existing session in an effort to compromise the internal host. Serious implications are seen in UDP traffic that is by design stateless; however, the same could be accomplished (given host susceptibility) in TCP or other protocols. In addition, NAT may not provide protocol conformance, sequence number checking, or any other layer 2 or layer 3 DoS security measures that firewalls or advanced security devices inherently provide. NAT also provides no tools to respond should security breaches occur."

That article is about carrier grade use of NAT.. If you read it carefully (and RFCs linked in it) you will see that there are many things called NAT..

NAT we are talking about (one implemented on all Internet routers) is Masquerade NAT, a stateful Network Address Port Translation (NAPT), outbound direction type. With IOT devices that use only outbound SSL connections there is very low probability of compromise by outside actor. If you have internally compromised network that is not router or IOT device fault. If you have IOT device that is compromised  that is not router's fault.

There is this prevalently bad thinking in IT security industry (driving up the FUD to pump up profits, most likely) that ANYTHING is possible. There is also a lot of people that really don't understand how things really work, so if someone says "there was this exploit on this version of XYZ by ThatNetworkCompany because they bodged that particular implementation, in next version of security scanners ALL versions of XYZ older than newest patch are proclaimed unsafe, even for hundreds for manufacturers that didn't screw up implementation and are perfectly fine... Because it is easier to just forbid certain name/version number than to expect security experts to actually think and do their job...

NAT is not firewall in a sense it simply isn't. NAT does this specific stateful network traffic filtering. It doesn't do (deep) packet inspection, doesn't monitor traffic, you cannot create application layer filters..
But it will prevent you to connect from the outside to internal network..

For instance, there is this "NAT attack":

NAT Slipstreaming allows an attacker to remotely access any TCP/UDP service bound to any system behind a victim's NAT, bypassing the victim's NAT/firewall (remote arbitrary firewall pinhole control), just by the victim visiting a website.

So you read it and it has nothing to do with NAT, i.e. NAT was not compromised.  User from secure network behind the NAT connected to server that installed exploit to your PC(internal device) and now you have malware bot inside your network...
This is not NAT problem or attack. It is disingenuous by industry to proclaim it is.. And ANY and ALL malware Command-and-control attacks for many years are doing just that, how is that new thing in 2020 and specifically connected to NAT ?

Reaction to this by industry was supposed to be education campaign to educate people that NAT is not going to protect you from this kind of malware exploit because it specifically was not design to be firewall but simple stateful network filter.  Proper name for that type of exploit would be Malware slipstreaming, and recommendation would be to install antimalware software on critical nodes... It has nothing to do with NAT. Yes a good FW would also be able to maybe detect something wrong..

Also DDOS attacks are carrier problem and not a SECURITY problem, but availability problem. Unless you have janky router/fw that will core dump and reboot into telnet session with exposed root access when subject to DDOS...

[madires]

And there are attacks like CSRF which can impact a device inside a LAN protected by a firewall. Security is a process, and not just simply adding some TLS lib, placing a firewall in front or whatever. It starts with a lot of questions. What needs to be protected? How much security do I need (e.g. regulations)? How much I'm willing to pay (money and convenience)? What would be the damage in case of a security incident? What are possible attack vectors?

[madires]

Another typical security issue is a faulty implementation: MEGA: Malleable Encryption Goes Awry (https://mega-awry.io/). We have this problem especially with complex protocols, like IPsec. Over the years many implementation faults were found in a multitude of IPsec products, including super expensive carrier/enterprise class boxes. Or check the CVEs for OpenSSL. The sad reality is that many IoT devices never will see any updates.

[janoc]

And even when IPv6 is available, NATs are commonly used as a part of firewall for security reasons, as a supplementary line of defense, with the internal networks completely isolated on non-routable addresses.

RFC 1918 addresses can be routed. You would be surprised how often ISPs/telcos/carriers see those addresses from customers (usually blocked by an ingress filter, but some still haven't heard of BCPs). BTW, you can also use private IPv6 addresses (ULA).

There are also compliance/legal reasons because you can't allow any traffic to go out untracked/unmonitored. Forcing everything to go out through a centralized "chokepoint" helps with that.

It doesn't matter if IPv4, IPv6 or both, all can be filtered or monitored without any problem to comply with whatever regulation. And again, NAT isn't a security feature, but a stateful firewall is. Also, there are many flavours of NAT, some would make your security staff go berserk. Have you ever met an 'expert' telling you that his network is totally safe because of NAT and when you check the firewall settings UPnP is enabled?

You don't need to explain me that. I have been building and running corporate networks for a while as part of my job, so I believe I know quite well what is and what isn't possible or safe.

The problem is that you are talking about things from a typical engineering point of view - and totally ignoring the corporate logistics of putting anything of this in place. Which tells me you don't really have an experience trying to deploy anything like this in a large corporate network because these things are the 90% of the problem, not whether or not NAT is not a security feature or whether some address is or isn't routable.

[AndyBeez]

@janac I agree. We do not know the use case of the OP's device. A tiny SoC suggests a quasi domestic setting, such as a wifi lightbulb or thermostat.

As you say, it not the what but the where. I will jail any IoT device on their own subnet, VLAN, SSID and block WAN access. But I do this because I can. To most people a DMZ is something in Korea, not a setting on their vanilla router. In the corporate space, only tight control and enforcement keeps departments from establishing their own WAN behind the corporate firewall connection. Deployed IoT devices may also come with 4G built-in.

IoT devices have two nasty habits: calling home, often an endpoint in China. And keeping WAN facing ports open, providing a front door for hackers. Has the OP  pen' tested their device?

[madires]

The problem is that you are talking about things from a typical engineering point of view - and totally ignoring the corporate logistics of putting anything of this in place. Which tells me you don't really have an experience trying to deploy anything like this in a large corporate network because these things are the 90% of the problem, not whether or not NAT is not a security feature or whether some address is or isn't routable.

I thought we're discussing security issues of IoT devices and not corporate bureaucracy. BTW, I had plenty of it too. Can be very frustrating, and you need a thick skin and a lot of patience. Anyway, I just wanted to point out common misconceptions of network basics.

[TomS_]

For example every instance of win10 has its predefined IPV6 address but that just means hackers who know the ranges can target them, in the hope of discovering win10+ installations which are not behind NAT.

Incorrect. OSes dont get pre-defined IP addresses, that is just nonsense.

IP addresses are determined locally on the LAN using a variety of methods, the OS itself being none of them.

[madires]

What about ::1, ff01::1 or ff02::1?

[peter-h]

I am checking out the above. I was told otherwise... but it could be win11.

On a slight tangent but picking up a point above:

I am told that an HTTPS client does not need a public and private key pair pre-generated. That is done in the TLS negotiation. All it needs is the server certificate, and that is optional and is needed only if you want to protect yourself from a spoofed DNS pointing to a spoofed server.

[madires]

For HTTPS the client (webbrowser) doesn't need a certificate, but it may use one optionally. But the server (webserver) must have a certificate for identification (please see https://www.rfc-editor.org/rfc/rfc2818#section-3.1).

[peter-h]

The curious thing is that the client does not need to store anything in a secure manner, for an encrypted connection.

Only if it needs to authenticate the server then it needs to store the server's certificate in a secure manner.

[madires]

In case there's a misunderstanding, encryption and certificate are two different things. The certificate is used for identification (or authentication).

[Stray Electron]

The other thing is that "IOT" is going to end up with a really dirty reputation, as companies go bust, or just stop maintaining the servers. So the remotely controlled irrigation system, where you have a nice app connecting to that server, or even just a website served by that server, goes dead one day and there is no way to fix it. You have to rip the whole lot out.

   I didn't read the whole thread but what I'd really like to know is this: WHY do these manufacturers make all of these devices so that they CAN be reprogrammed?  Why don't they just put all of the OS in ROM and then NO ONE could hack, not even the OEM. Who, I will add, that I don't trust any further than I trust the hackers in China, Russia, etc, etc, etc.  The one thing I really worry about with all IOT devices is that the manufacturer can later decide to brick them or degrade their performance enough that they're inoperable (i.e. Apple).

[ve7xen]

The curious thing is that the client does not need to store anything in a secure manner, for an encrypted connection.

Everything required for the session is or can be ephemeral. Typically you also want to have trusted storage (it doesn't need to be secret, just trusted) for your trust store, so you can confidently identify the servers you talk to, but as you say, that's optional if you don't want protection against MITM, and depending on your application you may not even care about trusted storage here, if you allow the user to manipulate the trust store.

The most 'difficult' requirement on the client side for a proper TLS implementation is probably the need for a secure RNG.

   I didn't read the whole thread but what I'd really like to know is this: WHY do these manufacturers make all of these devices so that they CAN be reprogrammed?  Why don't they just put all of the OS in ROM and then NO ONE could hack, not even the OEM. Who, I will add, that I don't trust any further than I trust the hackers in China, Russia, etc, etc, etc.  The one thing I really worry about with all IOT devices is that the manufacturer can later decide to brick them or degrade their performance enough that they're inoperable (i.e. Apple).

It's kind of opposite of how you are presenting it. If ROM code has a severe vulnerability, it's out in the wild and nothing can be done about it. At least with programmable devices, there is the potential for field updates to occur.

[Bassman59]

A friend pointed out DTLS.

Matthew Garrett, known kernel hacker and security expert, examined an Ikea IoT device and was impressed by their effort. Usually most devices he has examined have gone down in flames.

https://mjg59.dreamwidth.org/47803.html

I've gotten rid of most of my other IoT crap (mainly because the shit died) and the IKEA stuff is not only much less expensive than the competition, it does not have any cloud service capabilities at all.

Of course you read reviews of the products: "PROs: Works well. CONs: They do not offer remote access to the devices, so you must be on the local network."

As if not having a cloud service for remote access is something bad and to be avoided ...

[tellurium]

Only if it needs to authenticate the server then it needs to store the server's certificate in a secure manner.

Not exactly. Server sends its certificate during the handshake. What client needs to store, is the CA cert to verify server's cert:

1. With TLS, any party can authenticate it's peer. If client authenticates server, client must have a CA (certificate authority) cert stored. During the handshake, server sends its certificate, and client verifies it against the CA cert.
2. Likewise, a server also may authenticate a client. Then, a server must store a CA cert. During the handshake, a client sends its certificate, and server verifies it against the CA cert.
3. If both client and server exchange certificates, it is usually called a "two-way TLS". For example, AWS IoT uses that method to authenticate MQTT clients.
4. Browsers usually only authenticate servers, but servers do not authenticate clients (browsers). So it is a so-called "one-way TLS". Therefore browsers are installed together with a big bundle of CA certs from various authorities. When a browser connects to a HTTPS server, one of the pre-bundled CA certificates is used for verification, so no extra action is required from the user.

[peter-h]

client must have a CA (certificate authority) cert stored

Can it be a self signed one? I don't think you can get a (e.g.) Verisign signed one which is valid for 100 years, which is exactly what one does want for a server one one's control.

[ve7xen]

client must have a CA (certificate authority) cert stored

Can it be a self signed one? I don't think you can get a (e.g.) Verisign signed one which is valid for 100 years, which is exactly what one does want for a server one one's control.

If it's a closed system, you don't need to talk to Verisign (or any other public CA). The only reason they are needed is to get browsers/OSes to trust your certificate by default, there's no technical requirement for them. You can make your own CA to sign certificates and use whatever expiry terms are appropriate, or as you suggest you can use self-signed certificates with explicit trust instead of transitive trust through a CA.

Certificate signing is meant to 'chain' up to a root trust store. So for example google.com's certificate might be signed by Google's CA, and that CA's private key might be signed by Verisign (for example), which the browser has in its trust store. Sometimes there are 3 or 4 levels of chaining to reach the root, but as long as there is a continuous chain of signatures that gets to the trust store, it theoretically can be any depth (I think).

Nothing stopping you from adding the server certificate directly to the trust store either (whether it is self-signed or CA-signed). In a constrained implementation, you might be able to omit the whole chaining thing from the code and just authenticate the server directly.

[tellurium]

client must have a CA (certificate authority) cert stored

Can it be a self signed one? I don't think you can get a (e.g.) Verisign signed one which is valid for 100 years, which is exactly what one does want for a server one one's control.

Sure.
A CA cert, a cert and a private key could be self-generated.

Usually the issue with the browsers, which use a pre-installed CA bundle from known authorities. None of the CA certs from the bundle would verify a self-signed cert, and a browser would raise a security error. To make a browser happy, as ve7xen has pointed out, the self-generated CA could be added to the browser's CA bundle manually.

An IoT TLS client also needs a CA bundle to verify server's cert. If it is only one domain, and a cert issuer is known, then a CA bundle can consist of only one CA certificate. That is important for mbedTLS, because mbedTLS keeps the CA bundle in memory all the time.

[AndyBeez]

What exactly is this IoT device and what is it's deployment scope? If it's a one off gadget used on a private network, then the CA can be self signed (using OpenSSL) and no one else will care. If it's deployed anywhere else, then you will need to spend money on a validated certificate.

Self signing example: https://devopscube.com/create-self-signed-certificates-openssl/

[peter-h]

Usually the issue with the browsers, which use a pre-installed CA bundle from known authorities

This is on a tangent, but I sometimes wonder how easy it may be for an attacker to simply replace these certificates in somebody's Chrome etc installation, install a fake DNS server on their PC, and then use that to capture their banking credentials. The eventual defence would be only that setting up a new payee usually involves answering a phone call...

And this is the problem: if you can't guarantee security of the client machine, any server certs stored on it are meaningless. And in most IOT scenarios this is difficult because getting onto the LAN is quite feasible, with an "inside job" attack (an email with a trojan, etc).

That is important for mbedTLS, because mbedTLS keeps the CA bundle in memory all the time.

There are some patches for that but you still have the problem of updating those certs securely. So being able to process what is today about 200 kbytes' worth of certificates in your IOT box is not worth a whole lot. I am pretty sure most IOT boxes which implement server auth are storing just one cert with a 100 year life