CVE-2019-12776
📋 TL;DR
This vulnerability allows remote attackers to gain root access to affected ENTTEC devices via SSH using a hard-coded cryptographic key. Anyone with the associated private key can execute arbitrary commands as root on all affected products. This affects ENTTEC Datagate MK2, Storm 24, Pixelator, and E-Streamer MK2 devices with specific firmware.
💻 Affected Systems
- ENTTEC Datagate MK2
- ENTTEC Storm 24
- ENTTEC Pixelator
- ENTTEC E-Streamer MK2
📦 What is this software?
⚠️ Risk & Real-World Impact
Worst Case
Complete compromise of affected devices allowing attackers to install persistent malware, pivot to internal networks, disrupt operations, or use devices as botnet nodes.
Likely Case
Unauthorized root access leading to device takeover, data exfiltration, and potential lateral movement within the network.
If Mitigated
Limited impact if devices are isolated in separate network segments with strict firewall rules and SSH access is blocked.
🎯 Exploit Status
Exploitation requires only the private key matching the hardcoded public key, which has been publicly disclosed.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Firmware versions after 70044_update_05032019-482
Vendor Advisory: https://www.enttec.com/
Restart Required: Yes
Instructions:
1. Download latest firmware from ENTTEC website. 2. Follow vendor's firmware update procedure. 3. Verify the update removed the hardcoded SSH key from root's authorized_keys.
🔧 Temporary Workarounds
Remove hardcoded SSH key
linuxManually delete the hardcoded SSH public key from root's authorized_keys file
ssh root@device_ip 'rm -f /root/.ssh/authorized_keys'
ssh root@device_ip 'chmod 600 /root/.ssh/authorized_keys'
Disable SSH service
linuxStop SSH service to prevent remote access via the backdoor
ssh root@device_ip 'systemctl stop ssh'
ssh root@device_ip 'systemctl disable ssh'
🧯 If You Can't Patch
- Isolate affected devices in a separate VLAN with strict firewall rules blocking SSH (port 22) access
- Implement network monitoring and intrusion detection for SSH connection attempts to these devices
🔍 How to Verify
Check if Vulnerable:
Check if the hardcoded SSH key exists in /root/.ssh/authorized_keys on the device: ssh root@device_ip 'cat /root/.ssh/authorized_keys | grep -i "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ"'
Check Version:
ssh root@device_ip 'cat /etc/version' or check device web interface for firmware version
Verify Fix Applied:
Verify the hardcoded key is no longer present: ssh root@device_ip 'grep -v "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ" /root/.ssh/authorized_keys | wc -l' should return 0
📡 Detection & Monitoring
Log Indicators:
- SSH authentication logs showing root login from unknown IPs
- Failed SSH attempts followed by successful root login
Network Indicators:
- SSH connections (port 22) to affected devices from unexpected sources
- SCP file transfers to/from devices
SIEM Query:
source="ssh.log" (user="root" AND (src_ip NOT IN [allowed_ips])) OR (auth_method="publickey" AND key_fingerprint="[hardcoded_key_fingerprint]")