← Back to context

Comment by wongarsu

10 hours ago

Somebody wrote the software that is the interface between the fridge and the internet. And while it would be nice if HVAC technicians would remember to only make this software accessible via VPN, it is in fact possible to write software that is reachable from the internet while still being secure

Given that we agree that HVAC technicians can't be relied on for network security, this is 100% on the fridge company for having insecure software. If it's a bad password or an unchanged default password that's still on the fridge company for not enforcing something better

Of course its "possible" for it to be secure, but the people involved are not experts.

The grocer likely has the least expertise. The HVAC company has more, but as evidenced by the article, not enough.

Now obviously, these companies have internal "information systems experts" but again, how does the banana guy interview a CIO ? Grocery store CIO might have gotten the job because he made the banana guy comfortable by talking about sports.

Each party was confident in a successful outcome, until the 15 year old kid across the globe pulled the rug.

The processes that created this situation were inadequate, because glad handing and name dropping cost less than formal systems validation.

Of course, the other way to view all of this is ... they just completed formal systems validation, found 1 bug, and paid whatever the food spoilage cost was for it, because no matter how much preperation one does on a project, at some point the power switch gets flipped, and its wait and see.

In a group project, noone is ever sure if Poindexter over there in the corner is quiet because he's quiet, or is quiet because he knows the code is crap and his boss ordered him to ship it anyway.

We're likely dealing with at least 4 companies here, if not more:

contracted programmers <-> fridge equipment maker <-> HVAC sales/service group <-> grocer

3 of the 4 companies could have all said to themselves "Project ships on Monday, no matter what" because who carries the risks for any flaws ? The grocer(s).

  • > Of course its "possible" for it to be secure, but the people involved are not experts.

    They're selling network-accessible equipment so it's their duty to make it secure within some well-defined envelope. How's that any different from any other part of engineering and product development?

    > "Project ships on Monday, no matter what" because who carries the risks for any flaws

    Soon that will be the OEMs, per the EU Cyber Resilience Act [1]:

    > Directive (EU) 2024/2853 [on liability for defective products] of the European Parliament and of the Council (16) is complementary to this Regulation. That Directive sets out liability rules for defective products so that injured persons can claim compensation when a damage has been caused by defective products. It establishes the principle that the manufacturer of a product is liable for damages caused by a lack of safety in their product irrespective of fault (strict liability). Where such a lack of safety consists in a lack of security updates after the placing on the market of the product, and this causes damage, the liability of the manufacturer could be triggered. Obligations for manufacturers that concern the provision of such security updates should be laid down in this Regulation.

    [1] https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

    • Given the potential service contract nature of this particular situation, where the grocers signed a service agreement with HVAC companies, one would think the contract included clauses addressing this very situation, where a significant loss of inventory occurs. After all, the service being paid for is refrigeration.

      With floor planning, the loss itself could be spread across multiple companies, under multiple insurance policies.

      With that said, this particular hack could easily be a systems / networking "configuration error" and not any particular piece of softwares fault ( as in a bug, or hardcoded backdoor password. )

IoT platforms provided all the required functionality. Device provisioning (it is not easy to do identity on 'things'). MQTT for service-assisted communication where devices don't need to accept incoming connections. Over-the-air software updates. Over-the-air kernel security updates.

The 'fridge company' and other product manufacturers decided to skip all that and run everything on a raspberry pi with apache, or an ESP32 soldered onto the control board, and call it finished. There are millions of these devices out there.

  • I just read the article again. It mentions "Danfoss" HVAC controls.

    I happen to have a Danfoss HVAC controller here, and its controllable via Modbus. Its an older model, but its my understanding that larger HVAC systems commonly use Modbus.

    Modbus systems are multi-drop serial, and the hack likely came in from the server side of one of the companies involved, and the HVAC controllers were all sent defrost commands. Thats my guess anyway.

    I have a pump thats Modbus controllable as well, made by a company called Grundfos.

    Gonna make a water battery.

    Shift my cooling load into off-peak rate hours.

    Stickin it to the power man. :D

    Seriously, you guys would love these pumps.

    https://product-selection.grundfos.com/us/products/magna-nor...

    It has wifi. Neighbor kids are gonna defrost me. :(

    • Modbus is the equivalent of VGA connector in displays and projectors. It does have a TCP/IP version as well, but it has no security whatsoever. Or any features besides reading/writing a 16-bit value (or a single bit, charmingly referred to as "coil")

      1 reply →

    • Yes, that is likely. Although Danfoss seems to have their own controllers, I think that you are right, that the attack was not an 'Internet connected fridge', but an HVAC or FMS (Facilities Management System) that was connected to the fridges.

      2 replies →