This article is the last in our series of articles on CMS analysis, this time we will be focusing on vBulletin. We have previously profiled Joomla, WordPress, Drupal and phpBB.

vBulletin is a little bit different than the list of CMSes we have been analyzing in this series. The first and most apparent being that it is not a free piece of software. The vBulletin site displays a cost of $195-$285 for a new license. The obvious question then, is why do people pay for this CMS when there are other good CMSs available for free? The answer lies in the varied list of features, such as a built-in photo album, event management and many other interesting and helpful features. Add to this good support, compatibility with existing software, many themes, built-in integration for payment engines and advertisement support… it’s not hard to see why vBulletin has acquired a large fan base.

Next, we will take a closer look at vBulletin to understand security issues facing active installations seen publicly on the Internet.

The aim of this experiment:

• To determine the number of vBulletin sites using older versions of the CMS package (and hence vulnerable to attacks).
• To identify the associated scripts vBulletin that users install in addition to core vBulletin functionality.
• Identify the vulnerabilities of using the associated scripts.

Experiment methodology:

An initial corpus of 100,000 websites was mined (via Google) using a keyword search to locate websites which discussed vBulletin. Understandably, not all 100,000 websites would actually be using vBulletin. Approximately 10,000 websites from this corpus were analyzed. Each website was analyzed to determine if it was generated by vBulletin or its associated plugins. Each website was then cross-referenced with the Google Safe Browsing List. This experiment was conducted between February 5th and February 8th, 2010.

Distribution of vBulletin versions:

In 93.09% of sites running on vBulletin the version number could be identified. We found the following distribution of vBulletin versions in the websites examined (where versions of installations could be determined). A more detailed breakdown of the distribution of vBulletin versions can be seen at the end of this article.

Significant numbers of older vBulletin installations are present on the Internet.

Note: Publicly available information about exploits for vBulletin 3.x.x and earlier versions exist. [1] [2]

We present the most interesting results here:

• Nearly 95% (see graph above) of vBulletin sites are running older versions for which exploits are available.
• None of the vBulletin sites were blacklisted by Google Safe Browsing.
• Only 13.5% of vBulletin sites had Iframes embedded in them. None of the Iframes were obfuscated or tried to load malware. All Iframes found loaded ads.
• 10.2% of the vBulletin sites which had Iframes were using JQuery.
  Note: JQuery has been known to be targeted by malicious hackers as a code-injection delivery mechanism.
• Only 0.1% of the vBulletin sites use Mootools
• None of the vBulletin sites use AC_RunActiveContent.js.

Conclusion:

This limited experiment shows that like WordPress, vBulletin also suffers from a large number of vulnerable installations being available on the Internet. It is intriguing to see that a CMS system, which is not free, and is tightly controlled is not kept up to date across the board. Consider the case of Drupal, where we observed that the variety in the versions of various installations is very low. The natural question at this point is: why is a free CMS system like Drupal doing better, security-wise, than a commercial CMS system like vBulletin? Why are most Drupal installations up to date. One thing to note though is that like Drupal and phpBB, vBulletin installations also seem to be relatively safe from the most prevalent malware. Most Iframes on vBulletin sites are Ads, a likely revenue stream for most forum admins.

The fact remains that there many vulnerable installations of vBulletin which can fall prey to malicious hackers.

Till next time.
Read more…

News, Report, Security CMS, safety, Security, vbulletin

Continuing with our series of articles on CMS security, this time we will be focusing on phpBB. We have previously profiled Joomla, WordPress, and Drupal.

I can already hear CMS purists howling that phpBB is not a CMS. In a way they’re right, but in other ways it is a CMS.  phpBB is without a doubt one of the most popular “Internet Forum” software packages available. Its ease of installation, various custom skins, and large installation base make it a very attractive choice for anyone who wishes to set up a community discussion board on the Internet. phpBB has had a few million downloads at the very least and enjoys a very active user group.

phpBB is popular among webmasters who want to set up Internet forums easily. Users of phpBB also benefit from a high level of customization. Another big plus for this CMS. Support for this CMS is awesome, in fact, phpBB has flash based video tutorials to help new users get started! Additionally, the phpBB developer community is very security conscious.

Next, we will take a close look at phpBB to understand security issues with active installations seen publicly on the Internet.

The aim of this experiment:

• To determine the number of phpBB sites using older versions of the CMS package (and hence vulnerable to attacks).
• Identify the associated scripts phpBB users install in addition to core phpBB functionality.
• Identify the vulnerabilities of using the associated scripts.

Experiment methodology:

An initial corpus of 100,000 websites was mined (via Google) using a keyword search to locate websites which discussed phpBB. Understandably, not all 100,000 websites would actually be using phpBB. Approximately 10,000 websites from this corpus were analyzed. Each website was analyzed to determine if it was generated by phpBB or its associated plugins. Each website was then cross-referenced with the Google Safe Browsing List. This experiment was conducted between February 1st and February 3rd, 2010.

Distribution of phpBB versions:

In 84.16% of sites running on phpBB a version number of the CMS package could be identified. We found the following distribution of phpBB versions in the websites examined (where versions of installations could be determined).

• 32.2% of sites were running version 2.x
  Note: Publicly available information about exploits for phpBB 2.x versions exist.
• 67.8% of sites were running version 3.x

We present the most interesting results:

• None of the phpBB sites were blacklisted by Google Safe Browsing.
• Only 2.5% of phpBB sites had Iframes embedded in them. None of the Iframes were obfuscated or tried to load malware.
• None of the phpBB sites which had Iframes were using JQuery.
  
• About 4.2% of all phpBB sites use jQuery.
  Note: JQuery has been known to be targeted by malicious hackers as a code-injection delivery mechanism.
• Only 0.3% of the phpBB sites use Mootools.
• Only 0.3% of the phpBB sites use AC_RunActiveContent.js.

Conclusion:

This limited experiment shows that like Drupal, phpBB installations seem to be relatively safe from the most prevalent forms of malware. However, the fact remains that there are quite a few vulnerable installations of phpBB which can fall prey to malicious hackers. This trend is echoed by our analysis of WordPress . It will be interesting to probe further and understand why the number of “infected” sites is not higher when there are vulnerable installations in the wild.

Till next time.

Report, Security CMS, phpbb, safety, Security, website

Continuing with this series of articles on CMS security, we have previously profiled Joomla and WordPress, this time we will be focusing on Drupal. Another, in a line of popular CMSs available today, Drupal, is used by tens of thousands of websites. Similar to WordPress, it has various plugins to customize the base installation and also sports interesting features such as “friendly links.” Quoting from the Drupal site, “Drupal uses Apache’s mod_rewrite to enable customizable URLs that are both user and search engine friendly.” Additionally, this particular CMS enjoys a large user community that is very serious about security.

Drupal is another prime example of a modern CMS. With more than 250,000 weekly hits to its APIs, this CMS has gained immense popularity! One would agree with the statement on the Drupal site which proclaims: “Tens of thousands of people and organizations are using Drupal to power scores of different web sites”.

Similar to the other CMSs which we have profiled in this series, Drupal offers the flexibility to manage content easily, add attractive themes and otherwise customize websites. Considering the plethora of themes available through the Drupal website, users seem to be very conscious of the attractiveness of their sites.

In this post we will be taking a close look at Drupal to understand any interesting issues with active installations publicly seen on the Internet.

The aim of this experiment:

• What associated scripts do Drupal users use in addition to core Drupal functionality?
• What are the vulnerabilities of using the associated scripts?

Experiment methodology:

An initial corpus of 100,000 websites was mined (via Google) using a keyword search to locate websites which discussed Drupal. Understandably, not all 100,000 websites were actually using Drupal. Approximately 10,000 websites from this corpus were analyzed. Each website was analyzed to determine if it was generated by Drupal or its associated plugins. Each website was then cross-referenced with the Google Safe Browsing List. This experiment was conducted between January 28th and January 30th, 2010.

We present the most interesting results in brief:

• None of the Drupal sites were blacklisted by Google Safe Browsing.
• 10.1% of Drupal sites had Iframes embedded in them. None of the Iframes were obfuscated or tried to load malware.
• 79.3% of Drupal sites which had Iframes were using JQuery.
  Note: JQuery has been known to be targeted by malicious hackers as a code-injection delivery mechanism.
• A whopping 66.2% of all Drupal sites use jQuery.
• None of the Drupal sites use Mootools.
• Only 1.7% of the Drupal sites use AC_RunActiveContent.js.

Conclusion:

This limited experiment shows that unlike some of the other CMS packages we have looked at, Drupal installations seem to be safe from the most prevalent malware. Furthermore, it seems that the correlation between Drupal users and jQuery users is much tighter than in the case of other CMS packages. It might be an interesting point to probe further, to understand why the number of infected Drupal installations is much less than the number of infected installations of other CMS systems while jQuery continues to be a common attack vector.

Till next time.

Report, Security CMS, drupal, safety, Security, website

Following up on our last article, this time we will be discussing issues relevant to, likely, the most popular CMS software package available today: WordPress.  WordPress, is used by a plethora of individuals and organizations, from bloggers to content publishers, news media outlets and many more. The great thing about this particular CMS is the level to which it can be customized and the number of plugins that exist for it.

WordPress is a prime example of a popular CMS. With more than 8,176 plugins and 73,037,498 downloads, this particular CMS package is extremely popular! I would agree with the statement on the WordPress site which proclaims: “WordPress is a state-of-the-art publishing platform with a focus on aesthetics, web standards, and usability.” It is.

WordPress also offers the flexibility to manage content easily, add attractive themes and customize webpages to your hearts content. And again quoting the main site: “Plugins can extend WordPress to do almost anything you can imagine.” I would agree with this too.

In this post we will be looking at WordPress closely to understand any interesting properties of the active installations publicly seen on the Internet.

The aim of this experiment:

• To determine the number of WordPress sites using older versions of the CMS package (and hence vulnerable to attacks).
• What are the associated scripts do WordPress users use in addition to core WordPress functionality?
• What are the vulnerabilities of using the associated scripts?

Experiment methodology:

An initial corpus of 100,000 websites was mined (via Google) using a keyword search to locate websites which discussed WordPress. Understandably, not all 100,000 websites would actually be using WordPress. Approximately 10,000 websites from this corpus were analyzed. Each website was analyzed to determine if it was generated by WordPress or its associated plugins. Each website was then cross-referenced with the Google Safe Browsing List. This experiment was conducted between January 28th and January 30th, 2010.

Distribution of WordPress versions:

• 30.9% of sites were running version 2.9.1
• 4.7% of sites were running version 2.9
• 9.14% of sites were running version 2.8.6
• 4.7% of sites were running version 2.8.5
• 21.42% of sites were running version 2.8.4
• 7.1% of sites were running version 2.8.2
• 9.14% of sites were running version 2.7.1
• 2.3% of sites were running version 2.6.2
• 2.3% of sites were running version 2.6
• 2.3% of sites were running version 2.1.3
• 2.3% of sites were running version 2.0.4

We found the following distribution of WordPress versions in the websites examined (where versions of installations could be determined).
Note: Publicly available information about exploits for WordPress version < 2.8.6 exist.

We present the most interesting results in brief:

• Only 0.18% of the WordPress sites were blacklisted by Google Safe Browsing.
• Only 1.6% of WordPress sites had Iframes embedded in them. We found that all these sites harbored Iframe based malware. The Iframes were not obfuscated (examples provided below)
• 44.4% of WordPress sites which had Iframes were using JQuery.
  Note: JQuery has been known to be targeted by malicious hackers as a code-injection delivery mechanism.
• About 7.2% of all WordPress sites use jQuery.
• None of the WordPress sites use Mootools.
• None of the WordPress sites use AC_RunActiveContent.js.

Examples of malware found:

Now we present some examples of the non-obfuscated malware that was detected on some of the analyzed sites.

Example Code #1,  detected on: olgamake.com/wp-login.php?action=lostpassword

<if ra e src="hxxp://a151.scrappi ng.cc:80 80/ts/in. cgi ?op en" width=971 height=0 style="visibility: hi dden"></i fra m e>

Example Code #2,  detected on: makinghimknown.com/wp-login.php

<if ra e src="src="hxxp://ke ymydoma ins.com/" width="3" height="2"></i fra m e>

Example Code #3,  detected on: bisoppreview.com/wp-login.php

<if ra e src="hxxp://ntw porta l.com/" w idth="2" hei ght="4"</i fra m e>

Conclusion:

This limited experiment shows that there are many older WordPress installations active on the Internet. Furthermore, some of them are have been infected by non-obfuscated Iframes which point to malicious websites to load exploit code dynamically. WordPress makes for an easy target by lieu of its popularity and wide installation base. The people associated with this CMS software take security very seriously and have done a great job releasing security patches and stable releases. However, the fact remains that vulnerable versions of WordPress are live on the Internet and are hosting malware, primarily via infected Iframes.

Till next time.

News, Report CMS, safety, Security, website, Wordpress

In this series of articles, we will be discussing issues relevant to popular Content Management Systems (CMS). These software packages make it relatively simple for web-administrators and lay people to host a website or an Internet forum and manage the content on it. Using a CMS, one can easily keep track of various versions of web-pages, allow visitors to contribute to the pages and host complex discussion forums too.

CMS software packages have gained widespread popularity owing to the easy to use interface they provide to web-administrators. CMS packages can be easy to set up. Most web hosting companies already have CMS packages ready to be set up on their client’s account, all the clients need to do is click a button in their hosting control panel! Furthermore, maintaining web-pages using CMS software takes away the pain of keeping track of multiple versions, manually granting user permissions and other mundane issues.

Joomla is prime example of popular CMS packages. With thousands of downloads and upwards of 7,000 followers on Twitter, this CMS package is extremely popular among web-administrators and content publishers. Joomla offers the flexibility to manage content easily, add attractive themes and customize web-pages to your hearts content. All this can be achieved without having any programming experience.

In this series of posts, we will be looking at five popular CMSs. Joomla is the first one on which we will focus.

The aim of the experiment:

• To determine the number of Joomla sites using older versions of the CMS package (and hence vulnerable to attacks).
• What associated scripts do Joomla users use in addition to core Joomla functionality?
• What are the vulnerabilities of using the associated scripts?

Experiment methodology:

An initial corpus of 100,000 websites was mined (via Google) using a keyword search to locate websites which discussed Joomla. Understandably, not all 100,000 websites would actually be using Joomla. Of these, approximately 10,000 websites from this corpus were analyzed. Each website was analyzed to determine if it was generated by Joomla. Each website was also cross-referenced with the Google Safe Browsing List. The experiment was completed between January 27th and January 29th, 2010.

We present the most interesting results in brief:

• In 80.25% of Joomla websites examined, the version of the installation could be determined.
• All websites for which the Joomla version could be identified were running Joomla 1.5.
  Note: Publicly available exploits for Joomla version < 1.5.6 exist.
• None of the Joomla sites were blacklisted by Google Safe Browsing.
• Only 0.84% of Joomla sites had Iframes embedded in them.
• 75% of Joomla sites using Iframes were using Mootools.
• 79% of Joomla sites use Mootools.
  Note: MooTools has been known to be targeted by malicious hackers as a code-injection delivery mechanism.
• Only 0.42% of Joomla sites use AC_RunActiveContent.js.
  Note: When using HTML templates in Flash CS3 Professional, a JavaScript file linked to the HTML file, named AC_RunActiveContent.js is automatically created.
• Only 0.63% of Joomla sites use jQuery.
  Note: JQuery has been known to be targeted by malicious hackers as a code-injection delivery mechanism.

This limited experiment showed that there is a correlation between Joomla installations and vulnerabilities targeted by hackers to spread malware. It will be interesting to compare this trend with the trends of the CMS packages that we will analyze in the coming days. Nonetheless, it is heartening to see that none of the websites hosting Joomla 1.5 were actually listed on Google’s Safe Browsing List.

Till next time.
Read more…

News, Report CMS, Joomla, Security, website reputation