Website Security | White Fir Design Blog

Be Careful With Your Website’s Backup Files

When a high profile website gets hacked it always useful to see what lessons can be gleamed to insure that other websites don’t get hacked. Several days ago the technology website Ars Technica (who doesn’t have the best track record with security reporting) was breached, while the details on how they were hacked are somewhat limited, one thing stood out (emphasize ours):

At 20:00 CT on December 14, an Internet intruder gained access to one of the Ars Web servers and spent the next hour attempting to get from the Web server to a more central machine. At 20:52, the attempt was successful thanks to information gleaned from a poorly located backup file.

That is a good reminder that since backup files often store sensitive information (including database login details and user info), securely storing them is important to the security of your website. For example, you would not want to store the backup in a file named backup.zip in the root of your website since hackers will go looking for that as can be seen in the log file entries below from a recent attempt to find backup files on our website:

124.231.26.79 – – [03/Dec/2014:04:11:07 -0500] “HEAD /www.whitefirdesign.com.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:07 -0500] “HEAD /www.whitefirdesign.com.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:08 -0500] “HEAD /www.whitefirdesign.com.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:09 -0500] “HEAD /www.whitefirdesign.com.sql HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:10 -0500] “HEAD /whitefirdesign.com.rar HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:12 -0500] “HEAD /whitefirdesign.com.zip HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:12 -0500] “HEAD /whitefirdesign.com.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:14 -0500] “HEAD /whitefirdesign.com.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:15 -0500] “HEAD /whitefirdesign.com.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:15 -0500] “HEAD /whitefirdesign.com.sql HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:16 -0500] “HEAD /whitefirdesign.rar HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:17 -0500] “HEAD /whitefirdesign.zip HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:18 -0500] “HEAD /whitefirdesign.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:19 -0500] “HEAD /whitefirdesign.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:20 -0500] “HEAD /whitefirdesign.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:20 -0500] “HEAD /whitefirdesign.sql HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:21 -0500] “HEAD /back.rar HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:22 -0500] “HEAD /back.zip HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:23 -0500] “HEAD /back.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:23 -0500] “HEAD /back.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:24 -0500] “HEAD /back.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:25 -0500] “HEAD /back.sql HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:26 -0500] “HEAD /backup.rar HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:27 -0500] “HEAD /backup.zip HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:28 -0500] “HEAD /backup.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:29 -0500] “HEAD /backup.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:30 -0500] “HEAD /backup.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:31 -0500] “HEAD /backup.sql HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:31 -0500] “HEAD /web.rar HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:32 -0500] “HEAD /web.zip HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:33 -0500] “HEAD /web.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:34 -0500] “HEAD /web.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:35 -0500] “HEAD /web.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:35 -0500] “HEAD /web.sql HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:36 -0500] “HEAD /webroot.rar HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:37 -0500] “HEAD /webroot.zip HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:38 -0500] “HEAD /webroot.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:39 -0500] “HEAD /webroot.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:40 -0500] “HEAD /webroot.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:41 -0500] “HEAD /webroot.sql HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:41 -0500] “HEAD /www.rar HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:42 -0500] “HEAD /www.zip HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:43 -0500] “HEAD /www.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:44 -0500] “HEAD /www.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:45 -0500] “HEAD /www.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:46 -0500] “HEAD /www.sql HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:46 -0500] “HEAD /wwwroot.rar HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:48 -0500] “HEAD /wwwroot.zip HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:48 -0500] “HEAD /wwwroot.7z HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:49 -0500] “HEAD /wwwroot.xls HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:50 -0500] “HEAD /wwwroot.xlsx HTTP/1.1” 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:51 -0500] “HEAD /wwwroot.sql HTTP/1.1” 404 506 “-” “-”

Unfortunately not every risk is that easy to spot, take for example a vulnerability in the XCloner – Backup and Restore WordPress plugin that we discussed last week that allowed any logged in user to download any backups made by the plugin.

Hackers Still Trying To Exploit Joomla 1.5 Vulnerability Fixed Six Years Ago

We were recently checking something in our analytics and noticed that a rather odd URL had been accessed. The URL, http://www.whitefirdesign.com/blog/?option=com_user&view=reset&layout=confirm, was for a section of our website running WordPress but the URL parameter, ?option=com_user&view=reset&layout=confirm, was for something Joomla related based on the “com_user” portion. A quick search identified that this was an attempt to exploit a vulnerability in older versions of Joomla. What is interesting about this is that the vulnerability was fixed in Joomla 1.5.6, which was released in August of 2008. Since most hacking attempt will not show up in analytics – due to them not requesting the tracking code – we were curious to see if there had been other attempts to exploit this that would show up in our access logs. We found that in the last six months there were attempts to exploit the vulnerability on 48 days. So hackers still feel there are enough Joomla website that haven’t been updated in six years to try to exploit it regularly.

There are a couple of quick takeaways from this. One is that is that if you still have websites running Joomla 1.5, for which support ended in September of 2012, you should make sure they have been upgraded to the last version, 1.5.26, and had the additional security fix applied so that they are protected against attempts to exploit any vulnerabilities in older versions. The other is that you don’t need concerned just because there has been an attempt to exploit a vulnerability on your website, considering that in this case a hacker tried to a vulnerability in very old versions of Joomla on a website running WordPress.

Automatically Updating Plugins in WordPress

In WordPress 3.7 a new feature was introduced that causes WordPress to automatically apply minor updates to WordPress (for example, going from 3.7 to 3.7.1). The underlying system that handles that also supports doing automatic updates for major updates, plugin updates, and theme updates as well. The reason for limiting it to minor updates by default makes a lot of sense, because there is a process in place for minor updates to make sure there is a little chance as possible for something going wrong. The lead developer of WordPress describes the process as:

Background updates are incredibly, incredibly safe. Sites already running WordPress 3.7 have attempted more than 110,000 updates without a single critical failure, thanks to a number of verification steps that have made updates that much more reliable. A background update for a minor or security release (which is all they are enabled for, by default) means downloading and copying over just a few files. We’ve gotten really good at that. We’ve also spent years honing our craft of shipping stable and targeted fixes in minor releases — we don’t indiscriminately backport bug fixes. They must be serious bugs, and fixes go through additional levels of review, including at least two lead developers. And, we have the ability to roll out an automatic update over a period of hours or days. For 3.7.1, we’ll likely see how a few hours of user-initiated updates go before telling about 1% of sites to update, then steadily increase that percentage.

Depending on the situation of an individual website enabling other updates to occur automatically as well makes sense. Keeping plugins up to date is an important as it prevents the website from being exploited due to a vulnerability in an outdated version of the plugin. At this point we haven’t seen a vulnerability in WordPress that is likely to lead to the average website being hacked in years, but with plugins that isn’t the case. So keeping plugins up to date is at least as important as keeping WordPress up to date. If you use plugins that have a good track record of not breaking after an update (we haven’t had any issues with the plugins we use on our blogs over many years) then it can make sense to turn on automatic updates for plugins.

Turning on automatic plugin updates can be accomplished by adding the following line to functions.php of your current theme:

add_filter( 'auto_update_plugin', '__return_true' );

If you prefer not to modify your theme you have another option with our new plugin, Automatic Plugin Updates, which enables automatic plugin updates along with providing a couple of additional features. The lesser additional feature is that it turns on email notifications for those automatic plugin updates (this can be disabled). The bigger feature is that it enables disabling automatic updates for selected plugins. This can be useful if you have modified plugins in use or if you have plugins that you are more concerned that an update could cause problems with the website. While you can roll your own code to do this as well, with our plugin you don’t have to worry about changes being made in the process of handling excluding plugin from automatic updates. As of the current beta of WordPress 3.9 the process has changed from previous versions, causing code written for the old versions to not stop the automatic update from happening, and our plugin is already ready to handle that if the change remains in the production release of 3.9. Both of the additional features can be accessed on the plugin’s setting page:

Automatic Plugin Updates Settings Page

Migrating From Joomla 1.5 Won’t Necessarily Clean Up a Hack

Fairly often we have people contacting us about doing an upgrade of software on a website, which they are hoping will resolve a hacking or other security issue. Unfortunately in most instances they don’t tell us that is why they want an upgrade done. In the worst case this could cause the upgrade to get messed up if the hack has made modifications to things that are affected by the upgrade. In many cases the upgrade isn’t going to fully resolve the issue and may not have any impact at all. For example, if a website was running Joomla 1.6, 1.7, or 2.5.0-2.5.2 and it got hacked due to the privilege escalation vulnerability in those versions, which allows someone registering a new account to escalate their account to “Administrator” level, upgrading would prevent new accounts with those privileges from being created but the existing accounts would still exist. Those accounts can be deleted, but you have to know they exist to do that. The upgrade also might overwrite other modifications the hacker(s) made to the website, but it might not.

For website still running Joomla 1.5 the website cannot be upgraded to a newer version. Instead a more complicated migration, which move content from the Joomla 1.5 installation to a new install of Joomla 2.5 or 3. Despite support for that version ending in September of 2012, the version is still widely used and we recently have been contacted about a lot of hacked website that are still running Joomla 1.5. Since the migration leaves a lot of the website behind it would reasonable to wonder if a migration will resolve the hack. A website we were just dealing is reminder that isn’t the case.

There are three major areas where parts of the hack could move over during the migration. First a common place for placing malicious files is in a website’s images folder, which is something that will move over to new website. Another common area where malicious code is placed is in theme files. While Joomla 1.5 themes are not directly compatible with newer versions of Joomla, some can be easily converted to the new version either by hand or with automated tools. The third area, which is where malicious code was in this situation, is the in the database. In this case the malicious HTML code had been added to the content of a number of articles, which was moved over during the migration.

The malicious HTML code (shown below) was relatively harmless; it just added a link to a spam page to the page and used JavaScript code to hide the link. While this won’t harm someone visiting the page, it can lead to Google placing a “This site may be hacked” label in their search results and the lowering the website’s ranking. It was also causing the AVG antivirus software to alert for Exploit Blackhat SEO (type 1703), which is likely to scare away some visitors.

Source Code of Hidden Spam Hack

All the Exploit Attempts Security Products Stop Don’t Necessarily Mean Much

When it comes to the poor state of website security we have a situation where basic security measures often are not taken but security products of questionable value are proliferating. What we see in dealing with websites that have been hacked is that it is harder to get someone to make sure that proper security practices are being taken then it would be to sell them on these questionable security products. One of the things we see that really sells people on these security products is that they will highlight that they have stopped numerous attempts to exploit a website. It sounds impressive, but in reality they may not be stopping anything at all. Let’s take look at an example of why this information doesn’t mean much.

JCE is a popular extension for Joomla. Older versions had a serious security vulnerability that was fixed in August of 2011. For people that used JCE the simple way to protect themselves against the vulnerability was to keep their software up to date. For anyone not running JCE they didn’t need to do anything since it wouldn’t impact them at all. We would fall in to that second category as we haven’t used Joomla on our website, so there is no chance that we would be running JCE. That hasn’t stopped hackers from attempting to exploit the vulnerability on our website. In March for example our logs recorded 16365 attempts (or about 528 attempts per day) to exploit the vulnerability. Here are the numbers of attempts our logs show for the last six months:

October: 277
November: 362
December: 674
January: 6551
February: 17050
March: 16365

Even in the month with the lowest attempts we had an average about 9 attempts a day. If you are not familiar with the vulnerability and the fact that unless a website was running a fairly out of date version of JCE there is no chance of being exploited then it would certainly sound scary that there were so many attempts. It also wouldn’t seem unreasonable that you would recommend the product to others.

While we wouldn’t recommend security products for most websites (those basic security measures are all that you will need), what you should look at when considering these products is if they have independent testing results showing that they do in have fact protect against vulnerabilities that wouldn’t be stopped by taking basic security measures. You should also consider if they will even protect against threats you face. For example a product designed to protect against exploiting software on your website isn’t going to stop someone from getting in via FTP or from exploiting a web host’s poor security.

Norton Secured Seal Service Doesn’t Do Basic Security Check

Three years ago we posted about the fact that trust marks shown on websites that claim to certify that the websites are secure cannot be trusted to identify if a website is actually secure for a number of reasons, including that in many cases they scan the websites from the outside so there are many things that they would never detect. What we recently noticed is that the Norton Secure Seal service fails to do a really basic security check that can be done from the outside. When it comes to the security of websites one of the basic security measures is to keep the software running the website up to date. This prevents the website from being hacked to the exploitation of a known vulnerability in the software that has been fixed in a subsequent release. As we have found the Norton Secure Seal service doesn’t check to make sure the software running the website they are claiming is secure is up to date.

As an example of this we will take a look at the website of an IT security company that carries the Norton Secure Seal as you can see here:

Norton Secure Seal

Using our Joomla Version Check web browser extension you can see that the website is running an outdated version of Joomla:

That version of Joomla, 3.1.1, is seven months out of date and more importantly subsequent versions have fixed four security vulnerabilities, including a vulnerability rated as having critical severity and a vulnerability rated as having high severity. A website with that level of security issue should not be labeled as being secure.

The technology our web browser extension uses to detect that Joomla is powering a web page and what version is in use is rather simple and there is no excuse for a major company such as Symantec, the maker of the Norton Secured Seal service, not being able to do the same. Providing more awareness that an outdated version of Joomla is in use is definitely needed as outdated versions of Joomla are widely used, including among companies that provide security services for Joomla websites, and some older versions contain a vulnerability that is being exploited by hackers.

It isn’t just Joomla that Norton Secured Seal service doesn’t check to make sure is up to date; the same website has a blog running an outdated and insecure version of WordPress as well:

Vulnerability in Joomla 1.6, 1.7, and 2.5.0-2.5.2 Being Exploited Now

When people contact us about hacked website they often state that there website must have been hacked due to running an outdated version of a CMS (WordPress, Joomla, Drupal, etc.). In most cases this isn’t true; there are a number of other issues that lead to most hackings. Unfortunately there are a lot of people providing security advice – including web hosts and security companies – who don’t know what they are talking about that will tell people that website must have been hacked due to an outdated CMS without actually determining that, which likely leads to the people contacting us believing that. Because we actually determine how a website gets hacked we actually know when it is a vulnerability in an outdated version of a CMS that is at fault and it is worth mentioning.

Based on a website we just cleaned up we can see that a vulnerability that existed in Joomla 1.6, 1.7, and 2.5.0-2.5.2 is actively being exploited now. The vulnerability isn’t new; it was publicly disclosed on March 15, 2012. Exploitation of the vulnerability isn’t new either; we found that the website had also been exploited in July and August of last year. The vulnerability allows a hacker to register a new user with “Administrator” privileges and then they can use the access provided by that user for malicious purposes. The best way to protect your website against the vulnerability is to upgrade to the latest version of Joomla 2.5, as number of other security issues have been fixed in subsequent version. If you are unable to do that in a timely manner, disabling user registration should protect the website as that will block a hacker from being able to register a new user.

Determining How a Website Got Hacked

One of the first things we do when trying to determine how a website is hacked is to look over the files. Most hacks are contained in the files and the metadata and location of the files can provide important information. In some cases the ownership of the file will point to a possible source. In other cases the last modified date on the file can be used to narrow where we need to start looking in the log files for indication of the source. In some cases the hacker sets the last modified dates on files to match other files so that cannot be done. If a hacker is using a backdoor script that they placed on the website, which allows them remote access to the website, we can find that access in the logs. In this case the last modified dates had not been tampered with by the hacker and backdoor script had been accessed, so we had a good starting point.

First up we spotted the first access to the backdoor script in the log of requests to the website (we replaced some of the identifying information from the log entries shown):

78.47.55.70 – – [07/Jan/2014:03:53:31 -0700] “GET example.com/modules/mod_administrator/config.php HTTP/1.1” 200 189 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 9 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/modules/mod_administrator/config.php” 11922

The entries right before that shed more light on the situation. They show that the same person had just logged in to the administrator area of Joomla and installed an extension. The extension they installed would have contained the backdoor script that they would access right afterwards.

78.47.55.70 – – [07/Jan/2014:03:53:22 -0700] “GET example.com/administrator/index.php HTTP/1.1” 200 4362 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 0 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 1344521
78.47.55.70 – – [07/Jan/2014:03:53:23 -0700] “POST example.com/administrator/index.php HTTP/1.1” 303 220 “http://example.com/administrator/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 1 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 536578
78.47.55.70 – – [07/Jan/2014:03:53:24 -0700] “GET example.com/administrator/index.php HTTP/1.1” 200 31537 “http://example.com/administrator/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 2 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 1282790
78.47.55.70 – – [07/Jan/2014:03:53:26 -0700] “GET example.com/administrator/index.php HTTP/1.1” 200 31537 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 3 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 231378
78.47.55.70 – – [07/Jan/2014:03:53:27 -0700] “GET example.com/administrator/index.php?option=com_installer HTTP/1.1” 200 23546 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 4 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 743778
78.47.55.70 – – [07/Jan/2014:03:53:28 -0700] “POST example.com/administrator/index.php?option=com_installer&view_install HTTP/1.1” 303 504 “mainaadmin/administrator/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 5 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 1080171
78.47.55.70 – – [07/Jan/2014:03:53:29 -0700] “GET example.com/administrator/index.php?option=com_installer&view=install HTTP/1.1” 200 23817 “mainaadmin/administrator/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 6 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 199474
78.47.55.70 – – [07/Jan/2014:03:53:29 -0700] “POST example.com/administrator/index.php HTTP/1.1” 200 23554 “http://example.com/administrator/index.php?option=com_installer” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 7 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 500162
78.47.55.70 – – [07/Jan/2014:03:53:30 -0700] “GET example.com/administrator/index.php?option=com_installer&view_install HTTP/1.1” 200 23529 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 8 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 172137

Those log entries contained the username of the user that had accessed the admin, mainaadmin. With that we could take a look at the details for that user in the database to get some idea of if the user is an account that was comprised or a malicious account. The email address, ivan.kachelya@yandex.ru, was from a Russian website, so that made it likely that it was a malicious user as the website is a locally focused US website with a webmaster in the US. Also included in the data is the date the account was registered, which we could then use to see how the account was created in the log file.

The log files showed the user being created through the User Registration page:

94.244.157.180 – – [04/Jan/2014:07:43:34 -0700] “GET example.com/index.php?option=com_users&view=registration HTTP/1.1” 200 9676 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 0 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 2302755
94.244.157.180 – – [04/Jan/2014:07:43:36 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 1 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 409104
94.244.157.180 – – [04/Jan/2014:07:43:37 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9611 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 2 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 279085
94.244.157.180 – – [04/Jan/2014:07:43:37 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 247 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 3 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 1082792
94.244.157.180 – – [04/Jan/2014:07:43:38 -0700] “GET example.com/component/users/?view=registration&layout=complete HTTP/1.1” 200 5977 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 4 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 290820
94.244.157.180 – – [04/Jan/2014:07:43:39 -0700] “GET example.com/index.php?option=com_user&view=register HTTP/1.1” 302 201 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 5 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 125098
94.244.157.180 – – [04/Jan/2014:07:43:39 -0700] “GET example.com/index.php?option=com_content&view=article&id=26&Itemid=162 HTTP/1.1” 200 14916 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 6 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 799530
94.244.157.180 – – [04/Jan/2014:07:43:40 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 7 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 586594
94.244.157.180 – – [04/Jan/2014:07:43:41 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 8 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 496821
94.244.157.180 – – [04/Jan/2014:07:43:44 -0700] “GET example.com/index.php?option=com_users&view=registration HTTP/1.1” 200 9539 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 9 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 288962
94.244.157.180 – – [04/Jan/2014:07:43:44 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 10 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 306529
94.244.157.180 – – [04/Jan/2014:07:43:45 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9611 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 11 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 294107
94.244.157.180 – – [04/Jan/2014:07:43:45 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 12 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 305668
94.244.157.180 – – [04/Jan/2014:07:43:46 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9609 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 13 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 278854
94.244.157.180 – – [04/Jan/2014:07:43:46 -0700] “GET example.com/index.php?option=com_user&view=register HTTP/1.1” 302 201 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 14 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 61939
94.244.157.180 – – [04/Jan/2014:07:43:47 -0700] “GET example.com/index.php?option=com_content&view=article&id=26&Itemid=162 HTTP/1.1” 200 14722 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 15 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 298259
94.244.157.180 – – [04/Jan/2014:07:43:47 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 16 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 497553
94.244.157.180 – – [04/Jan/2014:07:43:48 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 17 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 527134
94.244.157.180 – – [04/Jan/2014:07:43:50 -0700] “GET example.com/index.php?option=com_users&view=registration HTTP/1.1” 200 9601 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 18 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 263082
94.244.157.180 – – [04/Jan/2014:07:43:51 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 19 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 313744
94.244.157.180 – – [04/Jan/2014:07:43:51 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9611 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 20 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 291806
94.244.157.180 – – [04/Jan/2014:07:43:52 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 21 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 335271
94.244.157.180 – – [04/Jan/2014:07:43:52 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9609 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 22 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 279791
94.244.157.180 – – [04/Jan/2014:07:43:53 -0700] “GET example.com/index.php?option=com_user&view=register HTTP/1.1” 302 201 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 23 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 78710
94.244.157.180 – – [04/Jan/2014:07:43:53 -0700] “GET example.com/index.php?option=com_content&view=article&id=26&Itemid=162 HTTP/1.1” 200 14722 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 24 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 364741
94.244.157.180 – – [04/Jan/2014:07:43:54 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 25 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 475204
94.244.157.180 – – [04/Jan/2014:07:43:54 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 26 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 502942

Normally a user created that way would not be an “Administrator”, which this user was, so we checked to make sure that the registration settings had not been set to do that and there were not. The question then was how the user became an “Administrator”. A likely source would be a privilege escalation vulnerability that would allow a lower level user to change their account to have “Administrator” privileges. A quick check for Joomla privilege escalation brought the vulnerability we mentioned earlier. The Joomla version in use was a vulnerable version and the log of the user registration appears to match with what needs to be done to exploit the vulnerability, so we then had the likely source of the hack.

Hackers Still Targetting Outdated PHP Versions

Back in May we discussed a website we cleaned up that had been hacked due the exploitation of a vulnerability in the outdated version of PHP being used on the server. The hack would have prevented if PHP had been kept up to date, but based on the fact that we have recently had numerous attempts to exploit the vulnerability there must a fair number of website still being run on vulnerable versions.

The vulnerability in question was fixed in versions 5.3.13 and 5.4.3 and only impacts CGI-based setups. The most recent releases of PHP – 5.3.28, 5.4.23, and 5.5.7 – all include security updates, so PHP should be upgraded to those versions as soon as possible.

If you are wondering what version of PHP your web host is using for your website there are a number of ways to find that out. The least technical way to do that is to contact their customer support and ask them what version of PHP in use. It would also be good to ask them what their upgrade policy is for PHP and other software powering the web server, to make sure that they properly handling that. You can sometimes find the PHP version in use in the control panel for your website or the administrative area of the website. You can also use a tool we have created that allows you to check the version of various software running the server your website is on.

An example of the requests we have been seeing recently is included below. One change from the successful hack we mentioned in the previous post is that the requests are encoded in this instance. That could be to make it harder for software attempting to filter malicious requests to detect that the requests are malicious.

209.139.209.78 – – [31/Dec/2013:23:38:21 -0500] “POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1” 301 2347 “-” “Googlebot/2.1 (+http://www.googlebot.com/bot.html)”

209.139.209.78 – – [31/Dec/2013:23:38:22 -0500] “POST /cgi-bin/php5?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1” 301 2347 “-”

“Googlebot/2.1 (+http://www.googlebot.com/bot.html)”
209.139.209.78 – – [31/Dec/2013:23:38:23 -0500] “POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1” 301 2347 “-” “Googlebot/2.1 (+http://www.googlebot.com/bot.html)”

209.139.209.78 – – [31/Dec/2013:23:38:24 -0500] “POST /cgi-bin/php.cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1” 301 2347 “-” “Googlebot/2.1(+http://www.googlebot.com/bot.html)”

209.139.209.78 – – [31/Dec/2013:23:38:24 -0500] “POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1” 301 2347 “-” “Googlebot/2.1 (+http://www.googlebot.com/bot.html)”

Is Your Web Host Keeping PHP Up to Date?

When it comes to keeping your website secure your web host should be the least of your worries. These are technology companies, sometimes rather large, whose focus is on websites. You would think that they would be better at handling website security than anyone other security professionals. Unfortunately we often find that they are not. As just one example, last year we discussed the fact that Media Temple was incorrectly blaming a hack of websites hosted by them on their customers running outdated software on their websites, while they themselves were running outdated software on their website. Over a year later they are still are not bothering to take the basic step of keeping software running on their website up to date:

Trying to access the security of web hosts is difficult because much of the information needed to do that assessment is only available to them. There are some things that you can check on and one of those is whether they are keeping the version of PHP on the server hosting your website up to date. If you are using WordPress, Joomla, Drupal, or a lot of other web software then you are using PHP and it is important to keep that up to date, as a hacked website we cleaned up this week shows.

One of the basic steps of cleaning up a hacked website is determining how it was hacked and then fixing the vulnerability so that the website doesn’t get hacked again (unfortunately, many companies that clean up hacked websites cut corners and don’t do this). In reviewing the log files for the website in question we traced the original exploitation to this line in the website’s access log:

91.224.160.25 – – [16/Apr/2013:19:18:32 -0400] “POST /?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input HTTP/1.1” 200 68

What that shows is that a vulnerability in PHP versions prior to 5.3.13 and 5.4.3 was attempting to be exploited. Unfortunately the website in question was running an older vulnerable version of PHP and was configured in a way that made it susceptible to the vulnerability. If PHP had been kept up to date the website would not have been hacked.

The PHP developers fairly regularly release new versions that fix security vulnerabilities in the software. The most recent releases with security fixes were versions 5.3.23 and 5.4.13, released in March. Unfortunately, we often find that our client’s web hosts are not keeping PHP up to date. If your web host isn’t keeping PHP updated you probably should move to a web host that takes such basic security seriously.

Web Hosts Blocking Access to WordPress Login Page

We have had a number of people contact us about having issues gaining access to the login page in WordPress recently and we wanted to pass along information that affected websites should be getting told by their web hosts as well by now. There has recently massive attempt to brute force the login for WordPress based websites. Hostgator describes it as being a highly-distributed and global attack. While hackers have been attempting to gain access to website, whether using WordPress or a variety of other software, that use weak passwords for years, the big issue here is that the massive size of attempts is causing high load on servers and that has caused web hosts to block access to the WordPress login page while attempting to deal with this. If your website is hosted on a server shared with websites being targeted it can impact your websites even if you are not targeted.

Hostgator has reported seeing over “90,000 IP addresses involved in this attack”, which means that a web host cannot simple block a few IP address to stop the attempts. That also provides a reminder that limiting login attempts by blocking IP addresses after several failed attempts has a serious limitation as security feature when massive amount of IP address are available for an attack.

While security of the login process can be improved by restricting login access to certain IP addresses or using multi-factor authentication, websites can prevent an un-targeted login attack by making sure only strong passwords are used.