Care to divulge which three?

"The script looks for various vulnerabilities specific to the visiting OS"

Does this mean that non-Microsoft Operating Systems are also affected?

I was worried for a moment then realized that this primarily only affects those poor saps that insist on running mission critical stuff on Windows/IIS. Have fun! It's getting boring keeping these Linux/Apache/MySQL/PostgreSQL servers humming along (months without a reboot, yawn).

Just based on the look of the websites involved... painfully old versions of various bits of system software?

"I was worried for a moment then realized that this primarily only affects those poor saps that insist on running mission critical stuff on Windows/IIS."

Um, as much fun as Windows bashing is, make sure you at least sound credible:

"They don't use the same web host, and while most use web serving software from Apache, the versions vary widely, making it unlikely that attackers are exploiting a vulnerability in that program."

Seems that Kaspersky is one of the 3 anti-virus programs thats blocks the malware. Not sure on the other two, but will keep looking.

Hello,

It's a variante of Exploit.HTML.IESlice.h and Exploit.HTML.IESlice.p

Exploit different QuickTime vulnerabilties and America Online SuperBuddy ActiveX Control "LinkSBIcons()", NCTAudioFile2, etc.

Regards.

http://www.webhostingtalk.com/showthread.php?t=651748

"Victims are unlikely to know they've been infected because the installation is clear and seamless, and the malware uses few PC resources."

Maybe Bill Gates should get in touch with these guys before he retires. Clear and seamless installation, use of few PC resources...

The only really common server platform vulnerability I can think of that may not not be patched for reasons of backwards compatibility belong to Python thats not to say there aren't any but that one stands out as many scripts are popular and will simply not run on the latest version. Don't go by what I say I am often wrong. Off to check the sites then.

Checking random sites from the list on uptime.netcraft.net, looks like they're all running Apache 1.3 and PHP 4.4 (although these arent technically EOL). I didn't see any with 4.4.8 (latest version). Who knows what other unpatched PHP software/modules are on there. Even Linux needs security updates once in a while :P

Romang: That's the exploit used by the compromised site to infect the PC of the visitors. It still doesn't explain how the sites themselves have been compromised. Obviously via some kind of common exploit in their setups - but which one?

I know I just went through a critical Perl update a couple of months ago on my webserver , if not done cPanel and other associated server side software wouldn't update either

"Mom and Pop" websites ? .. does this perhaps mean they are using cheap shared hosting or webhost reseller packages without proper WebHostManagement licenses(?), and therefore aren't being updated daily, rarely, or not at all(?) ... plus the server ops not giving a rat's ass

was there years ago, alot of crud webhosting and reseller packages out there .. once found some very bad stuff in the files of 1 site (of about 25 I had hosted on a cheap reseller package out of Canada) ... very poor administration and security ..cheap is cheap might be the common thread

just another thought

Are we assuming that these are Linux hosts because they're using Apache and PHP?

Apache and PHP also run on Windows.

I hope the illustrious person researching this, has been good enough to inform the aforementioned website owners that their domains have been "got at"...!

Of the hosts that responded with a "Server" HTTP header, all of them had mod_bwlimited/1.4 installed. Versions of Apache, PHP, etc varied. It looks like most of them are old cPanel installations (mod_bwilimited was widely included with that).

My suspicion is that someone broke in via SSH (probably using brute force) and then built a new mod_bwlimited module after gaining root (via an old exploit, as these systems all seem to be quite old). All of the hosts seem to have SSH and just about every other service imaginable open to the world.

The Javascript is not always embedded in responses (it seems fairly random), and the random nature of the js filename suggests some server side scripting to generate the name. Since the majority of the pages infected are plain HTML, I believe the malicious code is embedded in one of the Apache modules.

Nothing to do with the Fasthosts break-in last year then?

How many companies will have a) checked their content once they'd got access to it again, or b) fundamentally updated it / replaced it since November?

ref:

http://www.theregister.co.uk/2007/10/18/fasthost_police_hack_investigation/

It's trivial to download the javascript file using wget.

I hope she meant "impossible to get access to the bit of script/code that generates the polynamed.js script" otherwise this might explain why it spins out of control.

As mailed to the author of the article, perhaps the solution is far simpler than a mysterious cross-platform exploit.

The infection occurs on multiple server platforms but all on small to medium sized business sites. The kind which a web developer would create on their desktop PC then FTP up to a shared hosting server.

Could the infection method be via stealing cached FTP passwords from (easy to compromise) desktop systems and then FTPing the infection code up to the site? Not too hard to search for index.html on a server and insert a <script> tag in the <head> block.

Only puzzling thing is the (psuedo?)random name of the Javascript file - although this could just be half a dozen different copies of the same script uploaded as a static file under different names?

Lots of small UK sites -- online florists, specialist travel agents, that sort of thing -- over the last month being detected by our Bluecoat ICAP with Sophos signatures as Mal/ObjJS. But the reported URLs don't end in .js.

I don't really pay enough attention to what gets stopped -- makes me a bad citizen I suppose.

But it's nice to have figures for my "no site is really safe" educational campaign....

Hi,

I am the owner of this site and noticed it mentioned and found there was indeed some fishy actvity although my own AVG and antivir software do not detect any thing how ever I spoke to the hosting provided and it seems it is a bug in apache and now has been resolved at least on our web site.

Jamal

A) Client machines has Apple Updater installed (usually via QT)

B) infected servers are smalltime servers that probably aren't quite uptodate on SSL libraries

C) Infected servers have mod_bwlimited/1.4 installed.

Methinks the infection started with someone engineering a .mov that scripts downloading the server-infecter and backdooring code.

Solution: Avoid quicktime (and it's evil twin iTunes, since the latter gets force-downloded as soon as apple-updater has a chance to spoonfeed it to you!)

//Svein

(who really enjoys not having slowtime installed)

It was Dan Goodin that made the "impossible" remark. And it very much implied that it was difficult to get at the javascript because it kept changing its name.

However I've just found some more intriguing behaviour; on the second wget to the same site (having picked another one at random) the .htm file doesn't contain the link to the .js file. Followed those two with a wget to get the .js, but found that a second wget to fetch the .js got 404'd.

I assume from this that it's keeping track of IP addresses and making sure that only one copy of the .js gets delivered per machine.

Sneaky.

At first Jamal, your site is still infected:

body onload="initDate()";>------- language='Java------' type='text/java------' src='bjkwq.js'>--/------->

------------Dubai hotels, Tours, Desert Safaris

and online hotel reservations. Lowest Rates Guaranteed------

( Sorry I have to sanitize severely, else it won't post )

For info the js attempts 8 different exploits ( which can work probably only on windows desktops ).

The virus is smart enough to attempt the exploit only once per ip address.

Then, all these sites run linux. Many post here show clearly the real problem with security on linux: too many users deny the problem even exist. No matter the facts, all the blame is rejected on admins, windows, "end of life" , specific distribs... They boast about "no reboot for so long.."..

Linux users should accept that security is also problem on this platform, and because of the success of this platform they have too deal with users like Jamal who search worms on their server with AVG on their windows desktop..

So now I've got two copies of the .js; they differ in one line:

< var arg="qgenahfr";

---

> var arg="dqwejbdj";

arg is appended in the script to the hostname thus:

www.example.com/dqwejbdj

and again it's a one-shot download - the second GET is a 404.

The download appears to be a Windows binary - I ran "strings" on it and it's full of this sort of thing:

KERNEL32.DLL

ADVAPI32.dll

LoadLibraryA

GetProcAddress

This is certainly an interesting one. Initially I thought it must be an Apache module that had installed or doctored which was inserting the code into the pages, I've certainly not seen anything like this working at kernel level before.

This doesn't appear to be that difficult to write signatures (or heuristic rules) for though, the exploit xxxxx.js files are all the same across domains other than the filenames and the very first line of the file 'var arg = '

Looks like a bit of a pain to clean up your server though - especially given that chkrootkit doesn't appear to find it according to that WHT page.

So now, how will the "community" react?

Those who have the chance to find someone like "Scott.MC" from WHT will have their servers cleaned, one by one, manually. Those who will get the help of the very many "linux-tech" from WHT will just reboot / reinstall endlessly, keep on serving viruses, and complain about "frontpage virii"..

Will Redhat release "critical updates" like the "Malicious Software Removal Tool" or will they just say customer should migrate to RHEL5 with SELINUX enforced ( ok, "targeted" is enough for protecting /dev/mem I think )? What will happen for the other (non commercial) distributions? How many linux admins will be able the fix the systems they manage?

This has gotten me thinking now. Following a bit of Googling for 'trojan kmem kernel' I've found a number of forum posts reporting very similar issues:

Here for instance: http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/27857

As one of the posts I've read [somewhere] says, inserting the malicious code through an Apache module would be extremely straightforward to do, though having a kernel module doing the same thing (although much more complicated to write) would be much harder to detect (it's got us talking!) and much more difficult to remove - half the problem being to know what you're looking for.

It looks like an evolution of the code on that xpire.info link I posted above which inserted an Iframe into the page; in that now the compromised server is hosting the whole shebang. It also shows hallmarks of a modern web attacks:

1) Hiding from sys-admins trying to remove it in order to remain active as long as possible

2) Giving researchers the run-around by only exploiting once per IP

3) Using a number of published exploits in order to get a binary onto the target machine

4) Obfuscating the actual exploit code through various means to try to prevent static/automated analysis

It's certainly not 'randomly' inserting the code into the page / serving the exploit. It's doing it once per IP, once you've had your fill of exploit then there's no coming back for seconds. Randomly inserting the code would be pretty silly - some people (potentially AV researchers) would get multiple copies, whilst others wouldn't get it at all. Some people may visit multiple pages within the same site - thereby giving further chances that they may randomly encounter the exploit, whereas others may visit the homepage then move on. Serving the malicious code once per IP gives everybody a fair shot at getting infected whilst slowing researchers down at little.

Unlike Storm and similar the server isn't generating the obfuscated exploit code on the fly. The server contains a static copy of the trojan and the obfuscated exploit, with probably a simple string replace on the "var arg = xxx". This means that every copy of the xxxxx.js file is identical across all servers and all domains. As posted on the WHT forum page, there are no traces of the .js files on the server - these are obviously being generated on the fly. There is obviously quite a bit of keeping state happening on the server though - who has downloaded the files already? what filename did I tell this IP address to use? (unless it's a hash of some sort), I would guess this is stored in a file somewhere on the system (which the rootkit is then denying the existance of).

It would be interesting to know how the trojan infected the servers in the first place, given that in order to install either an Apache module or a kernel rootkit would require root privileges. Could this be a buggy PHP script with some fancy privilege escalation or has the attacker somehow SSH'd into the box? I guess the only way to answer these questions would be to get hold of a compromised box and hope they didn't clear the log files out.

It would be interesting to look at the rootkit itself though - modifying Apache replies on the fly can't be the easiest thing in the world to achieve.

Too many google hits for .cfm files on those sites. Ill bet a fiver on a new coldfusion remote exploit.

An exploit in APACHE? Good grief Charlie Brown, does this mean LINUX MIGHT NOT BE SO SECURE AFTER ALL? Sorry for the caps, but I really had to yell that.

And the exploit hook on Windows OS machines (well, you want to attack the majority, thats Statistics 101) invloves APPLE SOFTWARE? NO! THE MIGHTY APPLE IS INFALLIBLE! Well, thats what Mac-fanbois always yell...

All computers are exploitable, so long as most of the people writing software keep looking for the shortest, easiest quickest dodgiest ways to do things; lucky we don't build physical infrastructure with such easy exploits, like tram systems!

No, wait....

If Dubai (above) has an infected server, let him back it up and make the files available.

Have lemons ? Make lemonade !

Edmund

> An exploit in APACHE? Good grief Charlie Brown, does this mean LINUX MIGHT NOT BE SO SECURE AFTER ALL?

Yes, an exploit in Apache... no, it doesn't mean that it's fundamentally more secure than Windows... after all, there will always be Linux exploits, but there will never be Linux viruses... let's not go through all the FUD again, let's just agree that no-one has yet, in the last decade, claimed the thousands of pounds that has been on offer from Netproject for anyone who is able to infect one of their properly-configured Linux machines with a "virus".

Get a real multi-user operating system.

avast! picks it up with no problem at all....

Why oh why does everyone still keep linking Apache/PHP as "Linux".. Even if there is an apache or PHP exploit, its not the O/s to blame, its a fault in the application layer. Apache runs on windows too.

I see some of you trying to find commonalities.

Doesn't it occur to you that if an exploit checks the OS to see what it is vulnerable to, in the same vein an exploit of webserver software could also have a similar plan so the only commonality would have to be that someone is looking to hack them for some reason.

(Most likely one of two things)

1) Create a new bot army for childish reasons.

2) Cause general chaos, regardless of whether it be a PO'd individual, group, government, or company looking to make the competition look bad.

Yawn, same story different day, only thing different this time is more forethought before the attack. IOW, you don't put all your apples in one basket if you want to survive someone else shutting things down.

I don't care if I look dozy because operating systems and desktop software are not my field at all.

On my home PC, I always refrain from surfing with administrative privileges. I only do it if I'm trying to use WindowsUpdate.com or something like that. I also allow IE7 to block add-ons and do not run them unless really necessary. Does this mean my PC is unlikely to be infected, or does it make no difference?

Secondly, I have a small website hosted on which I update from the same desktop using WS_Ftp. How can I be sure whether it is infected or not?

Sorry but this is a release from a company that makes money scaring people into buying their product.

It could be that at any given time it is normal that 15% comes from a few hundred sites?

Seems like criminal packages client exploit, criminal picks server vulnerability to exploit (usually old software for which a security updates has existed for month), criminal infects several hundred sites ......

Outbreaks like this could be the norm.

The only thing new or clever is maybe renaming the .js file so you just find all the sites with evil.js and then know they were infected as part of the same attack.

That'll teach me not to get up until lunch :o/ Seems all the domains listed have been scrubbed and are (with the exception of reallybored.com which prolly actually gets some traffic) showing cPanel holding pages.

I mean Jesus - web hosting support staff working on a weekend?! Who'd a thought it?

The domains seem to be spread across a number of hosts, although it is of course possible that some of those hosts are resellers and it's one parent host that has been exploited. Probably not tho - I would bet 50p on it being an automated cPanel exploit.

Oh well, no reversing on a quiet Sunday afternoon for me :o(

> An exploit in APACHE? (...) does this mean LINUX MIGHT NOT BE SO SECURE AFTER ALL?

Apache != Linux, dum-dum.

It doesn't serve the JS once per IP. I automated 100 requests to three of the sites listed (whilst they were still running) and the JS was inserted between 3 and 10 times on each. Interestingly, the frequency of which it was present declined as the number of requests increased (i.e. it was always there on the first, then usually the third, then the tenth, then maybe around 20-30, etc...).

I agree that there will be some kind of hash table storing information about recent visits, but I imagine that it's probably an in-memory table, and not likely one that you'll find on disk anywhere.

I too would be interested in having access to a compromised server (not that I'm volunteering one of my servers!!)

Ok - I am no good on these things - i just keep my av running and pray.

BUT - How long has it been since an attack came out on the source of software.

There were supposedly two bad code problems that came out of suppliers on original cds THIS WAS BEFORE WWW. One had gotten on a machine because the programmer took his code to a trade show it was infected there and then was put in production.

What I am getting at is a contaminated source for the download of Apache or an associated program. Mom and Pop sites could have gotten downloads instead of original CDs. Only one alternate download site need have been contaminated or rerouted to China or something.

Just a thought - paranoid but it matches the criteria - different hosts etc

AC says: > Why oh why does everyone still keep linking Apache/PHP as "Linux".

I agree, but let me fix your phrase, which clearly comes from the heart:

"Why oh why do people that can't distinguish an operating system from a webserver spend their time posting here instead of reading Computers For Dummies instead". To say nothing of cretins who in some incomprehensible manner suddenly bring up Red Hat (?!??!).

Token effort at saying something intelligent:

Article says the infected sites are "generating an enormous amount of traffic". I imagine that this is not only due to visitors visiting said sites. Does this mean that the "sites" in question do lateral attacks, i.e. that the hosting machine has become a general attack platform (aka. roach motel).

(Image of His Holy Jobsiness just for the hell of it)

http://news.bbc.co.uk/2/hi/technology/7183008.stm

Dont know if there's a connection or not ?

Just look for a malicious .htaccess file in the root directory thats generating the random javascript.

I ran some scripts.

First I wget'd all 35 sites in the article. I did this 6 times and got a varying number of javascript references.

Run 1: 9 js

Run 2: 4 js

Run 3: 6 js

Run 4: 1 js

Run 5: 2 js

Run 6: 3 js

(Average % chance of catching the js file is 25/6*35 = 12%)

As described, all javascript filenames differ although "tezam" came up as per the article which means Im either very lucky or there's a round-robin or algorithm..?

The List:

cgolu.js czynd.js eenom.js eqfps.js erztp.js frpmg.js iggmy.js jiodm.js khkev.js kksyr.js kobgw.js kolqj.js lvmlt.js nrvaj.js oalhi.js pcqab.js tezam.js tfxep.js unolc.js vduoz.js vjytq.js wdnfn.js xihrj.js yrslu.js zouoq.js

Then I wget's www.peshawarjob.com/index.html 52 times.

46 times the filesize was 20834

6 times it was 20917, the extra bytes being the js reference:

eeeoc.js fsqnp.js fxpui.js ibumz.js qfkjh.js rajuw.js

6/52 = 11.5% by the way

wget -S showed a diversity of servers. * means "latest version"

Mostly Apache

6 Undefined

28 Defined:

2 Apache/1.3.26

5 Apache/1.3.37

5 Apache/1.3.39*

2 Apache/2.0.46

5 Apache/2.0.52

2 Apache/2.0.53

2 Apache/2.0.61*

4 Apache/2.2.6*

1 WebServerX (ie Apache)

27 UNIX & Linux with 7 Undefined

27 Defined:

7 (Red Hat)

20 (Unix)

13 PHP of 28 reporting

2 PHP/4.3.10

4 PHP/4.4.7

1 PHP/5.1.2

2 PHP/5.2.5*

4 PHP-CGI/0.1b

10 OpenSSL of 28 reporting

6 OpenSSL/0.9.7a

1 OpenSSL/0.9.7f*

1 OpenSSL/0.9.8a

2 OpenSSL/0.9.8b

10 mod_ssl of 28 reporting

2 mod_ssl/2.0.61

5 mod_ssl/2.8.28

3 mod_ssl/2.8.30*

Others (of 28 reporting)

9 mod_auth_passthrough/1.8

2 mod_auth_passthrough/2.1

11 mod_bwlimited/1.4

1 mod_jk/1.2.14

9 mod_log_bytes/1.2

(While doing this I got more js names:

arqmi.js bdjpm.js gljkm.js gtrmu.js ietnf.js lgvte.js oavnn.js pmglm.js qriox.js tdhse.js tzkuo.js urofu.js uvbvk.js wpjph.js wrfbn.js xcats.js )

All the names returned today are unique in 46 attempts.

I am not a security guru and this is less than scientific doesnt seem to point the finger at any single module. However, all instances are Apache so my guess is something is going on in Apache or lower down.

By using wget I was able to catch the js file 12% of the time, about 1/8th. It was happy to serve me multiple js scripts using wget.

When you get the js, it is basically 31K of escaped hex. When you run it in a safe place (ie unconnected sacrificial ubuntu with firefox) you see references to ActiveXObjects, AJAX, and something called "mosvs8.exe" - the JS_IESLICE. Heh. ActiveX. Again. Switch it OFF!

I think the .htaccess buffer overflow was fixed in Apache 2.0.51.

nice work, "mosvs8.exe" showing up on Google search now :(

Perhaps asking the site owners for an inventory of all software / patch levels from the boxes serving this content would allow for some cross reference? Perhaps Mary should consider this?

Personally I suspect some unpatched CMS may be responsible for this.

Many of these sites seem to be using SEF urls based on the category / title of the content you click through to i.e "homes-for-sale.htm" etc, and this is classic CMS behaviour. This would also account for the fact that there is no obvious pattern. Most CMS's based on PHP / Apache will run cross platform, and admins usually try to conceal the fact it's a CMS from the client browser and thus quite difficult to spot a pattern.

Hope this helps

//Steve Jackson

Security Researcher

Hmm...

http://news.netcraft.com/archives/2006/09/23/hostgator_cpanel_security_hole_exploited_in_mass_hack.html

I wonder if these servers have had their Cpanels patched in the last 18 months? I wonder if perhaps somebody's found another hole...

(Steve icon seems appropriate, seen he's been implicated in this too.)

Depending on the programming language - it'd be very easy to just have the contents of the .js compiled into the apache module.

then you just send a new header and the content of the file from within the module to send the file to the web browser.

As for including the file in the html, php files - it would again be pretty simple to amend the data sent to the browser. If it has got to move through apache - then it'll be a module there that is doing it.

As for infiltration.... Systems get hacked everyday.

What, no mention of "That IE for you"?

So does this attack punch through Opera and Firefox too?!?

I can second the remark about dodgy CMSes. I have had the dubious pleasure of disinfecting a machine which got infected by a rootkit, thanks to some badly-written CMS software (written in PHP, as it happens, but that's by the by). The problem is related to file upload by HTTP and the way Windows handles permissions. And it's not a problem with PHP per se, but with the way some people (mis)use it.

Every file on a Windows box has execute permission set. (This appears to be a designed behaviour of Windows.) If you do not perform a chmod on it after upload, it keeps its execute bit. (This is entirely to be expected, and any other behaviour would violate the Principle of Least Surprise.) And if you transfer the uploaded file to a directory from which the web server can serve pages directly to the outside world, it becomes a CGI script. (This is a designed behaviour of the web server: on a UNIX system, files with execute set are executed and their STDOUT stream is served up.) In short, by uploading a crafted script from a Windows host using a badly-written PHP script on a webserver, you can execute arbitrary code on the server.

A naïve developer testing PHP scripts on a Linux desktop machine with Apache + PHP installed (a very common environment for pre-deployment testing; always used to be a Windows desktop with Apache + PHP, but it's easier nowadays to get Linux up and running than it is to get Apache + PHP on Windows up and running) probably will not spot this, because files uploaded from Linux hosts usually do *not* have the execute bit set. Furthermore, development systems tend to be on the safe side of a NAT router and so will never end up getting the second half of the exploit (where someone gets in as root using a modified sshd.)

One possible fix would be for the PHP developers to add a third parameter to move_uploaded_file() allowing you to set the permissions on the destination file, and make this default to 644 if absent. Until then, if you're developing scripts in PHP, don't forget to chmod() uploaded files -- and it probably wouldn't hurt to put a .htaccess file in your upload directory, blocking all HTTP transfers from there. (Scripts can still see the directory because they are accessing the filesystem natively, not via http.)

But blaming PHP for this is a bit like blaming Severn Trent for drownings!

It is interesting that this new threat has appeared shortly after the disappearance of the Russian Business Network and when the Storm Worm is losing its power too, perhaps there is a connection to one or both. Presumably their operators are in need of a new income source and are among the limited number of people who have the ability and motivation to create this type of threat.

Also, albeit more tenuously, the RBN was believed to be routed through the UK, where this is focussed on too.

I dont spend all day doing this, honest...

Of the 35 examples (or the 28 that gave helpful header responses), none had the same complement of modules. They (the 28) all did, however, run different Apaches and PHPs which makes me beleive the problem is there (or in something that uses them as a pre-requisite, eg a CMS.

The js reference insertions were at various lines. Lowest is #4, highest is #223. However, in my 50-odd wget'd www.pehswarjobs home pages the inserted js reference is always at line 4. So it's not "programmed to move about". It pops up wherever it was planted - although that point clearly depends on where the attacker decided to plant it. Not that it doesnt randomly interrupt other HTML structures so some minimal "thought" has gone into planting it.

Line feeds are interesting...

In nearly all cases the rogue js reference was inserted with a preceding linefeed. This sticks out like a sore thumb in some HTMLs where there are otherwise no linefeeds. This makes me think someone on a Windows editor has inserted the rogue code into a file that is otherwise UNIX-like.

Checking out peshawarjobs, I see its a rudimentary CMS written in PHP. My guess is someone has found out how to insert content and has done so, cutting and pasting his rogue code from a Windows editor.

So look like Linux and Apache ARE secure, but there's no accounting for inexperienced PHP programmers.

> Every file on a Windows box has execute permission set.

Uh, no. Executability is implied by the file extension in Windows.

> If you do not perform a chmod on it after upload, it keeps its execute bit.

If you're using ftp, the server should have a UMASK 666 (or less) setting to prevent this.

> And if you transfer the uploaded file to a directory from which the web server can serve pages directly to the outside world, it becomes a CGI script.

No, in Apache that's the XBITHACK setting, which is not set in any default config I've seen.

One of my client sites was hit by a 20 minute scan Saturday morning, attempting just about every type of injection I can identify, along with both Windows and Linux directory traversal sites. Unfortunately I only have limited access to logs due to host configuration, so the only data I captured was via invalid querystring. I'm not sure what other avenues were explored.

I have a new cpanel apache serve rthat has this compromise. It had a few web sites on it. Very little else. My Guess so far is that it is a Cpanel issue, and that a rootkit has been installed.

Where do I start looking?

Javascript is scaped code, that once unescaped, writes the attack code in the page for then execute it. It tries several attacks called in file MDAC, Slide, VML2, QuickTime, SuperBuddy, AudioFile, GOM and WVF and executed in this order. If one works, the rest of the attacks are not executed:

if (startMDAC() || makeSlide() || startVML2() || startQuickTime() || startSuperBuddy() || startAudioFile() || startGOM() || startWVF()) {}

It seems that this attacks are for Windows (several of them use ActiveX objects) and none of them has worked in Firefox + Linux, and some of them try to inject payload code using some Javascript buffer overrun.

Of course, the point is not this Javascript but how the servers have been infected.

I hear that this virus can be identified with three anti-virus programs (including Kaspersky and AVG). Does anyone know what these vendors are calling the virus? It might help the rest of us determine if more anti-virus programs detect it. Or at least help us track when the one we're using *will* detect it...

this is funny. watch out

Thomas,

On WHT there is a competent guy who already cured the rootkit from several servers ( Scott.MC I think ).

No point looking here, just guys claiming "that there will never be Linux viruses" and that it is "an Apache issue".

Good luck!

My guess at the site vilnerability is that these "mom-and-pop" websites are copy-and-pasting dodgy example code from somewhere.

Scott.MC from WHT does NOT cure the rootkit - he knows how to clean up the exploit (which is serving the nasty js) from infected servers.

HOWEVER, every cleaned up box is STILL rooted and rootable as no one so far has determined how the hackers gain root access to set up the exploit in the first place.

I have tested 10 random urls from the article and each site is hosted on a cpanel server. If someone could set up a script to check all the reported infected sites and see whether they're hosted on a cpanel server that'd be great.

eg. if you can collect a list of say 1,000 known infected sites and write a script to see if they all answer on ports 2082/2083 (cpanel ports) we'd find the common link to this exploit for sure. My gut feeling says this is a cpanel-related root hole.

At least a cure for symptoms is far better than the disdain campaign we can see there.

If your site were a "roach motel" you can understand it is appreciable that customers do not see the roaches walking on the walls. And Scott.MC at least *knows* this is not an "Apache issue".

Then, the exploit was very probably installed via cpanel ( hostgator and many other sites had a wide infection last year ), and the hole is very likely to be fixed with a clean update ( if the exploit was possible in up-to-date versions, there would be tens of thousands of sites infected right now ).

Anyway Thomas Phillips would maybe give more info once he has been able to do some pest control.

ScanSafe have posted a report on their findings on their blog:

http://blog.scansafe.com/journal/2008/1/15/mom-pop-sites-hit-hard-by-host-compromise.html

It's definitely a kernel issue though - read the posts on the WHT forum which detail many people having the same issues - and all are running Linux.

Finjan are calling this "random.js toolkit" and have apparantly been seeing this since late on in 2007 - see here for details and a nice writeup by them. http://www.finjan.com/GetObject.aspx?ObjId=550&Openform=50

@Anonymous Coward:

People are linking Apache/PHP as Linux because all of the affected sites were running Linux! You've obviously not read over the WHT postings which detail those affected and whose servers have been exploited to serve this junk. What's more - it's not an Apache or PHP exploit (though some application layer stuff may have been used for the initial compromise), it's a rootkit which has buried itself deep down at the kernel. From what I've read it looks like there might be an unpublished flaw in cpanel (though I'm sure I've heard before that there are some lesser known exploits in cpanel) which allows an attacker to gain root on the box and install the rookit.

There's a simple solution to this. We need a kernel / GCC hack that basically will make it impossible for code compiled on one computer to run on a different computer.

Then all you, as a responsible sysadmin, need to do is build your system from the ground up -- exactly like a Gentoo Stage One install -- with this protection built-in. And, therefore, unable to run code compiled by anyone else. If you keep the gcc binary on a removable disk which you do actually remove when not in use, then nobody else can compile code to run on your system either.

OK, it's not perfect; because we have C-T Complete interpreted languages such as Python. And it means you have to wait a few minutes while packages are compiled. But at least an exploit in an interpreted language depends on the interpreter, which is more than you could say for a compiled exploit.

as a massive linux advocate I have to agree 100% here, there's no excuse for shoddy sys admin skills. Good firewalls, package updates and the regular round of sysadmin paranoia that someone is out to hack them are all good doses for us to take.

I've had countless old mambo installations hijacked by worms, running on linux, and apache. They are generally easy enough to remove because of the quarantine aspect of proper user separation (the apache user can't write to /bin). However this doesn't at all mean that the server wouldn't be trying to hijack other machines or visitors machines. The intrinsic security of Linux can only be broken by bad sys admins and all too regularly it is.

Had some time to play at last :o)

Gotten a hold of the .js and binary. Seems the binary is served in a similar fashion to the .js file - random file name that is deleted after being served.

The server exploit seems to be the one Matt Bradley above linked to. It's only usable locally tho so owners of affected domains might want to check their systems for key loggers. I really can't imagine the attackers bought a hosting account on each affected server, although it may be possible to execute the exploit through the "try before you buy" test account that some providers have...

Frankly if I were one of the users caught out by this, and my customers were being trojaned and it did turn out to be an exploit that was patched back in September 2006 I'd be fuming.

The binary is a 453k PE file. PEiD says it's packed with:

UPX 0.89.6 - 1.02 / 1.05 - 1.24 modified -> Markus & Laszlo [Overlay]

Going to have to find my OllyDB CD out to see what's inside.

"does this perhaps mean they are using cheap shared hosting or webhost reseller packages without proper WebHostManagement licenses(?)"

Not meaning to be rude here, merely baffled. WTF do you by "WebHostManagement licenses"? Is there some secret society which requires Web host owners to pay a licensing fee, an which so far has managed to miss noticing my hosting service?

Bang icon because there's no ? icon.

WHM is a software package (see www.cpanel.net) - there was a locally exploitable vuln in it in late 2006 that elevated the attackers privs to root. It was patched fairly swiftly, but those ppl running it without paying for it don't get support and so no patch.

No need to worry about the hosting mafia :o)

I am getting a number of hits when testing with NIS2008 from each of those sites. Some appear to have been cleaned up:

- Gretech GOMPlayer openURL BO

- MSIE ADODB.Stream Object File Installation Weakness

- VML BO

- MSIE WebViewFolderIcon BO

- MSIE RealPlayer sometihing..

- QuickTime something

- AOL Superbuddy BO

There were a couple of others.

Until someone slips code into GCC.

Its been done before, as a proof of concept.

A backdoor was inserted into the 'login' program on a Unix system - this was detectable in the source, however, so he modified the compiler to insert the backdoor at compile time. Clean source built with that compiler would still have the backdoor.

He went even further though - the backdoor code was still visible in the source code for the compiler, so he modified the compiler further, to insert the backdoor in itself when compiled.

He then built a new compiler with fresh, unmodified code and his hacked compiler. This produced a compiler from clean source that contained the backdoor, and would insert the backdoor in any copy of the compiler that it compiled, and any of those compilers would insert the backdoor in 'login'. No source code audit would ever detect it.

Starting fresh from source still needs a compiler, and that compiler can be enough to exploit the entire system.

Not saying it'd be easy to do, but a compile only system doesn't protect you from everything.

That sounds like Ken Thompson's "reflections on trusting trust" paper. And what it comes down to is this: Anything compiled with a tainted compiler is liable to be compromised, and may behave in ways other than suggested by the Source Code.

The way around it, if you don't trust the compiler, is to rewrite the compiler -- starting from clean Source Code -- in straight assembler. You know it's clean because you wrote it. Nothing compiled with a "clean" compiler will do anything that was not in the Source Code.

But there's another way that takes a little bit less hard work. All you really need is to write in assembler is a *partial* C *interpreter*: it only has to be able to interpret enough of the language to run the compiler Source Code interpretatively. It doesn't matter if it's slow, because it only needs to be run once. You know the interpreter is clean because you wrote it, and you know that the interpreted compiler is also clean because you checked the Source Code. Therefore, you know you will be compiling a "clean" compiler.

Well, at least to the extent that you trust the silicon .....

Depending on the sophistication of the backdoor, even a C interpreter written in C might be enough protection (since the compiled compiler is never seeing compiler Source Code; only the interpreter Source Code, which it probably doesn't know about.)

You're right in saying that a compile only system doesn't protect you from everything, but that is no reason not to think it's a good idea anyway. Seat belts don't protect you from your car going on fire, but that's not a good reason not to wear one.