Today I found out we had one website with this hack. Besides the "Core Services" plugin, the hacker also created a plugin called "Highlight Search".
-
☆ A M B ☆
- 309 Posts
Today I found 4 sites with this hack. 2 were infected in February and 2 in June (2014). They are all older versions of Revo (2.2.2, 2.2.7, 2.2.10, 2.2.10) All 4 sites have advanced installs with the core directory above the webroot. I found the "Core Services plug-in in all 4 databases, although it was not visible from within the manager. In all 4 instances the plugin had the "Source" and "Locked" fields equal to 1 (these fields are 0 in all other plugins that I've seen).
I found these files in all:
core/cache/xPDO.idx.php
assets/.cache.idx.php
assets/xPDO.idx.php
assets/siteManager.idx.php
The 2 that were infected in Feb. did not have any users added. Of the 2 that were infected in June one had a "support" user created with the obscene-anti-modx email address, and the other had 3 different "support###" users created with support@ email addresses. All of these new fake user accounts were sudo. One difference between the 2 sites that had fake users created and the 2 that did not is that the 2 sites that were given fake support users also still had the original default "admin" user. Just wondering if that account was somehow used as a way in.
I guess I will continue checking my sites. And updating... carefully.
-
☆ A M B ☆
- 309 Posts
In total agreement about the admin username! I consider that an oversight on my part, as I usually change that account first thing. Not sure if new installs still add this user as the default or not? Would be great I think if a new MODX install did NOT prefill the first user account with the username "admin" but instead forced one to enter an original username.
Really looking forward to your plugin Everett! Where do I donate?
-
☆ A M B ☆
- 24,524 Posts
Revo hasn't set a default user in a long time.
I use this
http://strongpasswordgenerator.com/ and it's not just for passwords, you can use it for the usernames as well. A password locker, like KeePassX, is a good idea as well. I do not like to use the "in the cloud" type of password storage. Too many things can go wrong, from governments demanding records to their site going down just when you need it.
You can even create really odd email accounts to use only with sensitive sites that use the email, like PayPal.
Just chiming in here as I have been in the thick of cleaning a site. I went back to copies of my previously infected site and found that gnuz script embedded within the TinyMCE snippet.
I had since uninstalled and removed all Extras and then redownloaded and reinstalled only those that I needed for the site. Still experiencing issues with my manager, but certainly, looking within all Extras for the nefarious code is advisable.
-
☆ A M B ☆
- 309 Posts
So is there a best practice for updating a site that has had this hack? I am wary of carrying over the infected DB, etc. but not really sure how best to clean it...?
-
☆ A M B ☆
- 309 Posts
Thank you for that. It doesn't really address how to deal with a compromised database other than to re-install from a clean backup. In some cases the earliest date of infection is over 5 months ago. I can't imagine rolling back that far and losing the last 5 months of content. For some sites that is a considerable amount. So, would I try to save just the content tables from the db and ditch the rest?