If your website runs on CMS WordPress or Drupal, update your software now or you will lose all your data and your machine. Why so?? Since this software is suffering from specific vulnerabilities, around 100 million websites are under threat. Let us know more.
Two of the most popular and widely used open-source Content management systems, Drupal and WordPress, face vulnerabilities affecting millions of websites. The two companies are coordinating with each other for the first time to eliminate the flaw.
The flaw was discovered by Nir Goldshlager, a salesforce.com researcher. According to him, with a few keystrokes, the entire Drupal or WordPress website can be taken down quickly. The flaw is a potential denial of service (Dos) issue with the XML processing module by both WordPress and Drupal. The spot is highlighted because US government websites, including whiteHouse.gov, use Drupal. According to a post by WordPress, the WordPress issue in PHP’s XML processing and updating could protect against specific brute force attacks and address possible code execution vulnerabilities. A post by the 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 XML Quadratic Blow Up attack. This attack distorts the Memory Limit, MySQL and Apache Max client works.
But what is a Denial of Service (DOS) attack? It is an attempt to make a resource or a machine unavailable to a user who requested it. However, the reasons and motives behind the denial may vary, but when intentionally done, it consists of efforts to interrupt or suspend the services of a host temporarily. These attacks are sent by one person or a system.
The versions 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 repeatedly. Due to this, an XML document of a few KBs can end up requiring up to hundreds of MBs and even GBs. This heaviness can bring down an entire website or server down quickly. Here, the question arises of how this attack is exploited? The default memory allocation limit for PHP (the language in which WordPress and Drupal are written) is 128MB per process. Theoretically, 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, WordPress and Drupal’s database, 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 must 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
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 can fix the possible DoS issue in PHP’s XML processing. Since the vulnerability is present in WordPress 3.5 to 3.9.1, several sites need to be manually updated 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 help 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, as 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 administrators could trigger only.
Users can update to version 3.9.2 immediately by browsing 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 are security releases against security vulnerabilities.
- 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.
- The XML-RPC system and OpenID XRDS parser will also reject messages containing over 30,000 XML tags. This limit is not expected to matter for most use cases. If you need to process an XML-RPC message 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 similarly.
Suppose you are unable to install the latest version of Drupal immediately. Alternatively, you can 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 XML-RPC or OpenID functionality. However, this mitigation will not be effective if you use a contributed module that exposes Drupal’s XML-RPC API at a different URL (for example, the Services module); updating the Drupal core is therefore strongly recommended.
At this moment, I conclude that update your websites to the latest versions of Drupal and WordPress and secure your websites.
Ananova 
You must be logged in to post a comment.