On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • I found a nasty little php file in /assets/flash/center_t.php -- it exploded itself and its payload of a bunch of binary zip data onto unsuspecting visitors. I’m not sure how it got in there... that directory typically has 777 permissions, so that’s a logical place for a nasty file to appear. This site had the reflect snippet on it... not sure if it’s the old exploit at play. Anyone heard of this file? Maybe the file name isn’t important...
        • Perhaps it’s this hack :
          Check your main index.php and document.parser.class.inc.php files for eval code at the end.

          • With this phpThumb hack, you can literally do anything you want to the site. It’s a bad hack. I’m working on a patch...
            • The Hack on phpThumb:
              (From http://www.juniper.net/security/auto/vulnerabilities/vuln39605.html):
              The application (phpThumb) is prone to a command-injection vulnerability because it fails to adequately sanitize user-supplied input to the ’fltr[]’ parameter in the ’phpThumb.php’ script. Attackers can exploit this issue to execute arbitrary commands in the context of the webserver.
              Note that successful exploitation requires ’ImageMagick’ to be installed.
              phpThumb() 1.7.9 is affected; other versions may also be vulnerable.

              The Fix:
              You can fix this by editing a single file: phpThumb/phpthumb.functions.php (around line 443). On Evo sites, it’s usually installed in assets/snippets/phpThumb. You just need to add a couple filtering commands to the SafeExec function to filter its input before it sends it to the command line. Right after the function declaration, add lines that filter the $command input. I haven’t tested this against all possible valid phpThumb input arguments, but this does prevent a "contained" hack that I performed on my own site.

              function SafeExec($command) {
              // Strip off any commands after the first semi-colon
              // and prepare the data to be sent to the command line.
              // EVERETT @ www.fireproofsocks.com 9/26/2010
              $command = preg_replace('/;.*$/','',$command); // <-- *NIX only 
              $command = escapeshellcmd($command);

              NOTE: if you are hosting on a Windows server, you would need to edit the first of the $command lines to this:
              $command = preg_replace('/&&.*$/','',$command);

              You should also turn OFF the debug mode in your config file because it can display valuable information to a hacker:
              Inside the phpThumb/phpThumb.config.php file, make sure the following setting is set to true (around line 196):
              	$PHPTHUMB_CONFIG['disable_debug'] = true;

              I’m not going to post how to perform the exploit (you can PM me if you want a test case).
              • Thanks for the work @Everett.

                Could save many a site, hope all will install it if ImageMagick is installed. Keeps the power out of "their" hands till the next exploit.

                This really looks bad news.
                  DEVELOPMENT ENV:- Ubuntu 12.04 | MODx Revolution 2.2.8 | LAMP 2i Apache 2.2.22 | Php 5.3.10 | Mysql 5.5.31 MySQL client version: 5.5.31
                • One of my Evo 1.0.4 sites was hacked. I found the same eval code appended to document.parser.class.php, as well as a VERY nasty file named xmlrpcw.php within my export directory.

                  This is getting scary, as I don’t have ajax search installed, neither do I have phpThumb. I thought I was relatively safe from this infection.

                  I’m going to scourge my logs and report any findings.


                    MODx Evolution/Revolution | Remote Desktop Training | Development
                  • Although I am not using phpThumb or AjaxSearch in my compromised site, I discovered that I failed to remove the snippet files from the server. It appears that the attack may have targeted the ajaxSearch 1.9.0 snippet files based on these log entries. It looks like the attack vector in my case is the index-ajax.php file, most likely posting some tainted data to ajaxSearch.

                    The attacker then immediately checks docmanager for two files that don’t exist in my installation - tv.php and inc.php. Perhaps these are files from an older version of the module. The 200 status is due to the page-not-found resource being served.

           - - [17/Sep/2010:06:29:21 +0000] "GET /assets/snippets/ajaxSearch/ajaxSearch_readme.txt HTTP/1.1" 200 66674 "-" "-"
           - - [17/Sep/2010:06:29:22 +0000] "POST /index-ajax.php HTTP/1.1" 200 150 "-" "-"
           - - [17/Sep/2010:06:29:22 +0000] "GET /assets/snippets/ajaxSearch/debug/ajaxSearch_log.txt HTTP/1.1" 200 4238 "-" "-"
           - - [17/Sep/2010:06:29:23 +0000] "POST /index-ajax.php HTTP/1.1" 200 3900 "-" "-"
           - - [17/Sep/2010:06:29:23 +0000] "POST /index-ajax.php HTTP/1.1" 200 3893 "-" "-"
           - - [17/Sep/2010:06:29:23 +0000] "GET /assets/modules/docmanager/tv.php HTTP/1.1" 200 12604 "-" "-"
           - - [17/Sep/2010:06:29:23 +0000] "GET /assets/modules/docmanager/inc.php HTTP/1.1" 200 12133 "-" "-"
           - - [17/Sep/2010:06:29:24 +0000] "POST /assets/modules/docmanager/inc.php HTTP/1.1" 200 12456 "-" "-"

                    I’ll post more info if I discover anything else.

                      MODx Evolution/Revolution | Remote Desktop Training | Development
                    • Hey Everett,

                      thanks for posting the fix! smiley