Category Archives: Website Security

Looking at the Claimed WordPress setup-config.php Security Issues

Posted on February 3, 2012

Last week TrustWave’s SpiderLabs claimed that there were multiple vulnerabilities in WordPress 3.3.1 and below. Their report was also discussed in a post on threatpost. Unlike the Websense and M86 Security Labs reports of a vulnerability in WordPress 3.2.1 that were based on false information, these claims are based on factual information but the issues are presented in a way that we consider to be misleading.

What should have been made very clear by TrustWave and threatpost is that the possible security issues only exist if you have placed the WordPress files on your website but have not run the install script. If you are currently running WordPress this is not an issue in your installation.

If for some reason you have an extra copy of WordPress on the website that has never been used and someone could determine where that it is then this could be an issue. You should remove that copy, as you should with any software on your website that is not being used

Here are the findings made in TrustWave’s SpiderLabs’ report and some possible mitigations for the issues raised:

Finding 1

The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. This typically requires a user to have valid MySQL credentials to complete. However, a malicious user can host their own MySQL database server and can successfully complete the WordPress installation without having valid credentials on the target system.

After the successful installation of WordPress, a malicious user can inject malicious PHP code via the WordPress Themes editor. In addition, with control of the database store, malicious Javascript can be injected into the content of WordPress yielding persistent Cross Site Scripting.

What this is saying is that if the WordPress files are on a website and the install script has not been run someone else could run it. They could have WordPress connect to a database sever they control during the install and then they would we be able to place PHP code or JavaScript code on the website. As far as we can tell what they are describing would also be equally true of Joomla, Drupal, and other web software because they have similar web based installers.

It is not uncommon for WordPress to be setup with a remote database server, so removing or restricting the ability to do that would not seem to be advisable.

One possible mitigation for this vulnerability be to require the person using the install script to add or modify a file on the website to confirm that they have control of the website before proceeding through it. A similar mitigation would be to require the database credentials be entered into a file on the website instead of through the web installer. Either of those would make the installation process more complicated for users without providing any security benefit for anyone that promptly runs the install script after putting the WordPress files on a website.

Finding 3

The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. When using this installation page the user is asked to supply the database name, the server the database resides on, and a valid MySQL username and password.

Malicious users can omit the “dbname” parameter during this process, allowing them to continually bruteforce MySQL instance usernames and passwords. This includes any local or remote MySQL instances which are accessible to the target web server. This can also be used as a method to proxy MySQL bruteforce attacks against other MySQL instances outside of the target organization.

What this is saying is that if the WordPress files are on a website and the install script has not been run someone could use install script to make login attempts on a local or remote database server.

In addition to the mitigations mentioned for Finding 1, it would be possible to place limits on the number of attempts to log in into database servers with the installer. That would add complication to the installation process without providing any security benefit for anyone that promptly runs the install script after putting the WordPress files on the website.

Finding 2

The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. When using this installation page the user is asked to supply the database name, the server that the database resides on, and a valid MySQL username and password.

During this process, malicious users can supply javascript within the “dbname”, “dbhost” or “uname” parameters. Upon clicking the submission button, the javascript is rendered in the client’s browser.

What this is saying is that if the WordPress files are on a website and the install script is not run someone could create POST requests to the install script page which cause arbitrary JavaScript to included on the page in response to that request.

It seems like it should be possible to sanitize these parameters to prevent the described issue, but it doesn’t seem like this would be likely to be exploited as it would make more sense to exploit the issue mentioned in Finding 1. Exploiting the issue in Finding 1 would allow arbitrary JavaScript to be placed on pages without requiring a POST request, which would be easier and evade cross-site scripting (XSS) filters built-into some web browsers, as well as allowing other things to be done which are more of a concern then being able to place arbitrary JavaScript on a page.

WordPress’ Response

WordPress responded to the report by stating that “We give priority to a better user experience at the install process. It is unlikely a user would go to the trouble of installing a copy of WordPress and then not finishing the setup process more-or-less immediately. The window of opportunity for exploiting such a vulnerability is very small.”

We largely agree with WordPress’ view. We would further say that trying to make this a WordPress issue seems inappropriate as the most serious claim is related to having a user friendly web based install script, which is common among web software, rather than something specific to WordPress. If TrustWave’s SpiderLabs believes this is a serious issue they should have raised it instead of trying to make this into an issue with WordPress.

Posted in Website Security, WordPress | Leave a comment

DreamHost Does Store Non-Hashed Passwords

Posted on January 23, 2012

On Friday DreamHost reset all of their customers “FTP/shell access passwords” after they had unauthorized activity within one of their databases, the situation is discussed in blog posts on DreamHost Status blog and the The Official DreamHost Blog!. Since then there have been questions and confusion as to whether DreamHost only stores passwords in their hashed form. While we have no way of knowing if the database they detected unauthorized activity stored non-hashed password there is no question that they store non-hashed passwords in their systems. It’s fairly easy to see that DreamHost is doing this and we will show you how you can check this for yourselves at the end of the post.

The fact that they stored passwords in a non-hashed form has been discussed for many years and DreamHost has so far has decided that insuring that they were follow proper security practices by only storing password hashes wasn’t necessary for whatever reason. It’s then not all to surprising that they had this most recent security incident and the other apparent security incidents they have had over the years. For some time we have listed DreamHost in our list of web hosting providers with security issues due to them storing non-hashed passwords.

One possible reason for some of the confusion from DreamHost is that they don’t understand the difference between encryption and hashing, in which case it they probably shouldn’t be handling the security of a website, much less that of a major web host.

While discussing DreamHost’s security it is also worth bringing up the fact that both of those blogs are running an outdated version of WordPress, 3.2.1. They are also are running an outdated and now unsupported release of MediaWiki, 1.16.5, on a portion of their website (so are a number of the websites of web software). In a message that was forwarded to us while we were cleaning up a hacked website for client recently, DreamHost had told them that they should make sure to keep web software running on their website up to date. Obviously DreamHost don’t feel it is important to follow the advice they give to their customers. If you want to see when websites are running out of date version versions of WordPress, MediaWiki, and other software check out our Meta Generator Version Check web browser extension for Firefox and Chrome.

Considering DreamHost’s questionable security practices we would recommend that people avoid using their services until they have fixed these lapses in their security. We also don’t think that WordPress should be recommending them or describing them to be one of the hosts that “represent some of the best and brightest of the hosting world”.

What is Hashing?

You can think of hashing as one way encryption. To produce a hash you run a hash function on a specified value, in this situation it would be the value being set as a password. For example, using the MD5 hashing function the hash for the password value “password” would be “5f4dcc3b5aa765d61d8327deb882cf99”.

Unlike encryption, hashes are not meant to be decryptable and ideally you wouldn’t be able to determine what the password value was if you gained access to its hash. This is why it is important to store passwords as hashes. If they are stored them in a non-hashed way someone that gains access to them could easily use the passwords to log into your account, which has happened previously after web host’s were exploited, or if you use the same password on different systems they could potentially gain access to those as well. There are a number of ways to determine the underlying value of passwords hashes, so systems using hashing for passwords need to insure they follow best practices including making sure they use salts.

So how does a system know that the correct password was entered during a login attempt if they only have the hash? The answer is that when the login attempt is made the password you enter is run through the same hash function and then compared with the stored hash of the password. If the two are they same the login attempt will succeed. If you entered the wrong password the hashes would be different and it would fail.

If passwords are only stored in hashed form there will be no way for a provider to retrieve the password from storage that for you. The only instances where they could show you the password would be when they are generating a new password for you or if they show you the password in response to you entering it.

The most common place to see that passwords are being stored in non-hashed form is on pages for handling a situation where you forgot your password. If they can show or send you the password it means the password in being stored non-hashed in their systems. With web hosts we also sometimes see that passwords are visible somewhere in the control panel for the websites.

Spotting Non-Hashed Password Storage at DreamHost

From the DreamHost’s homepage click the Panel link at the top and then click the Forgot password link. That page currently looks as follows:

If the password were only stored in the hashed form they wouldn’t be able to email you your password because they wouldn’t know what it was.

Posted in Bad Security, Website Security, WordPress | Leave a comment

Outdated Software Running on Websites of WordPress and Other Web Software

Posted on January 20, 2012

When the makers of web software talk about security they always emphasize the importance of keeping software updated. One of the developers of WordPress said it this way “The only thing that I can promise will keep your blog secure today and in the future is upgrading.” Keeping software updated is good advice, but isn’t advice that the software makers, including WordPress, always follow themselves.

We recently mentioned a pretty egregious example of this from OpenX. Their blog, where they recently said it is critical to keep software up to date, is running a version of WordPress that is over three years out of date. Also, the main portion of their website appears to be running a version of Drupal that is over a year out of date.

MediaWiki, the software the powers the Wikipedia, is run on portions of many web software websites so we decided that it would be a good choice to see if software makers are keeping other people’s software running on their website up to date. There are several ways to check what version of MediaWiki is running and the easiest way to check for outdated MediaWiki installations is to use our Meta Generator Version Check web browser extension, available for Firefox and Chrome. The extension will show a warning icon when a web page has a meta generator tag from an outdated version of web software.

For those not familiar with MediaWiki they currently provide security updates for the two most recent releases 1.17.x and 1.18.x. The most recent version of those releases 1.17.2 and 1.18.1, both of which were released on January 11. We update our web browser extension a month after a new version is released, so until then it will check for MediaiWiki versions below 1.17.1.

Before mentioning the websites running outdated versions it is worth noting that one website we checked was actually up to date. TYPO3′s TYPO3Wiki is running 1.18.1.

WordPress

The WordPress Codex is the most out of date as it is running 1.15.5, which is two supported releases out of date. Support for 1.15.x ended in December of 2010.

Zen Cart

The Zen Cart Wiki is one supported release out of date and running a version, 1.16.2, that that is three minor updates out of date. Support for 1.16.x ended in late November of last year.

Joomla

Joomla! Documentation is one supported release out of date and running a version, 1.16.4, that that is one minor update out of date.

phpBB

The phpBB Development Wiki is at least running the most recent version of 1.16.x, 1.16.5, but that release is no longer supported.

Moodle

MoodleDocs is at least running a supported release, 1.17.x, but the version, 1.17.0, is two minor updates out of date.

Posted in Joomla, MediaWiki, Moodle, phpBB, Website Security, WordPress, Zen Cart | Leave a comment

Our First WordPress Plugin Security Bug Bounty Payouts

Posted on December 21, 2011

We finally have an opportunity to discuss our first two security bug bounty payouts for WordPress plugins, both for relatively minor issues. We actually paid them out in late October but we were waiting until after one them was finally fixed (the other was fixed within hours of the developer being notified) to write about the issue.

Both NextGEN Gallery and WP e-Commerce suffered from reflective cross-site scripting (XSS) vulnerabilities in the portion of the plugin accessible in the admin area. With a reflective XSS vulnerability if an attacker can get you to visit a specially crafted URL they can cause the website included arbitrary HTML code, most often JavaScript, which they specify. That could be used to cause actions to take place of the web page, another file to be loaded, your browser cookies to be read, among other things.

XSS vulnerabilities are not as big an issue as vulnerabilities that allow adding arbitrary code to a database or into a file. Because these two vulnerabilities are only accessible in the admin area, it limits there severity even more. If they were to be used by an attacker they would be used in a attack to target at an individual website instead of a mass attack. Most attacks on WordPress based websites are mass attacks.

A fix for NextGEN gallery was included in version 1.8.4 and a fix for WP e-Commerce was included in version 3.8.7.3.

Web Browser Based Reflective XSS Protection

The ability to exploit the vulnerabilities is also limited by protections in some web browsers designed to restrict reflective XSS vulnerabilities from occurring. While doing a test with a XSS that attempts to load a JavaScript file from a third-party website that reads cookies associated with the WordPress based website we found that the web browsers performed as follows:

We found that both Chrome 15 and Safari 5, whose protection come the WebKit rendering engine they share, were able to successfully block the attempted XSS.

We found that Internet Explorer 9 only blocked the attempt XSS if you were already logged into WordPress when attempting to access the malicious page. If you were not logged in you would be asked to login and then be taken to the malicious page where the XSS was not blocked. This is due to Internet Explorer disabling the protection for requests originating from the same website. This is one of a number of weaknesses in Internet Explorer’s protection discussed in the paper Bypassing Internet Explorer’s XSS Filter (PDF).

Firefox doesn’t currently provide any similar functionality, but with the NoScript add-on installed we found the attempted XSS was blocked.

Keep in mind that the web browser protections are not full proof and it is possible that XSS attacks could be crafted that can evade the protections.

Testing Security Plugins Against These Vulnerabilities

Now that updates for both plugins have been released the way to prevent these vulnerabilities is to make sure you are running the latest version, which should make sure to with any installed plugins, but what about similar vulnerabilities that developer are not yet aware of? The biggest protection that you have is that targeted attacks are rather uncommon, so you are unlikely to be exposed to this type of issue. Then protection comes from being careful when clicking on links and using a web browser that provides protections against this type of hack.

There are also a number of security plugins for WordPress, some on them specifically claim to protect against XSS. We wanted to see if they would have blocked the exploitation of the vulnerability in either plugin. To test this out a crated a XSS attempts to load a JavaScript file from a third-party website that reads cookies associated with the WordPress based website. We used Firefox without NoScript so that any protection would be from the plugin and not the browser.

For this test, we tested plugins that did not require signing up for any service. We tested the following plugins:

BulletProof Security
Secure WordPress
Better WP Security
TTC WordPress Security Tool

For all four plugins we found that provided no protection. This is rather disappointing as this is just the type of thing they might be useful for. Most times when WordPress based websites are successfully attacked it is due to outdated software, which keeping software updated would have prevented, or it is due to a hacker gaining access to the underlying files that make up WordPress. In a case where the hacker has access to the underlying files the plugins cannot prevent access to the files (making files un-writeable is generally not effective as the hacker generally has the ability to make the writeable again) and the hacker could remove or modify the plugins. They could even modify the software to report that the website is still secure (You probably won’t find much security software of this type warning about this serious weakness, though it doesn’t appear that many hackers bother doing that as the software isn’t popular enough to be worth the time it would take to do that.).

Posted in Website Security, WordPress | Leave a comment

OpenX Continues Questionable Security Posture

Posted on November 8, 2011

Last Thursday OpenX released version 2.8.8 of their software. They have yet to make any sort of public announcement of the update on their blog or anywhere else that we could find. The only information given, found on the Product Updates page in the OpenX admin interface, says that:

It is highly recommended to install this update as soon as possible, because it contains a number of security fixes. The version of OpenX which you are currently using might be vulnerable to certain attacks and is probably not secure.

With a release that includes important security fixes, as this seems to be, you would expect that they would want to make sure people that use their software would be well aware of the update.

There was no information was given as to what the vulnerabilities were or what other changes were made in the new version. This is a continuing practice from OpenX as we have written about before. While it is understandable that developers would want to limit the amount of information to make it harder to for people to be able to exploit the vulnerabilities, hackers have shown that they are able to hack OpenX without this information and the information would be useful for people not looking to hack OpenX. To repeat what we said after the last OpenX release, “[w]ithout knowing what the issue or issues that were fixed makes it hard to determine the source of a hacking, potentially leading to new vulnerabilities that are exploited in OpenX going undiagnosed in the future if the OpenX installation hacked was running an out of date version.” It also makes it hard for anyone to independently verify the vulnerabilities were fully and properly fixed in the newer version.

The larger concern we have now is that OpenX seems to continue to be releasing security fixes in response to vulnerabilities being actively exploited, commonly referred to as zero-day exploits, instead them being found beforehand during development or during subsequent security reviews. We know that with past vulnerabilities they were being exploited before updates were released. We have seen some reporting that vulnerabilities in the last version were being exploited (with the most specific report we were not able to replicate the vulnerability, but that could be because of using a different server configuration) before this version was released. This at least means that users keeping the software up to date are not safe from being hacked, which they generally are with most web software that have a good track record of finding and fixing vulnerabilities in their software before they can be exploited. It also could be an indication that OpenX is not as concerned about the security of the software as they need to be for something that is so widely deployed.

What makes there apparent lack of concern towards the security of their software more troubling is the way they used the update message for 2.8.8 as a chance to promote their hosted solutions. This is the message that followed the warning about the need to update:

OpenX also provides both free and Enterprise hosted versions of the ad server, offering significant improvements in both infrastructure and functionality. Both of these products are managed and operated by the OpenX team, including upgrades, maintenance, and security scans, freeing you and your team from handling such issues. If ad serving is mission-critical to your business, we suggest contacting our team to learn more about OpenX Enterprise. As always, please let us know of any potential security problems by emailing security@openx.org.

All the hacks of OpenX we have dealt with so far have been due to security vulnerabilities in the OpenX software and not due directly to something related to self-hosting. In many of those cases OpenX had released a update before they were hacked, so automatic upgrades provided by their hosted solutions would have helped. But unless OpenX is providing their hosted customers with a more secure version of OpenX, then the hosted customers remain as vulnerable before the fixes for the security vulnerabilities are released. The quality of their security scans should be in question as well, if vulnerabilities keep getting found and exploited before they are fixed by OpenX.

Update (November 14, 2011):

Another thing that should be noted when considering how OpenX views the importance of security is the fact that their blog is still running WordPress 2.6.2. One of the most basic and important security measure anyone running a website should be doing is making sure they keep any software running on the website up to date. The version they are currently running is now over three years out of date. Since version 2.6.2 there have been 16 releases that include security fixes that they have missed (and 26 overall releases).

Posted in Bad Security, OpenX, Website Security | 4 Comments

Our New Web Browser Extension to Warn When Outdated Software is Being Used

Posted on October 18, 2011

We are always looking for ways how we can help to improve the security of the web. One of the basic security measures that needs to be taken to keep websites secure is keeping the software running on them up to date, as newer releases often contain security fixes and enhancements.

The developers of web software have done a lot to make that easier by providing messages in the software that the websites is in need of update and making the update process easier. Even with this there is still many website running outdated versions of that software.

When we are in touch with people running websites whether they are potential clients, people we are contacting to let them know their website has been hacked, or for some other reasons, we make sure to let them know if we see they are running outdated software that needs to be updated. We only reach a limited number of people so to increase awareness that outdated software is running on websites we have created a new web browser extension, named Meta Generator Version Check, to make it easier for others to see when there is outdated software running a website.

With the web browser extension installed, each time a web page finishes loading the extension checks the web page’s source code for a meta generator tag. The one for the current version of WordPress looks like:

<meta name="generator" content="WordPress 3.2.1" />

After reading that, the extension then provides a warning if it detects one of the following software is running on the website:

WordPress versions prior to 3.2.1
Joomla 1.0 and Joomla 1.6
Mediawiki versions 1.16.4-1.13 (earlier versions do not contain a meta generator tag)
vBulletin versions prior to 3.8.7
TYPO3 versions prior to 4.3
Movable Type versions prior to 4.37, 5.06, and 5.12
Melody versions prior to 1.0.2

Looking at that list you might notice that there is a fair amount of software missing. The limitation of checking the meta generator is that not all software produces one and some of those that do, do not provide a tag that allows us to identify what version is running. In other cases only partial version information is given. For Joomla, this means the extension can warn about websites running Joomla 1.0 and 1.6, which are no longer supported, but for Joomla 1.5 and Joomla 1.7 there is no indication if they are running the current version of those, as of yesterday they were 1.5.24 and 1.7.2, or an older version.

Another issue we have found as we looked to add checks for more software is that the supported versions of software are not always easy to find. We would recommend that software developers make sure that they prominently display what versions of their software are supported so that people looking for that information can easily find it.

If you see that we are missing a check for software that provides the required information in the meta generator tag please let us know so that we can include that in the extension.

While it would be possible to have the extension do a more intensive check to determine what version of software is running on website, using information not available in the meta generator tag, this would in most cases require requesting additional files when each page is loaded and would provide information that is not being made available by the web page itself.

We currently plan to update the extension to warn that software is outdated a month after a subsequent version has been released or support has ended for a version. For severe security vulnerabilities the extension may e updated sooner provide an earlier warning.

Uses

The main use for the extension is to be alerted that websites that you are visiting are running outdated software so that you can let them know that they need to update it or if they are your client you can do the update yourself.

It also could be useful in looking at who you considering doing business with or what software you might use on your website.

If a web host isn’t keeping software on the frontend of their website updated, it is reasonable to be concerned that they might not be taking proper security measures for their hosting clients as well. After checking just a few web hosts we found that both Just Host (3.0.3) and IX Web Hosting (3.1) were running outdated version of WordPress. It is also interesting to note that homepage of IX Web Hosting’s website has security seals from both McAfee Secure and something called Ecommerce HackerShield (which appears to something created IX Web Hosting’s parent company) claiming the website is secure despite the outdated software, with known security vulnerabilities, running on a sub-domain of the website and linked directly from the homepage.

For software, an example of something that might be concerning that we just noticed with a piece of software that we run on our website, Piwik, is that their website is still running WordPress 3.0.4.

Availability

A version of the extension is now available for Chrome. A version for Firefox is currently pending a review from Mozilla. The Firefox version has some limitations in comparison to the Chrome version due to current limitations of the Mozilla Add-On SDK, as the Add-on SDK is further developed those limitations will also go away. A version for Safari will not be released until Apple modernizes their enrollment process for Safari Extension development.

You can also find a web-based version of the tool here.

Is Running Outdated Software Always a Security Concern?

Outdated software is not automatically less secure than a newer version, it would only be more insecure if it contains a security vulnerability that does not exist in a newer version. Often new releases include fixes for security vulnerabilities or security enhancements. There is also a possibility that changes have been made in a newer version that removed a security vulnerability that was not known to be security vulnerability at the time. To be safe it is a good rule to update the software even if the developers have not warned of vulnerabilities in prior versions. To keep things simple we have decided that the extension will warn if outdated version is running instead providing a warning only when we know an old version contains a security vulnerability.

Is Including a Meta Generator a Security Concern?

With software that includes a meta generator tag there are often people claiming that it makes websites less secure, this is especially true when it comes to WordPress. We previously discussed the issue in detail in regards to WordPress. The summary of that is as follows: The bad guys are not generally checking the meta generator tag and they usually don’t even check if you are running the software they are trying to exploit. On a daily basic there are attempts to exploit software that is not and has never been on our website. Because the bad guys attempting to exploit vulnerabilities do not bother to check what version of software you are running the website, you will get hacked if you are running a version with that vulnerability even if you managed to completely hide the version running. Finally, if someone wanted to find out what version you are running they could do that even if you remove the meta generator tag.

With our new extension we think it makes even more sense to include a meta generator tag as it increases the usefulness of the tag by letting people inform others they have outdated software running on their website that needs to be updated.

Posted in Joomla, Piwik, Website Security, WordPress | Leave a comment

Securing osCommerce 2.2 and 2.3

Posted on March 28, 2011

osCommerce continues to be one of the most exploited pieces of web software. Back in October we wrote about the need to secure osCommerce to prevent these exploitations. Since then we have seen a lot of bad information on securing osCommerce against these exploitations as well as questions on securing osCommerce 2.3, which was released in November, so we have put together additional information on securing osCommerce 2.2 and 2.3.

osCommerce 2.2

There are several vulnerabilities in osCommerce 2.2 that are being exploited. The simplest and most effective method to protect against the exploitation of these vulnerabilities is to rename and password protect the admin directory. Doing this is also recommended by osCommerce.

Renaming the admin directory requires changing the name of the directory and changing the DIR_WS_ADMIN and DIR_FS_ADMIN lines in the /includes/configure.php file located in admin directory with the new admin directory name in place of admin.

The easiest way to turn enable password protection is using the HTACCESS from osC admin menu add-on (this is add-on has also been integrated into osCommerce 2.3) following these steps:

Install the add-on, make sure to install the files located in the admin folder in the add-on to the renamed admin directory.
Login into the admin area.
In the left hand menu, click on Administrators link in the Configuration section.
Click edit.
Enter your current password in the New Password field and select Protect With htaccess/htpasswd.

You can find information on extra security measures you can take in the osCommerce forum thread How to secure your osCommerce 2.2 site.

For existing osCommerce 2.2 based websites that do not already have these protections in placed it is likely that the website has already been hacked. Many of these hacks only involve placing a backdoor script, which allows the hacker to run commands from and access files on the website. With the backdoor script in place they can come back later and use the website for malicious purposes. Other hacks involve using the website for spam, malware, or other malicious purposes.

The best way to insure that any code added by hacker has been removed is to revert to a clean backup of the website. Because osCommerce have been being hacked for so long it is unlikely that a backup that was made of the website from the last year or two would be clean at this point. If you have a copy of the website that was never placed on the website you could use that, you would need to add any new files you created since then, such as images.

Another method to clean the website is to remove the malicious code and files that the hackers have added. Malicious code is often added to the index.php and /includes/header.php. Backdoor scripts can be placed throughout the website; our Basic Backdoor Script Finder will find some of the most popular ones. You can also look for any .php files in the images folder and for files that begin goog1e located in the root directory of the osCommerce installation as the will be backdoor scripts.

osCommerce 2.3

osCommerce 2.3 included fixes for the vulnerabilities in osCommerce 2.2 and at this point there are no known vulnerabilities in 2.3.1 (there was an incorrect advisory that claimed there was one), so it would be safe to run the software without additional protection, but it is still recommend rename and password the admin directory.

It is possible to rename the admin directory during the installation of osCommerce 2.3. If the admin directory was not renamed during the installation it can be done by changing the name of the directory and updating the DIR_WS_ADMIN and DIR_FS_ADMIN lines in the /includes/configure.php file located in admin directory with the new admin directory name in place of admin.

Password protection is integrated into osCommerce 2.3, it can be turned on following these steps:

Login into the admin area.
In the left hand menu, click on the Administrators link in the Configuration section.
Click edit.
Enter your current password in the New Password field and select Protect With htaccess/htpasswd.

You can find information on extra security measures you can take in the osCommerce forum thread How to secure your osCommerce 2.2 site (most of the information applies to 2.3 as well as 2.2).

osCommerce 2.3 also includes a number of security enhancements. The Portable PHP hashing framework has been added to more securely hash passwords, this software is also used in WordPress. A customer session token has been added “to forms to protect against Cross-Site Request Forgeries (CSRF)”. A new section of the admin, Security Directory Permissions, displays the current write permission of the various osCommerce directories and what the recommend permissions are. A built-in version checker allows for checking if a new version of osCommerce has been released.

Posted in osCommerce, Website Security | Leave a comment

Understanding the Role of File Permissions in Website Security

Posted on March 22, 2011

Often in discussions of website security or hackings the issue of file permissions comes up. Unfortunately, important information needed to understand what effect permissions have is often not explained and in many cases bad information is spread. Most of the bad information relates to limiting other’s access to the files in your account on a shared server.

First let’s explain the basics of what file permissions are made of. In Unix based operating systems, which is what most web servers are running on, file permissions are composed three type of permissions: read, write, and execute. The read permissions allow reading the file, the write permissions allows modifying the file, and the execute permissions allow a file to run (because of how PHP works .php files do not need to be executed to run).

Directories also have the same types of permissions, but they are somewhat different. The read permissions allows see a listing of the files in the directory, the write permission allows creating, deleting, or renaming files in the directory, and the execute permissions allows accessing the files in the directory.

Those types of permissions are set for three different classes: the owner, group, and others. The owner is normally the user that created the file, the group is whatever groups the owner is part of, and other involves any other users on the system.

The first important thing to understand in terms of security is how the files can be accessed in the first place, because for permissions to come into play the hacker first has to be able to access the files. This requires having login access to the server, a FTP login for example, or having found some exploit in software running on the server. Just by browsing the website they could not access the files. If the hackers gains login access to your account or exploits software on your website they will have the same access that you have, so restricting others access will have stop someone from accessing your files in those cases.

We sometimes see it suggested that to protect a website that is being repeatedly hacked in a way that modifies files, that the write permissions for the files should be removed. The idea is that because the write permissions are disabled the hacker would no longer be able to modify the files. The problem is that most instances the hacker would have the ability to change the permission so that the files are writeable again. For almost as long as we have been seeing it be advised to make the files unwriteable we have been seeing hacks in which the permissions set to be writeable during the hack, so this is not effective strategy. What needs to be done is determine how the hacker is gaining access to the files and stop that.

The most important thing to understand about file permissions is that on a shared server, no matter what the file permissions are set to other users should not have access to your files. One of the developers of WordPress put it this way:

A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.

If your hosting provider does not have proper access controls in place the need to add those or your need to find a new host.

While setting permissions as low as possible is not going to do any harm, in most cases where the file permissions are blamed it would not have mattered what the permissions were set as. This is due the fact the files were being accessed in way that file permissions would not have restricted access. For example, a recent hack involved exploiting the web server instead of individual websites. Once the hacker gained access to the server they had access to all of the files on the server.

Posted in Bad Security, Website Security | Leave a comment

Google Adds “This site may be compromised.” Warnings To Search Results

Posted on December 9, 2010

In the last several weeks Google has begun to show “This site may be compromised.” warnings, for websites they “believe may have been hacked or otherwise compromised”, in their search results. According to Google’s article about of the warning they have been added “To protect the safety of our users” and they recommend users “should be careful about providing personal information to the site” being flagged.

In the past when Google has detected websites they believe to be hacked and violate their Webmaster Guidelines, they have removed the websites from their index and placed a “Notice of Suspected Hacking” message in their Webmaster Tools to let the webmaster know. It’s unclear at this point if Google has replaced doing that with the new warning or if the warning is only for websites that have been hacked in such a way that does not warrant being removed for their search index. Unlike the malware warning (“This site may harm your computer.”) Google places in their search results, which sends users to an interstitial page when they click search result for an affected website, users are still able to directly access the website.

For websites which display the warning, after the hack has been removed reconsideration needs to be requested from Google to have the warning message removed. According to a post by Google employee John Mueller “These requests are processed fairly quickly (usually within a day, though it’s not possible to give an exact timeframe). “

Posted in Google, Website Security | Leave a comment

osCommerce 2.3 and 2.3.1 Do Not Contain Vulnerability in categories.php

Posted on December 6, 2010

It was recently reported that the /admin/categories.php file in osCommerce contained a vulnerability that would allow someone to remotely add files to an osCommerce installation without. This could be used to add backdoor script, which would allow the hacker access to all the website files and the ability to run code on server. This could be used for a number of malicious purposes including added spam or malware to website. osCommerce has been a frequent target for hackers lately, mainly being used to spread malware, due to a number of security vulnerabilities in older versions. In SecurityFocus’s advisory it was stated that version 2.3.1, which is the most recent version of osCommerce, is the vulnerable version. Using the exploit code they provided we tested the exploit and we found that version 2.3.1 is not vulnerable. Version 2.3, which included fixes for a number of security vulnerabilities and a number security enhancements, is also not vulnerable. Version 2.2rc2a and probably versions older than that are vulnerable if the workaround to secure the admin area has not been applied to them.