How “Peter Parker’s” Mirai Variant Took Down 900,000 Routers

What happens when service providers issue routers with remotely exploitable flaws? This weekend, we saw a glimpse of what is possible when attackers attempted to load Mirai-based malware on routers through a vulnerability in an exposed remote management protocol. Although the attackers probably failed in their ultimate goal of creating a large botnet, the efforts did not go unnoticed by some 900,000 disconnected customers of German ISP Telekom. Initial reports suggested that the malware may have interacted poorly with certain infected devices; however, we have since learned that the implicated SpeedPort W921v router was in fact not vulnerable to the command injection but rather was just easily overwhelmed by the scanning activities of infected routers. (As it turns out, the SpeedPort is not even running Linux and has no wget binary as reported by Comsecuris.) I learned about this situation early Monday morning through a message from German journalist and security researcher Hanno Böck informing me that there were ongoing attacks on TCP/7547. Firing up netcat on this port, I received an HTTP POST request with a SOAP payload within 90 seconds. The payload was clearly designed to exploit a command injection flaw. The vulnerability being exploited had been described earlier this month as affecting a particular router series deployed in Ireland. The payloads were designed to use wget to download and execute code from a remote server with the hostname l.ocalhost.host or p.ocalhost.host or tr069.pw. Most of the attack payloads I saw attempted to download one of two static linked binaries for the MIPS architecture. But some – apparently, from a newer variant – would instead download and run a shell script attempting to run code built for each of the seven architectures (MIPS, MIPSEL, ARM, Renesas SH, PPC, SPARC and Motorola m68k), indicating that the botnet operator suspected that this vulnerability is present on a variety of devices.

Analysis

After downloading the malware samples, I found that they had distinct characteristics of a Mirai-based botnet likely built from the recently released source code. Upon loading, the malware would attempt to block further exploit attempts by running ‘busybox iptables -A INPUT -p tcp --destination-port 7547 -j DROP’. It would also then proceed to unlink itself from the filesystem and use prctl/PR_SET_NAME to set a random process name as shown in the main() function for the released Mirai bot source. At this point, it should be clear that this is, in fact, malware derived from Mirai but the similarity does not end there. Dumping strings from the binary reveals a long list of clearly obfuscated strings, such as ‘qGVlvrqGPTGPQ’. Looking in the Mirai source code, there is an encoding tool designed to obfuscate strings through a relatively simple XOR process using a dummy key of 0xdeadbeef. Sure enough, a hex dump of the binary reveals these bytes starting at offset 0x18054 (MIPSEL binary), so I figured it would be worth a try to extract and decode the obfuscated strings using a simple Python function to apply the XOR process. I have put this code in a Gist in case it is of use for anyone else.

import sys

def decode(input):
	key = 0xdeadbeef
	k1 = key & 0xFF
	k2 = (key>>8) & 0xFF
	k3 = (key>>16) & 0xFF
	k4 = (key>>24) & 0xFF
	output = ""
	for n in input:
		output += chr(ord(n)^k4^k3^k2^k1)
	print output

decode(sys.argv[1])

Applying this process to the bytes stored in my malware sample revealed additional strings confirming Mirai and also showing the various payloads being sent. (It is also interesting to note that the attacker was apparently too lazy to change the 0xdeadbeef XOR key.) Further analysis of the binary demonstrated some potential indicators of compromise, including domain names rep.securityupdates.us, ntp.timeserver.host, tr069.pw, and p.ocalhost.host.  Checking out the registration details for securityupdates.us and ocalhost.host made me laugh a little when seeing that it was registered by Peter Parker out of Kiev, Ukraine (hence the title of this post). Whois records for timeserver.host, on the other hand, indicate the same street address (27 Hofit St) but this time, indicate a name of ‘spider man’ and that the address is in Tel Aviv, Israel. Additional analysis on this attack is here: ISC SANS Port 7547 SOAP Remote Code Execution Attacks Against DSL Modems

Sample Details

Samples obtained from p.ocalhost.host on Monday, Nov. 28:

LSB MIPS: 7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2
MSB MIPS: fc683bdfc51b2f4eec162e80ab253f3d7f5f22a1c64630c7c7d5509932a6a346
ARM:      1fce697993690d41f75e0e6ed522df49d73a038f7e02733ec239c835579c40bf
Renesas:  828984d1112f52f7f24bbc2b15d0f4cf2646cd03809e648f0d3121a1bdb83464
PowerPC:  c597d3b8f61a5b49049006aff5abfe30af06d8979aaaf65454ad2691ef03943b
SPARC:    046659391b36a022a48e37bd80ce2c3bd120e3fe786c204128ba32aa8d03a182
M68k:     5d4e46b3510679dc49ce295b7f448cd69e952d80ba1450f6800be074992b07cc

Samples obtained from tr069.pw on Tuesday, Nov. 29:

LSB MIPS: 4b759457fbb423375510fa5125b6ac28ae7b347eb544be4ad21b4cbc8e91450d
MSB MIPS: fc683bdfc51b2f4eec162e80ab253f3d7f5f22a1c64630c7c7d5509932a6a346
ARM:      1fce697993690d41f75e0e6ed522df49d73a038f7e02733ec239c835579c40bf
Renesas:  828984d1112f52f7f24bbc2b15d0f4cf2646cd03809e648f0d3121a1bdb83464
PowerPC:  c597d3b8f61a5b49049006aff5abfe30af06d8979aaaf65454ad2691ef03943b
SPARC:    046659391b36a022a48e37bd80ce2c3bd120e3fe786c204128ba32aa8d03a182
M68k:     5d4e46b3510679dc49ce295b7f448cd69e952d80ba1450f6800be074992b07cc

Takeaways

Whether or not this attack was a success, it is noteworthy that this could be a new trend to implement exploits in Mirai rather than simple password-guessing operations. As I’ve been saying for some time (here and here for example), the stage is set for an IoT botnet of unprecedented scale when someone decides to incorporate a few public exploits into the Mirai arsenal. In this particular case, the worm was able to be particularly successful due to the large deployment of vulnerable devices along with the fact that there was no patch available but searching on Shodan reveals that there are millions of additional devices with other known vulnerabilities waiting to be exploited. Another interesting observation is that like many IoT flaws, the vulnerability may actually exist in products from multiple brands, indicating that it may have crept in from an improperly vetted supply chain. While it is not proven in this specific case as of yet, vendors really need to step up their own responsibility by thoroughly auditing all source code used in their products, regardless of origin. Unfortunately, this is not the norm and as a result, vulnerabilities in code supplied by chipset makers or the open source community (specifically, OpenWRT) have been integrated into countless devices from numerous manufacturers. Moving forward, this behavior must change or else bad actors will continue to amass large botnets made up of our devices.