Uploader Plugin Exploited to Upload Scripts Dec 2015

Hey,

So sorry to hear you got hacked. However, let me point out a couple of things –

Frontend Uploader fully relies on WP to process uploads, there’s no custom code doing file operations. Meaning, anything that could be uploaded through WP Dashboard can also be uploaded with FU.

Uploading PHP files is disabled in WP by default (though it can be overwritten with filters). However, if you rename PHP file into, say, zip, it’ll get through.

Now, the problem starts when something like that slips through and files in uploads folder have executable flag (which is exactly your case, 755 – means read+write+execute (owner of the file), 5 – read and execute (group), 5 – read and execute (all system users).

Once this fake zip (which is actually a php script) gets uploaded, all the attacker has to do is to figure out the url of the file (which isn’t that hard because by default wp has it as /%year/%month%/%filename%), after that he can hit that url in the browser and the file gets executed, wreaking all kinds of havoc. Typically, original file is a small script that downloads bigger and more complex scripts. This is as bad as it gets (the only worse thing would be if your server software was running under root user).

Here’s a good read on how to make WP more secure – https://codex.www.ads-software.com/Hardening_WordPress
Pay close attention to Changing file permissions section. (and the rest is important too).

All your ideas are valid and doable but will require some work and coding skills, changing permissions is easy and should fix your issue.

To be on a safe side you need to make might want to either do a completely new install (which is a hassle) or ask security professionals to scan your site. https://sucuri.net/ is pretty good, but it costs money.

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.