Threat Level: green Handler on Duty: Manuel Pelaez

SANS ISC InfoSec Community Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Linksys Worm "TheMoon" Summary: What we know so far
Quoting Diary:

I am writing this summary as the prior diaries about this topic became a bit difficult to parse. 

At this point, we are aware of a worm that is spreading among various models of Linksys routers. We do not have a definite list of routers that are vulnerable, but the following routers may be vulnerable depending on firmware version: E4200, E3200, E3000, E2500, E2100L, E2000, E1550, E1500, E1200, E1000,E900

The worm will connect first to port 8080, and if necessary using SSL, to request the "/HNAP1/" URL. This will return an XML formatted list of router features and firmware versions. The worm appears to extract the router hardware version and the firmware revision. The relevant lines are:

<ModelName>E2500</ModelName>
<FirmwareVersion>1.0.07 build 1</FirmwareVersion> 

(this is a sample from an E2500 router running firmware version 1.0.07 build 1)

Next, the worm will send an exploit to a vulnerable CGI script running on these routers. The request does not require authentication. The worm sends random "admin" credentials but they are not checked by the script. Linksys (Belkin) is aware of this vulnerability.

This second request will launch a simple shell script, that will request the actual worm. The worm is about 2MB in size, samples that we captured so far appear pretty much identical but for a random trailer at the end of the binary. The file is an ELF MIPS binary.

Once this code runs, the infected router appears to scan for other victims. The worm includes a list of about 670 different networks (some /21, some /24). All appear to be linked to cable or DSL modem ISPs in various countries.

An infected router will also serve the binary at a random low port for new victims to download. This http server is only opened for a short period of time, and for each target, a new server with a different port is opened. 

We do not know for sure if there is a command and control channel yet. But the worm appears to include strings that point to a command and control channel. The worm also includes basic HTML pages with images that look benign and more like a calling card. They include images based on the movie "The Moon" which we used as a name for the worm.

We call this a "worm" at this point, as all it appears to do is spread. This may be a "bot" if there is a functional command and control channel present.

Indicators of compromisse:

- heavy outbound scanning on port 80 and 8080.
- inbound connection attempts to misc ports < 1024.
 

Detecting potentially vulnerable system:

echo "GET /HNAP1/ HTTP/1.1\r\nHost: test\r\n\r\n" | nc routerip 8080

if you get the XML HNAP output back, then you MAY be vulnerable.

 

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

Dr. J

1648 Posts
ISC Handler
Just to be clear, this is all happening on the outside interface of those routers?
With remote administration turned on or off?

That hadn't crossed my mind until reading this latest summary. (worm/spreading)
K-Dee

42 Posts
This is happening on the outside interface with remote admin turned on.
Dr. J

1648 Posts
ISC Handler
I am guessing this worm only attacks Linksys routers with original firmware and not open source firmware ie: DD-WRT?
newzbie

1 Posts
Correct: Only routers running stock firmware are vulnerable. OpenWRT is not vulnerable to this issue.
Dr. J

1648 Posts
ISC Handler
Thanks for the clarification Dr J.

If remote admin is turned on, but restricted to a certain IP address, does that thwart the attack?

Also I assume if the remote admin port is changed that would also thwart the attack? (Unless they scanned you, figured out your new port, and then changed their code to check that port)
K-Dee

42 Posts
The worm only scans port 80 and 8080 (http and https). Changing the port will prevent this attack. Restricting access to the admin interface by IP address will help as well.
Dr. J

1648 Posts
ISC Handler
Is there a list of the ~670 networks mentioned available? Or a copy of the binary for those of us who have not yet to encounter this in the wild?
Anonymous

1 Posts
Can anyone share the 670 IP ranges or even the list of countries being targeted.
Also does anyone know if DNS values inside router are being modified.
AussieBob

1 Posts
I dropped a list of the networks here (627 actually)

isc.sans.edu/diaryimages/…

It isn't clear if DNS values are being modified, but it is likely. Brett saw routers that used Google's DNS servers (8.8.8.8, 8.8.4.4.) instead of the once he pushed. But of course, the Google DNS servers wouldn't cause any problems (maybe better for the attacker then OpenDNS?)

There are some strings in the binary that may indicate that the DNS settings are changed:

@/etc/resolv.conf
nameserver
domain
search
options
timeout
attempts
/etc/hosts
Dr. J

1648 Posts
ISC Handler
GOOD GRIEF!

I've been seeing an tidal wave of HNAP1
probes in the Apache logs since MAY of
LAST YEAR!

Was so bad that I wrote an ASA firewall
rule to unceremoniously drop and discard
the plague of annoying connection entries.

It took you guys a YEAR to figure
out this was a worm? I guessed as much
and I'm not a security researcher.

I'm not impressed.
Starlight

10 Posts
I have had remote admin disabled (plus the latest firmware) on my E2500 since day one, but when looking into this vuln, I found that tcp 80 and 443 are still open, and they both offer up the schema at /hnap1/. Is there any additional info you can disclose that would allow me to test the vuln under this configuration?

This does make me miss Tomato/OpenWRT though. Maybe it's time for the WRT 1900AC...
brad

3 Posts
Quoting Starlight:GOOD GRIEF!

I've been seeing an tidal wave of HNAP1
probes in the Apache logs since MAY of
LAST YEAR!

Was so bad that I wrote an ASA firewall
rule to unceremoniously drop and discard
the plague of annoying connection entries.

It took you guys a YEAR to figure
out this was a worm? I guessed as much
and I'm not a security researcher.

I'm not impressed.


Its because not all the HNAP requests are the worm. The HNAP request isn't the vulnerability or the exploit, its just a probe for information that is used to target the xploit. Ever since an article (and a tool) came out last year you have millions of systems probing the internet making HNAP requests trying to map SOHO router infrastructure. Some are malicious, some are just researchers.

Its only certain types of HNAP requests followed by an exploit attempt that are attributable to the worm. Which is why it went unnoticed. If you have firewalls dropping millions of requests a day, you don't look at everyone of those drops every day. You just bin them by common characteristics and decide whether they require actions. Which means in situations such as this, the subtle differences between the HNAP probes means it went unnoticed until someone took the time to dig into the haystack to look at the one piece of straw. As its not a needle in a haystack problem, its looking for an odd looking piece of straw in a pile of straw.
pktman

10 Posts
Quoting brad:I have had remote admin disabled (plus the latest firmware) on my E2500 since day one, but when looking into this vuln, I found that tcp 80 and 443 are still open, and they both offer up the schema at /hnap1/. Is there any additional info you can disclose that would allow me to test the vuln under this configuration?

This does make me miss Tomato/OpenWRT though. Maybe it's time for the WRT 1900AC...


I have found that on most of these SOHO routers with HNAP, that disabling remote administration doesn't disable the router from answering HNAP1 requests on the WAN side. Have sent more than a few emails to a few manufactures who replied that devices where functioning "as designed".

I don't like anything like that allowing attackers to probe my systems for information or potentially compromise them. In the absence of anyway to disable this in firmware the only reliable way I have found is to enable port forwarding and forward the traffic into the abyss. To make this safe you need to setup DHCP on your LAN side to not allocate certain addresses. Then port forward the incoming port 80/443 traffic to an ip that isn't assigned to anything.

For example if your routers internal LAN IP is 192.168.1.1, setup DHCP to allocate only 192.168.1.5-192.168.1.250. Then set up port forwarding rules so that incoming traffic to port TCP port 80 and TCP port 443 on the WAN side of your router gets forwarded to 192.168.1.2.

Its not pretty, its not ideal. But on the devices i have tried, it has at least made port 80/443 go dark to the WAN as the SYN's just go into nothingness.
pktman

10 Posts
Looks like DLINK routers are vulnerable as well. I am from India, and I am using a DLINK 2750U router. Last week the connection was totally erratic, and none of the https: connections were going through, had a tough time shouting at the ISP. They sent a guy who changed the entire cable, suspecting some physical cable damage. (Okay dont laugh. That is as much as he knows to do).

But after I logged into the router config I found the secondary DNS was changed to 8.8.8.8. Never remembered seeing such a number in the ISP config. So I thought some geeky hacker around my apartment has hacked into my wifi and played around. Immediately reset the router and changed all default router access passwords. Things are fine now.

Either my router was infected with a better version of the worm which targets other brands as well, or DLINK is using Linksys/CISCO codebase! The second thing is rats!
Anonymous

1 Posts
The DLink issue is not necessarily a worm. It could be (one of many) DNS changer attacks agains these routers. Typically, the DNS Changer uses a weak password, or a vulnerability, to change settings like the DNS server. But they don't run code on the router to infect others. The only way to find out for sure is to capture packets at the uplink port of the router. Make sure no devices are connected to the router while you do so (wifi or wired) to get a clean packet capture.
Dr. J

1648 Posts
ISC Handler
I own a Linksys E2000 router, remote management is enabled since initial setup (2-3 years ago). After some research I was able to login to the router remotely with an exploit posted on the web, which gave me shell-access.

Without further modification I was able to read the next details (clear-text) with just one binary:
- wps pin and password, no wps-crack tools needed.. just read it!
- guest network password
- remote management password

With the same binary I was able to change the DNS-servers and DMZ settings (and a lot more like network-settings and security-settings).

The weird part was, those changes were not all visible (dns-servers) on the webUI but a linux machine hooked up on this router was using the changed values.

After seeing all kind of traffic from China, Vietnam and Romania through my modem in the logs of my E2000 router, I decided to buy a new router (Belkin/Cisco doesn't support this one anymore) and now I use this router in a test-environment.

It's scary to know I had this router all that time, latest firmware etc and now knowing how vulnerable home-networks can be.

Thanks for your posts, else I didn't knew anything about this!
Anonymous

1 Posts

Sign Up for Free or Log In to start participating in the conversation!