Same issue here… I have installed 2.0.25 version, but my latest DB version is 2.0.10 and the “updater” will not run – it just sits on “Get upgrades packages…” all day. Really frustrating after the amount of money I have sunk into this over the years.
Anyway, here is the file I found with the virus:
~/public/wp-content/uploads/ultimatemember/temp/tfCE0YbNhMMHQw4IRZiada6vLS1J7XuCEDzohcq0/stream_photo_12261104284b7316c107dd17323d5cb9_5b7ab0958bf57.php
Not sure what it would be for you, but you may just want to clear your whole temp directory.
The worst part is that this crazy instability introduced with the “move” to version 2 of the plug-in has resulted in pretty much an unusable front end for my clients. In this case, even after deleting the virus files, I have an issue that I cannot log in without disabling the plug-in, then re-enabling afterward – which basically means that no user can log in period. What a pain…
Good luck.
Hi @n13design,
Please make sure that you have the latest 2.0.25 version installed on your site.
Do the upgrade process under the Ultimate member section this will clear your temp folder. Please also check WordPress files using Wordfence security plugin.
@nboot8, I’m sorry to hear that you have issues with the latest version of the Ultimate member. If it is possible please submit a new ticket on our website (click on “I’ve read the pre-purchase FAQs & want to ask a question”) and describe your login issue so we can investigate what’s wrong on your end.
Regards.
@ultimatemembersupport I was able to update the UM plugin and confirmed the temp file folder is cleared. I appreciate the information about the Wordfence plugin. I know there’s a few other files that were added outside the temp folder that will require hunting down. Hopefully Wordfence will find them.
You may want to look for files like these (which were also infected as a result, on our site). I’m not sure how specific they are to each domain (except of course the SiteOrigins infection is only if you run that plug-in).
~/public/wp-content/uploads/siteorigin-widgets/hsnbm2ju9o.php
~/public/7q0ny7bgmy.php
~/public/wp-super_cache.php
…th1s_1s_a_4o4.html…
One of prevention that might avoid this attack successfully infect all of your (index) files is to add .htaccess in /uploads and prevent non-asset files for being executed.
From what I remember, target wp files to infect were:
/index.php
/wp-admin/index.php
/wp-content/index.php
/wp-content/plugins/index.php
/wp-content/themes/index.php
/wp-content/themes/<themedir>/index.php
/wp-content/themes/<themedir>/header.php
Notice chmod files also modified to 777, turn it back to 644.
Infected host will somehow include & load external asset files, and might redirect to lalaulala..
I’ve experience this too, not sure how hotfix should be made, but uploaded payload suppose not to be effective to modify other files.
https://stackoverflow.com/questions/8414840/prevent-upload-php-script-to-be-executed/8415600
-
This reply was modified 7 years, 9 months ago by
idoenk.
-
This reply was modified 7 years, 9 months ago by idoenk.
-
This reply was modified 7 years, 9 months ago by
Steven Stern (sterndata).
Moderator
Jan Dembowski
(@jdembowski)
Forum Moderator and Brute Squad
Side note: I’ve redacted the name of the place being sent to. Why give bad people more air time?
I think coz it ring a bell to other, that we facing the same issue., Why dont redacted name replaced with lil bit obfuscated but still pointing to something like [redacted]
