First, they are refrigerators. They do not need to be connected to the internet and should not be, period. You want to remotely manage them? Use anything but the internet.
I'll bite, what sort of remote control can you do that isn't, some how, some way, using the Internet? You gonna lease RF spectrum and set up some kind of radio controls?
Second, why would you make them remotely accessible FROM ANY IP ADDRESS? Do you not know what a firewall is? A whitelist? Conditional access?
This is realistically where the failure sits, but it's unlikely that in an IPv4 network, that the IPs of the IoT endpoints would be directly exposed to the Internet as they'd normally be RFC1918 addresses and would require someone to explicitly set up inbound NAT rules to forward to those endpoints for them to be directly exposed. So the question then becomes, what as the method of exposure? Were they on Internet-routable IPv6 addresses where someone screwed up setting up security? Was some other method used to get into a private network, and from there they hopped through to these endpoints? Was the network security for the LAN the fridges were on actually done right, but the vendor's management tool breached and the tampering from "the cloud"?
Third, why the fuck would a REFRIGERATOR need the ability to COOK anything? Did someone forget the difference between Fahrenheit and Celsius and give them a max temp of 50C when it should've been 50F?
Fourth, vendors should be held liable for this shit. Manufacturers who provide always in fully connected devices should not get a "get out of liability free" card by saying "you should always upgrade to the latest firmware" and should be held accountable for producing REFRIGERATION units that can be turned into OVENS.
We don't really know if they actually got to 50C, just that they were set to that. For all we know they just shut off when the actual thermostat realized that the commanded temperature was higher than the actual temperature. But the point about liability still stands, and we don't know if they have any sort of privilege escalation based on type of administrator.
Fifth, and finally, as per the norm, I did not RTFA so maybe it mentioned this, but I'm willing to bet there were default passwords still in use. Yet another thing manufacturers should be held liable for. It shouldn't be possible to hook it up and start using it without configuration that requires setting reasonably secure credentials.
I did give it a skim. It looks to me like despite this being a supposedly industrial system, the company behind it neither understands IT security practices, no do their customers. This isn't exactly surprising, as HVAC technicians who are used to troubleshooting blown fuses, bad compressor pumps, and clogged heat exchangers are busy and the nature of IT security is shifting. It sounds like both the company behind the products and the customers made serious errors, very likely in the guise of keeping costs down by simply not addressing vulnerabilities.
I'm personally against industrial controls that connect back via normal outbound NAT like any other internal endpoint would that use destination port 443 for their communications. This is becoming increasingly common as BACnet traffic (typically on port 47808 and up) is replaced by BACnet Secure, which just uses normal SSL. Don't get me wrong, the old way on BACnet isn't exactly secure even when an enterprise customer sets up a VPN tunnel and forces all traffic from the particular equipment to the management cloud tool that traffic is unencrypted on the customer's network, but the SSL model along with cloud endpoints' IPs changing regularly as their various cloud hosts switch between AWS, Azure, and other providers means it's more difficult to determine if someone's internal endpoint is communicating with the only hosts that it should, or if it's compromised and connecting to some command-and-control server that looks superficially the same as normal traffic.
If I were investigating this, I'd start by getting the operational topology from the vendor that made the equipment and presumably the control software, and I'd start at the point most in-common among the victims. If the vendor itself was compromised then there's the problem. If the vendor wasn't compromised, I'd start to look at how the protocols on these systems work and what sort of opportunity there was for interception to learn of the endpoints in order to build out the profile used for the attack. I'd then want to review the actual faults that the vendor supposedly warned their customers about.
Unfortunately good IT security is expensive, and I expect that most businesses adopted these supposedly smart commercial refrigerator controls to save money, not to spend more on it. They might well have been better off to just install Internet-connected temperature sensors that had no actual control capability, where a central monitoring room could call the customer if a fridge was being reported as outside of the proper temp range, so that the customer could engage a technician to troubleshoot. But instead they tried to go even cheaper by centralizing all of it, to a fault.
