This vulnerability is listed on the CVE website as CVE-2018-6389 and on Exploit DB as exploit number 43968. Barak Tawily first wrote about it on February 5, 2018 on his blog.
First lets talk about what Dos actually is:
A Denial of Service (DoS) attack is a cyber-attack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to the Internet.Wikipedia
Or in plain English, this kind of vulnerability is used to make a server (the computer that’s hosting your website) unavailable by flooding it with many resource requests. By default, Linux servers allow up to 200 max-worker connections, and IIS just a little bit over 5000. This means that the server is capable of serving just 200 simultaneous connections at the same time, and in theory, f you can create those 200 connections you can make the server unavailable to everyone else but yourself. You can read more about it in this article here.
Back to the WordPress DoS vulnerability: This issue, in particular, is related to files called load-scripts.php and load-styles.php which are a part of the WordPress core.
- load-styles.php is also used to improve the performance by loading multiple Cascading Style Sheet (CSS) files in a single request.
Barak first noticed the problem when he saw an unusual URL that was loading when he visited certain WordPress pages. That URL was
He noticed that the load-scripts.php file was receiving a parameter called
After reviewing the source code of WordPress CMS, Barak determined precisely how WordPress loaded these files. He discovered that load-scripts.php file was designed to economize the loading of external JS files. Another file, called load-styles.php, was doing the same thing for Cascading Style Sheet (CSS) files.
This feature allowed the browser to receive multiple files with a single request, dramatically improve the load time of each admin page. Although it was only designed for use on admin pages, it was also being used on the login page — before the user had been authenticated. This oversight is responsible for this particular vulnerability.
Barak began to look at ways that load-scripts.php could be exploited. He started by altering the URL to include the JS file’s name multiple times in the hope it would cause WordPress to continually load the same file. This failed because WordPress removed duplicate names from the
He continued to explore the source code of WordPress and discovered that there is a variable that contains a defined list of scripts that can be loaded. If one of the names in the load array matches one of these script names, the server will perform an I/O read action to load it. The list of scripts that are available is defined in a file called script-loader.php. It includes 181 different scripts:
Barak found that when he included these names in the
load array, WordPress would search for each one, performing 181 I/O actions on the server. After it found files, it would combine them into one request, creating even more load on the server.
After testing the vulnerability, he found that the server took 2.2 seconds to gather the files, merge them into one file, and send them to the browser. Barak used a DoS tool written in Python to test the extent of this problem. This tool is capable of sending many HTTP requests in rapid succession to a server. He simply added the names of the JS files to the URL and fed it into this DoS tool.
After performing 500 requests, the server was overloaded and became unable of responding to subsequent requests. He posted a video showing how quickly it could be used to take down a WordPress website.
The following is a Python 3 script that takes advantage of this WordPress vulnerability and performs a DoS attack on a given IP.
NOTE: the following code from Github is for educational purposes only, and as such please only use it on servers that you own or have a writing statement from the owner for pen-testing it.
Usage: python .\load-scripts-dos-attack.py <IP ADDRESS>
Has the vulnerability been patched?
No, WordPress core developers refused to patch it, and I quote:
“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.”
Fortunately, Barak decided to create his own patch to ensure that only authenticated users were able to access the functionality in load-scripts.php. He has created a forked WordPress project that fixes the vulnerability and a Bash script that modifies the relevant files.
How to protect your WordPress website?
If you are a server administrator
- Hybrid DDoS Protection – Get on-premise DDoS defense and cloud DDoS protection for real-time DDoS attack prevention that also addresses high volume attacks and protects from pipe saturation.
- Behavioral-Based Detection – Quickly and accurately identify and block anomalies while allowing legitimate traffic through
- Real-Time Signature Creation – Promptly protect from unknown threats and zero-day attacks.
Most of the security issues that WordPress faces are not caused by the core application — they occur because of vulnerability in plugins and themes. It is estimated that over 50% of all WordPress exploits come from one of these vulnerabilities. The risk of these vulnerabilities can be mitigated by using a theme from a security-conscious developer and limiting the number of plugins you use.