We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 21112
    • 156 Posts
    I’m having problems, arrived at by a rather complex route.

    Currently, after an upgrade to 0.9.6.3, my site is loading just a blank page: http://neilcreek.com/

    A few days ago my site appeared to be blank. Logging in I saw that the index page was 0 bytes. I uploaded a new index.php to replace it, but I saw a new error at the bottom of my pages. I was using 0.9.6.2 and later learned I uploaded a 0.9.6 index.php. The error was complaining about not being able to find a file generated by the wpsupercache file, generated by a plugin to my wordpress blog installation on the same domain. I’ve had problems with this in the past, and disabling the plugin removed the error message. This time, however, the error message appeared with the plugin deactivated. I removed the plugin completely, but the error remained. Throughout all of these problems, the manager functioned perfectly.

    I decided to download and upgrade to 0.9.6.3, and did so by overwriting all the files in my existing installation and runnong the installation (in uprade mode) which completed successfully. No I can access the manager with all functions working, but the front page of the site (and any direct urls under ModX are loading as completely empty documents.

    I’m sure I’ve screwed up somewhere along the way. Does anyone have any ideas where I should look to fix this? Thanks in advance!
      • 21112
      • 156 Posts
      I’ve just noticed I’m getting intermittant errors through my blog now too, for example:

      Fatal error: Call to undefined function: wp_remote_get() in /nfs/c01/h03/mnt/33105/domains/neilcreek.com/html/blog/wp-includes/functions.php on line 1278
      Fatal error: Call to undefined function: wp_remote_request() in /nfs/c01/h03/mnt/33105/domains/neilcreek.com/html/blog/wp-includes/rss.php on line 540
      Fatal error: Call to undefined function: wp_remote_post() in /nfs/c01/h03/mnt/33105/domains/neilcreek.com/html/blog/wp-includes/cron.php on line 205

      These are happening intermittantly. The blog and dashboard load sometimes and not others. Could this be related? I’ve done nothing new to my wordpress installation for several weeks.
        • 3749
        • 24,544 Posts
        I get a server 500 error on the site. If you do a search for that, you’ll find lots of causes.

        I’m going to take a wild stab and suggest that the index.php and/or .htaccess in the root got their permissions changed on upload or install. If the server is running SuPHP or SuExec, they need to be 644 (and the directories 755). See if they have different permissions from the index.php file in the manager (or if the manager folder has different permissions than the root MODx folder).

        Another possibility is that the .htaccess file in the root has one or more php commands (e.g. php_flag), which can generate a 500 error if you host doesn’t allow that.

          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
          • 21112
          • 156 Posts
          Thanks for the reply.

          I checked the permissions and all files were set to 755. I changed the index.php and .htaccess in root to 644 as well as the index.php in the /manager directory. That didn’t have any effect.

          My .htaccess does have a php_flag command, but it always has, as far as I’ve known, and I haven’t changed anything recently. Perhaps the host has changed whether that is allowed?

          Here’s my full .htaccess (in root) if it helps:
          # MODx supports Friendly URLs via this .htaccess file. You must serve web
          # pages via Apache with mod_rewrite to use this functionality, and you must
          # change the file name from ht.access to .htaccess.
          #
          # Make sure RewriteBase points to the directory where you installed MODx.
          # E.g., "/modx" if your installation is in a "modx" subdirectory. If you have
          # problems with your .htaccess working at all, try un-commenting the first 
          # line above the "RewriteEngine On" directive.
          #
          # You may choose to make your URLs non-case-sensitive by adding a NC directive
          # to your rule: RewriteRule ^(.*)$ index.php?q=$1 [L,QSA,NC]
          
          #Options +FollowSymlinks
          RewriteEngine On
          RewriteBase /
          
          
          
          # Rewrite www.domain.com -> domain.com -- used with SEO Strict URLs plugin
          #RewriteCond %{HTTP_HOST} .
          #RewriteCond %{HTTP_HOST} !^www.neilcreek\.com [NC]
          #RewriteRule (.*) http://www.neilcreek.com/$1 [R=301,L]
          #
          # or for the opposite domain.com -> www.domain.com use the following
          # >>> DO NOT USE BOTH THE ABOVE AND BELOW <<<
          #
          #RewriteCond %{HTTP_HOST} .
          #RewriteCond %{HTTP_HOST} !^www\.example-domain-please-change\.com [NC]
          #RewriteRule (.*) http://www.example-domain-please-change.com/$1 [R=301,L]
          
          
          
          # Rewrite secure requests properly to prevent SSL cert warnings, e.g. prevent 
          # https://www.domain.com when your cert only allows https://secure.domain.com
          #RewriteCond %{SERVER_PORT} !^443
          #RewriteRule (.*) https://neilcreek.com/$1 [R=301,L]
          
          
          
          # The Friendly URLs part
          RewriteCond %{REQUEST_FILENAME} !-f
          RewriteCond %{REQUEST_FILENAME} !-d
          RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
          
          
          
          # Make sure .htc files are served with the proper MIME type, which is critical 
          # for XP SP2. Un-comment if your host allows htaccess MIME type overrides.
          
          #AddType text/x-component .htc
          
          
          
          # If your server is not already configured as such, the following directive
          # should be uncommented in order to set PHP's register_globals option to OFF.
          # This closes a major security hole that is abused by most XSS (cross-site
          # scripting) attacks. For more information: http://php.net/register_globals
          #
          # To verify that this option has been set to OFF, open the Manager and choose
          # Reports -> System Info and then click the phpinfo() link. Do a Find on Page
          # for "register_globals". The Local Value should be OFF. If the Master Value
          # is OFF then you do not need this directive here.
          #
          # IF REGISTER_GLOBALS DIRECTIVE CAUSES 500 INTERNAL SERVER ERRORS :
          #
          # Your server does not allow PHP directives to be set via .htaccess. In that
          # case you must make this change in your php.ini file instead. If you are
          # using a commercial web host, contact the administrators for assistance in
          # doing this. Not all servers allow local php.ini files, and they should
          # include all PHP configurations (not just this one), or you will effectively
          # reset everything to PHP defaults. Consult www.php.net for more detailed
          # information about setting PHP directives.
          
          php_flag register_globals Off
          
          
          
          # For servers that support output compression, you should pick up a bit of
          # speed but un-commenting the following lines.
          
          #php_flag zlib.output_compression On
          #php_value zlib.output_compression_level 5
          
          
          
          # The following directives stop screen flicker in IE on CSS rollovers. If
          # needed, un-comment the following rules. When they're in place, you may have
          # to do a force-refresh in order to see changes in your designs.
          
          #ExpiresActive On
          #ExpiresByType image/gif A2592000
          #ExpiresByType image/jpeg A2592000
          #ExpiresByType image/png A2592000
          #BrowserMatch "MSIE" brokenvary=1
          #BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
          #BrowserMatch "Opera" !brokenvary
          #SetEnvIf brokenvary 1 force-no-vary
          
          DirectoryIndex index.php index.html index.htm
          
          #Options +FollowSymlinks
          
          RewriteEngine On
          
          RewriteBase /
          
          # The Friendly URLs part
          
          RewriteCond %{REQUEST_FILENAME} !-f
          
          RewriteCond %{REQUEST_FILENAME} !-d
          
          RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
          
            • 3749
            • 24,544 Posts
            Try commenting out the php_flag line. If it works, you’ll have to make sure register_globals is turned off another way (i.e. "register_globals off" in the php.ini file).

            You should also check the MODx error log and the server error logs to see if they contain any clues.

            It’s also possible that there’s a corrupted file somewhere in your 9.6.3 upload, although it’s less likely with the Manager working.

            BTW, you did do an upgrade install after putting up the 9.6.3 files, right?

              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
              • 21112
              • 156 Posts
              Commenting out the php_flag line had no effect.

              Here’s the most recent wrror in the log, the last several dozen errormessages appear to be the same:

              « MODx Parse Error »
              MODx encountered the following error while attempting to parse the requested resource:
              « PHP Parse Error »
               
              PHP error debug
                Error: 	gzinflate() [function.gzinflate]: buffer error	 
                Error type/ Nr.: 	Warning - 2	 
                File: 	/nfs/c01/h03/mnt/33105/domains/neilcreek.com/html/blog/wp-config.php(1) : eval()'d code	 
                Line: 	1	 
               
              Parser timing
                MySQL: 	0.0123 s	(7 Requests)
                PHP: 	0.1046 s	 
                Total: 	0.1169 s	 


              I’m not sure where to get my server error logs. I’m on a third party hosted virtual server at Media Temple.

              Yes, I successfully ran the upgrade install after re-uploading the 9.6.3 files, and the install directory was removed.

              Thank you for your continued assistance!
                • 22303 MODX Staff
                • 10,725 Posts
                neilcreek, check the first line of your wp-config.inc.php -- I think your account has been compromised by c99madshell or a similar exploit, or you have an invalid character in the first line of that file.
                  • 21112
                  • 156 Posts
                  I think you may be right. I found blibks of machine code at the start of wp-config.php and wp-config-sample.php. I couldn’t fine wp-config.ing.php however, nor did a google search return the path. Where would I find this file?

                  I removed the offending code, but my site is still invisible and my blog still gives intermittant errors. Should this have solved the problems?

                  Are there any other files I need to check? Do I need to do anything else to repair the damage done by the exploit? Is there any way to prevent it from happening again?

                  If my ongoing problem is not caused by this exploit (as it still persists) can you suggest another solution?

                  Thanks very much for making me aware of the issue!
                    • 22303 MODX Staff
                    • 10,725 Posts
                    Quote from: neilcreek at May 26, 2009, 09:02 AM

                    I think you may be right. I found blibks of machine code at the start of wp-config.php and wp-config-sample.php. I couldn’t fine wp-config.ing.php however, nor did a google search return the path. Where would I find this file?
                    wp-config.php is the file I meant, sorry.

                    Quote from: neilcreek at May 26, 2009, 09:02 AM

                    I removed the offending code, but my site is still invisible and my blog still gives intermittant errors. Should this have solved the problems?

                    Are there any other files I need to check? Do I need to do anything else to repair the damage done by the exploit? Is there any way to prevent it from happening again?

                    If my ongoing problem is not caused by this exploit (as it still persists) can you suggest another solution?

                    Thanks very much for making me aware of the issue!
                    Your welcome, but you are about to experience a very painful recovery, depending on the extent of the damage they did. Once c99madshell is successfully uploaded to a server, depending on the configuration of the server and the permissions, it is possible they a) deleted files via a pattern, like rm- R *log*, b) attempted to ssh in and gain root access to own the server, c) setup a porn site somewhere within your site, or d) any number of other nasty things (see http://www.derekfountain.org/security_c99madshell.php for more information on what this exploit is all about).

                    I feel for you; I spent last weekend recovering from this exploit, though ours was uploaded through an SMF vulnerability involving avatar/attachment uploads. It was really nasty, and we had to recover some files/data from old backups I had. For some folks, they have to completely wipe the machine and rebuild it from scratch.
                      • 21112
                      • 156 Posts
                      Ugh... That’s not what I wanted to hear. I had a look and found the same added code in two of my client’s sites, on different hosts each. How did this happen? Was there a loophope in the host’s security?

                      I’m not a server owner. All of my sites are hosted on third party hosts as virtual servers, shared with othre customers. What do I do? Should I ask the host to restore the site from an older backup? Do I need to get my host to find out what they did to the server with the exploit? I’m completely lost, and don’t know what to do to fix all this mess. The link you gave is very scary, but doesn’t show how to recover from the exploit.

                      This news has just made my day... sad