| This 37 message thread spans 2 pages: < < 37 ( 1  ) || |
|Shut down "Random JS Toolkit" exploit|
| 3:27 pm on Jan 17, 2008 (gmt 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.
RewriteRule \.js$ - [G]
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.
| 12:59 am on Jan 28, 2008 (gmt 0)|
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.
| 1:22 am on Jan 28, 2008 (gmt 0)|
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.
| 3:31 pm on Jan 28, 2008 (gmt 0)|
|The JS (not using it) point is a moot point |
We all have pretty much been forced fed with Ajax
While at it take a look at CookieSafe, does the same for cookies, with the same handy interface.
| 3:37 pm on Jan 28, 2008 (gmt 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.
| 6:51 pm on Jan 28, 2008 (gmt 0)|
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:
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.
And I was reading the finjan report literally. Their report is a PDF that you can download and it states both the following ...
The Trojan executable is hosted on the same legitimate website server (server B)
|and there is no logging of the request. |
How do we know this for certain?
| 7:51 pm on Jan 28, 2008 (gmt 0)|
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.
| 9:19 pm on Jan 28, 2008 (gmt 0)|
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:
| This 37 message thread spans 2 pages: < < 37 ( 1  ) |