Magento Shoplift (SUPEE-5344) Exploits in the Wild

As warned a few days ago, the Magento Shoplift (SUPEE-5344) vulnerability details have been disclosed by the CheckPoint team. They show step by step how it can be exploited to take over a vulnerable Magento site.

They have prepared the following video showing a Proof of Concept (PoC) in which they create a fake coupon:

That’s a simple example. This vulnerability can be exploited in much more devastating ways.

Magento ShopLift in the Wild

As expected, it is now actively being exploited.

In less than 24 hours since the disclosure, we have started to see attacks via our WAF logs trying to exploit this vulnerability. It seems to be coming from a specific crime group, since they all look the same:


Read More

Security Advisory: XSS Vulnerability Affecting Multiple WordPress Plugins

Multiple WordPress Plugins are vulnerable to Cross-site Scripting (XSS) due to the misuse of the add_query_arg() and remove_query_arg() functions. These are popular functions used by developers to modify and add query strings to URLs within WordPress.

The official WordPress Official Documentation (Codex) for these functions was not very clear and misled many plugin developers to use them in an insecure way. The developers assumed that these functions would escape the user input for them, when it does not. This simple detail, caused many of the most popular plugins to be vulnerable to XSS.

To date, this is the list of affected plugins:

There are probably a few more that we have not listed. If you use WordPress, we highly recommend that you go to your wp-admin dashboard and update any out of date plugins now.


Read More

Critical Magento Shoplift Vulnerability (SUPEE-5344) – Patch Immediately!

magento-security

The Magento team released a critical security patch (SUPEE-5344) to address a remote command execution (RCE) vulnerability back in February. It’s been more than two months since the release and still more than 50% of all the Magento installations have not been patched, leaving them open to attacks.

This means hundreds of thousands of websites are vulnerable right now, worst yet they are Ecommerce websites. This means that they are used to sell goods online, capturing personal identifiable information (PII), including credit card information. The impacts of Magento websites getting compromised can be devastating for every online buyer that uses or has used a website built on the platform.


Read More

FBI Public Service Annoucement: Defacements Exploiting WordPress Vulnerabilities

IMG_2802

The US Federal Bureau of Investigation (FBI) just released a public service announcement (PSA) to the public about a large number of websites being exploited and compromised through WordPress plugin vulnerabilities:

Continuous Web site defacements are being perpetrated by individuals sympathetic to the Islamic State in the Levant (ISIL) a.k.a. Islamic State of Iraq and al-Shams (ISIS). The defacements have affected Web site operations and the communication platforms of news organizations, commercial entities, religious institutions, federal/state/local governments, foreign governments, and a variety of other domestic and international Web sites. Although the defacements demonstrate low-level hacking sophistication, they are disruptive and often costly in terms of lost business revenue and expenditures on technical services to repair infected computer systems.


Read More

Intro to E-Commerce and PCI Compliance – Part I

Sucuri-ecommerce-PCI-compliance

Have you ever heard of the term PCI? Specifically, PCI compliance? If you have an e-commerce website, you probably have already heard about it. But do you really understand what it means for you and your online business? In this series, we will try to explain the PCI standard and how it affects you and your website.

We will focus mostly on small and medium size e-commerce based solutions, which is the category that most of our clients fall into.

Part I – Introduction to E-Commerce and PCI Compliance
Part II – PCI and E-Commerce cloud-based SMB’s (coming soon)
Part III – PCI and your WordPress-based e-commerce (coming soon)
Part IV – PCI requirements in detail for cloud-based servers – Open source can help

What is PCI?

PCI is not a law or a government regulation. The right name is actually PCI DSS, which means Payment Card Industry – Data Security Standard. So PCI is a standard that contains a series of security requirements that every merchant, big or small, must follow, to be in compliance.

PCI was created and is mandated by the five major credit card companies: Visa, MasterCard, American Express, Discover, and JCB. The PCI council now administers and keeps it updated.

Every merchant falls under PCI, even if you do not handle a large volume of transactions or use external providers to outsource your credit card information.

For those merchants that outsource their payment process, the scope of PCI is smaller and the verification requirements are lower and can likely be achieved by completing the PCI Data Security Standard (DSS) Self Assessment Questionnaire (SAQ). However, they must still follow the requirements.

PCI and Small Businesses

Many of our clients think that PCI does not apply to them because they are small. This is a very common mis-conception. PCI applies to any business that processes, stores or transmits credit card data. I will quote the PCI website section for SMB’s to explain how seriously they take it:

Small Merchants – You must secure cardholder data to meet Payment Card Industry rules!

Small merchants are prime targets for data thieves. It’s your job to protect cardholder data at the point-of-sale.

If cardholder data is stolen – and it’s your fault – you could incur fines, penalties, even termination of the right to accept payment cards!

If you are not taking security seriously and you do get hacked and your customers information is stolen, you will face serious repercussions.

Why should you care about PCI?

PCI compliance is mandatory if you accept credit card payments. You can’t run away from it. If you do not follow their requirements, you may face penalties, fines and even be prohibited from accepting credit cards in the future.

But that’s not the real reason why you should care about PCI. The real reason is that PCI gives you a number of very good recommendations to secure your online business. They will minimize the risk of your site getting compromised and having information stolen. I assure you that your customers will be very grateful not to have their information stolen from your website.

The fines for not complying with PCI can be harsh, but won’t be worse than the brand impact and the lost of trust from your clients by not taking security seriously.

PCI requirements

Now that you know what PCI is and what you should care about, let’s look at what it entails.

It is divided into 6 major categories, 12 requirements:

Build and Maintain a secure network
Requirement 1- Install and maintain a firewall.

Requirement 2- Do not use vendor-supplied defaults for system passwords or other security parameters.

Protect Cardholder data
Requirement 3- Protect stored cardholder data.

Requirement 4- Encrypt transmission or cardholder data across public networks.

Maintain a vulnerability management program
Requirement 5- Protect all systems against malware and regularly update anti-virus programs.

Requirement 6- Develop and maintain secure systems and applications.

Implement Strong Access Control Measures
Requirement 7- Restrict access to card holder data by business need-to know.

Requirement 8- Identify and authenticate access to system components.

Requirement 9- Restrict physical access to card holder data.

Regularly Test and Monitor Networks
Requirement 10- Track and monitor all access to network resources and card holder data.

Requirement 11- Regularly test security systems and processes.

Maintain an Information Security Policy
Requirement 12- Maintain an information security policy.

These 12 requirements cover different business areas that break down into more than 200 sub-requirements.

Each sub requirement is a check box in the self-assessment questionnaire that you will have to to follow. They can be very simple, an example being 6.2 that requires that “all system components and software are protected from known vulnerabilities by installing patches” to some more complex requirements like 10.2 that requires “automated audit trails implemented on all system components”.

PCI and e-commerce sites

In the next article of this series, we will talk about PCI and E-Commerce-only businesses. What do you have to do if you have a small business that is all online? What if you do not have a real network and your site is in the cloud? What if your business is only you?

Understanding WordPress Plugin Vulnerabilities

The last 7 days have been very busy with a number of vulnerabilities being disclosed on multiple WordPress plugins. Some of them are minor issues, some are more relevant, while others are what we’d categorize as noise. How are you supposed to make sense of all this?

To help provide some clarity on the influx of data, we want to provide some insights to help you, the website owner, navigate and understand these vulnerabilities. We will provide a summary and an explanation of the ones that matter and the ones that do not.

The Impact of Roles (Authentication) in Vulnerabiltiies

Contrary to popular belief, just because you hear “SQL Injection”, it doesn’t mean someone can actually hack your site. The real problem comes in remote and unauthenticated attacks. These can lead to mass compromises; compromised can be mean leveraged to distribute malware, spam and can lead to brand reputation issues like getting blacklisted by Google.

When an attack requires an authenticated user, the severity drops. However, it is not that uncommon for sites to allow subscribers to register. So, any vulnerability that requires a subscriber user can also lead to serious issues.

Once a vulnerability requires a higher role, think authors or editors, the severity and our overall score drops though. The reason this is true is because users with higher roles often have higher permissions and abilities to do things that can sometimes be seen malicious, but are in fact by design. A perfect example of this can be seen in WordPress core.

In core, an administrator is able to inject unfiltered html in posts and pages, and can also execute any command they want via plugins they install. Is this a vulnerability? No, it’s a feature and it’s based on one very important element – Trust. The user that is given that role is given permission to do whatever features have been made available, so if that’s to inject unfiltered html, then the user is expected to do so responsibly.

In security, this is why we place so much emphasis on concepts like Least Privileged – the principle of giving someone the permission they require to do their job, no more, and no less. If they require higher permissions, then give them what they need, for as long as they need it, then reset the role to its original configuration. This however is a topic for another day, but worth understanding as it sets context moving forward.

Scoring Vulnerabilities on WordPress Plugins

We like to use the DREAD score when assessing a vulnerability in WordPress Plugins. A question we often get is, why did you not report on this recent release? Or, why did you report on this release? DREAD allows us to take a more objective approach to released, in hopes that we’ll be able to cut down on the noise and market confusion.

DREAD was developed by Microsoft many years ago and is not that widely used anymore. For us however, we find it to be very useful for web applications, especially when it comes to Content Management System (CMS) disclosures.

DREAD breaks a vulnerability down into 5 categories:

Damage – How bad would an attack be?
Reproducibility – How easy is it to reproduce the attack?
Exploitability – How much work does it take to launch the attack?
Affected users – How many people will be impacted?
Discoverability – How easy is it to discover the threat?

Each category gets a score from 0 to 10 and at the end, you sum them all and divide by 5 to get the final value.

How we classify each category is what counts the most in the work we do:

  1. Damage – 0:same as what the role has, 3:Information Leaks, 5:XSS, 8:Authenticated RCE or SQL Injections, 10:Unauthenticated Remote command execution or SQL injections.
  2. Reproducibility – 0:requires admin, 2:requires editor, 3:requires author, 6:requires subscriber, 10: unauthenticated
  3. Exploitability – 0:fully manual and takes very long, 3:hard to automate, requires author+, 5:hard to automate, requires login, 8:easy to automate, multiple steps 10:one click on a browser
  4. Affected users – 0:less than 1k installs, 5:100k+ installs, 10:1m+ installs
  5. Discoverability – 0:you have to attempt an exploit to see if it works or not, 3:you have to guess and it requires a log in,6:you have to guess but can attack remotely, 10:plugin announces that it is installed.

With these ranges in mind, let’s see how each vulnerability stacks up.

Gravity Forms: SQL Injection / Severity: Low

The gravity forms team just released an update fixing a SQL Injection (SQLi) on the “sort” argument on their edit page. Only an authenticated admin or editor can actually reach that part of the code, so we consider it a low severity vulnerability. Editors and admins can do so much already, that only trusted people should have this role. If the admin user is performing a SQLi attack, they are likely conducting a number of other attacks and SQLi is probably the least of your concerns.

It can be used on targeted attacks, due to the lack of nounces, but we will not see any major issues coming out of it.

Looking at DREAD:

D: 8
R: 2
E: 3
A: 7 (since it is a paid plugin, we don't know exactly the number of installs)
D: 3

The final score is 4 – Low (8 + 2 + 3 + 7 + 3 / 5)

Pods Plugin: SQL Injection / Severity: Low

The Pods vulnerability is actually very similar to the GravityForms and the WordPress SEO ones. Looking at the DREAD score:

D: 8
R: 2
E: 3
A: 2
D: 5

Final score is 3 – Very Low (8 + 2 + 3 + 2 + 3 / 5)

MainWP-Child: Password Bypass / Severity: High

The MainWP vulnerability was found by our team and we gave it a high severity. The reason we did so is that it was very easy to exploit (unauthenticated) and allows anyone to get admin access to the vulnerable site.

D: 10
R: 10
E: 9
A: 5
D: 6

Final score is: 8 (high) (10 + 10 + 9 + 5 + 6 / 5)

WooCommerce: SQL Injection / Severity: Very Low

The WooCommerce vulnerability is interesting, since it requires an admin or shop manager in order to exploit it. We would not treat is a vulnerability, but as a bug, since it does not allow more damage than what the role (admin) actually can cause.

D: 0 (same damage as the role itself can cause)
R: 0 (requires admin)
E: 1
A: 10 (1m+ installs)
D: 3

Final score is: 2 (very low) (0 + 0 + 1 + 10 + 3 / 5)

WordPress SEO: SQL injection / Severity: Low

The WordPress SEO vulnerability got a lot of media coverage due to its popularity. Was it valid? Let’s look at the scores again:

D: 8
R: 3
E: 3
A: 10
D: 3

Final score is: 5 (Low) (8 + 3 + 3 + 10 + 3 / 5)

Judging Vulnerabilities

Judging vulnerabilities and its impacts is always very hard. A low severity score on DREAD, doesn’t mean it can’t be used on a targeted attack against your site. It doesn’t mean you do not have to patch it and keep your site updated.

That’s why we always make sure our Website Firewall (WAF) is protecting against all of them. For every new vulnerability disclosed, our research team invests the time to test, verify and validate their impacts and ensures that our protection mechanisms are effectively patching and protecting or users.

When looking at the internet as a whole, low severity vulnerabilities will have a small impact overall and requires less marketing to get to the ear of the users. It’s also difficult to decipher the amount of noise being disclosed, we hope this helps provide some guidance into how to make sense of all the information you might be reading.

– Your Trusted Security Team

Daniel

Vulnerability Disclosures – A Note To Developers

This post is entirely for developers. Feel free to read, but approach it with that in mind.

There is no such thing as bug-free code. We all make mistakes and every piece of software will have issues that we did not anticipate. We ourselves find weaknesses in our code, and have to work extra hard to stay ahead of the issues. The same applies to every other company out there.

However, some of these bugs may have security implications that can affect the integrity, availability or confidentiality of the users deploying it. They are called software vulnerabilities.

I think it’s fair to assume that we can all relate with this to some level. What seems to be a problem however is how we, using the collective we, handle the disclosure of these vulnerabilities when brought to our attention.

  • What happens when someone identifies a vulnerability in the code we write?
  • What if it can or is being misused to hack websites that employ that same code?
  • How should we as developers respond and handle these situations?

I want to share some thoughts that I hope will provide some insights on a good disclosure and engagement strategy.

Accounting for Vulnerability Disclosures

If you are a builder and are shipping code the first thing you should plan for is a method to allow security researchers to contact you. This is first and foremost; you want to encourage folks to review your work and contact you if anything is found. You don’t have to set up a bug-bounty program or anything too formal, but at least some method to ensure that you get notified immediately of issues. We should all want to know if there is serious problem with our code.

Here are 6 steps we encourage every builder take into consideration when an if a vulnerability disclosure occurs:

1. Do Not Panic

Take a deep breathe. Everyone makes mistakes and this is likely not the end of the world. It may seem like a big deal and you may get worried that you will lose business and the trust from your users. However, if you deal with the disclosure properly, it may actually have the reverse effect and you may actually gain their trust from this experience.

I think as humans we have a predisposition for jumping straight to the negative. I’m going to lose business!! I’m going to go out of business!! We should flip this mindset to one that is more approachable, What can I learn from this? You’re in essence getting a free security review; this is a positive thing and you want to encourage an open dialog with the researchers.

2. Acknowledge.

As soon as you get the notification, let the reporter know that you have received the notification and are looking into it. We sometimes fail to realize how important this small step can be.

In the business of disclosures, it’s not uncommon for organizations to shun researchers away, and over time it’s built a culture of distrust; forcing them to believe the organization doesn’t care. This reduces the tolerance for lack of acknowledgement and can often lead to bad outcomes for everyone involved.

A simple, Thank you so much, we’re looking into this and will get back to you within X hours will pay you huge dividends.

3. Do Your Homework.

Take all the information provided by the researcher and try to confirm the issue. If you can’t reproduce the issue, don’t jump the gun and tell them they are wrong, instead ask for something known as Proof of Concept (PoC). Remember, this researcher is taking time out of their day to report something to you to help you, attacking them or blowing them off will do little in your favour.

Once the PoC is provided, you should work to provide the researcher a timeline. In the world we live in today, with web applications, timelines that extend beyond 2 weeks really aren’t acceptable. If you must extend beyond that, be sure to communicate with the researcher on the reasons behind the delay.

The pressure to release sooner will honestly be determined by its severity, ease of exploitation and impact to the larger audience.

4. Patch It!

Please patch the problem effectively. One common mistake is to patch it where it was identified, but leave it susceptible in other parts of your code. Don’t be lazy.

Take the time to review the rest of your code for similar issues. There is nothing that will hurt you more, than to have a similar vulnerability found a week later, but on another part of your code.

5. Coordinated Disclosure

Before you release the patch, involve the researcher. Send the fixed version to the researcher, ask them to review, engage them in the process and watch it pay you dividends. They will often go above and beyond to help you think through the problem, and will help built a rapport. Once this is done, you have to plan a release – there really isn’t a way around this, especially for severe vulnerabilities.

Let the researcher know when you plan to release. Work a coordinated disclosure release schedule, most researchers love to identify problems but also love to write and share about their findings.

A good email to the researcher would be:

I will be publishing a patch on DAY X at Y time (GTM). I will follow the release with a blog post of my own shortly and will email all my clients. Can you wait 24 hours for your own disclosure? I Want my users to hear from me first.

This is a very acceptable email and most reasonable researchers will understand and respect your request. Please do not do a silent release – a silent release is a release where you avoid any mention of the vulnerability in the hopes that no one will ever find out. The researcher is likely monitoring all patches, and if they see you do this without any proper disclosure they are bound to call you on this act, publicly.

When writing a blog post (and in the release notes), you should explain what happened, the severity, who reported the issue to you and what you did to fix it. Provide links for the patch and a timeline if possible. Your users will appreciate and trust you more when you do this. Again, do not try to hide if it is a security issue. The idea that by not sharing you don’t have to worry about it being exploited is an antiquated way of thinking. An attacker worth their salt, can run a diff and see the issue right away; not saying anything does not solve the problem.

6. The Backlash.

This seems to be the biggest fear most builders have. What will my community think? What will clients think? Will my company survive?

These are normal feelings, we can assure you though this will pass. In many instances, buyers will gain renewed faith in your product once they see how well you responded.

The core of your message should be: Yes, an issue was found, but more importantly this is what we learned and what we’re doing moving forward to make sure it never happens again.

Example of Good Disclosure

Remember, no one is perfect and with time, any product may have a security vulnerability discovered. I want to leave you with a good example from the JetPack team. They recently handled a vulnerability disclosure and did so brilliantly in our eyes: http://jetpack.me/2014/04/10/jetpack-security-update/.

They patched the issue right away and notified everyone, including hosts and partners about the problem. Even provided detection rules that security operators could use to detect and block a possible exploit.

Your Turn

I welcome thought and opinions in the comments, and if something makes sense we’ll address it accordingly. As mentioned before, this was drafted to provide you some thoughts and guidance, not dictate. Yet, we hope you find it helpful.

Zero-day in the Fancybox-for-WordPress Plugin

Update: We posted an analysis of the vulnerability following this post.

Our research team was alerted to a possible malware outbreak affecting many WordPress websites. All the infections had a similar malicious iframe from “203koko” injected into the website. We were also directed to a forum thread where users were sharing their concerns and describing similar issues they were experiencing.

In analyzing the infected websites, we found that all the websites were using the fancybox-for-wordpress plugin.

Zero day in fancybox-for-wordpress

The fancybox-for-wordpress plugin is a popular WordPress plugin with more than 550,000 downloads. There doesn’t appear to be any public vulnerabilities being reported, which piqued our interest. To understand how it was connected, we decided to do our own code / vulnerability review.

After some analysis, we can confirm that this plugin has a serious vulnerability that allows for malware (or any random script/content) to be added to the vulnerable site. Because it is currently unpatched, we will not disclose more information.

What makes things worse, is that it’s being actively exploited in the wild, leading to many compromised websites.

We could confirm via our Website Firewall logs by seeing many exploit attempts blocked.

This is what the attacks looks like:

46.4.76.174 – – [04/Feb/2015:00:25:09 -0500] “POST /wp-admin/admin-post.php?page=fancybox-for-wordpress HTTP/1.1″ 403 4207
INPUTBODY:action=update&mfbfw%5Bext.. malware payload hidden

Remove this plugin Immediately!

The plugin was just removed by the WordPress.org team from their repository and you need to remove it from your site as well! If you require it for specific features you really need to look at deploying alternative security solutions to help protect your website and block exploit attempts.

Users of our Website Firewall are already protected, but if you do not employ a similar service and leverage this plugin consider yourself highly vulnerable and high risk of compromise.

We will post more details about this vulnerability once we have given time for everyone to patch (when it becomes available).

Special thanks to Konstantin Kovshenin and Gennady Kovshenin for notifying and working with us on this issue.

DDoS from China – Facebook, WordPress and Twitter Users Receiving Sucuri Error Pages

Over the past few weeks, our Security Operation Center (SOC) has been seeing some different, and very suspicious requests to some of our servers. At first we thought it was a Distributed Denial of Service (DDoS) attack, mainly due to the high concentration of requests (thousands per second). Looking further however, it actually seemed like some DNS resolver was broken and redirecting all their users traffic to us.

Here are some example requests, see for yourself:

GET /100004020560199/picture HTTP/1.1
Host: graph.facebook.com

or

GET /extstyle.css HTTP/1.1
Host: static.ak.facebook.com
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

or

GET /wp-content/themes/vip/nesn/images/nesn_favicon_128.png
Host: s0.wp.com

If you do not understand why these requests are interesting, look at the Host: header. It means someone tried to visit static.ak.facebook.com or s0.wp.com and somehow reached our servers. Since we do not host Facebook or WordPress.com, it generates an error on our end.

These were not the only domains that were trying to reach us. Just in the last day, we received requests for: farm4.static.flickr.com, 24.media.tumblr.com, cdn11.optimecdn.com, l.longtailvideo.com, platform.twitter.com, media-cdn.tripadvisor.com, analytics.twitter.com, m.facebook.com, graph.facebook.com, assets.zendesk.com and many other domains.

Why is Facebook, Twitter, WordPress and Zendesk pointing to Sucuri’s Website Firewall (CloudProxy)?

That was a little mystery that took us a bit of time to understand. At first, we thought it was just a new form of DDoS trying to use random domains names to evade our detection.

However, the request headers looked very legitimate. Even via passive fingerprinting, we were able to properly tie the operating system, to the browser and the user agent. It also didn’t look like a DDoS botnet that we could identify. To our surprise, it seemed like real browser requests from valid users.

There was just one catch: all requests were coming from China.

We shared our logs and finding with multiple peers in the security community and the consensus was that these requests were not malicious per se. It seemed as if the Great Chinese Firewall was mis-configured, instead of blocking the requests to certain sites, it was redirecting, to us at that.

So if a specific site was blocked, the requests to graph.facebook.com also got blocked and redirected to us. Same for Twitter, Zendesk or media.tumblr.com.

This explains why most of the requests were actually for CDN, images or API files.

Why is the Chinese Firewall doing that?

That’s a good question and one we do not know the answer to. We can speculate that it is a bug on their end, but can’t be sure. It actually seems similar to the issue that TorrentFreak reported with Pirate bay requests being redirected to random IP addresses.

However, instead of Pirate Bay, it is happening with the most popular platforms and CDNs out there to some of our IP addresses. These “fake” attempts generate thousands of requests per second from thousands of different Chinese IP addresses. It would certainly be enough to DDoS most servers.

Is anyone else seeing something similar?

Full list of domains

If anyone is curious, these are all the domains that reached us just today:


host: “10.media.tumblr.com”,
host: “11.media.tumblr.com”,
host: “12.media.tumblr.com”,
host: “13c3a.http.cdn.softlayer.net”,
host: “15.media.tumblr.com”,
host: “16.media.tumblr.com”,
host: “17.media.tumblr.com”,
host: “18.media.tumblr.com”,
host: “1.media.tumblr.com”,
host: “20.media.tumblr.com”,
host: “22.media.tumblr.com”,
host: “23.media.tumblr.com”,
host: “24.media.tumblr.com”,
host: “26.media.tumblr.com”,
host: “28.media.tumblr.com”,
host: “29.media.tumblr.com”,
host: “2.bp.blogspot.com”,
host: “2-edge-chat.facebook.com”,
host: “2.media.tumblr.com”,
host: “30.media.tumblr.com”,
host: “3-edge-chat.facebook.com”,
host: “3.media.tumblr.com”,
host: “4.media.tumblr.com”,
host: “5.media.tumblr.com”,
host: “6.media.tumblr.com”,
host: “7.media.tumblr.com”,
host: “8.media.tumblr.com”,
host: “987hh.com-www.45878.com”,
host: “9.media.tumblr.com”,
host: “a1.dspnimg.com”,
host: “a248.e.akamai.net”,
host: “a4.ec-images.myspacecdn.com”,
host: “abs.twimg.com”,
host: “accounts.youtube.com”,
host: “ad-audit.tubemogul.com”,
host: “a.deviantart.net”,
host: “adn.6638.edgecastcdn.net”,
host: “ads.exoclick.com”,
host: “ads.gayfriendfinder.com”,
host: “ads.w55c.net”,
host: “am.6park.com”,
host: “analytics.twitter.com”,
host: “api.facebook.com”,
host: “apis.google.com”,
host: “api.twitter.com”,
host: “apps.facebook.com”,
host: “assets1.whicdn.com”,
host: “assets2.whicdn.com”,
host: “assets3.whicdn.com”,
host: “assets.crucial.com”,
host: “assets.mltd.com”,
host: “assets.modelmayhem.com”,
host: “assets.zendesk.com”,
host: “badge.facebook.com”,
host: “banners.videosecrets.com”,
host: “bbc6.global.ssl.fastly.net”,
host: “blogs.ocweekly.com”,
host: “bp0.blogger.com”,
host: “b.s-static.ak.facebook.com”,
host: “cache.armorgames.com”,
host: “cache.blogads.com”,
host: “cdn03.cdn.justjaredjr.com”,
host: “cdn11.optimecdn.com”,
host: “cdn1.barong.inxy-host.com”,
host: “cdn1.editmysite.com”,
host: “cdn1.nudevector.com”,
host: “cdn1.sidhe.co.nz”,
host: “cdn2.editmysite.com”,
host: “cdn2.search.xxx”,
host: “cdn3.aptoide.com”,
host: “cdn3.everyjoe.com”,
host: “cdn3.howtogeek.com”,
host: “cdn5.howtogeek.com”,
host: “cdn.adgear.com”,
host: “cdn.androidcommunity.com”,
host: “cdn.api.twitter.com”,
host: “cdn.collider.com”,
host: “cdn.c.photoshelter.com”,
host: “cdn.easyhotpics.com”,
host: “cdnedge.vinsolutions.com”,
host: “cdn.epom.com”,
host: “cdn.everyjoe.com”,
host: “cdn-frm-sg.wargaming.net”,
host: “cdn.gayboysbox.com”,
host: “cdn.gaycnn.com”,
host: “cdn.gaydudestube.net”,
host: “cdn.gq.com.tw.s3-ap-northeast-1.amazonaws.com”,
host: “cdng.vpnpie.biz”,
host: “cdnimages.gayhits.com”,
host: “cdn-images.mailchimp.com”,
host: “cdn.lfstmedia.com”,
host: “cdn-marketools.plus500.com”,
host: “cdn-mkt.wooga.com”,
host: “cdn.nitrome.com”,
host: “cdn.nudevector.com”,
host: “cdn.porn-lab.com”,
host: “cdn.pornvideospider.com”,
host: “cdn.ps.teenmodels.com”,
host: “cdn.recruitnet.co”,
host: “cdn.sidhe.co.nz”,
host: “cdn.slashgear.com”,
host: “cdn.soundstagedirect.com”,
host: “cdn.tubeporndiet.com”,
host: “cdn.usablenet.com”,
host: “cdn.xgaybox.com”,
host: “cms.myspacecdn.com”,
host: “cn.epochtimes.com”,
host: “cn.wsj.com”,
host: “comps.fotosearch.com”,
host: “content.onhotels.com”,
host: “css.c.photoshelter.com”,
host: “csync.flickr.com”,
host: “cti.w55c.net”,
host: “dc108.4shared.com”,
host: “dc200.4shared.com”,
host: “dc204.4shared.com”,
host: “dc205.4shared.com”,
host: “dc219.4shared.com”,
host: “dc265.4shared.com”,
host: “dc317.4shared.com”,
host: “dc327.4shared.com”,
host: “dc335.4shared.com”,
host: “dc644.4shared.com”,
host: “dc672.4shared.com”,
host: “dc733.4shared.com”,
host: “dingo.care2.com”,
host: “dl6.offercdn.com”,
host: “dl-web.dropbox.com”,
host: “docs.google.com”,
host: “drive.google.com”,
host: “e1.static.hoptopboy.com”,
host: “ecdn.liveclicker.net”,
host: “eg-img.agoda.net”,
host: “eg.img.agoda.net”,
host: “emoneycreater.appspot.com”,
host: “farm1.static.flickr.com”,
host: “farm2.static.flickr.com”,
host: “farm3.static.flickr.com”,
host: “farm4.static.flickr.com”,
host: “farm5.static.flickr.com”,
host: “farm6.static.flickr.com”,
host: “farm7.static.flickr.com”,
host: “farm8.static.flickr.com”,
host: “farm9.static.flickr.com”,
host: “fbstatic-a.akamaihd.net”,
host: “galleries.payserve.com”,
host: “gamemedia.armorgames.com”,
host: “gamerch-static-contents-gz.s3-ap-northeast-1.amazonaws.com”,
host: “graph.facebook.com”,
host: “graphics2.asiafind.com”,
host: “graphics2.asiafriendfinder.com”,
host: “graphics.alt.com”,
host: “graphics.cams.com”,
host: “graphics.outpersonals.com”,
host: “graphics.pop6.com”,
host: “graphics.streamray.com”,
host: “gs1.wpc.edgecastcdn.net”,
host: “i0.wp.com”,
host: “i1.sndcdn.com”,
host: “ia902706.us.archive.org”,
host: “icdn2.digitaltrends.com”,
host: “icdn5.digitaltrends.com”,
host: “icdn6.digitaltrends.com”,
host: “imagena1.lacoste.com”,
host: “imagena2.lacoste.com”,
host: “images.contactmusic.com”,
host: “images.goodsmile.info”,
host: “images.mrskincash.com”,
host: “images.neopets.com”,
host: “images.popin.cc”,
host: “img1.zergnet.com”,
host: “img2.zergnet.com”,
host: “img3.zergnet.com”,
host: “img4.zergnet.com”,
host: “img.docstoccdn.com”,
host: “img.elle.co.jp”,
host: “img.epochtimes.com”,
host: “img.fatxxxtube.com”,
host: “img.kanzhongguo.com”,
host: “img.muji.net”,
host: “img.qz.com”,
host: “img.secretchina.com”,
host: “imgs.ntdtv.com”,
host: “imgx3.dditscdn.com”,
host: “img.youtube.com”,
host: “i.utdstc.com”,
host: “livepassdl.conviva.com”,
host: “l.longtailvideo.com”,
host: “m1.aboluowang.com”,
host: “massmedia-cdn.wistia.com”,
host: “media1.break.com”,
host: “media.247sports.com”,
host: “media-cache-ec0.pinimg.com”,
host: “media-cache-ec2.pinimg.com”,
host: “media-cache-ec4.pinimg.com”,
host: “media.cathkidston.com”,
host: “media-cdn.tripadvisor.com”,
host: “media.dermstore.com”,
host: “media.livepromotools.com”,
host: “media.mademan.com”,
host: “media.sfweekly.com”,
host: “media.skincarerx.com”,
host: “m.facebook.com”,
host: “mobapi.bloomberg.com”,
host: “mobile.twitter.com”,
host: “mzstatic.playhaven.com”,
host: “p1.zdassets.com”,
host: “passets-cdn.pinterest.com”,
host: “pbs.twimg.com”,
host: “photos-a.pe.facebook.com”,
host: “photos.modelmayhem.com”,
host: “photos.pop6.com”,
host: “piclist.pop6.com”,
host: “pic.pimg.tw”,
host: “p.jwpcdn.com”,
host: “platform.twitter.com”,
host: “playstationna.i.lithium.com”,
host: “plus.google.com”,
host: “pmcdn.staticpmrk.com”,
host: “public.oneallcdn.com”,
host: “p.vitalmx.com”,
host: “q-ec.bstatic.com”,
host: “quests.armorgames.com”,
host: “r2—sn-nx57yn7s.googlevideo.com:443″,
host: “r6—sn-5uaeznze.googlevideo.com”,
host: “r6—sn-i3b7rnee.googlevideo.com”,
host: “r7—sn-jc47eu7l.googlevideo.com”,
host: “rc-regkeytool.appspot.com:443″,
host: “realtime.services.disqus.com”,
host: “s0.wp.com”,
host: “s1.dmcdn.net”,
host: “s1.hubimg.com”,
host: “s1.wp.com”,
host: “s2.dmcdn.net”,
host: “s2.wp.com”,
host: “s3-ec.buzzfed.com”,
host: “s3.hubimg.com”,
host: “s3.pimg.tw”,
host: “s7.pimg.tw”,
host: “s9.pimg.tw”,
host: “s9.thisnext.com”,
host: “s.cdn.gaiaonline.com”,
host: “s.gravatar.com”,
host: “s.pimg.tw”,
host: “sr.photos3.fotosearch.com”,
host: “s-static.ak.facebook.com”,
host: “static02-ec-vn.zalora.com”,
host: “static1.businessinsider.com”,
host: “static2.businessinsider.com”,
host: “static2.docstoccdn.com”,
host: “static3.businessinsider.com”,
host: “static4.businessinsider.com”,
host: “static5.businessinsider.com”,
host: “static6.businessinsider.com”,
host: “staticd.cdn.adblade.com”,
host: “static.exoclick.com”,
host: “static.libsyn.com”,
host: “static.linkbucks.com”,
host: “static.miniclipcdn.com”,
host: “static.movideo.com”,
host: “staticna2.lacoste.com”,
host: “static.payserve.com”,
host: “staticx2.dditscdn.com”,
host: “staticx3.dditscdn.com”,
host: “staticx4.dditscdn.com”,
host: “s.utdstc.com”,
host: “s.wordpress.org”,
host: “s.xe.com”,
host: “sync.graph.bluecava.com”,
host: “s.youtube.com”,
host: “t.6park.com”,
host: “tags.crwdcntrl.net”,
host: “th00.deviantart.net”,
host: “th01.deviantart.net”,
host: “th02.deviantart.net”,
host: “th03.deviantart.net”,
host: “th05.deviantart.net”,
host: “th06.deviantart.net”,
host: “th07.deviantart.net”,
host: “th08.deviantart.net”,
host: “th-th.facebook.com”,
host: “thumbs.3jizz.com”,
host: “ukcdn.usablenet.com”,
host: “use.typekit.com”,
host: “vdc-img-0.ig1-cdn.com”,
host: “video.ap.ntdtv.com”,
host: “wac.24ba.edgecastcdn.net”,
host: “wac.450f.edgecastcdn.net”,
host: “wac.76ff.edgecastcdn.net”,
host: “widgets.twimg.com”,
host: “wpc.a818.edgecastcdn.net”,
host: “wprp.zemanta.com”,
host: “www.open.com.hk”,
host: “www.secretchina.com”,
host: “www.stratfor.com”,
host: “www.youtube.com”,
host: “www.youtube-nocookie.com”,
host: “x.myspacecdn.com”,

Serious Vulnerability in VBSEO

The vBulletin team sent an email yesterday to all their clients about a potential security vulnerability on VBSEO. VBSEO is widely used SEO module for vBulletin that was discontinued last year. This makes the problem worse, no patches will be released for it.

If you are using VBSEO, you have 3 options:

  1. Completely remove VBSEO from your site – It is not supported anymore
  2. Apply the patch recommended by the vBulletin team
  3. Put your site behind a Website Firewall, this will prevent the exploitation of this vulnerability and many others.

Our research team is looking at this issue and it seems to be a remote, unauthenticated script (html) injection vulnerability. It might lead to a full remote command execution, but we have not confirmed it yet. That’s as serious as it can be, since an attacker can use that to inject malware, spam or take down the site.

This is the full email from vBulletin:

Dear VB License Holder,

It has come to our attention that there may be a potential security vulnerability in VBSEO affecting the latest version of the software (and potentially other versions as well). We’ve attempted to contact the vendor, but as they have been non-responsive we felt we should alert the community as many of our customers use this add-on software.

If you think you might be running a vulnerable version of the software, there is a simple fix: just comment out the following lines in the file vbseo/includes/functions_vbseo_hook.php:

if(isset($_REQUEST[‘ajax’]) && isset($_SERVER[‘HTTP_REFERER’]))
$permalinkurl = $_SERVER[‘HTTP_REFERER’].$permalinkurl;

should be changed to:

// if(isset($_REQUEST[‘ajax’]) && isset($_SERVER[‘HTTP_REFERER’]))
// $permalinkurl = $_SERVER[‘HTTP_REFERER’].$permalinkurl;

If you are running the “Suspect File Versions” diagnostics tool, you will additionally need to generate a new MD5 sum of the above file and edit upload/includes/md5_sums_crawlability_vbseo.php to use the new MD5 sum on the line:

Please be aware that you are making these changes at your own risk. We don’t know if making this change affects the terms of your VBSEO license and we can’t be responsible if making this change breaks your site.

CVE-2014-9463 has been assigned to this potential vulnerability by cve.mitre.org.

We will post more details as we investigate.