Evo 1.0.15 getting hacked

2 Posts

danilsk Reply #1, 11 years, 1 month ago

Hi there!
We had a bunch of ModX Evo 1.0.11-1.0.14 websites on our server. I am not exactly familiar with ModX, but when they got hacked I upgraded all of them to 1.0.15 and removed all of the backdoors and it solved the problem for 8 websites out of 12.

The other 4 keep getting hacked every day with numerous backdoors (blog.php, list53.php, diff17.php etc) being created all over the manager and asset folders. Here is the part of access log when the site gets hacked:

72.18.204.93 - - [30/Aug/2015:05:56:26 +0300] "POST /assets/cache/docid_114.pageCache.php HTTP/1.0" 403 483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:27 +0300] "POST /assets/plugins/tinymce/jscripts/tiny_mce/plugins/imagemanager/classes/Authenticators/IPAuthenticator.php HTTP/1.0" 200 432 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:27 +0300] "POST /manager/media/ImageEditor/Classes/Transform.php HTTP/1.0" 200 260 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:28 +0300] "POST /manager/processors/empty_table.processor.php HTTP/1.0" 200 368 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:29 +0300] "POST /assets/cache/docid_255.pageCache.php HTTP/1.0" 403 483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:29 +0300] "POST /assets/plugins/tinymce/jscripts/tiny_mce/plugins/filemanager/classes/Utils/CSSCompressor.php HTTP/1.0" 200 260 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:30 +0300] "POST /assets/cache/docid_65.pageCache.php HTTP/1.0" 403 482 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:31 +0300] "POST /manager/processors/save_tmplvars.processor.php HTTP/1.0" 200 368 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:32 +0300] "POST /assets/cache/docid_144.pageCache.php HTTP/1.0" 403 483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:32 +0300] "POST /manager/processors/unpublish_content.processor.php HTTP/1.0" 200 368 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:33 +0300] "POST /assets/cache/docid_112.pageCache.php HTTP/1.0" 403 483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:34 +0300] "POST /manager/media/ImageEditor/editorFrame.php HTTP/1.0" 200 584 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:35 +0300] "POST /assets/cache/sitePublishing.idx.php HTTP/1.0" 403 481 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:35 +0300] "POST /assets/plugins/managermanager/functions/tabs.inc.php HTTP/1.0" 200 260 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:36 +0300] "POST /assets/cache/docid_41.pageCache.php HTTP/1.0" 403 482 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:37 +0300] "POST /assets/cache/docid_281.pageCache.php HTTP/1.0" 403 483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:38 +0300] "POST /assets/plugins/tinymce/lang/tinymce.lang.php HTTP/1.0" 200 260 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:38 +0300] "POST /assets/plugins/tinymce/jscripts/tiny_mce/plugins/imagemanager/stream/default.php HTTP/1.0" 200 271 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:39 +0300] "POST /assets/snippets/ditto/debug/plugin.php HTTP/1.0" 404 4994 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
72.18.204.93 - - [30/Aug/2015:05:56:40 +0300] "POST /assets/plugins/tinymce/jscripts/tiny_mce/plugins/filemanager/plugins/History/History.php HTTP/1.0" 200 421 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"

I looked through all of the files and can't figure out what the vulnerability is. I would really be grateful if someone helped me with this. [ed. note: danilsk last edited this post 11 years, 1 month ago.]

☆ A M B ☆
1,031 Posts

Jako Reply #2, 11 years, 1 month ago

According to the log there are some php scripts found (and maybe used) by the attacker. All lines that have a 200 after the filename are called external, are found and are executed without an error. So those scripts could be attackable or could be infected.

It depends a bit, how you have updated MODX to 1.0.15. If you have used the Alternate Method you have a clean system after 10. If you copy back your assets/images and every other folder that is used by your installation inside of the assets folder, you have to look for php files that don't belong there (especially in assets/images/ or similar) or are infected (especially in custom extra folders in assets/snippets/, assets/plugins/ or assets/modules).

And don't forget the folders in the webroot that are not used by MODX. There could be infected files inside too.

2 Posts

danilsk Reply #3, 11 years, 1 month ago

Since there is a bazillion of different plugins in each ModX Evo installation with directly accessible php files many of which don't even have the basic !defined('MODX_BASE_PATH') protection, and a bunch of directly accessible files in manager folder, the only solution I came up with is to

Block direct access to php files in /assets/ 
 /assets/.htaccess:
  <FilesMatch "\.(php)$">
      Order deny,allow
      Deny from all
  </FilesMatch>

Protect /manager/ with Apache authentication
 /manager/.htaccess: 
  AuthUserFile .htpasswd
  AuthType Basic
  AuthName "Enter your credentials"
  Require valid-user

 /manager/.htpasswd:
  *auth data*

And after that cleaning everything out once again.

☆ A M B ☆
1,031 Posts

Jako Reply #4, 11 years, 1 month ago

A lot of modules would not work with that restriction.

2 Posts

smartnn Reply #5, 10 years, 8 months ago

Hello, I had the same problem, if needed, I can help for free My contacts http://capweb.ru/kontakty.html Skype sergeynn01

23 Posts

wishbone Reply #6, 9 years, 10 months ago

I'm struggling with the same problem.
New php-files everywhere, new folders in root ("headers", "pages" "views", "articles"...).
i closed some security weaknesses in the php.ini - no effect.
I tried the above .htaccess - no effect.
But now, editing in the manager, every " is being prepended a \ (wscape?)

I admit I use evo 1.04 because some third party changed files which I am not sure of, so I don't dare upgrading.

But as I hear above, a newer version is not secure either.

Can anybody help? Where is that open door??

thx!

953 Posts

iusemodx Reply #7, 9 years, 10 months ago

@Wishbone

You are probably not going to get around upgrading to the latest version

1) 1.0.4 doesn't support PHP 5.4 and above
2) There have been major changes made to the code since 1.0.4
3) The Evo core has been updated multiple times since 1.0.4

For more information on the latest hack, take a look here

Download the latest Evo release
Report an issue about Evo
Read the Evo documentation

23 Posts

wishbone Reply #8, 9 years, 10 months ago

Quote from: iusemodx at Nov 27, 2016, 02:10 AM

You are probably not going to get around upgrading to the latest version

thank you lusemodx for your answer!
How can I find commercial help for the upgrade?

23 Posts

wishbone Reply #9, 9 years, 10 months ago

Isn't there a possibility to prevent hackers to create new folders (with known names)? to begin with...

23 Posts

wishbone Reply #10, 9 years, 10 months ago

and where could these backslashes (before a quote, making the quote to be read as a html-entity) come from, because they only came after I tried the above .htaccess (which of course I deleted immediately). They haven't been there after the infection(s).