Motivation
Understanding the behavior of infected websites is very important. This provides security researchers with strategies to help deal a blow to the bad guys and at the same time, provide website owners and administrators an idea of the current state of website security.

Since the publication of our last article in this series, we have received good feedback from our colleagues in security. We will attempt to incorporate their comments and concerns in this part of the series.

Methodology
We discussed the aim of this experiment and methodology in the last part of this series. We won’t repeat them here, but we encourage you to take a look at our first article in this series if you haven’t already read it!

Analysis
Below we present some graphs which provide more information about the analysis.

• Websites have a high probability of getting hacked on a Wednesday!

Websites have a high probability of getting hacked on a Wednesday!

• Websites have a high probability of getting hacked between 7-8 PM PDT.

Websites have a high probability of getting hacked between 7-8 PM PDT.

• On Monday websites get hacked most between 11 AM to 12 Noon, PDT
• On Tuesday websites get hacked most between 9 AM to 10 AM, PDT
• On Wednesday websites get hacked most between 7 PM to 8 PM, PDT
• On Thursday websites get hacked most between 10 PM to 11 PM, PDT
• On Friday websites get hacked most between 11 AM to 12 Noon, PDT
• On Saturday websites get hacked most between 1 PM to 2 PM, PDT
• On Sunday websites get hacked most between 11 AM to 12 Noon, PDT

Note: Most hashes which stay on the blacklist (over the 113 day period) seem to get added to the blacklist on Wednesday.

Conclusions
We have presented more interesting statistics regarding the appearance of website hashes on the Google Safe Browsing List. These statistics provide information which website administrators and owners can use better arm themselves with against attackers. We will continue analyzing the dataset to provide more interesting information. If you have any questions please add a comment.

At stopthehacker.com, we work hard to help you combat malicious hackers. If you would like to work with us, please drop us an email. You can also visit our services page to find out how we can help you, in fact you can even sign up for free services!

Till next time…

Motivation
In this article we will be analyzing the Google malware hash lists that have been published over the past few months in order to answer these important questions:

• How many websites get blacklisted each day?
• How many websites manage to get off the blacklist?
• How soon do websites get off the blacklist?
• How many never get off the blacklist?

These are practical questions which are often posed by frustrated, sometimes confused and angry website owners, time and time again at help forums, and via our contact page.

Resources
Google has done a good job creating detailed help content describing the process of blacklisting, as well as a group where website owners can ask for help. Additionally there are excellent resources like BadwareBusters where users can find volunteers to help them. We also participate in these groups.

Yet, there is still a demand for getting clear cut answers to some basic questions like the ones detailed above. In this vein we want to provide scientifically sound and statistically significant analysis of freely available information to provide clear answers to these questions. A small FAQ is also available on our site to answer questions from website owners and admins.

Goals
This series of experiments is split into multiple parts. This article presents a first look (part 1) at openly available data. The goal of the experiment is to understand:

• How many websites get blacklisted each day?
• How many websites manage to get off the blacklist?
• How soon do websites get off the blacklist?
• How many never get off the blacklist?
• How many websites fall back onto the blacklist?
• How much time elapses before a website falls back into the blacklist?

Methodology
For the purposes of this experiment, Google malware hash lists were collected from March 3, 2010 to June 1, 2010 (113 days). Malware hash lists were collected every 30 minutes. Each malware hash list contains the information in the Google malware hash specification. All hash lists were parsed and unique hashes were extracted and time stamped, and correlated with the malware hash list version.

Subsequently an analysis was conducted to answer the questions posed above. At no point was an attempt identify a website name from the hashes. Also, note that a single website can have more than one unique hash. For example: “www.abcd.com”, “abcd.com”, and “www.abcd.com/infected/” can all generate different hashes.

Brief Highlights

• Total number of unique hashes tracked: 688,602.
• Average number of unique hashes per day (over 113 day period): 6093.
• 25.8% of hashes never got off the Google blacklist.
  Each one of these unique hashes was deemed infected for over 3 months (greater than 113 days).
• 43% of hashes were listed exactly once as infected and managed to get off the Google blacklist.
  The average time each of these hashes was blacklisted was 13 days (89 days max).
• 2% of hashes were blacklisted exactly twice.
  Each one of these hashes was blacklisted, was then removed from the blacklist and then fell back in (the sites were hacked again). These sites remained infected for an average of 19 days (89 days max), and remained clean for an average of 17 days before being hacked again.

Analysis
It is clear from these initial results that a very large number of websites, nearly one quarter of the 6000 hashes added per day never make it off the Google blacklist. There are a number of reasons for this. One being that most webmasters, who may be good at website design and layouts, may not have the technical skills which are required to clean websites infected by malware and code injection attacks. We have also met website owners who are extremely business savvy, but lack the technical expertise to recover from a blacklisting event. The income lost due to business interruption in these cases is considerable.

We see that 43% of websites which get blacklisted manage to make it off the blacklist, but these websites suffer for an average period of 13 days.

Some websites manage to get off the blacklist and then fall in again. The average time for these “repeat offenders” on the blacklist is larger than the previous case. The time for which these “repeat offenders” stay clean is not very high, an average of just 17 days.

Conclusion
These numbers clearly show the current sorry state of website security. It is unfortunate that thousands of websites are affected every day. At stopthehacker.com, we strive to help combat this trend.  These issues need to be addressed specifically by services that currently are not readily available to the masses. To address this vacuum in the service space, and disrupt the security market stopthehacker.com provides its advanced Health Monitoring and Vulnerability assessment services for website owners. Our services take away the anguish which business owners face when their websites are attacked. Please visit our services page to find out how we can help you. In fact, you can even sign up for free services.

Further detailed analysis will be presented in the second part of this series. We will show detailed analysis of the data and will provide more insight on the implications of these observations.

Stay tuned for Part 2!

The documents clearly show the amounts, the specific merchants, dates, and places where the transaction was made and more. The documents include a complete Microsoft Office Excel breakup of the charges, with account numbers and other details. These documents were not password protected or on a protected website, they were completely in the open, no authorization needed.

We notified American Express of these details of via their online contact form (which is available after you log into their system), at approximately on June 7th, 2010, at 9:17 AM PDT. The files were still available on the American Express website as of June 7th, 2010, at 9:28 AM PDT.

We’re curious if these are fake documents deliberately put out on the site. If they are, it would be interesting to know why they have chosen to do so.

We hope someone at American Express will take notice of this important issue. As previously mentioned, American Express was contacted prior to this posting. (Edit: See the reply from American Express below.)

The reply from American Express:

Thank you for your email.

I have forwarded your comments regarding this situation to our concerned department, so that they may look into this issue. During this review, we may contact you if additional information is required.

Be assured that the feedback we receive from Card members plays an important role in enhancing your customer experience

We take our Cardmembers’ security concerns very seriously. We hope that if you suspect the legitimacy of an e-mail you receive in the future, you will forward a copy to us, so we can investigate it for you.

We very much appreciate your vigilance on our behalf. If we can be of assistance to you in the future, please contact us.

We value the relationship built with you and we hope that you will continue to allow us to meet your Card needs for many more years.

Have a wonderful day!

Update: American Express replied on June 7th, 2010, at 9:51 AM PDT.

Obfuscated screenshot below:

Update: Screenshot removed.

Most universities spend large sums of money buying IDS, IPS and Spam Filter technology and their various licenses. This should, at least in theory, allow universities to cut down on the number of such zombie machines by identifying tell tale signs of malicious communication and by analyzing their network traffic.

Experiment Goal

To understand if universities are harboring zombie machines, which can be used for spam campaigns.

Methodology

We have collected a list of 2070 universities. Each university’s DNS was queried to determine the IP address being used to host each website. This IP address was cross-referenced with data from Route Views to identify the AS number hosting that IP (using data from CAIDA). The AS number was then used to mine IP ranges advertised as BGP updates. Once the CIDR IP ranges were been found, the IPs in the CIDR range were checked with Spamhaus’s Zombie Blacklist. The experiment was conducted between March 12th and March 16th, 2010.

Our Observations

• Number of unique universities: 2070
• Number of Unique ASes observed: 829
• Total number of probed: 434,083 IPs
• Size of zombie blacklist: 2,130,944 IPs

Highlights

We present some interesting observations on the data analyzed.

• Only AS174, Cogent Communications, Inc., was found to contain zombies (see list below).
• Only 0.67% of educational institutions are associated with spam-zombie IP addresses.
• Only 0.12% of ASes seem contain spam-zombie IP addresses.

Frequency distribution of the number of IPs tested.

Conclusion

It seems that Universities are unfairly maligned by reports of zombies in their networks. Based on the findings of this preliminary set of experiments, having not found spam-zombie machines in large numbers in residence on university sub-nets, it seems that universities are doing a pretty good job of combating spam-zombies and keeping the Internet safe.

Till next time.

The following educational institutes were associated with AS174:

69.87.162.66     http://www.morehouse.edu/
164.68.1.24      http://www.lakeforest.edu/
38.105.70.154    http://www.mica.edu/
216.177.122.173  http://www.bmc.edu/
131.125.1.105    http://www.kean.edu/
38.115.20.155    http://www.medaille.edu/
38.107.150.150   http://www.stvincent.edu/
198.17.40.106    http://www.ursinus.edu/
38.98.251.141    http://www.vfcc.edu/
192.188.131.10   http://www.wju.edu/
38.109.194.106   http://www.rmcad.edu/
216.228.143.82   http://www.desu.edu/
38.105.74.129    http://www.udc.edu/
216.177.122.152  http://www.tcmi.org/
192.133.83.145   http://www.holycross.edu/
198.100.0.33     http://www.marymount.edu/

In this article we show that, unlike what you might think, the credit card black-market operates very much in the open. Below we point out websites, which can be used to tap into the cyber black-market and find stolen credit card numbers and the associated credentials to purchase for any purpose they desire. We also show instant messenger handles, emails and details of what cyber criminals are selling on the Internet.

We analyzed 429 unique domains and 615 unique URLs. Each of these URLs contained information about buying stolen credit card information. Each URL lead to a web page where cyber-criminals have posted details about how to interact with them and buy stolen financial credentials. In the majority of cases, cyber criminals who are selling this information can provide one of the following types of data.

The data for this article was collected between February 27th and March 2nd, 2010.

Basic Credit Card Information Offers:

Usually consists of credit card number, type, expiration date and CVV.

USA & CANADA CCV2

VISA/Mastercard ~ 2USD/each
AmEX/Discover   ~ 4 USD/each

UK & WU CVV2

VISA/Mastercard ~ 3USD/each
AmEx/Discover   ~ 5USD/each

Premium Credit Card Information Offers:

Usually consists of credit card number, type, expiration date, CVV, SSN, Home Address, Full Name, Date of Birth and much more.

USA & CANADA CCV2

VISA/Mastercard ~ $35/each

UK & EU

VISA/Mastercard ~ $40/each

ACCOUNT INFORMATION:
First Name: xxxxx
Last Name: xxxxx
Address: xxxxx xxxxx xxxxx xxxxx
Apt:
City: Homestaed
State: FL
Zip: xxxxx
Home Phone: (xxxxx)xxxxx-xxxxx
Work Phone: (xxxxx)xxxxx-xxxxx
Email: xxxxx@yahoo.com
SSN: xxxxx-xxxxx-xxxxx
License Number: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
License State: FL
DOB: 09/xxxxx/xxxxx

PAYMENT INFORMATION:
Credit Card Type: VISA
Number: xxxxxxxxxxxxxxx
CCV: 889
Expiration Date: 11/2008
Name: xxxxx xxxxx
Card Name First: xxxxx
Card Name Last: xxxxx

PayPal Information Offers:

Verified account                 ~ 20USD/each
Verified account with email pin  ~ 25USD/each
Verified acccount with full info ~ 35USD/each
unverified account               ~ 10USD/each

Some domains host multiple instances of stolen Credit Card Ads, (CC-Ads). We present the frequency distribution of CC-Ads on each unique domain below.

Frequency of CC-Ads on each unique domain.

Interesting Highlights:

• None of the websites advertising stolen credit card data were blacklisted by Google’s Safe Browsing List. This could potentially indicate that cyber criminals are conscientious of not discouraging visitors to these sites.
• Cyber criminals prefer to get paid via Liberty Reserve and Western Union money transfer services.
• Some cyber criminals have used images to provide quotations [img].
• Yahoo.com seems to be the email and instant messaging service preferred by cyber criminals.
• Nearly 75% of sites with CC-Ads are located in the US (see graph below).

IP Geo-location for websites with CC-Ads.

Conclusion:

It is clear from the current state of the credit card black-market that cyber criminals can operate much too easily on the Internet. They are not afraid to put out their email addresses, in some cases phone numbers and other credentials in their advertisements. It seems that the black market for cyber criminals is not underground at all. In fact, it’s very “in your face.” Clearly a more concerted effort is required to clamp down on this problem. Simply tying up loose ends on the enterprise side is not enough to combat this problem when there is virtually nothing to stop criminals from touting their stolen wares freely in the Internet.

Editor’s Note: We are providing a limited list of sites as an example of the brash lawbreaking behavior of these cyber criminals. We believe it is important for the purpose of this article that the reader be able to verify our statements. Additionally, we believe that consumer awareness of the problem can only serve to reduce the ease with which these criminals operate.

Forums used to buy and sell stolen credit card information:

*hxxp://ghostmarket.net
*hxxp://gayatheists.2.forumer.com
*hxxp://www.pakbugs.com/sell
*hxxp://forums.lava-carding.com
*hxxp://www.offcarding.forums-free.com
*hxxp://hack0rz.forums-free.com
*hxxps://security-shell.ws
*hxxp://silverspam.net
*hxxp://sellcvv2.forums-actifs.com

Various instant messenger credentials [1] [2] [3] used by cyber criminals:

People who interacted with “ubuntu_kana” (Yahoo messenger):

• ahmadshrief11@yahoo.com, davidlindon1@gmail.com, frankykkk@yahoo.com, suzannasuro@gmail.com, alexgenieve@hotmail.com, dave3331@gmail.com, ccvhack21@yahoo.com, trungtuyen68@yahoo.com, XUAN_CCS@YAHOO.COM, niklasjulius@rocketmail.com, boy_magnanimous@yahoo.com, FRESH_HACK2002@YAHOO.COM, vic.sell@yahoo.com

People who interacted with “peeseller” (Yahoo messenger):

• aloopapa@yahoo.com, dumpsfresh@yahoo.com, ug.tsunami@yahoo.com, sellrep@yahoo.com,

People who interacted with “bagiabancc” (Yahoo messenger):

• WorkusaJob@yahoo.com, david_cuong_85@yahoo.com, salulynho@yahoo.com, vang_kiban@yahoo.com, pro.cv2er@gmail.com, pro.cv2er@hotmail.com

• Reuters via Threat Level | Wired.com

Users were targeted via a vulnerability in Internet Explorer when they visited websites infected with the malware. Spanish authorities shutdown the Mariposa bot-net on December 23, 2009 although the details of what is being called the “largest cyber-raid to date” are just being released.

Infection Statistics:

• 190 countries
• 40 of the largest financial institutions
• 50% of 1,000 largest companies

Consider the fact that malicious individuals and organizations have already targeted government organizations including the FDIC, IRS, FBI and many more with success. The government response trying to educate the masses can be found in many places. [1] [2] [3]

The goal of this experiment:

• To determine whether government sites provide authentication information using HTTPS.
• To identify characteristics of government websites using or not using HTTPS.

Experiment methodology:

An initial corpus of 150 government websites was mined (via USA.gov). Each website was tested for three signs that indicate whether they employ any authentication mechanism to prove their identity to a visitor.

This experiment was conducted between February 24th and February 25th, 2010.

The three points are listed below:

1. Does the website offer a SSL connection secured by a certificate?
   • If it does, we identify the issuer and the expiration date.
2. Does the website respond to the HTTPS request within 60 seconds?
   • If it does not, we identify the server as mis-configured.
3. Does the website seem to have pages, which have an “https://” in the URL?
   • We find these pages as indexed by Google (e.g. https://secure.site.gov/login.asp).

We present the most interesting results here:

• Only 53% of government sites offer an SSL certificate to prove their identity.
  Note: The certificates for these sites will not expire in less than 30 days.
• Approximately 6% of government sites have self-signed SSL certificates or certificates signed by authorities which are not widely recognized.
  Note: Accessing these websites via a modern browser will cause a warning message to be displayed.
• Approximately 13% of government sites use expired SSL certificates to prove their identity.
• Approximately 1% of government sites have credentials which will expire in less than 30 days.
• A whopping 33% of government sites with HTTPS are mis-configured. However, they work fine with HTTP.

Significant numbers of government websites are not using authentication mechanisms effectively.

Conclusion:

This limited experiment shows that websites operated by the government have a long way to go in terms of proving their identity to end users. These issues should not be treated lightly as they provide impetus to malicious individuals to develop phishing scams targeting government owned infrastructure.

Note: Due to the sensitive nature of this information we will not disclose specific government sites with security issues.

Watch Anirban describe the goals of stopthehacker.com:

• Scott Tech Center & Innovation Accelerator Host Cyber Security Event

Thanks again to the Silicon Prairie News for covering us at the event!

Case in point:

• Google: goo.gl
• Microsoft: binged.it

These URL shortening services are godsend for Internet surfers tired of copying and pasting long, ugly looking, URLs. But hold on a minute! All is not hunky dory in URL Shortening Land.

Due to processes inherent to “URL Shortening,” the original URL an Internet surfer might like to shorten is, for all purposes, being obfuscated. Is this a problem? Yes. Why, you ask? Consider the fact that people, not even necessarily tech-savvy ones, have learned to double check the links present in their emails and on websites. They even have help from various browser plugins, but in general, users are smartening up. When these same people see “shortened” links, they have no way to make a judgment call on whether visiting the link is safe, or not. For example, you may recognize www.stopthehacker.com as being a benign, safe to visit link, but what about bit.ly/oJMrP or bit.ly/dc38ze?

Articles published from credible sources, like ISC SANS, show that URL shortening services, when compromised, can provide an excellent mechanism for malicious hackers to infect unsuspecting visitors. Criminals use these services to bypass Google’s Safe Browsing service, which is used by popular browsers.

To combat this growing menace, URL shortening services have partnered with security companies to identify malicious URLs and websites. Some of them even use the SURBL blacklists to identify if someone has tried to link to a malicious website.

This article attempts to identify the effectiveness of security measures put in place by the various URL shortening services.

This experiment answers the following questions:

• Do URL shortening services have any kind of security measures in place?
• How effective are these security measures?

The 25 URL shortening services evaluated in this article are listed below:

We compare 25 URL shortening services listed below. Each URL shortening service is analyzed to measure the effectiveness of their security measures. We use a two stage process to evaluate the security implemented by each service.

snipr.com
budurl.com
bit.ly
short.to
twurl.nl
chilp.it
fon.gs
ub0.cc
snurl.com
fwd4.me
short.ie
a.gd
hurl.ws
kl.am
to.ly
hex.io
tr.im
cli.gs
urlborg.com
is.gd
sn.im
ur1.ca
tweetburner.com
tinyurl.com
snipurl.com

Experiment methodology:

An initial corpus of 932 websites was obtained from Malware Patrol a well respected source of information about malware infected websites, which receives nearly 3,500,000 hits/month. This experiment was conducted between February 2nd and February 4th, 2010.

For each URL obtained from Malware Patrol, we attempt to create shortened URLs for each site domain and full URL using each of the 25 services.

We denote a service as Stage 1 Compliant if it appears to use a security service or blacklist to identify malicious domains and does not allow a user to create a shortened link to any infected domain. Does the URL shortening service allow a user to create a URL pointing to a malicious domain (e.g. http://www.badsite.dom)?

We denote a service as Stage 2 Compliant if it uses a security service or blacklist to identify malicious domains and does not allow a user to create a shortened link to any infected domain or malicious full URL hosted on that domain. Does the URL shortening service allow a user to create a URL pointing to a malicious link hosted on a malicious domain (e.g. http://www.badsite.dom/badfolder/badfile)?

We present the most interesting results in brief:

• Approximately 68% of URL shortening services were Stage 1 Compliant.
• Approximately 56% of URL shortening services were exclusively Stage 2 Compliant.
• Approximately 52% of URL shortening services were both Stage 1 Compliant and Stage 2 Compliant (see graph below).

Observations on specific URL shortening services:

• bit.ly seems to favor blocking malicious domains rather than specific links.
• fwd4.me, hurl.ws and urlborg.com seem to favor blocking malicious links rather than specific domains.
• bit.ly failed to qualify as Stage 2 Compliant due to 0.5% of tested URLs.
• fwd4.me failed to qualify as Stage 1 Compliant due to 9.8% of tested URLs.
• hurl.ws failed to qualify as Stage 1 Compliant due to 0.3% of tested URLs.
• urlborg.com failed to qualify as Stage 1 Compliant due to 0.3% of tested URLs.

Venn Diagram depicting URL filtering capabilities of URL shortening services. Only about half of the most popular URL shortening services are effective at blocking malicious URLs.

Stage 1 Compliant and Stage 2 Compliant services:

budurl.com
cli.gs
fon.gs
hex.io
is.gd
kl.am
sn.im
snipr.com
snipurl.com
snurl.com
to.ly
tr.im
ub0.cc

Deeper security issues remain:

It seems that popular services like bit.ly, which do try to use blacklists in order to prevent malicious hackers from using their services and pointing to bad websites, can still be easily fooled by chaining together shortened URLs created by another service. We have found that if a malicious user can create a shortened URL using a service that does not implement blacklist checks or is not effective, then a service like bit.ly can be tricked into redirecting the visitor via the malicious shortened URL to a malicious domain. Effectively, users can be redirected to a malicious site regardless of bit.ly performing all its checks. See the appendix for an example below (wget log).

Conclusion:

This limited experiment shows that URL shortening services have a long way to go before Internet users can trust them to deliver safe links. About half of the most popular URL shortening services seem to be somewhat effective at blocking access to well known malicious URLs that can be found on blacklists. It remains to be seen if these URL shortening services can improve and provide a safer web experience for their users.

Appendix

Wget log example:

In this example, a malicious link (hxxp://wywg.ccsfyb.cn/wywg/txer) has been shortened using ow.ly (hxxp://ow.ly/Zyv3). Then, this shortened URL is fed to bit.ly. The shortened bit.ly URL (hxxp://bit.ly/5s4YhP) is created successfully and blacklist checks are no longer effective.

$ wget -O demonstrate_bit.ly_exploit http://bit.ly/5s4YhP
--scrubbed--  http://bit.ly/5s4YhP
Resolving bit.ly... 168.143.174.29, 128.121.234.46, 128.121.254.129, ...
Connecting to bit.ly|168.143.174.29|:80... connected.
HTTP request sent, awaiting response... 301 Moved
Location: http://ow.ly/Zyv3 [following]
---scrubbed--  http://ow.ly/Zyv3
Resolving ow.ly... 75.101.155.42
Connecting to ow.ly|75.101.155.42|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://wywg.ccsfyb.cn/wywg/txer [following]
---scrubbed--  http://wywg.ccsfyb.cn/wywg/txer
Resolving wywg.ccsfyb.cn... 98.126.11.178
Connecting to wywg.ccsfyb.cn|98.126.11.178|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://wywg.ccsfyb.cn/wywg/txer/ [following]
---scrubbed--  http://wywg.ccsfyb.cn/wywg/txer/
Reusing existing connection to wywg.ccsfyb.cn:80.
HTTP request sent, awaiting response... 403 Forbidden
-scrubbed-- ERROR 403: Forbidden.

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.

See below for detailed breakdown of the distribution of vBulletin versions:

• 0.89% of sites were running version 3.0.13
• 0.29% of sites were running version 3.0.14
• 0.29% of sites were running version 3.0.3
• 0.29% of sites were running version 3.0.5
• 0.29% of sites were running version 3.0.7
• 1.18% of sites were running version 3.5.2
• 2.67% of sites were running version 3.5.4
• 0.29% of sites were running version 3.6.1
• 1.18% of sites were running version 3.6.10
• 0.59% of sites were running version 3.6.12
• 1.18% of sites were running version 3.6.2
• 4.45% of sites were running version 3.6.4
• 0.29% of sites were running version 3.6.6
• 1.48% of sites were running version 3.6.7
• 4.74% of sites were running version 3.6.8
• 0.29% of sites were running version 3.6.9
• 2.96% of sites were running version 3.7.0
• 2.37% of sites were running version 3.7.1
• 1.78% of sites were running version 3.7.2
• 4.74% of sites were running version 3.7.3
• 2.37% of sites were running version 3.7.4
• 1.18% of sites were running version 3.7.5
• 2.96% of sites were running version 3.7.6
• 1.48% of sites were running version 3.8.0
• 8.90% of sites were running version 3.8.1
• 10.3% of sites were running version 3.8.2
• 3.85% of sites were running version 3.8.3
• 31.7% of sites were running version 3.8.4
• 2.07% of sites were running version 4.0.0
• 2.07% of sites were running version 4.0.1
• 0.59% of sites were running version 4.0.2