Welcome to WebmasterWorld Guest from 54.162.105.6
Forum Moderators: Ocean10000 & incrediBILL & phranque
Shut down "Random JS Toolkit" exploit
If you don't have to use external JavaScripts
Senior Member
joined:Mar 31, 2002
posts:25430
votes: 0
As described on various security sites, a dangerous exploit [finjan.com] is spreading on the Web. Compromised servers are being used to download a collection of several crimeware exploits to Web site visitors.
These Web sites are compromised at the server level; All virtual hosts on the server will become malware downloaders. Servers equipped with mod_bandwidth_limited and mod_dl seem to be vulnerable.
Having several sites that don't use external JavaScripts, or where the JS is small enough to include in-line, I decided that even if my servers are compromised, I didn't want to play any part is spreading this malware. So, I put a simple one-line mod_rewrite patch into my .htaccess file:
RewriteRule \.js$ - [G]
For sites that do use a small number of external JavaScripts, the nature of this malware implementation indicates that using a 'valid filename filter' may be helpful:
RewriteCond $1 !valid_js_script1_path\.js$
RewriteCond $1 !valid_js_script2_path\.js$
RewriteCond $1 !valid_js_script3_path\.js$
RewriteRule ([^.]+\.js)$ - [G]
This code does not prevent your server from being compromised. All it does is help prevent the spread of malware to your visitors if your server is compromised. This is not a general anti-malware solution; It addresses only the current implementation of this specific exploit.
Jim
Senior Member
joined:Dec 27, 2004
posts:1949
votes: 60
One learns a thing or two based up on someone's knowledge being presented with in tech docs(or not)... then that one fails to discuss it simply due to personal gain. Even worst, those facts put the one at gain and profits from it, and are equivalent to someone’s ignorance... said Winnie the Pooh.
Senior Member
joined:Dec 4, 2002
posts:1958
votes: 0
all the Javascript examples I have seen so far show that the path to the malicious Javascript is on your server, the root-compromised host.
AFAIK, javascript file is also served from memory. The file doesn't exist on disk, and there is no logging of the request.
I have not read where it has it's own httpd, but if so, it is acting as a proxy in front of apache, [otherwise they would have to both bind to port 80]. If it is either it's own webserver, or a proxy - rewriting js won't stop it.
Senior Member
joined:Aug 7, 2003
posts:4783
votes: 0
The JS (not using it) point is a moot point
We all have pretty much been forced fed with Ajax
Try Firefox with NoScript. It'll work nicely and you can enable (even just temporary) Javascript for those few sites you want to use it. As an added bonus it'll do the same for Flash and other plugins that you can do without.
While at it take a look at CookieSafe, does the same for cookies, with the same handy interface.
Senior Member
joined:Aug 7, 2003
posts:4783
votes: 0
It seems the researchers agree that the attacks originate over ssh and got in without any brute forcing. This seems to indicate they collected the passwords in another fashion.
Now there's no magic database of passwords, such a thing simply doesn't exist, so those passwords got obtained otherwise.
Perhaps the first place to look at for those being exploited is who knew their ssh passwords! And who let those passwords fall in the hands of the bad guys.
Similarly if you use passwords in more than one place, know that that might be a source of a leak too.
Next changing ssh authentication to a public key system is easy enough an operation and once that works you can disable passwords once and for all. Just make sure not to loose your private key and to not forget your paqssphase on that key.
Administrator
joined:July 31, 2003
posts:12548
votes: 2
>> proxy
Hmmm. That part wasn't mentioned anywhere yet. Great point to consider.
In regards to whether or not the mod_rewrite code here would work as planned -- I think the determining factor comes down to how incoming requests are being handled. Is the request being processed by your http server or by the malicious http server? Or both, via proxy as suggested? Obviously, if it is by your server alone, that code is going to work. I took some time today again to think about this stuff ... some of the information we have so far ...
I have not read where it has it's own httpd, but if so, it is acting as a proxy in front of apache, [otherwise they would have to both bind to port 80]. If it is either it's own webserver, or a proxy - rewriting js won't stop it.
From the cpanel article:
This agent binary is built with several additional scripts developed by the attacker to load a web server into memory and inject the random JavaScript into the HTML code after Apache has served the file, but before it has traveled through the TCP transport back to the web site visitor.
Yes, I read that statement to mean an http server. I don't know if it is configured as a proxy or not but I imagine that could be one option. And it starts to make more sense if that is indeed the case.
AFAIK, javascript file is also served from memory. The file doesn't exist on disk, and there is no logging of the request.
And I was reading the finjan report literally. Their report is a PDF that you can download and it states both the following ...
Malicious javascript hosted on the legitimated website server (server B)
...
The Trojan executable is hosted on the same legitimate website server (server B)emphasis added
So the request is checked to see if you've already requested once before, if not it inserts a <script> code block to include it's own file from your server. The file is indeed hosted on the server, according to the report. The question is how? I guess it could be that the file is "hosted" by being loaded in memory or something rather than in the filesystem itself but we haven't seen any of that detail offered, not yet at least. Like I said, I read the finjan report literally. The Javascript file is requested and returned at which time the trojan which is hosted on your system is pulled down as well. Then the end user compromise begins.
Thinking out loud here now ... if the Javascript file is indeed hosted on the compromised system in the filesystem and your HTTP server is handling the request, it is going to serve up that file the first and only time it is requested. And if your HTTP server is handling the request, which I think it would have to be (think dynamic sites and other configuration options that have been setup and/or modified on the fly that would have to be taken into account on an http server), then your mod_rewrite process would be invoked first. If that happens, the code above would indeed work.
But then again, perhaps your server is only handling part of the requests? A properly configured proxy would allow your server to do it's normal job and route the request for the Javascript files elsewhere. But I wonder how it is doing that? I mean, what if a legitimate Javascript file existed with a similar name as that being requested maliciously? I suppose they invoke their own RewriteRule at that point ... makes sense.
and there is no logging of the request.
How do we know this for certain?
Senior Member from KZ
joined:Jan 10, 2005
posts: 2938
votes: 24
I wouldn't put to much value on the Finjan report. It has been written by a sales representative telling how good they are and why you need their services. It is all sales talk there. So if there is the word "hosted", it could just as well mean "on the host", or "from the host", "sent by the host" or whatever.
For average users it is very difficult to detect if a proxy is running and masquerading httpd. You don't need a lot of code to transparantly intercept all traffic to and from port 80. the utility doesn't need to do any routing, rewriting or whatever, just reading and writing packets from port to port and restarting the Apache server on another port. Furthermore you only need two lines of code in a C program to start a program from the executable /dir/somename and put it in the top and ps listings as /otherdir/httpd. To make it invisible for administrators who scan the list of running processes.
With all the knowledge available now, I would say it is a memory based proxy frontend, not a second webserver.
Administrator
joined:July 31, 2003
posts:12548
votes: 2
I did quite a bit of hunting and calling over lunch today to try and find out more details. I have a verbal confirmation from a trusted source that has had some first-hand experience with this vulnerability that the file does not exist on the filesystem nor does it show up in the logs. There is no reason for me to doubt this source and therefore the mod_rewrite solution here is not going to work to prevent the spread of malware to your visitors if your server is compromised. At least not in this particular case.
The vulnerability is at least a couple months old now. One thing this thread has forced me to do is get a little more current with the latest vulnerabilities. For those that are interested and/or want to be more informed, get yourself on a mailing list from one or more of the following:
[us-cert.gov...]
[securityfocus.com...]
Join The Conversation
- Register For Free! - Become a Pro Member!
- See forum categories - Enter the Forum
Moderators and Top Contributors
- Moderator List | Top Contributors:This Week, This Month, Mar, Feb, Archive, Top 100 All Time, Top Voted Members
Hot Threads This Week
- Google Updates and SERP Changes - April 2018
- April 2018 AdSense Earnings & Observations
- Google AdSense: Expands "Funding Choices" To Replace Lost Revenue From Ad Blocking
- What Makes Good Web Content Today
- MauiBot
- Google Updates and SERP Changes - March 2018
- Chrome 66 for Windows, Mac and Linux Rolls Out
- Facebook Goes for World-Wide ToS Changes
- Mozilla: Internet Health Report 2018
- How About an RSS Revival
Featured Threads
- Facebook Goes for World-Wide ToS Changes
- Chrome 66 for Windows, Mac and Linux Rolls Out
- Google AdSense: Expands "Funding Choices" To Replace Lost Revenue From Ad Blocking
- What Makes Good Web Content Today
- Mozilla: Internet Health Report 2018
- Facebook Launches Data Abuse Bounty
- How About an RSS Revival
- Webmasters: Distrust of Symantec PKI in Chrome 66
- A Directory is a Utility far more than it is a Business Model
- Mozilla Readies Virtual and Augmented Reality Browser, Firefox Reality