CVE-2019-12776

9.8 CRITICAL

📋 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

Products:
  • ENTTEC Datagate MK2
  • ENTTEC Storm 24
  • ENTTEC Pixelator
  • ENTTEC E-Streamer MK2
Versions: Firmware 70044_update_05032019-482
Operating Systems: Embedded Linux
Default Config Vulnerable: ⚠️ Yes
Notes: The backdoor is enabled by default in the specified firmware version through scripts that copy the hardcoded key to root's authorized_keys.

📦 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.

🌐 Internet-Facing: HIGH - Devices exposed to the internet can be directly compromised by anyone with the private key.
🏢 Internal Only: HIGH - Even internally, any attacker with network access can exploit this backdoor.

🎯 Exploit Status

Public PoC: ⚠️ Yes
Weaponized: CONFIRMED
Unauthenticated Exploit: ⚠️ Yes
Complexity: LOW

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

linux

Manually 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

linux

Stop 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]")

🔗 References

📤 Share & Export