Major Security Vulnerability in WordPress, Drupal Could Take Down 73% Websites of the web

Major Security Vulnerability in WordPress, Drupal Could Take Down 73% Websites of the web

If your website runs on a self-hosted WordPress installation or on Drupal, update your software now.
Nir Goldshlager, a security researcher from Salesforce.com's product security team, has discovered an XML vulnerability that impacts the popular website platforms WordPress and Drupal.
The vulnerability uses a well-known XML Quadratic Blowup Attack — and when executed, it can take down an entire website or server almost instantly.
This is a big deal because

WordPress and Drupal are used by millions of websites

WordPress and Drupal are used by millions of websites. The latest statistics from W3Techs shows WordPress alone powers nearly 23% of the web. The XML vulnerability Goldshlager discovered affects WordPress versions 3.5 to 3.9 (the current version) and works on the default installation. It affects Drupal versions 6.x to 7.x (the latest version) and also works on the default installation.
The good news is that both WordPress and Drupal have released patches for their applications. Users and web hosts simply need to upgrade to the latest version to protect against the vulnerability.
When the vulnerability is exploited, the results can basically render a website or web server unusable. The vulnerability can cause 100% CPU and RAM usage, cause the server to become unavailable and also create a Denial of Service attack on the MySQL database program.
In other words, your website and web server can become totally inaccessible.

How the attack works

This vulnerability uses what is called an XML Quadratic Blowup Attack. This type of attack is similar to a Billion Laughs attack, which can allow a very small XML document to totally disrupt the services on machine in a matter of seconds.
The Quadratic Blowup Attack is similar; however, instead of using nested entities inside an XML document, it just repeats one large entity with tens of thousands of characters over and over again.
With this type of attack, an XML document that might be a few hundred kilobytes in size can end up requiring hundreds of megabytes or even gigabytes of memory. That will easily bring down an entire website or web server.
In Goldshlager's words:

1 2 3 4 5

<?xml version="1.0"?> <!DOCTYPE DoS [ <!ENTITY a "xxxxxxxxxxxxxxxxx..."> ]> <DoS>&x;&x;&x;&x;&x;&x;&x;&x;&x;...</DoS>

view raw Test hosted with ❤ by GitHub

"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 that expands to 2.5 GB when parsed. This expansion is enough to take down the parsing process."

How the 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. So far so good, right?
Here's the problem: Apache, the world's most popular web server, 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 (128x151), 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 victim's 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.
WordPress Denial Of Service PoC Video from Nir on Vimeo.

The fix

WordPress and Drupal have both updated their software to protect against this vulnerability. The update procedure will vary based on your setup.
WordPress 3.7 introduced automatic updates for minor releases for this very reason. This allows security patches, such as this one, to get rolled out to users automatically.
Automatic updates can turned on or off at the discretion of your web host, so it's a good idea to check your settings and update manually if automatic updates are not enabled.

Comment on disclosure

Because of the potential vector size of this vulnerability, Goldshlager made sure to responsibly disclose the vulnerability to the WordPress and Drupal teams before sharing the results with the public.
This allowed the teams time to patch their respective pieces of software before the vulnerability was exploited on a large scale.
Given the nature of this type of attack — and the relative ease in which it could have been exploited — the repercussions for plenty of website owners and web hosts could have been innumerable. WordPress alone is used by many of the biggest publishers on the web — not to mentions millions upon millions of regular users and small businesses.
Responsible disclosure was the best way to get the issue out in the open, and also fixed.
Notably, the WordPress and Drupal teams worked together on this solution and timed their security releases to coincide with one another.
Because the vulnerability targets WordPress's XML-RPC library file — a file that Drupal uses a derivative of — it made sense for the teams to work together on a patch and release.
Mashable worked with Goldshlager in preparing this post and writing up the disclosure, in the hopes that we can get the word out to as many people as possible. If you're running WordPress or Drupal, update now.

Source:-mashable.com/