New Community Forums are coming. Watch this space for news.
Subscribe: RSS
  • I have a 2.6.5 installation. Running for some years and upgrades. Now some viruses are detected. I think about reinstalling with a fresh download from the repository, maybe directly with 2.7.0. I hope to minimize most manual investigation of each file.

    Upgrad instructions say to build your upgrade upon the old installation with directory merging. I would like to avoid that. Is there any instruction with building up the installation direct from the fresh downloaded modx folder? And then manually copy all needed assets etc., to keep the amount of files low that have to be inspected. Any instruction / help on that?

    This question has been answered by spica8. See the first response.

    • I think that's a wise approach. Be sure not to transfer any bogus users.

      The files are pretty straightforward. Generally, all you need to transfer are files in the assets folder that you know are safe. Don't assume that they are safe just because they were there before. You need to check them to make sure they weren't altered. There are some tools out there that will perform checks on them for you, but if never hurts to take a look at the contents for suspicious code. Be especially careful if you're using the Gallery extra, since it was an attack vector.

      Be sure *not* to transfer the core/cache directory.

      The database is more difficult. If you install a newer version of MODX than the hacked site, you won't be able to do an easy transfer of the database tables unless you're able to update the hacked site first.

      If the two versions are the same you're sure the database has not been hacked (it's difficult to know, but most MODX hacking events haven't compromised the DB, just the files), you could install 2.7.0 on the new site, export the DB of the hacked site with the DROP TABLE custom option, and import it into the new site.

      The problem with any other method is the "intersect" objects that connect related objects in MODX. For example, every resource has fields telling who created it, who edited it last, and who published it. These contain user IDS, and if you create new users, the IDs won't necessarily match. There's a similar problem with which users are in which user groups, which resources are in which resources groups, permissions, policies, roles, and a bunch of other things.

      If the new site is going on the same server, you also have to consider the possibility that the hacker has gained access to that server (via, for example, a vulnerability in other software running on the same server like WordPress).

      Don't install any extras until the new site is fully updated, running MODX 2.7.0+, and has been hardened.

      https://docs.modx.com/revolution/2.x/administering-your-site/security/hardening-modx-revolution

      https://bobsguides.com/blog.html/2015/05/05/hardening-your-modx-site/

      I strongly recommend moving the MODX core above the web root of your site.

      There's some good advice here: https://modx.com/blog/recovering-from-a-hacked-site-part-1, but some of it assumes that you have a site backup from before the hacking occurred.

      I've been lucky enough not to have had any sites hacked. Others who have not been so lucky can probably give you better advice than I can.




        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
      • Hi Bob, thanks for your advices. Unfortunately its not clear, when the first corrupt files came up, so I cannot rely safely on a clean/secure backup.
        Do I get you right: I first have to proceed the full installation process of the same modx version before I import my db dump from the old one? Do I have do care about the old config file?
        • The odds are good that the hack occurred around 2018-Jul-11 unless you saw issues before that.

          It's not absolutely essential to do a clean install, but it doesn't take that long and it's nice to have a clean installation to start with. That way you can bring your assets files in use the site for a while to see if they cause trouble before importing the DB. You can back up the clean install by creating a compressed archive in cPanel. Then you can create a second one after moving the assets files. That way you can back out if there's trouble.

          If you do it that way, you don't need or want any of the config files from the hacked site.
            Did I help you? Buy me a beer
            Get my Book: MODX:The Official Guide
            MODX info for everyone: http://bobsguides.com/modx.html
            My MODX Extras
            Bob's Guides is now hosted at A2 MODX Hosting
          • Yes, arround July 18, I have found some hacked files. Interesting.

            Ahm, where can I finde the 2.6.5 distribution? Its not listed under prereleases. Maybe I should use the advanced distribution for hardening? Sorry, wrong akkordion, found.

            And how to deal all the extras that where mounted. Do I have to track and reinstall them manually or will I find assistance within the manager? [ed. note: spica8 last edited this post 1 month, 3 weeks ago.]
            • You probably want to make a list of their names. You can click on the download button in Package Manager, then search for their names and download each one.

              For snippets, you will usually (but not always) see "Snippet not found" in the error log, but for other elements, you won't see anything and there's a chance that a missing one could crash the Manager.
                Did I help you? Buy me a beer
                Get my Book: MODX:The Official Guide
                MODX info for everyone: http://bobsguides.com/modx.html
                My MODX Extras
                Bob's Guides is now hosted at A2 MODX Hosting
              • I am still busy tidiing up the files. I found lots of index.php and files like .75ce3115.ico and gahywgiq.php. Also the directory assets/components is full of them. Live all extras ressources inside here?

                As I have no access to the old manager anymore, I installed all extras corresponding to the folders in assets/components. So I have a fresh installation of modx, hardended it, installed all extras, and switched to a copy of the old db. Manager ist working. I only wonder, if the installed extras ressources and the corresponding old db entries can get a conflict.
                • As long as you've upgraded MODX to a recent version, the extras and DB shouldn't conflict.

                  Extras have most of their stuff in the core/components directory, but anything that needs to be available to the extra via URL (mostly images, JS and CSS code) goes in assets/components
                    Did I help you? Buy me a beer
                    Get my Book: MODX:The Official Guide
                    MODX info for everyone: http://bobsguides.com/modx.html
                    My MODX Extras
                    Bob's Guides is now hosted at A2 MODX Hosting
                  • [s]So, most things went well. Only one thing is left. 2 of three domains are running well. The third generates an error.

                    Fatal error: Uncaught Error: Call to undefined method phpThumbOf::createThumbnail() in /www/htdocs/web/core/cache/includes/elements/modsnippet/187.include.cache.php:53 Stack trace: #0 /www/htdocs/web/core/model/modx/modscript.class.php(70): include() #1 /www/htdocs/web/core/model/modx/modx.class.php(1798): modScript->process(NULL) #2 /www/htdocs/web/core/model/modx/filters/modoutputfilter.class.php(673): modX->runSnippet('pthumb', Array) #3 /www/htdocs/web/core/model/modx/modparser.class.php(941): modOutputFilter->filter(Object(pdoTag)) #4 /www/htdocs/web/core/components/pdotools/model/pdotools/pdoparser.class.php(305): modTag->filterOutput() #5 /www/htdocs/web/core/components/pdotools/model/pdotools/pdoparser.class.php(261): pdoTag->process() #6 /www/htdocs/web/core/model/modx/modparser.class.php(250): pdoParser->processTag(Object(pdoTag), false) #7 /www/htdocs/w009dd86/k in /www/htdocs/web/core/cache/includes/elements/modsnippet/187.include.cache.php on line 53


                    Tried with deleting core/cache. No effect. The other domains also use phpthumbof.[/s]

                    Reinstalled pThumb. Now working. [ed. note: spica8 last edited this post 1 month, 2 weeks ago.]
                    • discuss.answer
                      So, most things went well. Only one thing is left. 2 of three domains are running well. The third generates an error.

                      Fatal error: Uncaught Error: Call to undefined method phpThumbOf::createThumbnail() in /www/htdocs/web/core/cache/includes/elements/modsnippet/187.include.cache.php:53 Stack trace: #0 /www/htdocs/web/core/model/modx/modscript.class.php(70): include() #1 /www/htdocs/web/core/model/modx/modx.class.php(1798): modScript->process(NULL) #2 /www/htdocs/web/core/model/modx/filters/modoutputfilter.class.php(673): modX->runSnippet('pthumb', Array) #3 /www/htdocs/web/core/model/modx/modparser.class.php(941): modOutputFilter->filter(Object(pdoTag)) #4 /www/htdocs/web/core/components/pdotools/model/pdotools/pdoparser.class.php(305): modTag->filterOutput() #5 /www/htdocs/web/core/components/pdotools/model/pdotools/pdoparser.class.php(261): pdoTag->process() #6 /www/htdocs/web/core/model/modx/modparser.class.php(250): pdoParser->processTag(Object(pdoTag), false) #7 /www/htdocs/w009dd86/k in /www/htdocs/web/core/cache/includes/elements/modsnippet/187.include.cache.php on line 53


                      Tried with deleting core/cache. No effect. The other domains also use phpthumbof.

                      Reinstalled pThumb. Now working.