And remember, kids. Microsoft didn't develop PHP.
Can't blame them for this one.
And remember how to prevent getting infected before the fact? Yes, of course you do. Trend Micro knows too, but don't expect them to tell you.
/me waves at Dave Rand
More than half a million web pages have been compromised with malware as part of a new attack, Trend Micro warns. Badly configured PHP bulletin board applications are being used to plant malicious JavaScript on web forums. The JavaScript is used to push variants of the Zlob Trojan that come disguised as a video codec installer …
...remind us again which browser platform is affected by the malicious code.
Would this be the same non-web-compliant browser that Microsoft bundle with their OS ?
Is this the same one that specifically allows malicious code (aka activex) to operate, and in fact rely on it themselves to force people to use their inadequate browser to get security updates ?
We could do with a "no IE" icon at this juncture...
This isn't about PHP, but rather the exploitation of an application which happens to be written primarily in PHP, so let's not blame PHP, either. Turn the lasers on those sysadmins who have failed to protect their visitors by not patching their bulletin boards, or even, at the outside, blame PHPBB for the way they coded their product. It's not the first time PHPBB has been a conduit for exploits, and it's not likely to be the last.
User let an Active-x control install from a well-known company website. Was a pain to clean up, and also left nuisance remnants to deal with, like a policy that blocked access to the Task Manager, an obfuscated address bar at the top of folder windows, a hijacked homepage (of course), and other little tidbits. All to flog a rogue and useless AV "product" and join the machine to one or more botnets. Makes me sad that people waste their talents and energy adding misery to the world and to life, for such scant gain. So it goes.
Yes that's a small p.
Badly configured PHP bulletin board? What?
Never heard of one.
Badly written PHP bulletin board? Where?
pHP mail() being exploited by spammers? No way!
If you are going to market your product as easy to use (pHP), at least provide examples that show users how to work around the weaknesses in the mail() function.
pHP bulletin boards are not as bad as MS frontpage guest books, but they are not far behind.
The same guys who hacked (and continue to hack) iPower-hosted Web sites appear to be behind the phpBB and phpNuke attacks. They're also targeting outdated, vulnerable WordPress installations, leaving message board spam and Weblog spam advertising poisoned Google Groups, and leaving links to Zlob droppers in places like Facebook and MySpace.
The compromised PHP forums are merely the tip of the iceberg, and many of them do not rely on JavaScript to download copies of the zlob Trojan. The compromised PHP forums, WordPress installs, iPower Web sites, Facebook profiles, and so on are the inputs to a large and rapidly-changing network of servers, mainly hosted in Eastern Europe, that actually do the dirty work. A user coming in from a PHP forum or a compromised Web site might be redirected straight to a virus downloader, but usually he isn't; instead, he's redirected to a traffic manager site, which then silently redirects him, often through two or three intermediary servers, to the final destination, which hosts the exploit software and the malware it downloads.
A handful of these servers will look at the browser's user agent, and attempt to download the Macintosh DNS changer malware onto Macs as well.
I've documented this underground network, complete with flowchart, extensively at
http://tacit.livejournal.com/240750.html
PHP based forum... roll your own; PHPBB is only a forum with some user-centric bolt ons... or alternatively, as it's open source just tweak it and bolt in something like HTML Purifier [htmlpurifier.org] to help with sanitising any form data.
There's nothing wrong with PHP (per-se) but there's a LOT wrong in the world of web development... there's just so much god-awful code out there that gets by because "it works in Internet Explorer" - irrespective of the fact that the back-end code (PHP, ASP, Ruby, Java, C#, Perl etc) doesn't really have a whole lot to do with the display layer.
I work on the theory that if the code you CAN see (client-side) is sloppy then the server-side code will be just as sloppy. It's the eye-candy that sells the site unfortunately - clients are sold on "shiny shiny" not on how well something actually performs in the wild.