Shut down "Random JS Toolkit" exploit

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.

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.

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.

>> 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?

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.

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