homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / Apache Web Server
Forum Library, Charter, Moderators: Ocean10000 & incrediBILL & phranque

Apache Web Server Forum

This 37 message thread spans 2 pages: 37 ( [1] 2 > >     
Shut down "Random JS Toolkit" exploit
If you don't have to use external JavaScripts

 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.

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.




 5:41 pm on Jan 17, 2008 (gmt 0)

Thanks, Jim, for this suggestion (which I'll put in the virtual server config).

A stupid question, perhaps: is there any likelyhood that the malware would execute before the ReWrite?



 5:53 pm on Jan 17, 2008 (gmt 0)

The mechanism is JS based, so it is executed client-side. In an effort to cover their tracks, the perpetrators create the randomly-named payload-installer JS file on-the-fly on the infected server itself, and insert an external JS include in your pages' HTML to load that randomly-named JavaScript. Therefore, the client will request the JS file from your server, and the rule will return a 410-Gone. I picked that response as having the 'least impact' to the client, since it is not the client's fault that it is requesting the JS payload installer from your server.

At any rate, if you have no external JS scripts --or only a few-- these simple solutions should at least prevent the payload installer script from downloading from your server if your server gets infected.



 7:41 pm on Jan 17, 2008 (gmt 0)

Another option here may be to log those requests for further analysis. So, instead of sending a 410 Gone directly from the RewriteRule you could internally redirect to a server-side processing program that further processes the request before sending the 410 Gone. If you find anything nasty, email (text message, etc.) yourself right away.


 7:50 pm on Jan 17, 2008 (gmt 0)

Jim, just to double check, by adding that, it won't affect site coded javascript like adsense and stuff will it?


 11:24 pm on Jan 17, 2008 (gmt 0)

What about redirecting instead to a beacon - like an empty or 1 character .js file. Then if you see requests for that beacon in your stats you know something's up. The 410 would also show in your stats but with a wide variety of file names it may not be a large enough signal compared to other noise out there.


 11:40 pm on Jan 17, 2008 (gmt 0)

Any externally-described, local, legitimate JavaScript file would need to be added to the "filter list" as jdMorgan explained. If your Adsense JavaScript is in an externally described file on your site then you would need to add it to the "filter list" as shown earlier.

As far as viewing the request in your stats, yes, you could do that too ... but I would rather opt for immediate notification and be able to analyze details I captured from the request as opposed to only that information captured in the access and error logs. The important part here is the timeliness.


 3:15 pm on Jan 18, 2008 (gmt 0)

Somehow I missed your redirect note coopster, yeah that's a step further than what I was thinking about.


 4:15 pm on Jan 25, 2008 (gmt 0)

This will only stop your users getting infected, if you redirected all .js pages to a php file which checks if it is valid and serves it. It could email you if an attempt is made for a bad javascript file.

At the moment a bad js file is anything that matches [a-z]{5} but since they have root on your machine they could easily flash update all the machines to serve the exploit in a different file or using a totally different method. Its best if you know ASAP that something might be wrong so you can fix the root cause.


 4:53 pm on Jan 25, 2008 (gmt 0)

Cpanel has posted the most information on this that I've seen here:


Kudo's to them for this - I have seen them wrongly accused as the source of the compromise.

The fixes above are unlikely to work. This thing overwrites httpd in memory, and does not log these requests. I highly doubt that it will get to mod_rewrite in the module list, and it certainly won't show up in your stats.

The only 'tracking' that you could do, woudl be to do a periodic tcpdump for the requests as is described on the cpanel page.

This thing is very clever and well implemented. It will only serve the js once per IP/domain, and nothing shows up in the access log. It is affecting fully up-to-date boxes, and I suspect using a yet-unknown vulnerability to get root access.


 6:07 pm on Jan 25, 2008 (gmt 0)

How might I get infected with this malware, and how would I detect if my pages have been injected with it? From the description at Finjan, I'd count on seeing some unusual <script> with a random-looking "src" being included in my page output.


 6:13 pm on Jan 25, 2008 (gmt 0)

How might I get infected with this malware

The scary thing about this, is that no one knows that yet, despite the fact that it has infected 10's of thousands of sites.

how would I detect if my pages have been injected with it

One is that the first request you make to your site may or may not have a <script> tag inserted into it. IF it does, it will only have it on the first request your ip makes. Other than that, doing a tcpdump as described on the cpanel page, or booting to safe mode with a system rescue CD and looking for modified files.

One simple but not 100% reliable thing you may do, is go to the page with IE, and look for an activex warning that you know shouldn't be there. Again, this will only be there for the first request of the IP, and then only randomly.


 6:21 pm on Jan 25, 2008 (gmt 0)

Anyone have a rule set for this exploit for Mod Security?


 6:42 pm on Jan 25, 2008 (gmt 0)

jcoronella and jdmorgan
thanks for those info
my server admin just ran the cpanel test
clean :)

since finjan has been mentionned I used it years ago
before they became what they are now

they have some good tool (client side) just d-loaded
and will activate it.


 8:33 pm on Jan 25, 2008 (gmt 0)

This is also a good reason to encourage more people to install the NoScript add-in for Firefox which pretty much eliminates the problem in the browser unless one of your trusted sites gets compromised.


 9:56 pm on Jan 25, 2008 (gmt 0)

From [blog.cpanel.net...]

The cPanel security team also recognized that a majority of the affected servers come from a single undisclosed data-center.

the cPanel security team believes that the attacker has gained access to a database of root login credentials for a large group of Linux servers.

The cPanel security team asserts that the Boxer variant includes a small web-server which is how the Javascript is distributed to unsuspecting users of any website on the server. It is believed that the Javascript include is injected into the HTML code after ApacheŽ has served the file but before it has traveled through the TCP transport back to the user of the website. The web-server is not loaded onto the hard drive directly but loaded directly into memory from the infected Boxer binaries.


 10:36 pm on Jan 25, 2008 (gmt 0)

The fixes above are unlikely to work.

Actually, I believe they will, from what I understand about this so far.

This thing overwrites httpd in memory, and does not log these requests. I highly doubt that it will get to mod_rewrite in the module list, and it certainly won't show up in your stats.

It loads it's own httpd server in memory, yes, but from what I understand only to inject a Javascript include into your HTML after your Apache server has finished it's job and sent the file out. After the httpd-in-memory-server finishes up it's little edit, it pushes the page on through to the end user. Then the end-user compromise starts. The included Javascript file is requested from your host ... 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. Your Apache server looks up that file and sends it off, just like any other request, right on through mod_rewrite, etc. Therefore the request should still show up in your logs. The only thing is, it is a one time deal. You are only going to see a request for this particular js file once. After you dish up the malicious Javascript, the end user is redirected to the *bad* site(s) and it could very well start getting ugly for your end user.

I have indeed read that there is an httpd server in memory but the only information I have read so far is that the requests are being modified on the way out, not coming back in. The compromised user's IP address is stored on the server so the code checks against that file before modifying the HTML being served again. If the IP is found, the HTML is not modified this time before being passed along.

If there is any information to the contrary I have yet to review it.


 10:47 pm on Jan 25, 2008 (gmt 0)

Man...while I obviously find this unethical, illegal, etc. I am impressed with the ingenuity of those that created this exploit.

Most exploits are easily identified, but the lengths the creators of this exploit went to to obfuscate it are impressive.

If only these people would use their skills for something other than making other people's lives a nightmare and making some cash...


 11:03 pm on Jan 25, 2008 (gmt 0)

--- a majority of the affected servers come from a single undisclosed data-center --

I want to lknow WHOs


 11:10 pm on Jan 25, 2008 (gmt 0)

loaded the finjan tools (IE and FF)
does not cause any trouble or extended loading time
(that I can feel)


 8:36 am on Jan 26, 2008 (gmt 0)

my server admin just ran the cpanel test

henry0, how is the cpanel test run? (Where do I navigate to, to run it on my server?)


 12:18 pm on Jan 26, 2008 (gmt 0)

jake, I cannot be of help, sorry, I asked the network admin to review the Cpanel article
in light of it they ran the test
My servers are where used to be hosted WebmasterWorld

Try posting on a cpanel forum

or even start another thread here in case no one has your answer


 12:55 pm on Jan 26, 2008 (gmt 0)

From the cpanel security alert:
The vast majority of affected systems are initially accessed using SSH with no indications of brute force or exploitation of the underlying service. Despite non-trivial passwords, intermediary users and nonstandard ports, the attacker is able to gain access to the affected servers with no password failures.

What it looks like is that information only known at the provider's level is used to gain access to the system. Or there is a major vulnerability in the SSH server which is not discovered yet.

Although I appreciate jdMorgan's efforts to minimize the current effects by reconfiguring Apache to not allow JS files, or at least restrict their use to a whitelist of trusted filenames, this will only be a temporary solution. According to the cpanel article the attackers seem to have easy root access to the infected systems and have infected a number of system files which may contain additional backdoors for them to install enhanced versions of the software.

To prevent this kind of attack you should take other measures IMHO.

  • Stop using control panel software and learn administring your server on the command line.
  • Uninstall your control panel software, because you not using it is not preventing hackers from using it.
  • Disable password and interactive access to your SSH server and switch to keys if possible. (This is no option for people who access their servers also from untrusted systems where they don't want to have their key files installed like me)
  • Disable access to your SSH server from all IPs except from a handful of IPs that you might use to attach to it.
  • Disable access to your SSH server from all IPs of your hosting provider, including IPs from the support helpdesk. My experience is that many SSH attacks come from nearby servers, probably because they are bypassing intrusion detection systems which most hosting providers have only placed on their main internet pipes. Disabling SSH access to the helpdesk of your hosting provider may sound strange, but my experience is that they will always still have access via a serial console, direct console or in emergency situations can reboot the server in single user mode or from an install disk.
  • Disable root access via SSH. Instead, use an intermediate user with low access rights that has to use su to become root.
  • Give the intermediate and root users different and difficult to guess passwords.
  • Let all needed processes with possible open TCP or UDP ports (httpd, mysqld, ntp, bind, sendmail, etc) run under low user-rights usernames (different usernames for different processes), don't assign passwords to these usernames and disallow them in your /etc/ssh/sshd_config file.
  • Upload your webserver scripts (HTML, PHP, JavaSript etc) under a different username than the Apache server is running on. Give the Apache user only read access to those files and their directories to prevent script modifications cia URL injections. Many open source packages have very bad behavious in this matter, as they need the Apache server to have write access to config files. In that case give temporary write access to those files while installing or updating your configuration, and make them readonly afterwards.
  • Use shadow passwd files (the default now on most distros) so no encrypted password viewing can be done by users without root rights. For example a simple PHP script can--even when running as a non privilidged user--with a simple include statement show the contents of your /etc/passwd file to a hacker.
  • Switch from the orignial DES encryption to MD5 encryption for your passwords. (default now on most systems). DES is easier to decrypt and MD5 allows passwords longer than 8 characters.
  • Change Linux user passwords only via the passwd command in a SSH shell, not via any control panel software as it may be fished.
  • Uninstall the wget package from your system as wget is one of the main commands to load infections on your machine. There are alternatives like sftp or rsync over SSH that you can use for data transfer between servers.
  • Only tell your intermediate user and root passwords to the hosting helpdesk on the moment you ask them to do work on your server.
  • Change passwords for the intermediate user and root as soon as the helpdesk has finished their job. Again, remember that in emergency situations they can always access your server via the console in single user mode or with an installation CD. No need to have your passwords on file with them.
  • If your hosting provider gives you a freshly installed server, stop and uninstall all services that you don't need. You will be surprised how many webservers are provided with bluetooth, PCMCIA, NFS, Samba, NIS, mouse drivers, X font servers and other tools enabled by default, which are handy in a desktop or corporate office environment but may be a security risk or potentially cause instability in an internet server configuration. Remember, on Redhat and Fedora systems, yum remove is your friend. Other distro's have similar commands to remove packages permanently from your server.
  • Update your system regularly with the newest tools/versions.
  • Check regularly with the command netstat -nlp as user root which processes are listening to TCP and UDP ports. Write a list down after first installation. Every change you see may be a backdoor installed by a rootkit.


 3:02 pm on Jan 26, 2008 (gmt 0)

Excellent advice, lammert. Thanks for taking the time to throw out a list. I spent some time on the phone yesterday with an admin, a real tech-head, in regards to this particular exploit. Although not a lot of information was offered, one point came through quite clearly ... the JS part of this exploit is merely one angle. Yes, root-level access is being compromised but nobody is stating how yet. Either they haven't figured it out or worse, they have figured it out and they don't know what to do yet. If they have figured it out you would think the news would be all over the place though.


 5:54 pm on Jan 26, 2008 (gmt 0)

Just out of interest, does this mean Windows-based servers are currently more secure than Linux, etc?

lammert said
Uninstall your control panel software

What I know of this stuff, I could easily write on the end of a matchbox, nevertheless, this comment puzzles me. Are not control panels merely graphical front ends? It seems unlikely to me that a GUI could ever be used to compromise security (unless it introduces non-GUI libraries that can be accessed remotely).



 7:37 pm on Jan 26, 2008 (gmt 0)

A control panel is a graphical frontend with a high level of access to vulnerable parts of your server. As long as the control panel software is bug free, there is no reason not to use it, but unfortunately no control panel manufacturer guarantees that their software is bug free. Furthermore you can't always be sure that you are using a genuine version of the control panel, or that it is actually a modified version which not only performs all the tasks you want, but also logs them (including logging access details for your server).

I am not saying that a control panel is a security threat itself, just as httpd, mysqld, sendmail and all the other packages I mentioned in my post are no security threat by themselves. But they are all an extra hook that hackers can attach to and may try to exploit. Reducing the number of doors to your server, and using only doors that are not feature rich, like a SSH shell server with only protocol 2 allowed with key authentication and limited allowed IP addresses reduces the risk that a hacker finds a hole.

I know that no system is totally hacker proof, and even if it was, it could still be compromised by compromising systems that are in the trusted environment of the hacker proof server.

For example, I don't want to think about the situation where a hacker manages to upload a new openssh version to one of the redhat, centos, fedora, debian, ubuntu or any other linux clone repository.


 2:36 am on Jan 27, 2008 (gmt 0)

Since there is nothing inherently insecure in the concept of a GUI control panel, random bugs are unlikely to compromise security. If its a fake (logging stuff) then the system is already compromised.

It's far easier to fake a command-line tool than a complex GUI tool. Also, monitoring keyboard activity is easier than monitoring a mouse/GUI - this is why some online banking services provide dropdown lists in order to enter password data (with instructions to only use the mouse).

If administrators only know how to drive their servers using a graphical control panel, then they might be better sticking with that method rather than make mistakes using command-line tools.

I think several points need to be emphasized for webmasters and users (rather than server administrators)...

  1. Without javascript (or maybe ActiveX stuff) end-users cannot be affected so it is worth running without javascript and its also worth ensuring sites work adequately without it.
  2. Many exploits rely on buffer overruns. These can be disabled by enabling Data Execution Prevention provided you have XP-SP2 or Vista and a modern CPU. (Software DEP is almost worthless.)
  3. Firefox and Opera probably have fewer vulnerabilities than IE.
  4. Vista UAC was designed for this sort of scenario so if you have it switched off and normally browse as an admin, it's time to switch UAC back on.



 12:19 pm on Jan 27, 2008 (gmt 0)

The JS (not using it) point is a moot point
We all have pretty much been forced fed with Ajax
Even I resisted a long time but surrendered to Ajax
I remember when we used to say that we almost needed to dev without JS due to many users disabling it, I do not think that is still a valuable statement since Ajax has conquered the scripting word.


 2:48 pm on Jan 27, 2008 (gmt 0)

Kaled, I would like to remind you that the Javascript part is only the transportation method of the symptoms of this malware, rather than the source. The source are infected linux based webservers. Just as with human diseases, in order to fight a disease you should try to fight the source, rather than the symptoms.

Reducing the symptoms in the period that the real source has not clearly been detected yet is good because it may reduce the speed at which it spreads and reduce damages, but the only effectrive solution will be to close the holes the malware used to infect the current webservers.


 4:20 pm on Jan 27, 2008 (gmt 0)

I agree that javascript is merely a "transport medium", however, without it, hackers would need to rely on bad static content (the only known examples being bad images - a fault that is now patched on uptodate systems and, I believe, was not shown to affect Mozilla browsers). So far as I am aware, badly formed (x)html has not been exploited for hacking. Also the "symptoms" represent the motive for this hacking - without them it would be largely pointless (but server-bots would have some value to criminals).

There are two points not discussed in the finjan report (unless I missed them) that server admins should consider...

  1. It is likely that compromised servers can also sleep i.e. behave entirely normally until commanded otherwise.
  2. It is possible (perhaps likely) that there are bad CDs out there and reinstalling from such a CD might cleanse a system temporarily, but only until it is reactivated, perhaps months later.


This 37 message thread spans 2 pages: 37 ( [1] 2 > >
Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / Apache Web Server
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved