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

Why Are The Developers of Revive Adserver Ignoring The Statistics Bug in Version 3.0.3?

Earlier this week we mentioned that Revive Adserver 3.0.3 has introduced a pretty serious bug that caused new statistics data to not show up. At that point two bug reports for this issue had been created and then they were closed by one of the developers. With those reports maybe you could argue that there were not enough details given to identify what was going on, though there isn’t much to tell beyond the fact that the statistics are not being updated (we didn’t see message in the debug.log for this). Also at that point, a third bug report had been filed that contained more details on what was going on.

Earlier today the third bug report was report was closed and listed as being a duplicate of one of the previous bug reports. That previous bug report was closed, without the bug being addressed, and the reporter was directed to the Revive Adserver forum. On the forum the problem causing the updated statistics to not show had already been identified. At this point the bug just needs to be fixed in the software and a new version released, but that can’t happen if the developers keep closing the bug reports without doing anything. After years of neglect by OpenX, it is unfortunate that the new maintainers of the software are acting so oddly. Hopefully this will get resolved soon and a situation like this doesn’t occur again.

For those waiting on an official fix, the easiest way to resolve this for now is to go to the file /lib/RV.php and change the line:

require_once RV_PATH . '/lib/pear/PEAR.php';

to

require_once 'pear/PEAR.php';

Update (April 7, 2014): The bug has now been fixed and the fix will be included in Revive Adserver 3.0.4.

Posted in Revive Adserver | 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

Where Revive Adserver is Getting It Right and Wrong

It has been a little over six months since the software formerly known as OpenX changed hands and became Revive Adserver. We thought now would be a good chance to look at an important improvement that has occurred and pretty serious problem that has popped up.

Before we get to that we should note that anyone still running OpenX should upgrade as soon as possible as Revive Adserver has fixed several security vulnerabilities. Other than the bug we will get to later in the post, the upgrade should be rather seamless.

Improved Security

The story of the later years of OpenX was a series of security problems and a lack of concern for security that lead to at least some of those problems. In one instance their systems were breached and someone was able to modify the OpenX downloads so that malicious code was included. In another their systems were breached and used in conjunction with a vulnerability in OpenX, that the OpenX developers had been warned about, to gain access to individual OpenX installations. Another ongoing issue was that OpenX was not releasing the details of what changes were being made in releases. Doing this is important when security vulnerabilities are fixed as it allows others to double check that the issue has been resolved and it also helps people cleaning up hacked ad servers (like us) to know if the vulnerability that was exploited is an old vulnerability that has been fixed or a new vulnerability that would need to be reported to the developer to get fixed.

So far the people behind Revive Adserver have been handling things much better. For the last security vulnerability found in the software, which existed long before it became Revive Adserver, it was promptly fixed and a security advisory with details of it was released.

Our own experience with reporting a security issue to the OpenX and Revive Adserver teams showed the dramatic difference between the two. In June of 2012 a vulnerability was discovered in the XmlRpc component of the Zend Framework. Shortly afterward we sent an email to OpenX’s security address alerting them to the vulnerability in the component, which was included OpenX. We never heard anything back from them and the vulnerable component was never fixed. After the software became Revive Adserver we remembered the issue and decided to try reporting the issue again. Not only did we get a prompt response, but it was clear that they had actually looked into the scope of the vulnerability. As the components were no longer used in Revive Adserver the only way the vulnerability could be exploited is if a plugin used them. To resolve the issue they removed those components in the next release of Revive Adserver, 3.0.3.

A Serious Bug Unfixed

The latest release of Revive Adserver, 3.0.3, has a serious bug that causes new statistics data to stop showing up. Since statistics are important function of the ad server this is something that should have been promptly fixed, but about three weeks later it hasn’t. There were a couple of threads started on their forum (one of which is currently labeled as being HOT) shortly after the release raising the issue and identifying the problem. There were then a couple of bug reports filed, which were closed with a developer directing people to the forum. The latest bug report was filed a week ago and has yet to receive a response from the developers. This situation seems to indicate that improvements could be made in the handling of bug reports and that better pre-release testing might be needed, so that this type of bug can be spotted before it gets into a released version.

For those waiting on an official fix, the easiest way to resolve this for now is to go to the file /lib/RV.php and change the line:

require_once RV_PATH . '/lib/pear/PEAR.php';

to

require_once 'pear/PEAR.php';

 

Posted in OpenX, Revive Adserver | Leave a comment

Another Major University is Running Outdated and Insecure Version of Drupal

Last week we spotlighted the fact that only a third of websites running Drupal 7 are up to date. As keeping the software running a website up to date being an important security measure and with the most recent version of Drupal 7 being a security update that obviously is a problem (though certainly not a problem limited to Drupal). What makes this more troubling is that it isn’t just small websites that are not keeping their software up to date, but large institutions that are more than capable of doing the upgrades. In gets worse when you see institutions that have departments focused on the technology security that are failing to keep their software up to date. Last month we looked at the fact that the University of Cambridge was running an outdated version of Drupal, while the blog of their Security Group was running on a very out of date version of WordPress. They unfortunately are not alone.

Using our Drupal Version Check web browser extension, available for Firefox and Chrome, we can see that the Rutgers University website is still running Drupal 7.21:

The Rutgers University Website is Running Drupal Version 7.21That version is now a year out of date and two security updates have been missed (7.24 and 7.26). Making sure the website is kept up to date is something that you would hope that Rutger’s University Information Protection and Security Division would be on top of, but they are not even keeping their website up to date:

The RU Secure Website is Running Drupal Version 6.29That website is less out of date than the main Rutgers website as the current version of Drupal 6, 6.30, was released in January, but it was a security update so they should have gotten it upgraded by now.

For those reading this and realizing they need to get their Drupal installation up to date, you can find the upgrade instructions here.

Posted in Bad Security, Drupal, Outdated Web Software | 1 Comment

Only One-Third of Drupal 7 Websites Are Up-To-Date

Earlier this month we looked at some data from our tools showing that large percentages of Joomla, WordPress, and MediaWiki websites checked with them were running outdated versions of the software. For Drupal, there is much more comprehensive set of data publicly available that comes from the Update status/Update manger module. To get a better idea of how well webmasters are at making sure Drupal websites are being kept up to date we have analyzed the data reported for March 16, 2014, which has data on over a million websites. Making sure the software running websites is a basic security measure and when they are not it can lead to them being hacked if the vulnerability can be used for that (as we have been seeing recently with a vulnerability in older versions of Joomla).

At this point a large majority of the websites, 79 percent, using Drupal are using version 7. Of those only 33 percent are running the latest version, 7.26. This is troubling as this version was a security update, so websites running older versions are potentially vulnerable to being hacked. This version was released on January 15, so even websites that need extensive testing before apply an upgrade should have been updated by now. Looking beyond that, 72 percent of the websites are either up to date or less than a year out of date so the majority of websites are probably getting updated, if somewhat infrequently.

Drupal 7 Version Freshness: Up To Date 32.75%, Less Than 1 Year Out of Date 39.72%, More Than 1 Year Out of Date 22.53%, More Than 2 Years Out of Date 5.00%

For Drupal 6 the situation is worse. The latest version of Drupal 6, 6.30, was released alongside of 7.26 on January 15, but so far only 19 percent of websites have been updated to that version. The situation in terms of somewhat recent updated websites is also worse, with only 64 percent of website being up to date or less than a year out of date. 20 percent are at least two years out of date, which means they have missed at least four security updates.

Drupal 6 Version Freshness: Up To Date 18.62%, Less Than 1 Year Out of Date 45.06%, More Than a Year Out of Date 16.59%, More Than 2 Years Out of Date 11.34%, More Than 3 Years Out of Date 6.46%, More Than 4 Years Out of Date 1.90%, More Than 5 Years Out of Date 0.02%

To make it easier to check for Drupal websites in need of an update we have made the web browser extension Drupal Version Check, available for Firefox and Chrome, which in most cases will identify what version of Drupal is in use and in others indicate if the website is using an outdated version of Drupal.

If you are in need of a Drupal upgrade we can do that for you or we can also handle upgrades on an ongoing basis, so you don’t have to worry about taking care of this.

Posted in Drupal, Outdated Web Software | Leave a comment

Another ING US Website Running Outdated and Insecure Version of Drupal

Yesterday, as part our series of posts highlighting the fact that even high profile websites are not taking the basic security measure of keeping the software running them up to date, we highlighted the fact that ING US was using outdated and insecure versions of Drupal on their website. Today we have a few quick follow-ups.

First it was brought to our attention that the fact that ING was using Drupal was a big enough deal for the creator of Drupal to highlight it, saying in part

You know when a piece of software is mature when it starts being adopted by financial services organizations.

The fact that such high profile user isn’t keeping Drupal up to date in light of the security need of doing so either means that that Drupal is too hard to keep up to date, which we strongly disagree with based on keeping our own installation up to date and handling plenty of upgrades for clients, or there is more general problem with security practices for websites.

In the aforementioned post another ING US website was highlight as running Drupal and that website unfortunately has also not been kept up to date:

The ING Global Perspective Website is Running a Drupal Version 6.22That version is over two years and they have failed to apply five security updates (6.23, 6.27, 6.28, 6.29, and 6.30).

At the bottom on that website is a link to a Web Site Security page, which in part advises keeping the software on your computer update:

Take care of your computer

  • Update your computer by installing the latest software and patches to prevent hackers or viruses from exploiting any known weaknesses in your computer.

It would great if ING, as well as everyone else running a website, took that advice and applied it to their websites.

 

Posted in Bad Security, Drupal, Outdated Web Software | Leave a comment

ING US and Voya Financial Websites Running Outdated and Insecure Versions of Drupal

When it comes to keeping websites secure one of the basic things that needs to be done is to keep the software running the website up to date. This prevents the website from being exploited through a known vulnerability in old versions of the software that has been fixed in a subsequent release. We know that many websites are not doing this, which is troubling, but what is more troubling is that the major institutions are not even doing this with their websites. Last week we looked at major security software provider not doing it and if you go back in this blog, you can find other examples. Today let’s look at example of a major financial institution in the same boat. ING US, which in the process of rebranding as Voya Financial, reports having $511 billion of assets under management and administration and serving approximately 13 million customers. They use Drupal for main portion of the ING US website. Using our Drupal Version Check web browser extension, available for Firefox and Chrome, you can check if it is up to date:

The ING US Website is Running a Drupal Version Below 6.28You can see that they are not. With a little further checking we were able to determine they are using Drupal 6.19. That means they haven’t updated the software in over three years and they have failed to apply five six security updates (6.21, 6.23, 6.27, 6.28, 6.29, and 6.30). It is important to note that account access portions of their website are separate from the main website, so they are not directly impacted by this lax security. Though it does raise the question of how well they secure the other portions of their website if they are not doing something this basic. Also, if someone could exploit one of the vulnerabilities in the version of Drupal on the main website they could change the links directing people to the account access portion of the website to another location and use that to gather login credentials.

It isn’t just the ING US website that has an out of date version of Drupal in use. The website for their new name, Voya Financial, also is using an outdated Drupal version:

The Voya Financial Website is Running a Drupal Version Below 7.25With a little further checking we were able to determine they are using a version no newer than Drupal 7.21. That means that they haven’t updated the software in nearly a year and they have missed at least two security updates (7.24 and 7.26).

Posted in Bad Security, Drupal, Outdated Web Software | Leave a comment

Cisco’s Bad Research Should Be Wake-Up Call for Web Security Reporters

The Internet has lots of bad information on website security floating around. In dealing with many websites that have been hacked, we see the harmful impact this has due to it leading to bad security practices and making it harder to get people to take the measures that will actually keep websites secure. Much of the bad information comes from companies providing security tools and services, whom you would expect would know what they are talking about. We looked at an example of bad security research by Cisco on Friday that lead to bad security reporting by Ars Technica and by today they have both pulled back from their claims.

Cisco has struck through most of their post and included this update:

This post’s focus relates to a malicious redirection campaign driven by unauthorized access to thousands of websites. The observation of affected hosts running Linux kernel 2.6 is anecdotal and in no way reflects a universal condition among all of the compromised websites. Accordingly, we have adjusted the title for clarity. We have not identified the initial exploit vector for the stage zero URIs. It was not our intention to conflate our anecdotal observations with the technical facts provided in the listed URIs or other demonstrable data, and the below strike through annotations reflect that. We also want to thank the community for the timely feedback.

Ars Technica has added an update to their post, included below, which doesn’t explain why they went beyond the claims in Cisco’s post or why they repeated Cisco’s claim without doing basic research that would have shown the research was highly flawed.

The Cisco blog post has been updated to change a key finding Ars reported in the following post. Contrary to Cisco’s earlier reporting, the update says not all the servers compromised in the attack were running Linux version 2.6. “We have not identified the initial exploit vector for the stage zero URIs,” the update stated. “It was not our intention to conflate our anecdotal observations with the technical facts provided in the listed URIs or other demonstrable data, and the below strike through annotations reflect that. We also want to thank the community for the timely feedback.”

Considering how colossally bad Cisco’s findings were we want to expand on how they got it so wrong, so that it might point security reporters in the direction of better vetting security research before repeating its claims in the future.

One of their key findings was that all of the websites were running an old version of the Linux kernel:

All of the affected web servers that we have examined use the Linux 2.6 kernel. Many of the affected servers are using Linux kernel versions first released in 2007 or earlier.

They then raised the possibility that this was what allowed the hack.

It is possible that attackers have identified a vulnerability on the platform and have been able to take advantage of the fact that these are older systems that may not be continuously patched by administrators.

The original title of the post, Mass Compromise of the Obsolete, also implied that the hack was related to obsolete software.

What we brought up on Friday was that not all of the websites on their list of affected websites were even running Linux, much less the Linux 2.6 kernel. Cisco’s explanation for this discrepancy is that their claim that all of the examined websites were using the Linux 2.6 kernel was anecdotal. We don’t how you can square the claim you examined the websites, but your finding was anecdotal. It seems either they didn’t look at their whole list of websites or they used a faulty tool that determined websites not running Linux were using the Linux 2.6 kernel, neither of which we would describe as being anecdotal. Asking Cisco how they determined the website were all running the Linux 2.6 kernel and what there sample set was would have been something that should have been done before journalists repeated their claims. Incorrectly identifying a set of hacked websites as having a common software version is something that we have seen repeatedly from security companies (a couple of examples), so reporters should look carefully at the evidence and probably get a second opinion on the evidence.

While their original post doesn’t spell out what versions they are referring to by the “many of the affected servers are using Linux kernel versions first released in 2007 or earlier”, a comment by one of the authors of the post says that “version 2.6.18 appeared to be particularly prevalent”. If the Cisco researchers had look into why this version was rather prevalent they should have realized they were going down the wrong path. Why would Linux 2.6.18 be rather prevalent? Well for one thing, it happens to be the Linux kernel version used by Red Hat Enterprise Linux (RHEL) 5 and it derivatives, the most prominent being CentOS 5. A little further checking would have shown them that RHEL 5 will continue to be supported for some time, so servers using the Linux 2.6 kernel would not necessarily be obsolete or insecure. This is something that Cisco should be aware of since the server powering the Cisco Blog is using RHEL 5:

The Cisco Blog is Running on Red Hat Enterprise Linux 5 Because we often see people saying otherwise, it is important to note that just because there is a newer version of software available it doesn’t mean that an older version is not safe and secure, as long as the older version continues to receive security updates.

What ultimately would have prevented this mess is if Cisco had taken the basic step of determining how the websites were hacked instead of jumping to conclusions based on data that was not reliable. Security reporters should understand that determining how a website has been hacked is an integral to dealing with them and if somebody isn’t explaining that, it should be a huge red flag that the information being given might not reliable.

Posted in Bad Security | Leave a comment

Ars Technica and Cisco Provide Another Example of Bad Security Reporting

On Tuesday we looked at example of the poor state of security journalism. In that case a hack was tied to a specific version of TYPO3, despite fact that websites not running that version of TYPO3 or running TYPO3 had been hacked. There was also the larger issue that no evidence was provided as to how the websites were hacked, which would have been what would be needed to actually tie the hack to a specific version of TYPO3 and would allow people to make sure the protected their websites against it. Just a few days later we have spotted another very similar example worth highlighting. Ars Technica today put out an article “Ancient Linux servers: The blighted slum houses of the Internet” that states:

Now comes word of a new mass compromise that preys on even more neglected Web severs, some running versions of the Linux operating system kernel first released in 2007. According to a blog post published late Thursday by researchers from Cisco, the people behind the attack appear to have identified a vulnerability that has since been patched in later Linux releases that allows them to dish malicious content to unsuspecting people who visit the site.

If you read Cisco’s blog though they only state “it is possible” that a “vulnerability that has since been patched in later Linux release” was the source of the hack, while Ars Technica says that it “appears” to be the case. Here is the relevant section of Cisco’s post:

Attackers compromised legitimate websites, inserting JavaScript that redirects visitors to other compromised websites. All of the affected web servers that we have examined use the Linux 2.6 kernel. Many of the affected servers are using Linux kernel versions first released in 2007 or earlier. It is possible that attackers have identified a vulnerability on the platform and have been able to take advantage of the fact that these are older systems that may not be continuously patched by administrators.

That turns out to be less of an issue then the fact that the websites are not even all running Linux, much less the Linux 2.6 Kernel. Some websites provide information on the software running the in HTTP headers served with the page. Our Server Details web browser extension, available for Chrome and Opera, can parse those HTTP headers to provide the details in them and warn for outdated software. Using those headers we started going through the Cisco’s list of compromised websites and second compromised websites. For each we have listed below the first five websites we found not running Linux and what operating system they are running:

Compromised Websites

archive.mrpools.co.uk Windows Server 2003
blueprintbowling.com Windows Server 2008 R2
hwy65mx.com Windows Server 2003
jandjpoolspa.com Windows Server 2003
mussotra.com Windows Server 2003
Second Compromised Websites

3d2print.eu FreeBSD
7va.cc Windows Server 2008 R2
babycaust.info Windows Server 2008
banderil.com.ar Windows Server 2008 R2
c2consultores.com.ar Windows Server 2008 R2

Cisco provides no evidence of how the websites were hacked, which is the really important thing to prevent more websites from being hacked. If they had actually determined how it was hacked before jumping to speculation then they wouldn’t have tried to connect this to Linux, which it seems pretty likely it doesn’t have anything to do with. Cisco also has provided no evidence this has anything to do with outdated software, if we were to make an educated guess based on the evidence provide so far we would say it is more likely due to compromised FTP credentials, which could easily be checked for by reviewing the FTP logs for the websites.

We should also note that the use of the Linux 2.6 kernel is does not indicate that website using obsolete software, as distributions including Debian, Ubuntu, and Red Hat still have supported releases that use that version of the Linux kernel.

Posted in Bad Security, Outdated Server Software | 1 Comment