Welcome to WebmasterWorld Guest from 107.23.176.162
Forum Moderators: Ocean10000 & phranque
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]
Jim
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.
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.
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.
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?
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.
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...]