CVE-2018-16158
📋 TL;DR
This vulnerability allows remote attackers to gain root access to Eaton Power Xpert Meter devices via SSH using a hardcoded private key that is shared across all installations. Attackers can authenticate without credentials and obtain full system control. All customers using affected Eaton Power Xpert Meter 4000, 6000, and 8000 devices before version 13.4.0.10 are impacted.
💻 Affected Systems
- Eaton Power Xpert Meter 4000
- Eaton Power Xpert Meter 6000
- Eaton Power Xpert Meter 8000
📦 What is this software?
⚠️ Risk & Real-World Impact
Worst Case
Complete compromise of the power monitoring device, allowing attackers to disrupt power monitoring, manipulate readings, install persistent backdoors, or pivot to other industrial control systems.
Likely Case
Unauthorized root access to the device enabling data theft, configuration changes, and potential disruption of power monitoring functions.
If Mitigated
Limited impact if devices are behind firewalls with strict SSH access controls and network segmentation, though the vulnerability remains present.
🎯 Exploit Status
Metasploit module available (eaton_known_privkey.rb). Attack requires only network access to SSH port (default 22) and knowledge of the hardcoded private key.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 13.4.0.10
Vendor Advisory: http://www.eaton.com/content/dam/eaton/company/news-insights/cybersecurity/security-bulletins/PXM-Advisory.pdf
Restart Required: Yes
Instructions:
1. Download firmware version 13.4.0.10 from Eaton support portal. 2. Backup current configuration. 3. Upload and install the new firmware via the web interface. 4. Reboot the device. 5. Verify SSH uses unique keys post-update.
🔧 Temporary Workarounds
Disable SSH Access
linuxCompletely disable SSH service on affected devices if remote access is not required.
systemctl stop sshd
systemctl disable sshd
Restrict SSH Network Access
linuxUse firewall rules to restrict SSH access to trusted management networks only.
iptables -A INPUT -p tcp --dport 22 -s TRUSTED_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
🧯 If You Can't Patch
- Isolate affected devices in a separate VLAN with strict firewall rules blocking all inbound SSH except from jump hosts.
- Implement network monitoring and intrusion detection for SSH authentication attempts using the known private key.
🔍 How to Verify
Check if Vulnerable:
Check if SSH authentication succeeds using the known private key (available in public exploit code) or verify firmware version is below 13.4.0.10.
Check Version:
ssh -o ConnectTimeout=5 -o BatchMode=yes -o StrictHostKeyChecking=no root@device_ip 'cat /etc/version'
Verify Fix Applied:
Attempt SSH authentication with the known private key - should fail. Verify firmware version shows 13.4.0.10 or higher.
📡 Detection & Monitoring
Log Indicators:
- Failed SSH authentication attempts followed by successful authentication
- SSH log entries showing authentication with key fingerprint matching known vulnerable key
- Unexpected root logins via SSH
Network Indicators:
- SSH connections from unexpected source IPs
- SSH traffic patterns matching known exploit scripts
- Multiple SSH authentication attempts in short time
SIEM Query:
source="sshd.log" ("Accepted publickey" OR "authentication success") AND user="root" | stats count by src_ip
🔗 References
- http://www.eaton.com/content/dam/eaton/company/news-insights/cybersecurity/security-bulletins/PXM-Advisory.pdf
- https://www.ctrlu.net/vuln/0006.html
- https://github.com/BrianWGray/msf/blob/master/exploits/linux/ssh/eaton_known_privkey.rb
- http://www.eaton.com/content/dam/eaton/company/news-insights/cybersecurity/security-bulletins/PXM-Advisory.pdf
- https://www.ctrlu.net/vuln/0006.html