Record-breaking distributed denial of service attack targets Russia’s version of Google – Yandex.
Technical details tied to a record-breaking distributed-denial-of-service (DDoS) attack against Russian internet behemoth Yandex are emerging. A massive botnet, dubbed Mēris, is believed responsible, flooding Yandex with millions of HTTP requests for webpages at the same time.
This DDoS technique is called HTTP pipelining, where a browser requests a connection to a server &, without waiting for a response, sends multiple more requests. Those requests reportedly originated from networking gear made by MikroTik. Attackers, according to Qrator Labs, exploited a 2018 bug unpatched in more than 56,000 MikroTik hosts involved in the DDoS attack.
According to Qrator, the Mēris botnet delivered the largest attack against Yandex it has ever spotted (by traffic volume) – peaking at 21.8m requests per second (RPS). By comparison, infrastructure & website security firm Cloudflare reported that the “largest ever” DDoS attack occurred on Aug. 19, with 17.2m RPS.
Researchers have linked Mēris to the Aug. 19 DDoS attack tracked by Cloudflare. The Yandex attacks occurred between Aug. 29-Sept. 5 – when the 28.1m RPS attack occurred. Both are believed to be smaller preceding attacks by threat players behind the Mēris botnet, which have yet to utilise their enormous firepower.
“Yandex’ security team members managed to establish a clear view of the botnet’s internal structure. L2TP [Layer 2 Tunnelling Protocol] tunnels are used for internetwork communications. The number of infected devices, according to the botnet internals we’ve seen, reaches 250,000,” wrote Qrator in a Thurs. blog post.
Virtual Private Networks
L2TP is a protocol used to manage virtual private networks & deliver internet services. Tunnelling facilitates the transfer of data between 2 private networks across the public internet.
Yandex & Qrato launched an investigation into the attack & believe the Mēris to be highly sophisticated.
“Moreover, all those compromised MikroTik hosts are highly capable devices, not your typical IoT blinker connected to Wi-Fi – here we speak of a botnet consisting of, with the highest probability, devices connected through the Ethernet connection – network devices, primarily,” researchers wrote.
The technical attack specifics include the exploitation of CVE-2018-14847. Tenable Research warned at the time of its disclosure that the bug needed to be taken extremely seriously, because a newly found hack technique allowed for remote code execution on MikroTik edge & consumer routers.
“We are now able to show how an attacker can use it to get root shell on a system. It uses CVE-2018-14847 to leak the admin credentials 1st & then an authenticated code path gives us a back door,” Tenable explained in 2018.
While MikroTik patched CVE-2018-14847 back then, Tenable has now revealed that only approximately 30% of vulnerable modems have been patched, which leaves approximately 200,000 routers vulnerable to attack. MikroTik’s RouterOS powers its business-grade RouterBOARD brand, as well as ISP/carrier-grade gear from the vendor.
Qrato recent analysis of the DDoS attack revealed that the compromised hosts each had open ports 2000 (Bandwidth test server) & 5678 (Mikrotik Neighbour Discovery Protocol). Researchers reported 328,723 active hosts on the internet replying to the TCP probe on port 5678.
Mitigating a Monster
While patching MikroTik devices is the most ideal mitigation to combat future Mēris attacks, researchers also recommended blacklisting.
“Since those Mēris attacks are not spoofed, every victim sees the attack origin as it is. Blocking it for a while should be enough to thwart the attack & not disturb the possible end user,” wrote researchers.
“It’s unclear how the…owners for the Mēris botnet would act in the future – they could be taking advantage of the compromised devices, taking 100% of its capacity (both bandwidth & processor-wise) into their hands. In this case, there is no other way other than blocking every consecutive request after the 1st one, preventing answering the pipelined requests.”