Category Archives: Website Security

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

Posted in Website Security, WordPress Plugins | Leave a comment

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

Posted in Joomla, Website Security | Leave a comment

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.

Posted in Website Security | Leave a comment

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:

Joomla Version Used on Website ShownThat 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:

The eGestalt blog is Running WordPress 3.5.2

Posted in Bad Security, Website Security | Leave a comment

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.

Posted in Joomla, Website Security | Leave a comment

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)”

Posted in Website Security | Leave a comment

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:

Media Temple's Sytem Status Website is Running WordPress 3.3.2

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.

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.

 

Posted in Website Security | Leave a comment

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.

Posted in Website Security, WordPress | Leave a comment

1&1 Running Nearly Seven Years Out of Date Version of phpMyAdmin

Two weeks ago we posted about FatCow was running an over six years out of date version of phpMyAdmin on their servers. In the post we mentioned that was the most out of date software we had seen in a long time, but that dubious distinction has now been taken by 1&1 and the nearly sevens years out of date version of phpMyAdmin they use. They are running phpMyAdmin 2.6.4-pl3, which was released on October 22, 2005. The subsequent version, a security update, was released on November 15, 2005.

1&1 tells their customers it is important to keep software up to date to avoid being hacked:

One way to avoid attacks, is to make sure to keep your programs
and scripts up-to-date. Check regularly for security warnings and
make sure to install security patches as they become available.

They obviously don’t listen to their own advice, but they do claim that they do:

1&1 system administrators work hard to make sure that our 1&1 servers are protected from known vulnerabilities by keeping all programs and services up-to-date with.

phpMyAdmin provides a page that provides a listing of all security announcements for the software (something that other software developers should also be providing). In 2005, there were three serious security vulnerabilities found that probably impact the version of phpMyAdmin 1&1 is running. The version probably contains most, if not all, of the 16 serious severity security issues and 1 considered “quite dangerous” fixed in 2006 and 2007, that we counted that impact in the version used FatCow. And the version probably contains more vulnerabilities that were fixed in later years.

Posted in Website Security | 1 Comment

FatCow Running Over Six Years Out of Date Version of phpMyAdmin

One of the most basic measures for keeping websites secure is to keep software running the website up to date, this is something that web hosts know and tell their customers. Unfortunately, many web host don’t seem to feel that they need to heed their own advice and run out of date software on their servers. This put their clients at risk of being hacked though exploitation of a known vulnerability in that software. Their use of outdated software also a warning sign that they may not be handling the rest of the security properly as well.

When we do work on a client’s website we do a check of what version of some common software (PHP, MySQL, phpMyAdmin, etc.) is running of the server. This is partly so that we can see how well web hosts are doing at keeping that software up date and also so that we can alert the clients when severely out of date software is in use. We continue to see that in many cases web hosts’ servers are running out of date versions of that common software, with known security vulnerabilities. The good news is that for most part we are seeing that the software is less out of date then it has been in the past. That made something we saw while checking a FatCow server in the past few days stick out. The server was using phpMyAdmin 2.8.0.1. That version was released on March 8 of 2006 and the next version, 2.8.0.2, was released eight days later. If over six years out of date hasn’t been the most out of date we have ever come across, it at least the most out of date we have seen in a long time.

phpMyAdmin provides a page that provides a listing of all security announcements for the software (something that other software developers should also be providing). Based on just the announcements for 2006 and 2007, the version of phpMyAdmin FatCow is using probably contains 16 serious severity security issues and 1 considered “quite dangerous”.

Posted in Website Security | 2 Comments