WARNING: Powercool Smart UPS Software (potential supply chain attack)

[Potty Bert]

TLDR: DON'T INSTALL THE SOFTWARE ON YOUR NAS, IT'S A SECURITY NIGHTMARE,

DON'T INSTALL ANY SOFTWARE PROVIDED BY YOUR UPS UNLESS YOU REALLY, REALLY TRUST IT

I bought a Powercool Smart UPS earlier this year, it arrived with linux software and installation scripts, but I had concerns about just running this on my NAS so elected to try and manually configure it via TrueNAS (I couldn't get it working properly so abandoned that and bought a new Eaton UPS which just works).

I've just gone back to look at the Powercool UPS with the intention of getting it set up for my gaming PC and thought I'd check the software out.

First thing I did was look at how it was installed, which is as root, no sandboxing, no user for the software (so it's never getting installed)

Then I asked copilot to audit it (an actual good use for AI):
The summary (full report attached as markdown) is:

neokylin/

├── install.sh 🟡 MEDIUM #4 — deletes/relies on predictable /tmp socket & lockfile paths

├── SECURITY-REVIEW.md (audit report — added by this review)

├── upsSmartView.desktop ─ (launches per-user GUI that talks to root daemon; context for #2)

├── upsSmartView.service 🟠 HIGH #2 — runs upsSmartServer as root, no User=/sandboxing, Restart=always

└── upsSmartView/

├── upsSmartServer 🟠 HIGH #2 — root daemon, system()-executed external program via unauthenticated /tmp socket

│ 🟡 MEDIUM #4 — predictable /tmp lockfile (symlink attack)

│ 🟡 MEDIUM #6 — writes cleartext SMTP/shutdown passwords to config

│ ⚪ LOW #7 — insecure RUNPATH (relative `lib`, /home/zang/… dev path)

├── upsSmartServer.sh 🟠 HIGH #3 — forces LD_LIBRARY_PATH to EOL bundled libs

├── upsSmartView 🔴 CRITICAL #1 — hardcoded FTP update credentials; plaintext-FTP updater, MD5-only integrity

│ 🟡 MEDIUM #5 — default password `123456`, weak credential storage in SQLite

├── upsSmartView.sh 🟠 HIGH #3 — forces LD_LIBRARY_PATH to EOL bundled libs

├── copylib.sh ─

├── cp.sh ─

├── istartTest ─

├── snmpTest ─

├── snmpv3_boot_counter ─ (encoded engine ID only; not a secret)

├── libpng12.so.0 🟠 HIGH #3 — libpng 1.2.54, EOL branch with known CVEs

├── upsevent_ch.wav ─

├── upsevent_en.wav ─

├── config/

│ └── IDBK/

│ └── upsSmartView.conf 🟡 MEDIUM #6 — cleartext credentials at rest, world-readable (0644)

├── dep/ (95 bundled libraries) 🟠 HIGH #3 — EOL/vulnerable vendored stack, e.g.:

│ ├── libssl.so.1.0.0 🟠 HIGH #3 — OpenSSL 1.0.2v-dev (EOL Dec 2019)

│ ├── libcrypto.so.1.0.0 🟠 HIGH #3 — OpenSSL 1.0.2v-dev (EOL Dec 2019)

│ ├── libQt5*.so.5 🟠 HIGH #3 — Qt 5.9.8 (EOL)

│ ├── libicu*.so.56 🟠 HIGH #3 — ICU 56 (ancient)

│ └── … 🟠 HIGH #3 — old libc, libexpat, libgcrypt, libfreetype, etc.

├── lib/

│ ├── libupdateManage.a 🔴 CRITICAL #1 — contains the hardcoded FTP credentials / FTP updater code

│ ├── libsnmpClient.so ─ (SNMP attack surface for #3's vulnerable parsers)

│ ├── libSnmpManage.a ─ (SNMP attack surface)

│ ├── lib<model>*.so ─ (UPS device protocol drivers)

│ ├── cJSON/ ─ (leftover vendor build artifacts — CMakeFiles, .o files)

│ └── libmodbus/ ─ (leftover vendor build artifacts)

├── platforms/

│ └── libqxcb.so 🟠 HIGH #3 — part of the EOL Qt 5.9.8 runtime

└── sqldrivers/

└── libqsqlite.so 🟠 HIGH #3 — part of the EOL Qt 5.9.8 runtime

(also where #5's weak-password SQLite DB is accessed)

 

This is would appear to be an intentional developer backdoor/maintenance pipeline left in production code pulling anything from a remote chinese IP and running it on your computer.

It would be trivial to push some code to your NAS that not only can execute anything including stealing your data, but also wipe the entire thing (or just wipe any trace of them having been there)

SECURITY-REVIEW.md

[Mobius]

yikes, I haven't heard of this brand before but thats definitely a bit red flag. 

just curious which eaton psu did you go with?
my Eaton Tripp Lite OMNIVS1500LCD works just likes to provide wonky data because the nut drivers for it aren't great.

[Potty Bert]

The Eaton 3P Ellipse is what I ended up with, so far it's working well. I still need to detach some of the TrueNAS config I'd set up before in order to enable monitoring in HexOS, but I at least got it detecting

[Potty Bert]

re-reading this, I noticed how much I typed NAS instead of UPS.  OH the shame...

[Mobius]

4 hours ago, Potty Bert said:

re-reading this, I noticed how much I typed NAS instead of UPS.  OH the shame...

fixed for you

[Sarah Harris]

The NAS/ UPS mix-up made me smile — easy enough to do when you're juggling both TrueNAS and HexOS in the same setup. On the Eaton, it's worth untangling that monitoring config carefully before you let HexOS take it over, since leftover TrueNAS drivers can sometimes conflict rather than just sit idle. Curious whether HexOS picked up the Ellipse on its own or needed a shove. Either way, a native UPS integration that actually detects hardware is a reasonable starting point given what the thread warns about.

[Robert Robinson]

The NAS/ UPS mix-up is easy enough to make, especially when the monitoring config is the part you're actually wrestling with. Switching from the TrueNAS setup to HexOS detection sounds like the practical route; getting the Eaton recognized is the main hurdle, and the rest can follow once it's talking to the system. Curious whether HexOS picked it up over USB without extra drivers, since that's usually where these transitions get fiddly.

[Robert Martin]

The NAS/UPS slip is easy enough to make in a thread about monitoring, since TrueNAS config was part of the setup anyway. What matters more is that the Eaton Ellipse is being detected — getting that working before untangling the old monitoring config seems the right order. I'd be curious whether HexOS picks it up cleanly once the leftover config is detached, or whether it needs a USB driver tweak first.

[Robert Robinson]

The order you settled on — get the Eaton Ellipse detected before detaching the leftover TrueNAS config — makes sense, though I'd add one caution: if the old monitoring service is still running in the background, it can grab the USB device first and leave HexOS seeing nothing. So detaching cleanly may actually need to come first, then detection. That fits the thread's wider point too: verify what the software is actually doing rather than assuming it just sits idle. Worth confirming whether HexOS needs any driver step for the Ellipse once the old service is genuinely stopped.