Quite often with hacked websites outdated software is pointed to as the source of the hack. That is usually a claim that is made without any knowledge if the claim is actually true. Many security companies that market themselves as having unique expertise in dealing with hacked websites don’t even attempt to determine how websites are hacked, despite that being one of the three key components of a proper cleanup, so they would have no idea what the cause might be. Often times these companies don’t seem to even have a cursory knowledge of what they are talking about either, as an example, one well known security company, Sucuri, once told people to update software despite it being well known that the vulnerability being exploited in the software was in the then current version of the software (that kind of thing somehow never stopped journalists from repeating misleading and false claims made by that company or people claiming that they are a reputable company).
From what we have seen those baseless claims are usually easy to spot as there usually isn’t even a specific vulnerability that is pointed to as being the cause of the hack, which should be something known if someone has actually done the work to determine the source of the hack and determined it was outdated software.
As example of finding out that outdated software was actually the cause of a hack, we were recently brought in to clean up a hacked MODX website. MODX websites have not been a common type of website needing cleanups from us recently, so the software in use on the website was of some note right away.
In trying to determine how a website was hacked the logging is probably the most important resource, but the files can often tell you a lot, and both of them can work together to speed up the process. In the case of this website there was an obviously malicious file named dbs.php in the root directory of the website. That file had also had a number of POST requests made to it, which are requests that contain additional data and of which most requests sent by hackers are of that type, sent to it shortly before we started the cleanup. Looking back at the logging to where that file was first requested we found it in a set of requests sent by an IP address from Ukraine:
134.249.50.5 – – [19/Jul/2018:19:55:23 -0400] “GET / HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”
134.249.50.5 – – [19/Jul/2018:19:55:23 -0400] “POST /connectors/system/phpthumb.php HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”
134.249.50.5 – – [19/Jul/2018:19:55:24 -0400] “GET /dbs.php HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”
The first request there is for the homepage of the website. The second one sends a POST request to a file /connectors/system/phpthumb.php. Finally there is a request for the dbs.php file. Based on that, it would appear that the file phpthumb.php would be the vector for adding the dbs.php file.
In reviewing the file phpthumb.php there wasn’t anything in the file itself that looked like a vulnerability that would permit uploading a file as that series of requests would indicate was what the hacker would be attempting to do. In fact the file only contained four lines of code that just called on code in other files:
define('MODX_CONNECTOR_INCLUDED', 1); require_once dirname(dirname(__FILE__)).'/index.php'; $_SERVER['HTTP_MODAUTH'] = $modx->user->getUserToken($modx->context->get('key')); $modx->request->handleRequest(array('location' => 'system','action' => 'phpthumb')); |
Instead of digging through more code at that point we instead did a web search for “/connectors/system/phpthumb.php” and though that we got pointed to the issue. There was a post of the details of a vulnerability that matched what we had seen that was published on July 13 and what seems more important, code for exploiting the vulnerability that was released on July 18. On this website the first attempt to exploit it was one July 19, so it would seem the code to exploit it was quickly utilized by hackers.
That vulnerability had been fixed in version 2.6.5 of MODX, which was released on July 11, and the developers provided clear notice of the need to update due to security fixed in it. Writing in the release announcement
Today we released MODX Revolution 2.6.5. It contains fixes for two critical security vulnerabilities affecting all versions at or prior to 2.6.4. Upgrading to 2.6.5 should be considered mandatory.
and
Upgrading is Critical
Revolution 2.6.5 contains critical security enhancements, you should upgrade to 2.6.5 now. See below for more info.
We cannot stress the importance of diligently upgrading to the latest version of MODX enough. While no software is 100% secure, powering your site with the most current version usually helps protect you from hackers that rely on exploiting outdated software. If you’re not sure what version of MODX Revolution you’re running, log into your website Manager. If the version number doesn’t appear in the top left-hand corner of the Manager, go to Manage>Reports>System Info.
The two vulnerabilities refer to the ability to upload files and to remove files/directories. From the post with the details of the vulnerability it sounds like in version 2.5.1 to 2.6.4 the ability to exploit the file upload vulnerability would be more restricted than was the case with the website were dealing, which was running 2.4.1.
Cleaning Up After This Hack
On this website the hacker had done quite a number on it. The .htaccess file in the root directory had been removed, leading to all the pages other than the homepage to no longer being functional. That seems to have been done to remove any restriction in the .htaccess file that would have blocked the hacker from sending requests to the malicious files they were uploading. When trying to go to the admin area you would be redirected to another website due to the content of all of the JavaScript files on the website being replaced with malicious code.
The best option to clean up after this would be restore a clean back up from before the hack (making sure that all of the existing files are removed during the restoration). Seeing as the vulnerability wasn’t disclosed until July 13, a backup from before then would be a good option. You might be able to get way with one from before July 18 as well. A review of the logging by someone familiar with all of this would likely be able to confirm when the hacker hacked the website.
From what we could see from that website, it would appear that there are likely multiple hackers exploiting this vulnerability and doing different things, so it wouldn’t be possible to provide general instruction on what to remove from the website to clean up if there isn’t a backup available (though based on past experience that won’t necessarily stop someone from claiming to provide that and unintentionally or intentionally leading people astray).
If you are looking for a professional cleanup from this or any other hack of a MODX website we provide a service for that. We can also upgrade MODX for you.