Analyzing Malware for Embedded Devices: TheMoon Worm

All the media outlets are reporting that Embedded Malware is becoming mainstream. This is something totally new and we never heard of this before, right? The high number of Linux SOHO routers with Internet-facing administrative interfaces, the lack of firmware updates and the ease to craft exploits make them a perfect target for online criminals. The Internet of Threats is wildly insecure, but definitely not unpatchable.

To all infosec people out there, it's important to understand these threats and report it properly to the media. Some top-notch researchers recently uncovered "Massive Botnets" infecting refrigerators, microwaves, gaming consoles, soda machines and tamagotchis. The problem is that they never provided any sort of evidence, no malware samples, no IOC's and did not write a Hakin9 article describing it.

Refrigerator Botnet? Revd. Pastor Laphroaig says Show the PoC || GTFO

The aim for this post is to provide more information to identify/execute embedded binaries, describing how to set your own virtual lab. In case you missed it, head to the first post from the "Analyzing and Running binaries from Firmware Images" series.

TheMoon Worm

Johannes from SANS provided me a sample from "TheMoon" malware and posted some interesting information on their handler's diary. Their honeypots captured the scanning activity and linked the exploit to a vulnerable CGI script running on specific firmwares from the following Linksys routers: E4200, E3200, E3000, E2500, E2100L, E2000, E1550, E1500, E1200, E1000,E900.

SANS handlers classified TheMoon as a Worm because of the self-replicating nature of the malware. The worm searches for a "HNAP1" URL to fingerprint and identify potentially vulnerable routers. If you check your FW and Server logs you may find lot's of different IP's probing this URL.

The worm was named like this because it contains images from the movie "The Moon". It's possible to carve a few PNG's inside the ELF binary:

Identifying the Binary

A total of seven different samples were provided: they all seem to be variants from the same malware due to the ssdeep matching score.

Let's start by running the file utility and readelf to identify the architecture (MIPS R3000 / Little Endian):

The EXr.pdf variant (MD5 88a5c5f9c5de5ba612ec96682d61c7bb) had a VirusTotal Detection Rate of 3 / 50 on 2014-02-16.

QEMU

We'll be using QEMU to run the binaries on a controlled environment. I commonly use two different setups to run MIPS Linux binaries, both based on the Malta platform.

OpenWRT MIPS

OpenWRT Malta CoreLV platform is intended to be used with QEMU (in big or little endian mode). The install procedure is pretty straightforward using OpenWRT Buildroot. OpenWrt Buildroot is the buildsystem for the distribution and it works on Linux, BSD or MacOSX. In case you didn't remember, authors from Carna Botnet used it to cross-compile its binaries.

Installing prerequisites (on your favorite Debian Derivative):

Now head to the openwrt folder and set the proper settings for your Linux Kernel, choosing "MIPS Malta CoreLV board (qemu)" for the Target System and "Little Endian" for the subtarget. Don't forget to save the config.

Now build your image (use the -j switch to speed up if you have multiple cores, e.g "-j 3"):

Your image will be ready after a couple of minutes. Now you need to install QEMU full system emulation binaries and start it with the right command switches:

To exit the console simply hit CTRL+A followed by C and Q.

If you want to connect your emulated machined to a real network, follow the steps from Aurelien's Blog or simply run the following commands to get Internet access:

If you don't want to compile the Kernel by yourself, you can grab the pre-compiled binaries from here or here (at your own risk).

You may remember that it was not possible to run busybox-simet using the standalone qemu-mips-static. It's possible to fix that by manually patching QEMU or you can run it inside the proper virtual machine (OpenWRT Malta MIPS/Big Endian):

Debian MIPS Linux

I won't describe how to set up your Debian MIPS Linux because Zach Cutlip already did an amazing job describing it on this blog post. The process is quite similar to the OpenWRT one and if you're too lazy to build your own environment, Aurelien provides pre-compiled binaries here. Don't forget to set you network connections properly

Dynamic Analysis

In order to emulate the Linksys Environment, let's download and unpack the Firmware from E2500v2 (v1.0.07).

Let's copy and extract the root filesystem (e2500.tar.gz) and the malicious binary (EXr.pdf) to our test machine (Debian MIPS). Remember to copy the worm to the appropriate "/tmp" folder. Backup your QEMU image, start sniffing the connections from the bridged network (tap1 on my case) and bind the necessary pseudo-devices to the chrooted path. You can run the binary directly on your Debian MIPS environment, but using chroot and the target filesystem is highly recommended. If you try to chroot and run the worm without linking these devices, it will refuse to run and it won't drop the second stage binary.

You can use strace to log the syscalls and start your chrooted shell to run the malicious binary. I had some issues using strace on the 2.6.32 Debian MIPS Kernel (vmlinux-2.6.32-5-4kc-malta). The 3.2.0  (vmlinux-3.2.0-4-4kc-malta) version seems to be running fine.

If you don't want to use strace, simply start sh chrooted and run the malware:

The worm tries to remove files containing certain extensions and perform a series of system checks. After a few seconds the binary is removed from /tmp/ and three files are written on the disk: .L26 (PID), .L26.lunar (Lunar Base URL) and .L26.out (Debug log).

It's possible to dump QEMU's physical memory using the pmemsave command by hitting CTRL+A, C (to enter QEMU's administrative interface) and entering:

The 256MB raw dump will be saved on your host's local path. You can now try to use volatility or run strings against it.

The worm starts scanning for ports 80 and 8080 on a hardcoded list of networks. If the /HNAP/ URL returns a string identifying the targeted routers, the malware sends a HTTP POST trying to exploit a command injection on the vulnerable CGI.

Decoded POST:

TheMoon will also start an HTTPS server ("Lunar Base") on the router using the random port identified on the .L26.lunar file. The certificate's Common Name, Organization and Organizational Unit are hardcoded and other values seem to be random. Trying to find these entries on scans.io SSL certificates datasets would be really interesting.

The HTTPS server hosts three files: gerty.png, lunar.png and favicon.ico:

Rkhunter reports a few warnings on the infected system. I have upload the complete output from rkhunter to Pastebin, get it here.

Another useful technique is to compare the contents from the filesystem with a known good template. You can use binwally, WinMerge or binwalk's hashmatch.

Conclusion

I did not spend much time reversing the files and its functions as the main purpose of this post was to provide information to identify and execute embedded binaries, describing how to set your own virtual lab using QEMU.

It's still possible to improve the analysis by faking the nvram, by running a GDB server with QEMU or using Volatility with the proper profile and debugging structures, but this post is already way too long. You should also have a look on Avatar, from EURECOM. Avatar's goal is to enable complex dynamic analysis of embedded firmware in order to assist in a wide range of security-related activities, including malware analysis, reverse engineering and vulnerability discovery.

Let's keep drawing public awareness on the security issues of the Internet of Threats, persuading manufactures, ISP's and final users to collaborate to address these problems.