JetPack and TwentyFifteen Vulnerable to DOM-based XSS

WordPress Security Vulnerability Disclosure
Any WordPress Plugin or theme that leverages the genericons package is vulnerable to a DOM-based Cross-Site Scripting (XSS) vulnerability due to an insecure file included with genericons. So far, the JetPack plugin (reported to have over 1 million active installs) and the TwentyFifteen theme (installed by default) are found to be vulnerable. The exact count is difficult to grasp, but both the plugin and theme are default installs in millions of WordPress installs. The main issue here is the genericons package, so any plugin that makes use of this package is potentially vulnerable if it includes the example.html file that comes with the package.

DOM-based XSS

The XSS vulnerability is very simple to exploit and happens at the Document Object Model (DOM) level. If you are not familiar with DOM attacks, the OWASP group explain it well:

DOM-Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the Document Object Model (DOM) “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.


Read More

WP Symposium – Zero Day Vulnerability Dangers

Our friends at SpiderLabs released a blog post today talking about the latest WP Symposium file upload vulnerability, and the attacks they have been seeing in the wild.

This specific vulnerability was disclosed publicly Dec 11th, and attacks against it have started. If you use this WordPress plugin we encourage you to update your plugin.

Scan Timeline

This plugin is not one of the more popular ones, it has some 150,000 downloads, but we decided to look at our internal data threads to see if we could verify SpiderLabs findings.

Indeed, it was/is happening.

Filtering through this month, December, we see a large increase in the number of scanners looking to see if the plugin is configured on websites:

wp-symposiumscans

It went from 0 scans pervious months, to a couple early December, to sharp increase after it’s disclosure on the 11th of December. Since, the number of scans have been growing, with a slight pause for the holiday’s (guess everyone needs time to open gifts). As this plugin is not widely use, most of the scan attempts are generating mostly Not Found error (404 pages – plugin no found).

Exploit Attempts Timeline

The scan attempts timeline is not that interesting per se.

Yes, we started seeing a few more scans before it was publicly disclosed, but it doesn’t tell us much.

However, if a site is found to be using this plugin via one of these scan attempts, the next step is the exploit.

And what was really interesting to us is that when we looked at this specific exploit payload in our logs, we found this (look at December 1st and 9th):

wp-symposiumexploits

What you see is that on December 1st, (11 days before the public disclosure), one of our sites was attacked using this specific exploit. And again on the 9th (2 days before disclosure).

Someone out there knew of this vulnerability and was actively attempting to exploit it. Whether it was made public via underground forums, they are the ones that found it or some other means. Either way, we were dealing with an active 0-day vulnerability.

The website targeted in our stack never used this plugin, so they were naturally protected against it. Regardless though, even if they had the plugin, our Website Firewall would have blocked it through one our Virtual hardening signatures:

2014-12-01 19:24:10: 191.181.x.x – – “POST /wp-content/plugins/wp-symposium/server/php/index.php HTTP/1.1″ 403
BLOCKREASON:VIRTUALHARDENING

This is the kind of discovery that keeps us up late at night, and why we invest heavily in our routine audits. What if it happened in a plugin we were actually using on our own blog? Our WAF blocked it this time, but if it was another vulnerability? Would we block as well? We have many sleepless nights worried, and it’s the foundation of why and what we have built.

This is a classic example of what attackers could do with your website, what are you doing to protect yourself? What are you doing to make sure that website owners don’t abuse your websites resource and reader trust? How are you staying ahead of the threats?

WordFence WordPress Security Plugin Pushes a Security Update

If you are one of the many users of the WordPress Security Plugin, WordFence, we highly encourage you to update. They recently pushed out a security update that could be affecting your install. It is important to note however that what is interesting about this release is that it was actually a Low Severity issue. What’s remarkable however is both their immediate response to the issue, and the detail they provide in their change log.

This is a very good way for a development firm to respond in the event of incidents. Snippet from their change log:

Read More

WordPress and Drupal Core Denial Of Service Vulnerability – Moderately Critical

Both WordPress and Drupal are affected by a DoS (denial of service) vulnerability on the PHP XML parser used by their XMLRPC implementations. The issue lies in the XML entity expansion parser that can cause CPU and memory exhaustion and the site’s database to reach the maximum number of open connections. That will cause the vulnerable site (and server) to go down for a period of time, hence affecting Availability of your website.

Kudos to the security teams from both platforms for their collaboration and synchronized disclosure.

The bug was discovered by Nir Goldshlager and disclosed on his blog at BreakSec. He goes onto to explain the specifics of the issue:

An XML quadratic blowup attack is similar to a Billion Laughs attack. Essentially, it exploits the use of entity expansion. Instead of deferring to the use of nested entities, it replicates one large entity using a couple thousand characters repeatedly.

A medium-sized XML document of approximately two hundred kilobytes may require anywhere within the range of one hundred MB to several GB of memory. When the attack is combined with a particular level of nested expansion, an attacker is then able to achieve a higher ratio of success.

..

If an attacker defines the entity “&x;” as 55,000 characters long, and refers to that entity 55,000 times inside the “DoS” element, the parser ends up with an XML Quadratic Blowup attack payload slightly over 200 KB in size, which expands to 2.5 GB when parsed.

WordPress and Drupal sites are vulnerable to this attack whether XML-RPC is used or not. This is not a vulnerability to be taken lightly. This also has large reaching impacts, any other applications leveraging a similar XMLRPC implementation is vulnerable.

Both projects, WordPress and Drupal, released an update today to address this problem and all users should upgrade asap to the latest version. Since this bug is trivial to exploit, we expect to see it in the wild very soon.

Because of the wide ranging impacts, it’s categorized as Moderately Critical. Any time Availability is affected, one of the pillars that makes up the Security triad, severity goes up. In this case, websites and web servers will go down. This emphasis on it being minor is incorrect, from a Security perspective.

Sucuri - Security Triad

Sucuri Customers Protected

Customer using our Website Firewall (CloudProxy) product are currently protected via our Virtual Patching. This will be especially useful for those that are running out of date versions of the platforms and are unable to update, hence making them susceptible to the attack.

Security Issue on vBulletin uploader.swf

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 remove that file asap from their installs.

This is their full note:


Read More

Zero Day Vulnerability in OpenX Source 2.8.11 and Revive Adserver 3.0.1

If you are using OpenX or the new Revive Adserver (fork of OpenX), you need to update it ASAP. Florian Sander discovered a serious SQL injection vulnerability that affects all versions of OpenX and all versions of the Revive Adserver. From the Revive advisory:

An SQL-injection vulnerability was recently discovered and reported to the Revive Adserver team by Florian Sander.

The vulnerability is known to be already exploited to gain unauthorized access to the application using brute force mechanisms, however other kind of attacks might be possible and/or already in use. The risk is rated to be critical as the most common end goal of the attackers is to spread malware to the visitors of all the websites and ad networks that the ad server is being used on.

The vulnerability is also present and exploitable in OpenX Source 2.8.11 and earlier versions, potentially back to phpAdsNew 2.0.x.

The XML-RPC delivery invocation script was failing to escape its input parameters in the same way the other delivery methods do, allowing attackers to inject arbitrary SQL code via the “what” parameter of the delivery XML-RPC methods. Also, the escaping technique used to handle such parameter in the delivery scripts was based on the addslashes PHP function and has now been upgraded to use the dedicated escaping functions for the database in use.

We highly recommend anyone using OpenX to upgrade to the latest Revive version, or as a temporary fix, remove the file “www/delivery/axmlrpc.php” from your installation.

Clients using our CloudProxy Website Firewall are already protected against it. If you want to protect your OpenX / Revive install, you can sign up for CloudProxy here.

Server Update Time: OpenSSH Vulnerability Disclosed

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.

Read More

New WordPress and Joomla Updates Available

If you are a WordPress or Joomla user, you better start updating your sites now.

Joomla 2.5.14

Joomla 2.5.14 was released containing some critical security fixes. They didn’t provide much details, but by the summary is seems serious enough to allow users to bypass upload restrictions:

Project: Joomla!
Severity: Critical
Versions: 2.5.13 and earlier 2.5.x versions. 3.1.4 and earlier 3.x versions.
Exploit type: Unauthorised Uploads
Reported Date: 2013-June-25
Fixed Date: 2013-July-31
Description: Inadequate filtering leads to the ability to bypass file type upload restrictions.

More information on Joomla 2.5.14 update here: http://developer.joomla.org/security/news/563-20130801-core-unauthorised-uploads

WordPress 3.6

WordPress 3.6 (a major release) was also announced with multiple new features and bug fixes. It doesn’t have any specific security fix, but keeping your site updated is a must, so we recommend all users to update.

More information on WordPress 3.6 is available here: http://codex.wordpress.org/Version_3.6


We recommend upgrading as soon as possible to reduce the risk of issue. Make sure you test your upgrades in a development environment before you go hot.

If you have any questions, feel free to drop an email.

Ubuntu Forums Hacked

Ubuntu’s official forum web site (ubuntuforums.org) was hacked, defaced and all user names and
passwords stolen. The forum was very popular with over 1.8 million registered users. The site is now disabled with this warning:

What we know:

-Unfortunately the attackers have gotten every user’s local username, password, and email address from the Ubuntu Forums database.

-The passwords are not stored in plain text. However, if you were using the same password as your Ubuntu Forums one on another service (such as email), you are strongly encouraged to change the password on the other service ASAP.

The site was running vBulletin and according to some sources, it was outdated and didn’t have the admin panel protected. During the time it was defaced, it was redirecting to “ubuntuforums.org/signaturepics/Sput.html”, which had this image:

Ubuntu forums hacked

Size of the attack and consequences

The Ubuntu forum was very large with over 1,800,000 registered members. Even though the passwords were not stored in plain text, they should be considered compromised and known by the attackers. And since the site used vBulletin, it is likely that they were just hashed with md5, which makes the job a lot easier to the attackers.

If you have an account there and you use the same password some where else, please
change the password asap.

Globo.com redirecting users to Spam ads

Globo.com, one of the largest Brazilian web portals (ranked #107 on Alexa and #6 for Brazilian traffic) appears to be compromised and all visits to it are being redirected to a sub page inside pagesinxt.com. If you go to g1.globo.com (or any other of their sub domains), you will end up on a page full of ads about Hosting, Internet and fake email products:

Globo.com redirection

That redirection has been going for a few hours at least and we detected it for the first time around 8am EST and it is still live four hours later (noon EST).

What is going on?

We are investigating, but at the bottom of any page inside google.com there is a script being loaded from sawpf.com:

<script defer src="httx://sawpf.com/1.0.js"></script>

That javascript file is being very slow to load, but when it does, it runs the following code:

 window.location = httx://pagesinxt.com/?dn=sawpf.com&fp=3WBUwymfgey…

Which forces the browser to redirect the to pagesinxt.com. At this point, we recommend all users to do not visit any globo.com page (or go there with Javascript disabled).

Who really owns your site?

This brings up a good topic that we brought up before. Who really owns your site? Every time you include a javascript (or widget or iframe), the security of your site becomes dependent on that third party server. It doesn’t looks like Globo in itself got compromised, but since they are including code from sawpf.com, they are only as secure as them.

Every time you add a remote JavaScript (or widget or iFrame) to your site, you are giving the server that houses that code full control of what is displayed to your users. If their servers get compromised, your site will be compromised as well.

Can you imagine if the author of the Easing Plugin was malicious? Instead of just that pop-up, they could have added a URL redirect to send all your users to any site they of their choosing (SPAM, porn, you name it). What if their server was hacked? The attackers could have added malware and it would have loaded to all your users.

*update 1: Lots of users on Twitter are complaining about it as well. Search for sawpf or pagesinxt to see the amount of people complaining or worried about it.

*update 2: If you click on some urls inside sawpf.com, you will be redirected to pagesinxt.com as well ( for example: httx://sawpf.com/libs/jquery/1.7.1.js )