Mystery web infection grows, but cause remains elusive The mystery over a cluster of poisoned websites distributing a toxic malware cocktail may be better understood but it's still not solved. Five days ago, we wrote about the infection of several hundred websites that was unlike anything seasoned researchers had seen before. Mary Landesman, a cyber gumshoe who first brought it to …
If there isn't one common vulnerability, perhaps the malware is just using multiple vectors? Perhaps we're seeing the result of several distinct pieces of malware with similar (or even the same) payloads?
Like in medicine, when the patient presents unusual symptoms, it could be that they have some completely new disease, but it's also possible they have more than one ailment?
Looks like it might be related to this issue:
http://arstechnica.com/news.ars/post/20080116-javascript-worm-from-late-2007-happily-frolicking-in-2008.html
Javascript worm? Sounds serious. Anyhoo, Finjan thinks they have a solution. Yeah, can't wait for the next one of these to come across and do some real damage.
IT WAS ME! HAHAHA!
Sorry, just kidding, but I realised I was possibly the first commenter, and thought I'd the first to make that lame joke :-)
And now for my nieve suggestion: Could it be coming from an infected piece of software ommonly used in website design maintenance? e.g. if this was sneaked into the install package of a major FTP client or squirreled away into Dreamweaver (or CS3 or whatever they now call it), and therefore getting their way onto servers that way? You can all begin laughing now, but I never got much beyond HTML :-)
I don't suppose all these sites serve banner ads do they? And do they share the same banner ad provider?
Or the same website visitor tracking provider?
It's a great way to get script-based malware to appear to be from many sites when in fact the infection is at a shared host...
users computer is already infected with something harmless that thus goes undetected. some smaal thing that injects a 'magic packet' in any outpgoing http request.
an infected server 'trips' on this request and injects the 'payload' in its output stream. this payload then disables the user side 'magic packet' mechanism.
that could explain why it only happens once per ip address.
although if you are behind a router ..h mmmm maybe not.
anyway . the question remains. how do all these lamp installations become infected in the first place , and where is it hiding ...
They might consider site management software as a possible culprit. Certainly 0wn3d machines are a possibility. Someone writes some clever scripting code, uses an administrator's 0wn3d machine to inject it quietly while they do some routine site maintenance, and the slick little worm burrows into the lush, thick forest of the OS.
If the generator was written in something like Python or Perl, then it could run on a whole host of OSes and servers.
"she noticed two modules - one called mod_bwlimited and the other enable_dl - in the Apache webserver that were responsible for transmitting the randomized malware onto end users' machines"
enable_dl doesn't seem to be an apache module - rather a configuration setting in php (deprecated in php5). See here http://uk2.php.net/manual/en/ref.info.php#ini.enable-dl. It allows dynamic loading of php modules in apache servers.
if these TWO settings are always associated with compromised servers then it suggests that php is involved in the compromise
If a hacker does it it is called a man in the middle attack, if the ISP does it with a proxy server it is called marketing.
Compromise the proxy server and you have pretty well stuck cheap B2Bs d**k in the dirt.
Switching our clients to secure server (kicking and screaming because they are cheap SOBs); the fun just never ends.
You could be right. Perhaps it isn't an ad server though, so much as it is a malicious advertisement. Many people who elect to give out ad space on their site will often insert code that lets the ad server generate a little box that can randomly show one or multiple ads.
If one ad is infected, the javascript will only be inserted when that ad is randomly selected. The elusive nature of this virus could very well be that researchers simply aren't viewing the site when that ad shows up.
Hmm, I use a shared hosting server for my micro ISP. It's been offline for about 15 hours now, as the server administrators battle to remove what they say is a root kit related to this new bug. They have a tech from Scotland working on it. It is (was??) a cPanel-based service. Two other servers in their farm were affected too, but have been repaired much faster.
Haven't seen a good (bad?) bug like this in years! Oops - that'll be the phone again...
....this is all a pre-emptive April Fool's joke designed so that on April 1st, most of the web shuts down and displays a message? :P
Seriously though, this reminds me of trouble that happened to yoyotech.com fairly recently, where someone hacked their site and installed code that only activated if you pressed the back button. It was only at that point did it try and infect you with some dodgy javascript.
I really like the thoughts of a common ad, image, or stats server.
But it will probabaly be the Pee, in LAMP. I think it should be spelled LAMp, myself. The pee is a black hole of security, on a shared server (or a server on the internet). Some open source projects get too much of a break from everyone on security.
On a page or site level, it could be the overwriting of the pee variables, to include or fopen http or ftp URLs. On the server level, it could be a pee global prepend file.
Before anyone explodes with religious zealotry about the little p, and how it is all the coders fault.. Please think about it. Many of the code examples on their site, are poorly written. Pee is easy to use and marketed as so, but there are not even examples on their site of how to write a secure form mailer. Most of the top pee applications refuse to upgrade the applications to pee 5. Many of the top pee applications are (or have been) vulnerable to form injection. Many pee applications require the use of enable_dl, or allow fopen URLs.
Search for "requires enable_dl" or "enable_dl is required". You will probabaly find the problem, but it will be someone else's fault.
If whoever's doing this has found a vulnerability that allows them to compromise a server, I'd have thought that replication was a piece of piss.
1) compromise server.
2) serve moody .js to incoming clients.
3) vulnerable clients get rootkit.
4) client browses to new server.
5) *rootkit payload* checks for vulnerability on new server.
6) GOTO 1
That'd account for it quite nicely.
A variation on the above would be to have the rootkit send the IPs of any vulnerable servers found to a Command and Control server somewhere for action rather than doing the dirty deed itself. I think that this may be more likely as I'd expect it to spread somewhat faster if it were a fuly automated process.
[Landesman also reports how hard it is to remove the attack code from tainted web systems...But when she disabled them, she was dismayed to find the changes reversed and that the machines had soon resumed their attacks]
Removing it is very simple. It's a lot of work, but it's simple. Any rooted system *has* to be considered beyond redemption and reinstalled from known clean media. Thinking that applying a patch is enough risks leaving a root kit installed, so in essence you are doing the attacker a favour by protecting "their" server from other possible attackers.
Yes the system may be compromised again if you can't patch it, but given a clean system and IDS you can at least see *how* it's compromised again then (unfortunately) reinstall again then make the necessary modifications to avoid future compromise. Then you can obviously advise every bugger else and another wave of attacks comes to a (temporary) halt.
It's not sexy, it's hard bloody work, but that's the real world of IT for you.
Speaking as someone who knows next to nothing about this, I still think that the possibility exists for the solution to be not quite so simple. If you don't want to recreate your content from scratch (probably not possible in most cases and impractical in almost all others) you would:
1 Back up your CMS+data
2 Reinstall the OS
3 Restore CMS+data
Now if some viable component of the malware has hidden itself way in the CMS ...
According to http://www.webhostingtalk.com/showthread.php?p=4902045&highlight=%2Fmem#post4902045
The exploit injects code into the kernel by accessing /dev/mem through tainted binaries executed at boot time. Although I cannot confirm this works in practice, in theory admins looking to prevent being reinfected could compile a new kernel with the grsecurity patch (http://www.grsecurity.net) and use the following kernel options:
Security-->Grsecurity-->Address Space Protection --> Deny writing to /dev/kmem, /dev/mem, and /dev/port
Preventing the tainted binaries from accessing /dev/mem doesn't mean the attacker is not still able to replace the system binaries via the unkown attack vector. Using Grsec's RBAC to pevent the root use from altering system binaries would serve to further protect the system, and if the apache user role were also well defined it *may* help prevent the initial attack vector.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
