As if there aren’t enough ways to attack a WordPress site, an Israeli researcher has published details of how almost anyone can launch a denial of service (DoS) attack against almost any WordPress with just one computer. That, he suggests, is almost 30% of all websites on the internet.
The attack uses the vulnerability associated with CVE-2018-6389. The CVE database, at the time of writing, has no details, marking it only as ‘reserved’ for future use. Details, however, can be found in a Barak Tawily blog post published Monday. It is an abuse of the WordPress load-scripts.php function, which exists to allow administrators/web designers to improve website performance by combining multiple JavaScript files into a single request at the server end.
Tawily’s DoS methodology makes use of two elements. Firstly, use of load-scripts.php requires no user authentication — it can be invoked by anyone. The second element is that load-scripts.php receives a parameter called ‘load[]’, which is an array. The purpose of the array is to be able to specify which scripts should be combined and loaded to improve performance. Since it is also used to improve performance of the wp-login.php page, it can be invoked before any user authorization is required.
Within WordPress there is a wp_scripts list containing defined paths for all the 181 script files. The intention is that the administrator or web designer can include the path for specific scripts within the load[] parameter, and improve performance according to the supplied value from the user. The wp_scripts list is hard-coded in the script-loader.php file.
“I wondered,” writes Tawily “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. I did so…”
The result took 2.2 seconds and was almost 4 Mb of data — making the server work hard to comply.
Tawily’s next step was to use a python script he had written himself to send repeated identical requests to the server. And this time it worked. “As long as I kept sending those requests to the server, it was too busy to handle any other request, and I had effectively (and easily) caused DoS.”
He used HackerOne to report the issue to WordPress, even though DoS is outside the scope of WordPress bounties. Nevertheless, it is a vulnerability that needed to be reported. The response, however, was muted: “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,” said WordPress.
That’s debatable on two counts. First, many WordPress sites are blogs and micro-business sites run cheaply on shared servers with the respective service providers, and with little technical skill among the owners. There is simply no way that such sites can be mitigated at the server or network level.
Second, Tawily goes on to show that mitigation isn’t really that difficult if you know what to do (which many WordPress users do not). He “forked WordPress project and patched it so no one but authenticated users can access the load-*.php files, without actually harming the wp-login.php file functionality.” He goes further to provide a bash script that modifies the relevant files to mitigate the vulnerability.
Related: Nine Vulnerabilities Patched in WordPress
Related: Function in WordPress Vulnerable To Malicious Use, Serves As Attack Tool