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 surfacing as the digital dust settles. 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 and, 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.8 million requests per second (RPS). By comparison, infrastructure and website security firm Cloudflare reported that the “largest ever” DDoS attack occurred on August 19, with 17.2 million RPS.
The Looming Mēris Monster
Researchers have linked Mēris to the August 19 DDoS attack tracked by Cloudflare. The Yandex attacks occurred between August 29 through September 5 – when the 28.1 million RPS attack occurred. Both are believed to be smaller precursor attacks by threat actors behind the Mēris botnet, which have yet to utilize the enormous firepower.
“Yandex’ security team members managed to establish a clear view of the botnet’s internal structure. L2TP [Layer 2 Tunneling 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 Thursday blog post.
L2TP is a protocol used to manage virtual private networks and deliver internet services. Tunneling facilitates the transfer of data between two private networks across the public internet.
Yandex and Qrato launched an investigation into the attack and 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.
Early Warnings Ignored?
The technical attack specifics include the exploitation of a 2018 vulnerability, tracked as 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 and 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 first and then an authenticated code path gives us a back door,” Tenable told Threatpost in 2018.
While MikroTik patched CVE-2018-14847 back then, Tenable has now revealed that only approximately 30 percent 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) and 5678 (Mikrotik Neighbor 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 and 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 percent of its capacity (both bandwidth and processor-wise) into their hands. In this case, there is no other way other than blocking every consecutive request after the first one, preventing answering the pipelined requests.”