cPGuard Update Channel Breached to Plant Backdoor on Linux Servers

An attacker broke into the update system of the cPGuard security tool on November 2 and used it to push a malicious script to customers' Linux servers, according to the tool's maker, OPSSHIELD.

The script installed a backdoor and gathered password hashes and other sensitive files from servers that ran it. The attacker has since taken some of that data.

At 02:06 UTC, the unidentified attacker used compromised credentials to access cPGuard's update system. The script shipped in cPGuard versions 5.88.12 through 5.88.19. OPSSHIELD says it detected the attack within 12 hours of those versions going out, cleared its infrastructure credentials and stopped the script from reaching more servers. It is still investigating how the credentials were obtained.

Version 5.88.25 and later remove the backdoor and the files the script left behind. But credentials the script copied may still work, so any server that may have run it needs new passwords and keys.

OPSSHIELD has not said how many servers installed an affected version. Admins can check their update log for an entry showing any version from 5.88.12 through 5.88.19, though that alone doesn't prove the script ran or data left the server. A server with no matching entry, or a missing or incomplete log, may still have run it; unsure admins can contact OPSSHIELD Support.

The script collected /etc/shadow and /etc/passwd, root's MariaDB or MySQL configuration, root's shell history, and the SSH authorization and known-hosts files for root. It uploaded what it gathered to a licensing server run by OPSSHIELD itself through a compromised account, which the company has since secured. OPSSHIELD estimated late on November 2 UTC that the attacker took 32 files from that server, each tied to one customer server.

OPSSHIELD asks admins to update every cPGuard server and confirm the version, then reset root and local account passwords, rotate database passwords, S3 keys, DigitalOcean tokens and other secrets, and replace SSH private keys stored under /root/.ssh. It is not recommending a full rebuild as a routine step. Separately, it is releasing a precautionary update that removes its support-access keys from servers where they were added earlier.

Source: The Hackers News