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 …
Why does it have to be one cause?
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?
Web 2.0 begat malware 2.0
Welcome to the brave new world.
Same people who did the Benazir Bhutto virus
Looks like it might be related to this issue:
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 :-)
Shared Ad server?
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...
Can I apply to be a researcher?
Hand me the rocket propelled harpoons!
could this be a two prong attack ?
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 ...
New security update for Quicktime
I just downloaded the latest security patch for Quicktime. I wonder if it is in response to this.
Actually, Eddie Has a Good Point
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.
not apache module
"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
Re: Shared Ad server?
I think AC may be onto something. Another possibility is an http uploader written in PHP, a language in which it is notoriously easy to write functioning code with no security whatsoever (like playing the guitar - it's very easy to do it badly).
fighting similar crap.
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.
@Shared Ad Server
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.
It got ours apparently...
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
This is a Linux Kernel Module RootKit.
There have been already ample discussions and diagnostics about this.
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.
>tech from Scotland working on it
Doomed, doomed we're all dooooooomed I tell ye....
the end is near
Wont be long before were switching skynet live to combat the virus/malware and we all know what happens next :)
It got us
Our webhosts have admitted it has hit a number of sites they host including ours. One of our customers has informed me that his anti-virus software reports Trojan JS/Downloader-AUD when he visits our site.
Injecting code @ runtime.
Wot's about Apache Dynamic Shared Object / APache eXtenSion?
Get your hands on a vulnerable system, inject a binary/escaped stream that is module-like that does the trick and make sure the stuff is being sent to any compromisable server.
Hmmmm Y not
Look strangely familiar?
Hard to remove?
[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.
@Hard to remove ?
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 ...
Web page about this
Well here is one fairly good diagnoses a mate put me onto here. Not sure if this accounts for all of the instances talked about:
Details of current known information.
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
one more thing...
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 mom & pop sites could be checking out their visitor logs...I know I do.
Lately several visitors, when their link is clicked, try to down load a "movie" file. Even on a Mac I have to force quit my browser to regain control of it. The movie sites seem to be domained in Germany.
What anti virus software do we use for Mac's? Never needed any until now. My virus came attached to an email!
1. Uninstall Apache
2. Install IIS
I worked for a company that nearly went bust when Code Red hit their IIS servers and caused them to constantly restart. We were soooo close to missing all our SLAs at once.
Install IIS is hardly a perfect solution.
- Fee fie Firefox: Mozilla's lawyers probe Dell over browser install charge
- Did Apple's iOS make you physically SICK? Try swallowing version 7.1
- Neil Young touts MP3 player that's no Piece of Crap
- Review Distro diaspora: Four flavours of Ubuntu unpacked
- Pics Indescructible Death Stars blow up planets using glowing KILL RAY