Analysis of yesterday's PHP.net exploit | Hacker News Reader

Analysis of yesterday's PHP.net exploit

alienvault.com

52 pointsmartinml13 comments

Interesting! It might actually have a big impact, given how much in use the page is. And the target audience of php.net is likely to be a good target for keylogger attacks (SSH/SFTP logins and the like to development and production machines). It's certainly getting worse than I expected at first. Given how low the AV detection rate is, it would be interesting in how much impact the plugin exploits have for the overall installation base.

You're not wrong. It's almost a watering hole attack, with the aim of getting credentials to get leverage against other higher profile sites.

Site is a little sluggish, here's a render — http://i.imgur.com/IjbsN8v.jpg

Also in Coral Cache: http://www.alienvault.com.nyud.net/open-threat-exchange/blog...

I was expecting a detailed account of how the server was compromised, although this account of the drive-by malware operating details was interesting too.

My money is so far on Darkleech apache module[1] as the cause. As far as I know it's still unclear how the attacker gains root access to the server to do the install.

[1]http://malwaremustdie.blogspot.com/2013/03/the-evil-came-bac...

It says it's a Linux malware, but the server in question run FreeBSD. Of course, FreeBSD version might as well be out there too.

You're definitely right. I edited my title to match expectations.

Is there any good way to tell if you've been compromised by this exploit?

If you don't enable Java/Flash/etc. by default (which you definitely should not enable!) you're probably safe. If you do, well, it's sucky. I guess running a rootkit detection tool and monitoring your outgoing traffic for a while would be a good idea (and also a good food for paranoia - you'd discover how much outgoing traffic legit apps that you'd never expect talking to outside generate - version checks, usage updates, cloud syncs, etc.).

It doesn't seem to be possible to make Flash use 'click to play' on chrome. You can make all plugins 'click to play' but unfortunately that breaks any plugins that do initialization in the onload handler.

Java is now click-to-play by default, and I'm hoping that Flash goes that way soon. Flash is mostly just used for annoying adverts these days, so it won't be a great loss (and maybe that is why google is reluctant to disable it by default).

It is definitely possible - my chrome does it. I have a number of extensions so I am not sure which one does it, but I'm sure it can be done.

I guess you could close all your applications and watch traffic with Wireshark for a while, since antivirus software doesn't seem to be very proactive in this cases.

Fortunately this kind of exploits seem to go for the low-hanging fruit: outdated plugins like Java, Flash or Acrobat. If you have any of those enabled and not up-to-date, you're vulnerable.

The sensible recommendation seems to be use some form of click-to-play scheme, depending on your browser.

Reply on news.ycombinator.com