Botnets Attack Known Vulnerabilities in Unpatched SystemsResearchers Cite Moobot, Unnamed Botnet Launching DDoS Attacks
Botnet operators have begun to launch distributed denial-of-service attacks on devices that have not applied patches recommended for two separate vulnerabilities, say researchers at cybersecurity firms.
The vulnerability, according to the CVE description, abuses the web servers of "some" Hikvision products. Due to insufficient input validation, it allows threat actors to launch a command injection attack by sending specially crafted malicious commands, the description says.
The "vulnerability permits an attacker to gain full control of a device with an unrestricted root shell," the researcher who discovered the flaw in September, who uses the name Watchful_IP, told Information Security Media Group at the time. He says this gives threat actors "far more access than even the owner of the device has, as they are restricted to a limited 'protected shell' (psh), which filters input to a predefined set of limited, mostly informational commands."
In addition to a complete compromise of the device, successful exploitation of the flaw enables threat actors to access internal networks and penetrate deeply as well as laterally, Watchful_IP said.
The malware also modifies basic commands, such as "reboot," to stop administrators from rebooting the compromised device, according to the Fortinet researchers. The researchers also say they've discovered a downloader masked as "macHelper" fetching and executing Moobot with the "hikivision" parameter.
Fortinet's researchers, who fear a large-scale attack is on the horizon, say this botnet is a spinoff from Mirai since Moobot uses the "w5q6he3dbrsgmclkiu4to18npavj702f" data string in the random alphanumeric string generator function that is also used in Mirai. Moobot also shares several common elements with another variant of Mirai called Satori, including the use of a separate downloader, forking of the "/usr/sbin*" process, and overwriting the legitimate "macHelper" file with the Moobot executable.
Moobot aims to create an army of compromised devices to leverage in a DDoS attack, the Fortinet researchers say. Once the malware establishes communication with its command-and-control server, "[the] victim system receives the command [and] it starts a DDoS attack to a specific IP address and port number."
The DDoS attack command is 24 bytes in size and uses several flood commands, including SYN flood, 0x06 for UDP flood, 0x04 for ACK flood, and 0x05 for ACK+PUSH flood, according to researchers.
Although DDoS has fallen out of favor for cybercriminals over the past decade in comparison to ransomware's easy monetization feature, it can still pose a significant threat to organizations, especially those dependent on ecommerce for significant portions of their revenue, says Chris Clements, vice president of solutions architecture at Cerberus Sentinel.
For instance, a botnet owner may sell access to millions of compromised devices to a company looking to perform a DDoS attack on a competitor to disrupt operations, Clements tells ISMG. "In the case of cloud services, an attacker could cause a significant jump in costs if resources are configured to automatically expand to handle the illegitimate load brought by a DDoS attack."
Hikvision and Fortinet have not responded to ISMG's request for details, such as the number of victims in the current campaign, and whether a new notification has been sent to them.
The Unnamed Botnet
The botnet discovered by the researchers at Qrator Labs was spotted running a DDoS campaign in November, the company's report says. "We won’t give it a name. It is not 100% clear what we are looking at, what are the exact characteristics of it, and how big this thing actually is."
But based on the DDoS report by Qrator, the researchers tell ISMG, "We estimate the size of the botnet as no less than 55,000 devices. Based on the botnet components and its operational capabilities, we can assume this is the next iteration of the Mirai botnet, but we cannot be exactly sure before we have a living sample of this malware."
The researchers say that the botnet uses an "unusual" attack vector, which they call a "TCP random flood." Monitoring the distribution of answering endpoints in the attack sample, the researchers say the botnet primarily consists of connected cameras and routers, most notably two Cisco router models that are responsible for approximately 15% to 25% of the identified parts of the botnet.
Explaining the TCP random flood, the researchers say: "What happens with these attacking devices is that they establish a TCP connection with the victim server and then flood it with random data, with large-sized packets that almost reach the maximum transmission unit - or MTU - limit."
The researchers say that this particular technique is not very widespread and is more evasive than the User Datagram Protocol flood DoS/DDoS attack, in which the attacker targets and overwhelms random ports on the host with IP packets containing UDP packets or the smallest packet attack because higher bandwidth could be generated using reflection techniques, and higher packet intensity could be achieved by lowering the size of sent packets.
"It establishes a TCP connection with the victim's device so technically, that’s an L7 DDoS attack," Qrator's researchers tell ISMG.
In all, Qrator recorded five waves of the botnet-based DDoS attack, starting Nov. 8.
The 5 Waves
In the first wave, 14,973 devices were used with an attack peaking at 961 gigabytes per second - which is almost 1 terabit - and 88 million packets per second MPPS. The attack lasted for just two minutes and targeted both qrator[.]net homepage and its customers' resources. It was a combination of DNS amplification and TCP random flood attack vectors, the researchers say.
The second wave was observed on Nov. 12, and nearly 10,000 devices were used. This was the first instance of a pure TCP random flood attack, the researchers say.
In the third wave, observed on Nov. 13, the number of devices increased to 17,509 but the attack vector remained the same - TCP random flood.
In terms of attack volume, the fourth wave, which hit on the same day as the third, was the second-largest, peaking at 841.6 Gbps and 74 MPPS. Aimed at Qrator's customer Qiwi[.]com, the peak of the attack was reached with the use of "only" 8,600 devices. Again, it was a combination of DNS amplification and TCP random flood attack vectors, the researchers say.
In the fifth and the last wave of attacks, the number of devices doubled to 19,900 devices. Qrator did not tell ISMG the intensity of this wave or the vectors used ,but said that "in the last attack, we saw nearly 20,000 endpoints being used - this is bad news."
The researchers tell ISMG that all the DDoS attacks were short bursts to keep users from becoming suspicious. "If the exploited devices still serve their primary functions, attackers don't want to be very obvious and raise suspicion for the device owner. They'd probably assume that their devices were working a little 'slower' during a DDoS attack execution."
The Nov. 20, fifth wave has been the last one, the researchers say, raising speculation that the attackers may have switched to more vulnerable targets.
But this may not be the end, they say, as amplification of these attacks can be achieved easily over the public internet and cause huge collateral damages.
"Here we are looking at something consistent in the size of attack power, but nobody knows how it would evolve in the future. Three times what we saw here for a little longer and there you’ve got the record-breaking event," Qrator says.
The Moobot attacks observed by Fortinet began after the DDoS waves recorded by Qrator Labs. Neither company responded to ISMG's query on whether the attacks originated from the same attacker(s).
Who Is Responsible for Patching?
Network appliances and IoT devices have become favorite targets for attackers, because it’s challenging to identify and patch vulnerabilities as they are discovered, Cerberus Sentinel's Clements says.
"For systems such as Microsoft Windows or Google Chrome, the patching process is a part and parcel of the software’s functionality by either being centrally controllable by IT staff or fully automated. In contrast to this is the state of many network appliances or IoT devices that have no capabilities of notifying IT staff that they are vulnerable," he says.
The situation is even worse when the device vendor goes out of business or deems the hardware unsupported and ceases providing security patches, Clements says. "Every system or software package needs to have a plan for ongoing "care and feeding" to mitigate exposing the organization to risk as vulnerabilities are inevitably discovered," he says.
Nearly all devices run with either firmware or software, and most of them have exploitable bugs - bugs that people will mostly not patch, Roger Grimes, data-driven defense evangelist at cybersecurity firm KnowBe4, tells ISMG.
"People are far less efficient at patching anything not running on their PC, and the vendors who make those devices are horrible at allowing easy or automatic patching. You have to assume that most of the world will not patch their hardware, their routers, modems, cameras and IoT devices," he says.
According to Grimes, vendors can include auto-patching routines to overcome this problem.
"The device should reach out at least once a day to the vendor's website and ask, 'Is there a new critical patch available?' And if the answer is 'yes,' the device patches itself until the user has logged into their firmware or software and told the device not to auto-update."