Three critical 0-days allow RCE and even physical ignition in APC UPS | Hacker News Reader

Three critical 0-days allow RCE and even physical ignition in APC UPS

armis.com

31 pointsmadjam00212 comments

Concerning that researchers were able to cause a UPS to heat up and start smoking through software that connects to a cloud service.

Why any IT professional would use a cloud connected UPS management service is beyond me. You're putting so much trust in Schneider for quite literally controlling power for potentially larger segments of your infrastructure.

Came here to say this. Literally the most important piece of the infrastructure is the electrical distribution. Everything depends on it, everything.

Do not put it on the Internet at all, much a "cloud" connected service!

Why anyone would use a network connected UPS is beyond me.

The networked microcontrollers in UPSes are taken from "IOT" product lines. Like internet-connected dishwashers.

How else am I supposed to manage it? I go to that site maybe 5 times a year. There are no servers on-premises, just a switch and Wi-Fi APs. It's connected to the mothership via fiber.

It's on a management VLAN that has no direct internet access.

In my opinion things like this would be solved by having a management node or management software that the devices are allowed to connect to with mutual auth and a pairing process initiated/completed at each end. No inbound connections allowed at all to the UPS. Not a single listening socket.

Input the IP of the management node into the UPS and then log into the management node to complete the pairing process which should require the serial number of the device and a management key.

Given the crappy keypads on most of these units optionally also allow a USB with preloaded configurations, power thresholds, battery cuttoff, alert levels, ATS settings, voltage thresholds, management IP, etc... UPS verifies encryption key on USB and decrypts configuration that was written by the management node, loads and runs it, LED/LCD display says "Conf vers nnxxxx loaded. Have a good day!"

If it's on a separate VLAN with no internet access you're doing it right and would be immune to this vulnerability.

Because most of the time there is no other option to actually monitor it?

Sure, in the ideal world you always have a dedicated, HVACed closet with at least12/24U rack, at least /26 for network services, some 1U HL server to provide monitoring, network services, alerting, secure channels... In the real world you are often happy what your "rack" is at least not in the literal water closet.

You don't really need a server for this. A low-power Raspberry Pi will be good enough. If the device you're trying to monitor has a serial port, your existing network hardware most likely has a console port that can be connected to it and then remoted into (after auth by the router's firmware).

> A low-power Raspberry Pi will be good enough

Great, now you have some DYI solution with no warranty and no support. Also if it breaks you need to repeat the whole DYI process.

> , your existing network hardware most likely has a console

Haven't seen 'outbound' serial on network gear... for ages? And it dosn't help for

> that can be connected to it and then remoted into

if I can't run custom apps on the said router.

Sure, pfSense has apcupsd but the most pfsense platforms are already in the 1U server grade.

And if we talking 'low power RPi' than a chance of both having a serial port and a custom binaries are pretty low.

1) For ILOM and UPS, etc. Only allowed clients should be even allowed to reach the device, long before auth.

2) Hardware needs to have onboard safety interlock, meaning that there should be a separate hardware subsystem that enforces safety parameters. A user or programmer of the main system should not be allowed to put the system in an unsafe state. Software should not be the safety mechanism. A common way to harm devices is through rapid cycling. The subcomponent would implement rate control/hysteresis so that it could not be commanded in this way. Yes, the subcomponent has software on it, that isn't the point.

Flaws like these should have repercussions beyond market forces.

Someone should make a comment about how the C programmer was unskilled and that they should try harder to not make flaws.

Ha ha. Safety in HW is expensive and nobody wants to pay for it.

I don't think it is. Each subsystem would have a small processor infront of it, that you communicate with over SPI, it would enforce the different safety parameters and do the local control. Things like setting PID values, monitoring and setting voltages, etc. It would ignore values that exceeded its predetermined operating envelope for the subsystem. It would have cost about an extra 1 or 2 dollars to implement this technique in the UPS.

Reply on news.ycombinator.com