Researchers discover critical vulnerabilities in APC Smart-UPS devices

Jimmy2x

Posts: 91   +8
Staff
Why it matters: Three vulnerabilities were recently discovered affecting uninterruptable power supplies (UPS) made by APC. The vulnerability, classified as critical and high severity, is related to APC's SMT, SMC, SCL, SMX, SRT, and SMTL product lines. The TLS-based attacks can result in impacts ranging from physical damage of the device itself to unauthorized access to a target's internal networks.

Device security firm Armis discovered the APC vulnerabilities. The attack vectors, collectively named TLStorm, provide hackers with the means to execute remote manipulation of the UPS. These devices supply backup power for critical devices and services in data centers, hospitals, and other organizations requiring uninterrupted backup power.

Malicious actors exploiting the vulnerability can perform remote code execution (RCE) attacks against any vulnerable APC Smart-UPS device. Such attacks enable unauthorized users to alter the UPS's operation, potentially damaging the power supply itself or any assets connected to it. Hackers can execute the attack with no user interaction and leave no trace of a breach.

American Power Conversion's Smart-UPS devices use a cloud connection for all configuration and control. This remote connectivity is the basis for two of TLStorm's three vulnerabilities. The third is related to a design flaw preventing firmware updates from receiving secure cryptographic signatures.

  • CVE-2022-22806 – TLS authentication bypass: a state confusion in the TLS handshake leads to authentication bypass, leading to remote code execution (RCE) using a network firmware upgrade
  • CVE-2022-22805 – TLS buffer overflow: a memory corruption bug in packet reassembly (RCE)
  • CVE-2022-0715 – Unsigned firmware upgrade that can be updated over the network (RCE)

Armis researchers estimate that eight out of ten companies using the devices are currently vulnerable to TLStorm-based attacks. Mitigation measures include changing the default NMC password ("apc"), installing a publicly signed SSL certificate, deploying access control lists, and installing the patches found on the Schneider Electric website.

Permalink to story.

 

Uncle Al

Posts: 8,752   +7,668
For roughly the past 10+ years we have seen a parade of devices, etc. that have been compromised by this sort of thing. I would like to see a study of how many of these were discovered BEFORE the products were manufactured, showing how many companies ignored the information or simply didn't bother to make the necessary corrections in advance of selling/delivering the faulty product.
 

mountains

Posts: 65   +75
I hate when products we buy are required to connect to "the cloud". I would almost support legislation to require at least an option for non-cloud operation for devices sold. Except, I know it would be difficult to write that legislation.

But companies should offer non-cloud options (that are easy to access), and then make that a selling point. Yes, that includes MS as well.
 

Dimitriid

Posts: 2,203   +4,239
I hate when products we buy are required to connect to "the cloud". I would almost support legislation to require at least an option for non-cloud operation for devices sold. Except, I know it would be difficult to write that legislation.

But companies should offer non-cloud options (that are easy to access), and then make that a selling point. Yes, that includes MS as well.

This is the one case I have to disagree: UPS system *should* be on the cloud and interconnected. If you work on IT and depend on servers for well, anything, then you know having to restart a server when people are asking you for things and there's literally nobody in the office and you need to wake up an IT guy on a Sunday to make sure he drives to the offices, enters the cold room and literally just pushes a damn button to turn it back on because there was no IPMI on the servers or the UPS system it's let's just say, not ideal.

By the way I am literally describing things we had to deal with and having directors call managers to complain about not getting their reports in time and we having to explain "Well it's not our fault, infrastructure guys literally had to physically go enter their data center room and push a button to get back online" gets quite confusing and embarrassing.

Yes these types of connections are a liability, but the alternatives are a liability as well. In fact once a medium sized company goes through some of these stuff guess what? They will very seriously consider Microsoft's or Amazon's sales pitch for cloud based infrastructure because well, now they don't have to pay top dollar or otherwise get teams not well prepared enough to manage critical IT infrastructure without having interns come in on a Sunday morning to push a power button.
 

terzaerian

Posts: 1,262   +1,753
Steam, I think, once again offers a model that embodies the best of both worlds - it has an offline mode that you can turn on and off. Obviously your access to some Steam services is cut off but the base functionality of Steam as a game library is not.
 

Vanderlinde

Posts: 138   +93
This is the one case I have to disagree: UPS system *should* be on the cloud and interconnected. If you work on IT and depend on servers for well, anything, then you know having to restart a server when people are asking you for things and there's literally nobody in the office and you need to wake up an IT guy on a Sunday to make sure he drives to the offices, enters the cold room and literally just pushes a damn button to turn it back on because there was no IPMI on the servers or the UPS system it's let's just say, not ideal.

By the way I am literally describing things we had to deal with and having directors call managers to complain about not getting their reports in time and we having to explain "Well it's not our fault, infrastructure guys literally had to physically go enter their data center room and push a button to get back online" gets quite confusing and embarrassing.

Yes these types of connections are a liability, but the alternatives are a liability as well. In fact once a medium sized company goes through some of these stuff guess what? They will very seriously consider Microsoft's or Amazon's sales pitch for cloud based infrastructure because well, now they don't have to pay top dollar or otherwise get teams not well prepared enough to manage critical IT infrastructure without having interns come in on a Sunday morning to push a power button.

Your talking about tech from perhaps 20 years ago. Any good remote switch has a option to reboot a system remotely. No need to have someone head to the DC and press the ON switch.

As for UPS's - imagine flashing in a firmware that puts the charging voltage way over what the battery's can take. Guaranteed fire and toxic release of hydrogen which is extremely flammable and even deadly if you sit around it long enough.

I had a leaking battery in a closed office. Never again I'm taking a UPS inside my (closed) office again. Those things are sold for cheap but dangerous as f once battery's go bad.


 

Watzupken

Posts: 597   +500
This is the one case I have to disagree: UPS system *should* be on the cloud and interconnected. If you work on IT and depend on servers for well, anything, then you know having to restart a server when people are asking you for things and there's literally nobody in the office and you need to wake up an IT guy on a Sunday to make sure he drives to the offices, enters the cold room and literally just pushes a damn button to turn it back on because there was no IPMI on the servers or the UPS system it's let's just say, not ideal.

By the way I am literally describing things we had to deal with and having directors call managers to complain about not getting their reports in time and we having to explain "Well it's not our fault, infrastructure guys literally had to physically go enter their data center room and push a button to get back online" gets quite confusing and embarrassing.

Yes these types of connections are a liability, but the alternatives are a liability as well. In fact once a medium sized company goes through some of these stuff guess what? They will very seriously consider Microsoft's or Amazon's sales pitch for cloud based infrastructure because well, now they don't have to pay top dollar or otherwise get teams not well prepared enough to manage critical IT infrastructure without having interns come in on a Sunday morning to push a power button.
I feel it is probably easier to just push a button than have someone sabotage the systems just because it needs to be connected online. Both are not good, but to me having to drive and go into office and peacefully push a button is better than having to clean up the aftermath of security breach or damaged system.
 

Dimitriid

Posts: 2,203   +4,239
I feel it is probably easier to just push a button than have someone sabotage the systems just because it needs to be connected online. Both are not good, but to me having to drive and go into office and peacefully push a button is better than having to clean up the aftermath of security breach or damaged system.
To clarify, I actually do not disagree. The only problem is that you know, I'm not a director or CEO so it's kinda difficult for me to convince a huge, multi national corporation of "You know, it's not even the end of fiscal year you can have your data for your financial reports delayed by 3 days" because it honestly isn't that important. Even stuff that *could* be considered more important like ERP systems handling inventories and orders could just afford to be delayed a couple days.

The reality is that there's a lot of people with a lot of money that just don't want to hear about it and want things how they want them, when they want them and any second of any day they can't show to be making a profit is a huge tragedy and worth the risks. Mostly because well, it isn't their risk anyway they can just demand high availability for things like regular commerce that are honestly not super important and people who try to say "That's an unreasonable expectation" end up just getting fired and replaced by yes men that coincidentally, also end up getting fired when their fail systems have issues.
 
This is the one case I have to disagree: UPS system *should* be on the cloud and interconnected. If you work on IT and depend on servers for well, anything, then you know having to restart a server when people are asking you for things and there's literally nobody in the office and you need to wake up an IT guy on a Sunday to make sure he drives to the offices, enters the cold room and literally just pushes a damn button to turn it back on because there was no IPMI on the servers or the UPS system it's let's just say, not ideal.

By the way I am literally describing things we had to deal with and having directors call managers to complain about not getting their reports in time and we having to explain "Well it's not our fault, infrastructure guys literally had to physically go enter their data center room and push a button to get back online" gets quite confusing and embarrassing.

Yes these types of connections are a liability, but the alternatives are a liability as well. In fact once a medium sized company goes through some of these stuff guess what? They will very seriously consider Microsoft's or Amazon's sales pitch for cloud based infrastructure because well, now they don't have to pay top dollar or otherwise get teams not well prepared enough to manage critical IT infrastructure without having interns come in on a Sunday morning to push a power button.

There is a huge difference between a device being network-accessible and being "cloud-connected". The latter requires you to trust a third party 24/7/365, and when they are inevitably compromised, so are you.

In contrast, a *network-connected* device can be securely tucked behind a VPN, so your IT person can roll over at 3am, poke a few things on their phone, and have the servers rebooted in a matter of minutes without ever getting out of bed. Proper isolation via VLANs etc can further secure important devices such as these (there's no good reason for a UPS to be on the same network as a public-facing web server).

Devices that phone home and/or are otherwise "cloud-controlled" inherently have a massively larger attack surface, and often merely for convenience. While proper security can mitigate many of these potential vulnerabilities, most users don't know how to do so (or even that they *should*); at least with non-cloud network-connected devices there is some inherent sense of the user being responsible for their own security.
 

Dimitriid

Posts: 2,203   +4,239
There is a huge difference between a device being network-accessible and being "cloud-connected". The latter requires you to trust a third party 24/7/365, and when they are inevitably compromised, so are you.

In contrast, a *network-connected* device can be securely tucked behind a VPN, so your IT person can roll over at 3am, poke a few things on their phone, and have the servers rebooted in a matter of minutes without ever getting out of bed. Proper isolation via VLANs etc can further secure important devices such as these (there's no good reason for a UPS to be on the same network as a public-facing web server).

Devices that phone home and/or are otherwise "cloud-controlled" inherently have a massively larger attack surface, and often merely for convenience. While proper security can mitigate many of these potential vulnerabilities, most users don't know how to do so (or even that they *should*); at least with non-cloud network-connected devices there is some inherent sense of the user being responsible for their own security.
AFAIK the functionality doesn't necessitates a central authority in "the cloud" for the UPS devices as I've seen people doing projects connecting these to their own intranet only networks with raspberry pies and such.

But if the only option to even have the functionality is centralized or "cloud" control only and is not up to data center admins then of course it's a terrible idea.

So, to clarify my initial response was that the funcionality that can potentially be used to tied it to a cloud service doesn't needs to go away because people can use it without connecting to such services and can enact the security measures you mention.