MODX Hacks
(In Perspective)
You're likely already aware that a critical vulnerability was disclosed recently, on July 13, 2018, one day after the fix was released in MODX version 2.6.5. The discloser clearly had no concern for the unlikelihood that MODX site owners would be able to update within one day of release, but that's another discussion.
Any software vulnerability is a serious issue and must be addressed with maximum diligence. However to put things into perspective, and perhaps ease your mind about your CMS of choice, this is the 50th recorded MODX vulnerability, while other popular, open-source PHP CMS's have quite a different count:
It's true, MODX has less widespread adoption, and benefits somewhat from the obscurity, but the fact of the matter is, if you're a MODX site owner, you've had to deal with critical updates less frequently than if you had been running one of those other platforms.
That said, the most recent event was a nasty one, and I've seen lots of requests for help on the forums and the community Slack, so here are some tips for dealing with a hacked MODX site, as well as best-practices for securing your site going forward.
Before taking action on anything you read here, please read the site TOS and know that you're fully responsible for your own actions. It should go without saying that cleaning a hacked site is a task for a developer or IT professional familiar with the site's tech stack.
Also, a general caveat: hardening a site will only get you so far. Letting software updates lapse is a death-knell. If a malicious actor is intent on breaking your site specifically, you aren't likely to win that battle without a security expert, or team of them, on staff.
Filesystem
MODX was built from the ground-up with database security top-of-mind, so the most common point of entry for MODX vulns, that I've heard about, seems to be the filesystem. The good news is, all of the paths to MODX core folders are configurable, and you should absolutely take advantage of this huge security benefit.
- The core folder should be outside the web root. To add a bit of complexity for a malicious script, you can customize the folder name, as well as the config file for the site. Example:
/path/to/corehUjbM8et5E/config/configubS5d6ACSZ.inc.php - The manager and connectors folders should be similarly obfuscated, like:
/path/to/webroot/managerBzosH00TXb/and/path/to/webroot/connectors7AF6hI8yrO/
Your assets folder is almost certainly exposed in your site's html responses. If ALL your assets are served from a CDN and you NEVER reference the assets folder on your front-end, you can obfuscate your assets folder as well. This hides the components folder therein, which has been a target for bad scripts.
The most recent vuln involves the connectors folder, and from what I've heard (anecdotal and not concrete, mind you) MODX sites that have customized core and connectors folders have not been hacked. It's worth repeating that if your site had customized core and connectors folders, you likely did not have to deal with cleaning a hack, and simply needed to update the core software—a comparatively trivial task.
Caveat: Extras. Any MODX Extra that exposes your connectors folder should be avoided. Additionally, outdated Extras can themselves contain serious vectors. A version of the most recent attacks targeted the popular Gallery Extra. All the efforts enumerated above could be circumvented by a vulnerable Extra. Take "extra" care to monitor the MODX Community Slack and Forums for information regarding the reliability and maintenance of Extras you use on your site.
Assets Recovery
The best way to recover assets from a hacked MODX site is to export only the data you want to recover, and move it to a secure staging environment that only you can access (localhost, for example). Be careful not to execute any files prior to cleaning. When exporting data from a hacked site, DO NOT INCLUDE the core, manager, connectors, nor assets/components/ folders. These can be restored from fresh installs. You can avoid having to scour and clean those folders if you never take them with you.
As such, you should really only be dealing with the assets folder, but NOT assets/components/. This does depend on whether your site follows the MODX convention of putting ALL assets inside the assets folder. If you have other folders with required assets in them, you'll need to export those and clean them as well.
If you're dealing with a hacked site, you'll likely see *.php files hanging around in these assets folders, despite the fact that you would almost never need to put PHP files there. Examine them and remove the nefarious ones. Also remove any dot-files and any other executables, including JavaScript files that you do not recognize. You might benefit from a tool like phpmalwarefinder, with MODX Community member Gareth Parker's whitelist.
With clean assets folders, you're now ready to deal with the database.
Database
MODX is quite good at guarding against SQL-injections. From what I've seen, when a database contains malicious entries, it's the result, or symptom, of a filesystem vector. This isn't true 100% of the time, but it's the majority of cases I've seen, and having worked at MODX for 5 years, I've seen quite a number of different MODX scenarios.
That said, hacks seem to target 3 database entities: Users, Snippets and Plugins.
Database Recovery
When dumping the database, it's preferable to ONLY include the content tables, and ONLY the required data and configuration tables for installed Extras, in order to avoid the targeted entities. In practice, scouring through the database to identify the required tables can be very time-consuming. Another, slightly less safe method is to exclude the tables that contain executable code:
- modx_site_plugins (Plugins)
- modx_site_snippets (Snippets)
That takes care of 2 out of the 3 targets. Import this (partial) database into your secure staging environment. Scour the following tables for entries you don't recognize:
- modx_users
- modx_user_attributes
- modx_member_groups
Remove the baddies. You can now dump this clean database, in preparation for the site recovery step.
In extreme cases, your Chunks, Templates and Resources may have been hacked to include malicious scripts. In such cases a full audit of the content tables must be performed. One option is to regex all script tags, and then add the legitimate ones back in, but this is no trivial task and is prone to error. Going back to the last clean backup, possibly months old, may be the only sane solution.
Core Software
In your secure staging environment, re-install a fresh copy of the same version of MODX you had in your hacked site. You'll update it later, but first you'll want to recover the last working state.
Via the Extras Installer, manually install all the Extras that were in your hacked site. This will get the core codebase in sync (as much as possible) with what you had before.
Once that's done, import the cleaned database, and copy the cleaned assets back into their locations in the web root.
You may have had custom Plugins and Snippets installed in your hacked site. Someone who is able to identify malicious code, must thoroughly examine the custom Plugin and Snippet code, before manually restoring any of them to your cleaned staging site. To clarify, in the manager, create custom Plugins and Snippets, copying code from the hacked site, but ONLY after someone skilled in reading PHP code can confirm it is clean.
If all went well, you now have a clean, working MODX site, except for one thing: you still need to update! The update process for a working MODX site is fairly straightforward.
After upgrade, and testing for functionality, deploy your clean MODX site to a clean server. You might be able to get away with blowing away the files and database on your existing server and deploying from scratch, but generally I distrust any server that has been hacked in the past, because malicious artifacts could be hiding in dusty corners. Call me paranoid.
Additional Hardening and Best Practices
- Now that you've obfuscated all your paths, configure your web server to NOT send referrer data to any external domains.
- Keep your server software up-to-date as well. PHP 5.6 is nearing EOL in December 2018. To this end, a cloud-hosted service like MODX Cloud, or a server management service like ServerPilot can really help.
- Hopefully it goes without saying that you should enforce strong passwords on your site, and if possible, 2FA. Auth0 can help.
- Keep all installed Extras up-to-date and keep your eyes out for exploits in Extras. Also, remember to avoid Extras that expose your obfuscated directory paths, and ensure you only use Extras with active maintainers.
- Configure a firewall. Cloudflare is awesome in so many ways. When the latest vuln hit, I was on an island with no computer, but I was able to configure Cloudflare to deny requests to the vulnerable URL until I could update. HeatShield is also pretty cool. For more enterprise-y requirements, Sucuri is solid.
- Get periodic pentests or run them yourself. Google for the available tools out there, both paid and open source.
Security is a huge topic, and we only touch on the surface here. This guide to recovering/repairing a hacked MODX site is deliberately high-level. It's not a step-by-step tutorial. If you need help, reach out to the good folks at MODX, hit me up on LinkedIn or Twitter, or your best bet is to join the MODX Community Slack.
