Corporations get hacked all the time. This is not news to anyone in the security business, but it has certainly received a lot of attention from those in the media over the last few weeks because of a couple of large-scale credit card events at both Target and Neiman Marcus.
The vBulletin team recently disclosed a XSS (cross site scripting) vulnerability in the uploader.swf file that is included by default on vBulletin 4 and 5. This file comes from the YUI library that is not supported anymore, so the vBulletin team is recommending everyone to remove that file asap from their installs.
This is their full note:
It has come to our attention that there is a security issue in the uploader.swf file included as part of the Yahoo User Interface (YUI) library included in vBulletin 4. As the version of YUI included in vBulletin is end-of-lifed, Yahoo will not be fixing this issue.
The vulnerable file is also present in the vBulletin 5 download package though not used by the vBulletin 5 front-end. We recommend that you delete the file and replace it with the attached file.
To resolve this issue take the following steps:
-Delete uploader.swf located in clientscript/yui/uploader/assets or /core/clientscript/yui/uploader/assets
-Replace it with the attached file.
If you run vBulletin, please remove that file as soon as you can. Note that users of our CloudProxy website firewall are already protected against this threat.
We’re a few days short on this, but it’s still worth releasing as the number of attacks against this vulnerability are increasing ten-fold.
The folks at OSIRT were the first to report this in late November, 2013. In our cases we’re seeing mostly defacement attacks, and although not devastating, they can be a big nuisance for an unsuspecting website owner.
Please be sure to read the official announcement by the OptimizePress team.
This is an important announcement for OptimizePress 1.0 users. (Please note this does NOT apply to OptimizePress 2.0 which is built with a completely new codebase)
Back in April 2013 we discovered a potential security flaw in part of the code for OptimizePress 1.0. Our developers quickly patched this issue and we released an update to the platform. We also announced this to our customers via email, although it appears now that many of our users may not have received this email. – OptimizePress Team (Read Full)
The target of the attack is the following file: lib/admin/media-upload.php. It can be used to upload any file to the wp-content/uploads/optpress/images_comingsoon directory. It doesn’t even change the extension.
Vulnerable versions of this file provide the upload functionality to anyone, while newer patched versions check for the admin permissions first. It is easy to tell one from the other.
The beginning of the vulnerable files:
The OpenSSH team just released a security advisory about a vulnerability affecting both OpenSSH 6.2 and 6.3.
If you are not familiar with OpenSSH, it’s the software used by a large majority of servers and hosting providers to provide SFTP and SSH services. Any vulnerability discovered in OpenSSH could have a major impact to website owners, and the Internet in general.
The good news is that this vulnerability only affects newer versions of OpenSSH, which are not widely used yet. If you are using Ubuntu 13.10 or Fedora 19, you are likely vulnerable. All other Linux distributions appears to be safe. To double check, log into your server via SSH and type the following command:
# sshd -h OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
If you see OpenSSH_6.2 or OpenSSH_6.3, you know you are using the affected versions.
A few days ago, a zero-day SQL injection vulnerability in WHMCS was disclosed by localhost.re, along with the exploit code. It was quickly patched by the WHCMS team and rated as critical since it allows an attacker full access to the database hosting WHMCS:
The vulnerability allows an attacker, who has valid login to the installed product, to craft a SQL Injection Attack via a specific URL query parameter against any product page that updates database information.
Creating a valid login is very easy and allowed by default through the registration page.
WHMCS is very popular amongst hosts, and if you use it, you need to update/patch it ASAP!
Attacks in the wild
Due to its severity, we knew it wouldn’t take long before attackers started to use it in the wild. Yesterday we detected the first cases of servers getting compromised due to it. This is an example that was triggered on our honeypots:
First Name: 'USERX' to 'AES_ENCRYPT(1,1), firstname= (SELECT GROUP_CONCAT(id,0x3a,username,0x3a,email,0x3a,password SEPARATOR 0x2c20) FROM tbladmins)' Last Name: 'LASTNAME' to '1' Company Name: 'COMPANYNAME' to '1' Address 1: 'USA' to '1'
As you can see, it is leveraging the SQL injection (by modifying the first name) to dump the user database along with hashed passwords from the database.
If you are using WHMCS, you have to update it now! Our users running our CloudProxy WAF are already protected by it, but we still recommend the update.
If you are using Joomla and didn’t update your site recently, you better stop doing whatever you are doing, and update it now. There is a very serious vulnerability in Joomla’s Media Manager component (included by default), that can allow malicious files to be uploaded to your site.
The only two safe versions of Joomla are 3.1.5 and 2.5.14. If you are not using either of them, you are at risk.
As if on queue, almost 7 days since we released the post about the latest W3TC and WP Super Cache remote command execution vulnerability, we have started to see attacks spring up across our network.
In our post you might remember this:
<!–mfunc echo PHP_VERSION; –><!–/mfunc–>
In this example we explained how it was a very simple approach to displaying the version of PHP on your server. There were a lot of questions following that saying, well what’s so harmful in that. Etc… With little help from us the attackers go on to show us what they can do.
Taking a Look at the Attacks
In this section I’ll show you three of the various attacks we’re seeing. In each you can see how they abuse the mfunc vulnerability, one in a more traditional approach of injecting a backdoor and other in a more creative way that allows them to abuse HTTP headers. In either case they all seem to be getting passed via comments, and we give an example of that below. This is obviously for educational purposes only.
One thing you can’t take away from some of the attackers we deal with everyday is their creativity. From time to time we write about new trends we’re seeing, and this post is no different. We’re seeing a new tactic recently, and it may be affecting your pockets, even if you’re not into the latest trend of using digital currency.
Digital currency you say?
Shame on us for not catching this a month ago when it was first reported, but it seems that two of the biggest caching plugins in WordPress have what we would classify a very serious vulnerability – remote code execution (RCE), a.k.a., arbitrary code execution:
…arbitrary code execution is used to describe an attacker’s ability to execute any commands of the attacker’s choice on a target machine or in a target process. – Wikipedia
It appears that a user by the name of kisscsaby first disclosed the issue a month ago via the WordPress forums. As of 5 days ago both plugin authors have pushed new versions of their plugins disabling the vulnerable functions by default. The real concern however is the seriousness of the vulnerability and the shear volume of users between both plugins.
There are a few posts, released within the past few hours that do a great job of explaining what the issue was and what was being exploited. You can find some good after action thoughts on Frank Goosens’ blog and on Acunetix’s blog as well.
Why Such a Big Deal?
We are seeing in the media some noise about a large distributed brute force attacks against all hosts targeting WordPress sites. According to reports, they are seeing a large botnet with more than 90,000 servers attempting to log in by cycling different usernames and passwords against the WordPress access points: /wp-login.php and /wp-admin.
This got us thinking, well we block a lot of attacks why not look at the logs to see what they tell us. So we did.
Looking back, we can see in our historical database the following:
2012/Dec: 678,519 login attempts blocked
2013/Jan: 1,252,308 login attempts blocked (40k per day)
2013/Feb: 1,034,323 login attempts blocked (36k per day)
2013/Mar: 950,389 login attempts blocked (31k per day)
2013/Apr: 774,104 for the first 10 days – 77,410 per day