ChadVatx

Hi Rinat, thanks for the great advice!

I should mention that the exploit occurred while WP was still v4.3.1 and previous Edin theme installed. Coincidentally(?) both Edin and WP had updates last night, which I performed after the damage was already done. Perhaps this was a 0-day exploit that required old wp and/or old Edin in combination with FU. I’d still brace for a wave of new exploit reports of this kind coming in here. Also, time to make a FU update for wp 4.4!

But, since the UGC panel had these 3 script files listed in it, it strongly points to FU being the mechanism exploited. FU isn’t aware of files uploaded through other means, right? I also saw no logged visits to the web page with the form on it, so someone knows how to upload directly to the plugin. You might add enforcement that uploads can only come through the form on authorized blog pages.

I’ve removed the “execute” attribute on the uploads directory. That folder contains images for the website, but they still appear on the website afterwards. I believe the other folders still need to be executable or wp won’t be fully functional…? I’ll be sure to read the hardening tutorial.

Virtually every linux system has a pre-installed unzip utility. Your script can use that to verify that an uploaded .zip is valid. FU apparently accepted system.php as an upload since it had the same timestamp as one of the fake zips. I haven’t enabled wordpress to upload .php, and didn’t check any FU additional filetypes.

A setting to use an alternate upload directory would really be helpful. Perhaps even enabled by default! Also a permissions check upon install would truly impress. It all makes sense to do this, because we pick plugins like yours believing it enhances our security!

One last suggestion, when FU is “disabled” the upload form should break. I found that the upload form is still functioning until FU is fully uninstalled.

UPDATE: not sure if this is a co-incidence or not, but as I was writing the above, I decided to completely uninstall and re-install FU. Within seconds of enabling it, my server started pumping out spam, triggered by 1-per-min POSTs from a botnet (always a different IP) to a script placed among my wp-includes with a bogus file date/time (but the directory itself showed the valid modify time). This time, there is nothing in the UGC panel or restricted uploads directory.

I do not see any probes for this script or for FU script components leading up to this. It’s almost like they knew I’d just installed FU! Your code may have been infected, or they may be exploiting WP’s store somehow to learn when you have a new customer. It also strongly suggests that FU facilitates an upload to a directory of the hacker’s choice somehow.