So yesterday had a customer brought something to my attention that I passed over when I first saw mention of it a few weeks back. Boy am I glad it was brought back to my attention. Posted back on Feb 5th by Barak Tawily the researcher unveiled a method to send a packet requesting all 181 javascript items to the script-loader.php file in the WordPress install. This request makes the WordPress server reply with a 4Mb response to every request made.
I tested this on a virtual machine on my laptop, boy the results were astounding and nearly instant.
This is the POC from Barak Tawily, after less than 5 seconds. The VM load spikes to where the web services would become unavailable. Next I tested on my work VPS, and a bit of good news there. I have PHP-FPM configured with proper pool settings, this vastly improved the resiliency of the server. Load did increase but not to a point that the sever would be taken offline. Next I tested with PHP-FPM disabled, using CGI instead, and the results were the same as on the local VM, the server load within seconds became unsustainable. It seems that in addition to load this attack causes a exhaustion of connections to the web server (run over about 4 seconds):
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
1 104.X.X.X
27 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
1 104.X.X.X
127 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
1 104.X.X.X
129 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
1 104.X.X.X
146 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
1 104.X.X.X
152 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
157 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
162 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
171 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
178 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
182 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
185 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
194 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
198 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
197 159.X.X.X
[root@host ~]# netstat -tpn | grep 80 | awk '{print$5}' | cut -d : -f1 | sort | uniq -c
Currently work is being done to try and figure out a possible modsecurity rule to block this, so far I’ve just run into a bunch of syntax errors. At this time I have tested using Wordfence, my preferred WordPress WAF, and it will keep the web server mostly functional during this attack, however this is a scenario with just a 1 to 1 attack, under a many to 1 attack scenario this may not be enough.
Check your DDOS mitigation plans should you be responsible for a WordPress site, and good luck. Perhaps check on general best practices for defending WordPress here. I’ll update as better mitigations or updates become available.
Update:
Thought some more data may be useful. So whipped up a zip of pcaps and Apache log files from tests on my local VM. You can find them here:
https://laskowski-tech.com/downloads/CVE-2018-6389.zip