Flaw in SMA Technologies OpCon UNIX Agent Adds the Same SSH key to all Installations - Binary Defense

Threat Watch

Threat Watch Flaw in SMA Technologies OpCon UNIX Agent Adds the Same SSH key to all Installations

Flaw in SMA Technologies OpCon UNIX Agent Adds the Same SSH key to all Installations

On Tuesday the CERT Coordination Center at Carnegie Mellon University disclosed a vulnerability that affects the 21.2 and earlier versions of SMA Technologies’ OpCon UNIX agent. The vulnerability is identified as CVE-2022-2154. During the installation and subsequent updates of all affected versions of the agent, an SSH key that is the same across every installation of the agent globally is added to the root account’s authorized_keys file; this key is not removed on uninstall.

The key can be clearly identified as sma_id_rsa, and if an attacker has the private key (which is included with the agent installation files), they could gain root-level SSH access to systems with the agent installed. SMA has created a script for checking for the vulnerable key and removing it (which must be run as root), or administrators can manually remove the vulnerability themselves. SMA also reports that the latest version of 21.2 does not include the vulnerable key, so fresh installs with the updated 21.2 package should not be affected.

ANALYST NOTES

Vulnerabilities such as this can be difficult to detect, since typically when public keys are added to authorized_keys, the same public key is used for all systems within an environment. However, a few steps can be taken to mitigate the risk:
• Implement a test environment. Aside from all the other benefits of having a testing environment, using a test install of the server with test machines as clients should have a different key pair than the production environment’s key pair. A simple diff will show whether this is the case.
• Keep a robust asset list. Keeping a list of which types of systems have what software, and which software has what requirements (including, in this case, SSH keys), can help mitigate the risk of old, unused keys being left on systems.
• Periodically audit the authorized_keys file. In addition to reviewing changes to authorized_keys when they occur, validating that the keys listed in authorized_keys match the requirements of the software on the system (see above) can help identify issues with key management. This has the additional benefit of helping detect if an attacker has loaded their own SSH key as a persistence mechanism.

https://kb.cert.org/vuls/id/142546