CVE-2018-6389 WordPress Parameter Resource Consumption Remote DoS

[NickTheGreek 160]

Yesterday (Monday, February 5, 2018), a zero-day vulnerability in WordPress core was disclosed, which allows an attacker to perform a denial of service (DoS) attack against a vulnerable application. The vulnerability exists in the modules used to load JS and CSS files. These modules were designed to decrease page-loading time, but have effectively rendered the WordPress core susceptible to DoS attacks.

WordPress holds a market share of more than 29 percent of internet websites and 60 percent of content management systems (CMS) worldwide, turning any vulnerability in the WordPress core into a potentially large-scale exploit.

The vulnerability exists due to a flaw in the server-side static file loading mechanism. The parameter “load” in the vulnerable modules “load-styles.php” and “load-scripts.php”, which reside under the “/wp-admin/” path, accepts an array of JS/CSS files to fetch while the page is loading. The vulnerable modules are usually used only in pages accessible by authenticated users, with an exception being the login page, which exposes said modules to unauthenticated users as well. Thus, a malicious user can repeatedly request an excessive list of JS/CSS files, causing the server to retrieve vast amounts of data — and in so — render it unresponsive.

Although the load parameter can accept all 181 JS files that appear in the “script-loader.php” module. Our analysis has shown that, in fact, the server doesn’t retrieve any data when calling JS files that are pulled from an external source such as https://ajax.googleapis.com. Hence, appending these JS files to the requested list is useless from an attacker’s perspective.

Due to the simplicity of this attack, a low skill attacker can utilize the existing public exploit to take down virtually any unprotected WordPress site. Because the vulnerable modules are essential, a blacklist isn’t recommended and a simple authentication-based whitelist will not work either because it may break the login page.

WordPress did not patch this vulnerability because they view it as an extensive resource exhaustion attack, and as such should be mitigated by a network firewall / web application firewall. This may, of course, change, and WordPress webmasters should (as always) stay tuned for new patches and versions.

Until today (February 6, 2018), we have only seen a few dozen exploit attempts using this vulnerability, but we might see a steep rise in attacks using this exploit due to the popularity of the platform, unless a mitigation will be applied in the near future.

It is advised to set access restrictions to the “load-styles.php” and “load-scripts.php” modules by only allowing trusted IPs to access these resources or by enabling two-factor authentication on the wp-admin directory. Another solution is to set rate limits to these resources.

Vulnerability discoverer Barak Tawily released the following Bash script that patches the exploit by essentially allowing only admins to send requests to the vulnerable modules, and removes the requests to the modules from the login page. The script also removes most of the code from the “noop.php” module due to “re-declaration errors”. In a testing environment in our lab we didn’t encounter any such errors and thus we assume that altering the “noop.php” is not obligatory for all WordPress users.

We did not extensively test this patch in our lab, and as of today, it wasn’t integrated into the main WordPress repository. Thus, we cannot recommend this solution, as it deviates from the WordPress core source and may cause compatibility issues.

After analyzing the data on our CDN, we have deployed mitigations against this vulnerability, which are enabled by default for all Incapsula sites with protection against “Illegal Resource Access”.

 

https://www.incapsula.com/blog/cve-2018-6389-wordpress-parameter-resource-consumption-remote-dos.html?mkt_tok=eyJpIjoiWkdVNE5UUXhaalUxTUdZMSIsInQiOiJzSEl2RzJvaDZXM0FuWWJ6R1Z2SlNzdUU4OEh0Q0JZcXlhcTYzc0FUbW9hOUFwaFwvMmlmN0Y0bitEREtNUzlwYjk3SWdsOEVtZ2pkQlZ2TFZYTWlwUG1ndWhnaW42K1N6ODdSRFdMZ0YzSzI2eWpEbkhZaVYreWdxMUhKZ0NTakwifQ%3D%3D

 

[NickTheGreek 160]

The Israeli security researcher Barak Tawily a vulnerability tracked as CVE-2018-6389 that could be exploited to trigger DoS condition of WordPress websites.

The expert explained that the CVE-2018-6389 flaw is an application-level DoS issued that affects the WordPress CMS and that could be exploited by an attacker even without a massive amount of malicious traffic.

“In this article I am going to explain how Denial of Service can easily be caused to almost any WordPress website online, and how you can patch your WordPress website in order to avoid this vulnerability being exploited.” reads the analysis of the expert.

Tawily revealed that the flaw exists in almost all versions of WordPress released in last nine years, including the latest one (Version 4.9.2).

The flaw affects the “load-scripts.php” WordPress script, it receives a parameter called load[] with value is ‘jquery-ui-core’. In the response, the CMS provides the JS module ‘jQuery UI Core’ that was requested.

As you know, WordPress is open-source project, for this reason, it was easy for the expert to perform code review and analyzed the feature in detail.

The load-scripts.php file was designed for WordPress admins and allows to load multiple JavaScript files into a single request, but the researcher noticed that that is is possible to call the function before login allowing anyone to invoke it.

The response provided by the WordPress CMS depends upon the installed plugins and modules.  It is possible to load them by simply passing the module and plugin names, separated by a comma, to the load-scripts.php file through the “load” parameter.

https://your-wordpress-site.com/wp-admin/load-scripts.php?c=1&load[]=eutil,common,wp-a11y,sack,quicktag,colorpicker,editor,wp-fullscreen-stu,wp-ajax-response,wp-api-request,wp-pointer,autosave,heartbeat,wp-auth-check,wp-lists,prototype,scriptaculous-root,scriptaculous-builder,scriptaculous-dragdrop,scriptaculous-effects,scriptaculous-slider,scriptaculous-sound,scriptaculous-controls,scriptaculous

The ‘load-scripts.php’ finds the JavaScript files included in the URL and appends their content into a single file and then send back it to the user’s web browser.

The researcher highlighted that the wp_scripts list is hard-coded and is defined in the script-loader.php file, so he decided to send a request that in response will get all the JS module of the WordPress instance.

“There is a well-defined list ($wp_scripts), that can be requested by users as part of the load[] parameter. If the requested value exists, the server will perform an I/O read action for a well-defined path associated with the supplied value from the user.”

“I wondered what would happen if I sent the server a request to supply me every JS module that it stored? A single request would cause the server to perform 181 I/O actions and provide the file contents in the response.”

Tawily developed a proof-of-concept (PoC) python script called doser.py that he used to makes large numbers of concurrent requests to the same URL to saturate the resources of the servers.

An attacker with a good bandwidth or a limited number of bots can trigger the CVE-2018-6389 vulnerability to target popular WordPress websites.

Tawily reported this DoS vulnerability to the WordPress team through HackerOne platform, but the company refused to acknowledge the flaw.

“After going back and forth about it a few times and my trying to explain and provide a PoC, they refused to acknowledge it and claimed that:
“This kind of thing should really be mitigated at the server or network level rather than the application level, which is outside of WordPress’s control.“” Tawily wrote.

The expert has implemented the mitigation against this vulnerability in a forked version of WordPress, he has also released a bash script that addresses the issue.

https://securityaffairs.co/wordpress/68709/hacking/cve-2018-6389-wordpress-dos-flaw.html