A malware botnet is exploiting a zero-day vulnerability in end-of-life GeoVision devices to compromise and recruit them for likely DDoS or cryptomining attacks.
The flaw is tracked as CVE-2024-11120 and was discovered by Piort Kijewski of The Shadowserver Foundation. It is a critical severity (CVSS v3.1 score: 9.8) OS command injection problem, allowing unauthenticated attackers to execute arbitrary system commands on the device.
“Unauthenticated remote attackers can exploit this vulnerability to inject and execute arbitrary system commands on the device,” warns Taiwan’s CERT.
“Moreover, this vulnerability has already been exploited by attackers, and we have received related reports.”
According to TWCERT, the vulnerability impacts the following device models:
- GV-VS12: A 2-channel H.264 video server that converts analog video signals into digital streams for network transmission.
- GV-VS11: A single-channel video server designed to digitize analog video for network streaming.
- GV-DSP LPR V3: A Linux-based system dedicated to license plate recognition (LPR).
- GV-LX4C V2 / GV-LX4C V3: Compact digital video recorders (DVRs) designed for mobile surveillance applications.
All of these models have reached the end of life and are no longer supported by the vendor, so no security updates are expected.
Threat monitoring platform The Shadowserver Foundation reports that approximately 17,000 GeoVision devices are exposed online and are vulnerable to the CVE-2024-11120 flaw.
Kijewski told BleepingComputer that the botnet appears to be a Mirai variant, which is usually used as part of DDoS platforms or to perform cryptomining.
Most of the exposed devices (9,100) are based in the United States, followed by Germany (1,600), Canada (800), Taiwan (800), Japan (350), Spain (300), and France (250).
Source: The Shadowserver Foundation
In general, signs of botnet compromise include devices heating excessively, becoming slow or unresponsive, and having their configuration arbitrarily changed.
If you notice any of these symptoms, perform a device reset, change the default admin password to something strong, turn off remote access panels, and place the device behind a firewall.
Ideally, these devices should be replaced with actively supported models, but if that’s impossible, they should be isolated on a dedicated LAN or subnet and closely monitored.
Source: www.bleepingcomputer.com