I’m doing a black-box testing of a customer site running MODX, and they didn’t lock their core/ folder with a htaccess file (in fact, core/ht.access is still accessible).
Access to some files is denied, but some non-critical files (such as all files in core/docs, as well as for instance config/config.inc.php, that gives a blank page) are accessible.
What would be the actual security implications of a partially exposed core folder such as this one?
I’m having a hard time convincing the customer that they should lock it down and change their configuration, since I cannot really prove anything bad can be done, as far as I know.
That’s what I’m trying to convince my customer to do, but their approach is very much “if you can’t show me why it’s wrong, then I won’t change it”. So, would be nice to understand why in that specific case, having the core exposed would be dangerous
For one, accessing core/docs/changelog.txt will immediately confirm the exact version of MODX that is in use. If that’s an outdated version with known security issues, a potential attacker can use that information to be more effective in their efforts.
Same with extras; you could easily scan core/components/{extra}/docs/changelog.txt to see which extras are installed in what specific version. They can then either use a known vulnerability or try to find one in the specific extras in use to do more damage.
Any non-php file in the core directory that may contain sensitive data will also be readable/downloadable. That may include for example backups/invoices/exports that various extras may write to core/exports/, any logs with typically unredacted information in core/cache/logs/, and any other files not meant to be in the public.
In the event that accessing a PHP file directly causes an error, that could cause things like server paths or in-memory data to get dumped (if display_errors is enabled in the PHP configuration).
It makes sense! Indeed, they have their error log exposed. It only contains non-critical PHP errors / warnings, so it is not really that bad, but I’ll report regardless. Thanks!
Sorry for double-posting, but this next question seems to fall under the same umbrella as the other topic. Tell me if you’d rather have this in a separate topic, and I’ll split
Turns out, the installation is even more broken than I thought, and on certain conditions, file listing is enabled on apache, which obviously leaks script names, size, etc (but no config files apparently).
One thing that seems pretty dangerous is that the whole elements/snippets folder is available for file enumeration.
After looking at the documentation, it seems that the only way to actually execute those snippets (if they expect a parameter) is to use runSnippet. Would that mean that the snippets folder is actually “safe”, meaning people can’t just start querying snippets with GET / POST and input parameters directly in the query string arguments?
In general, it’s safe, because typically elements in the core/components directly have been installed into the MODX database and aren’t “live” there, so they don’t get read or executed from there at all. However, in the atypical case where snippets are defined as static files, and are linked to the snippets folder in the components core folder, then any change to the snippets in there WILL get run on the front end when those snippets are used. I use this setup on one site that I use to develop extras because it’s convenient. But if a hacker gets access to your public web directory, they can alter any files they can access there, so there’s a potential (if small) security risk.
GET/POST won’t make anything happen with the snippets, since $modx won’t be loaded, so only if the snippets are set to be location for static files would there be a potential problem. But if someone has gained access to your web directory, then that is a much different scenario from someone trying to access files over the Internet.
