Support » Plugin: Frontend Uploader » Uploader Plugin Exploited to Upload Scripts Dec 2015

  • Hey guys. This isn’t a complaint, rather advance warning that your product has been exploited by hackers, and it really bit us hard.

    Someone uploaded 3 php scripts to our /upload directory on the 9th, and I’m pretty sure FU was responsible because FU had these 3 files registered in it’s “Manage UGC” panel. The items did not have titles or descriptions. the linux ownership of the files was the same as for the website files, and just like other legitimate FU uploads.

    One uploaded script was called system.php, and two were called wp_module.zip and wp_module1.zip but were not really zipped, instead just being php script textfiles. I don’t know how these scripts were executed or how they created scripts in other directories. The two scripts which were created are alias82.php (found hidden in squirrelmail folders) and dirs34.php which was hidden in wp-content/upgrade These names are probably randomly generated.

    So for about a full day now, a botnet has been sending POST commands to one or the other of those last two scripts, resulting in batches of 30 spam emails going out to our SMTP relay service. We’ve been disabled now for using up all of our allotment of 10k. This is bad because we’re a neighborhood organization and people subscribe to our news, forum posts and email list!

    Suggestions for solutions: better rejection of .php scripts as uploads. Checking .zip files to see if they’re really zipped. Enforcing the location of uploads. Custom uploads location. I’d also really like advice for better permissions on our folders. Our current permissions are at the defaults created by virtualmin and wordpress:

    /home/%user%/public_html/wp-content/uploads/
    /755/750/750/755/755/

    Sorry if anything above is unclear. I should have been in bed 6-7 hrs ago. Thanks in advance for your help!

    https://wordpress.org/plugins/frontend-uploader/

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Rinat Khaziev

    (@rinatkhaziev)

    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 – http://codex.wordpress.org/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.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Uploader Plugin Exploited to Upload Scripts Dec 2015’ is closed to new replies.