Slider Revolution Plugin Critical Vulnerability Being Exploited

This post is available in Spanish (Este post está disponible en español).


Mika Epstein, Ipstenu, of Dreamhost, notified us today of a serious vulnerability in the WordPress Slider Revolution Premium plugin which was patched silently.

It turns out that the vulnerability was disclosed via some underground forums. ThemePunch confirms that their plugin was patched in version 4.2 for those that purchase the plugin directly from them, and they include an auto-updater which would address the problem. The real issue lies in the way the plugin is wrapped into theme packages. ThemePunch’s approach to disclosing the issue was based on guidance they received. [updated 20140903]

This a very popular plugin, and appears to be one of the most downloaded slider plugins from Envato’s Marketplace – Code Canyon. It also appears to be bundled in theme packages so be sure to check your theme / plugins.

This is an example of where things go terribly wrong.


Read More

JCE Joomla Extension Attacks in the Wild

Our friends from SpiderLabs, issued a warning today on their blog about increased activity on their honeypots looking to exploit the old JCE (Joomla Content Editor) vulnerability.

JCE is a very popular component that can be found enabled on almost any Joomla site. It has had a few serious vulnerabilities in the past (around 2011 and 2012), and unfortunately we still see thousands of unpatched sites out there. In fact, we get to clean and disinfect many sites compromised through it every single day.

You can read SpiderLabs’ full analysis here:

[Honeypot Alert] JCE Joomla Extension Attacks

And an old one we did on UnmaskParasites about the increased scans we started to see for it a few months ago:

Unmask: Invasion of JCE Bots

If you run a Joomla site and haven’t patched your site lately, please do it as soon as possible. If you are still on the Joomla 1.5.x branch, you need to do it today. There are exploits live in the wild for it, and if you have been lucky and didn’t get hacked yet, it will happen soon.


Read More

Security Exploit Patched on vBulletin – PHP Object Injection

The vBulletin team just issued a warning, and released patches for a security exploit that affected all versions of vBulletin including 3.5, 3.6, 3.7, 3.8, 4.X, 5.X. They recommend that anyone using vBulletin apply these patches as soon as possible. Here is part of their announcement:

A security issue has been found that affects all versions of vBulletin including 3.x, 4.x and 5.x. We have released security patches to account for this vulnerability. This includes patches for vBulletin 3.8.7, vBulletin 4.2.2 and all versions of vBulletin 5 (including Cloud accounts). The patch is also applied to vBulletin 5.1.0 RC1. It is imperative that you apply these patches as soon as possible.

Due to functionality changes, the minimum PHP version for the patch is 5.2.0. This represents an increase for vBulletin 3. Alternatively customers can install the JSON functions separately in which case it will work with any compatible PHP version that their particular version of vBulletin supports. You will need to collaborate with your hosting provider or systems administrator to apply the changes to PHP.

If you are using vBulletin, you know what to do: Patch now!

What really worries me from this announcement is that they increased their minimal PHP version requirement on the security patch. It means many webmasters will not be able to apply the patch quickly enough, and some may end up breaking their sites.

So, if your host is not running an updated version of PHP, you need to contact them ASAP to get it updated or your site will be vulnerable.

What a Security Exploit Means?

The vBulletin team provided no details on what exactly they patched, or what the vulnerability was. All they have said is it was a “security exploit”, which should be enough of a warning for people to update their forums.

Based on their patches, we were able to clearly see what the issue was:

They removed:
$temp = unserialize($check);
And added:
$temp = json_decode($check, true);

Later in the code where they were running “serialize($_POST”, they changed it to “json_encode($_POST)”. It appears like a PHP Object injection where they are passing user supplied data to an “unserialize” function.

This may lead to privilege escalation, remote code execution, or maybe even allow an attacker to run any PHP function they want. We don’t know how bad it is yet, but our team is still investigating this issue and trying to confirm the severity, and what can really be done.

Users running our Website Firewall are already protected against PHP Object injections, and we are building a custom virtual patching signature for it as well. Stay tuned for updates.

Potential vBulletin Exploit (4.1+ and 5+)

The vBulletin team just posted a pre-disclosure warning on their announcements forum about a possible exploit in versions 4.1+ and 5+ of vBulletin.

They don’t provide many details, but did state that webmasters need to remove the /install and /core/install from their websites. This is the full message:

A potential exploit vector has been found in the vBulletin 4.1+ and 5+ installation directories. Our developers are investigating this issue at this time. If deemed necessary we will release the necessary patches. In order to prevent this issue on your vBulletin sites, it is recommended that you delete the install directory for your installation. The directories that should be deleted are:

4.X – /install/
5.X – /core/install

After deleting these directories your sites can not be affected by the issues that we’re currently investigating.

vBulletin 3.X and pre-4.1 would not be affected by these issues. However if you want the best security precautions, you can delete your install directory as well.

Going back to our logs, we don’t see any specific scans for /core/install, but we see constant discovery requests for /install. We don’t yet know if that is related to vBulletin or other CMS’s.

Our team will be watching it closely, and any client under our CloudProxy WAF is already protected by it since we only allow access to the “install” directories by white listed IP addresses.

From a Site Compromise to Full Root Access – Local Root Exploits – Part II

When an attacker manages to compromise and get access to a website, they won’t likely stop there, they will aim to gain full root (admin) access to the entire server. If there are more websites hosted on the server being attacked, It is likely they will attempt to compromise every single one of them.

How can an attacker escalate their privileges? How can they go from FTP-only access to getting root on the server? In this series of articles we will show some techniques that attackers are using to go from confined FTP/web access, to full root level access on a server.


Read More

Public Service Announcement: Microsoft Security Advisory (2719165)

Today Microsoft released a security advisory to all users running the Windows operating system (OS). A new vulnerability has been identified that allows for the Microsoft XML Core Services to be exploited and used for remote code execution.

This vulnerability is known in Microsoft XML Core Service versions:

  • 3.0
  • 4.0
  • 5.0
  • 6.0

You can read more on the advisory in their post here.

Read More