WordPress/Drupal Vulnerability

If your website runs on CMS WordPress or Drupal, update your software now or else you would lose all your data as well as your machine. Why so?? Since these softwares are suffering from certain vulnerabilities, around 100million websites are in threat. Let us know more.

Two of the most popular and widely used open-source Content management systems, Drupal and WordPress are facing vulnerabilities that can affect millions of websites. The two companies are coordinating with each other, for the first time to get rid of the flaw.

The flaw was discovered by Nir Goldshlager, a salesforce.com researcher. According to him, with a few keystrokes the entire website of Drupal or wordpress can be taken down easily. The flaw is a potential denial of service (Dos) issue with the XML processing module by both WordPress and Drupal. The flaw is so highlighted because US government websites including whiteHouse.gov uses Drupal. According to a post by wordpress, the wordpress issue exists in PHP’s XML processing and updating could protect against certain brute force attacks and also addresses possible code execution vulnerabilities. A post by Drupal website says that Drupal is affected because the PHP XML parser used by a publicly available XML-RPC endpoint is vulnerable to an XML entity expansion attack.
This flaw is predicated on a popular cyber-attack, known as XML Quadratic Blow Up attack. This attack distorts the Memory Limit and MySQL, and Apache Max client works.

But what is Denial of Service (Dos) attack? It is an attempt to make a resource or a machine unavailable to a user who requested for it. However, the reasons and motives behind the denial may vary, but when intentionally done, it consists of efforts to interrupt or suspend services of a host temporarily. These attacks are sent by one person or a system.

The version affected by these attacks are wordpress 3.5-3.9 and Drupal 6x-7x. The Quadratic Blowup Attack repeats one large entity with tens of thousands of characters over and over again. Due to this, an XML document of few KBs can end up requiring up to hundreds of MBs and even GBs. This heaviness can bring down entire website or server down easily. Here, the question arises that how this attack is exploited? The default memory allocation limit for PHP (the language that WordPress and Drupal are written in) is 128MB per process. In theory, this means that you can’t exceed the 128MB limit with an XML bomb request. But the problem arises here. Apache has its “Max Clients” property set to 256 by default. Meanwhile, MySQL, the database that WordPress and Drupal use, has its default “Max Connections” value set to 151. If we multiply those connections against one another (128×151), we get 19328MB — which will consume all available memory. To successfully attack the server, the attacker needs to fingerprint the available memory limit on the target server. If the attack overwrites the PHP limit, the server will reject the overwrite, rendering the attack unsuccessful. A successful attack, however, will return the injected payload as a result. This will bring down the system.

The risks created due to these attacks are:

  • Service unavailable
  • 100% RAM and CPU Usage
  • Traffic on server
  • Server breakdown

After the disclosure of this flaw, Nir Goldshlager tried to find ways to resolve this issue and he was finally succeeded. The way by which the flaw could be destroyed is by updating both the softwares to their latest versions. Drupal and WordPress have released the updates to plug the flaw but it is still up to the users of these two CMS to use them on their sites. It is advised to the users of Drupal and wordpress to update their softwares immediately. To fix the flaw at a minute level, WordPress 3.7 introduced automatic updates. This allows security patches to get rolled out ton users automatically.

WordPress users are strongly advised to upgrade their sites to wordpress version 3.9.2. This version of wordpress has the capability to fix the possible DoS issue in PHP’s XML processing. Since the vulnerability is present in WordPress 3.5 to 3.9.1, there are several sites that need to be manually updated in order to be protected. Automatic updates for security releases were introduced in WordPress 3.7, leaving users of 3.6 and 3.5 especially vulnerable. WordPress 3.9.2 has some security updates that helps protect against this flaw:

  • Fixes a possible but unlikely code execution when processing widgets (WordPress is not affected by default), discovered by Alex Concha of the WordPress security team.
  • Prevents information disclosure through XML entity attacks in the external GetID3 library, reported by Ivan Novikov of ONSec.
  • Adds protections against brute attacks against CSRF tokens, reported by David Tomaschik of the Google Security Team.
  • Contains some additional security hardening, like preventing cross-site scripting that could be triggered only by administrators.

Users can update to version 3.9.2 immediately by browsing to Dashboard > Updates in the backend of WordPress. Sites that have automatic updates configured will be updated within 12 hours. Sites using WordPress 3.8.3 or 3.7.3 will be updated to 3.8.4 or 3.7.4. Older versions of WordPress are not supported, so it is recommended to update to 3.9.2, the latest.

Drupal 7.3.1 and 6.3.3 is a security release against security vulnerability.

  1. As of this release, the XML-RPC system in Drupal core will ignore information in <?xml> declarations contained within XML-RPC messages (for example, XML version or character encoding information). This is not expected to matter for the vast majority of use cases.
  2. The XML-RPC system and OpenID XRDS parser will also reject messages that contain over 30,000 XML tags within them. This limit is not expected to matter for the vast majority of use cases. If you need to process an XML-RPC message that is larger than that, you can change the limit by setting the “xmlrpc_message_maximum_tag_count” variable to a higher value. For example, in settings.php:

<?php
// Allow XML-RPC messages with up to 50,000 XML tags to be processed.
$conf['xmlrpc_message_maximum_tag_count'] = 50000;
?>

Do not set the value higher than you need, since allowing too many XML tags per XML-RPC message increases your site’s vulnerability to denial of service attacks. The OpenID XRDS parser has a similar variable

(“openid_xrds_maximum_tag_count”) which can be used in a similar way.

If you are unable to install the latest version of Drupal immediately, you can alternatively remove the xmlrpc.php file from the root of Drupal core (or add a rule to .htaccess to prevent access to xmlrpc.php) and disable the OpenID module. These steps are sufficient to mitigate the vulnerability in Drupal core if your site does not require the use of XML-RPC or OpenID functionality. However, this mitigation will not be effective if you are using a contributed module that exposes Drupal’s XML-RPC API at a different URL (for example, the Services module); updating Drupal core is therefore strongly recommended.

Hereby I conclude that update your websites to the latest versions for Drupal and WordPress and secure your websites.