I beg to differ. Even though it’s trivial to change the UA they obviously haven’t. I’m certainly not the first to urge for blocking libwww which means the exploit authors either don’t use Google, or realise only a small number of sites actually block the UA.

Looking forward to the modsecurity post!

Our new WPIDS will protect against these attacks :)

They are generic scans against PHP code and not based on any Wordpress code, I get these a lot.

I saw Donncha’s post and I think you’ve missed the point of it somewhat. The point wasn’t to eliminate all the nasties altogether — you will need to rely on other solutions for that — but reduce the load on your server. The traffic that it blocks is all coming from bots, which are churning out requests by the millions to try and cause as widespread damage as they can.

This technique may not stop all bot attacks, but it is not entirely useless.

Your point about RSS aggregation agents may be valid however, though do any really legitimate ones actually use the libwww-perl user agent, or is that more the domain of splogs and things, as I would have thought to be the case? In any case, if there are some legitimate LWP aggregators out there, I’m sure it must be possible to come up with some .htaccess rules that allow them access to your RSS feeds while denying them everything else.

You’re asking what’s that wp-pass thing? Interesting to see that you forgot your own post 3 months ago. :-D

About user-agent, I think Donncha actually got a point. From statistics of my own site, the user-agent from spam messages surprisingly concentrates on just a few choices (though most of them have null user-agent string). Not the ultimate solution, but can still block a noticable portion of the spam messages.

Abel, yes I know of the wp-pass redirect vulnerability that Adrian released on BlogSec a couple months back; however, the vulnerability they are trying to exploit here is a remote file include bug.

Abel, David,
My guess would be, that unless there’s a top-secret 0day out there ;) It’s more likely that some script-kiddy didn’t get what the vulnerability is, and therefore is pointless trying to include.

As others have noted, a lot of the script kiddies do use the unmodified libwww-perl user agent string, so it does help a lot to simply block that.

Also, they often try these include tricks with each and every PHP script that takes a parameter. Just because they try doesn’t mean an actual exploit exists for that script.

I use modsecurity for all sites, and block many attacks :))