Forum Replies Created

Viewing 15 replies - 1 through 15 (of 79 total)
  • Your plugin was of great help, because it identified 68 files that were infected with malicious code, and helped me see how serious the situation was. It missed two php files, however, which were designed to load and execute php code via an include, and it missed said .ico file which carried the payload.

    In my mind, if the plugin looked at all files by default, it would have a better chance of either eliminating all payloads or all detonators (catching either would have defused the situation). I don’t think many people realize that an image file carrying malicious php code can indeed be half the problem.

    In this case, the script didn’t find the .ico file even after I had activated all extensions, but it also got stuck several times and retried scanning. The furthest I got was 99%.

    Thanks for writing back – I’m sending over the files that weren’t identified.

    DISCLAIMER: I am not a security expert. Just someone stuck with the same problem.

    First thing you should do is delete um-image-upload.php – it is in the /lib/upload folder.

    Secondly, using the Anti-Malware plugin didn’t do the trick for me, as it didn’t find all files. But it helps see the scope of the problem.

    I am uploading a full backup of the compromised account as I am typing this. If you have recent backups, you are in luck. Just keep in mind that it won’t help if you use a backup that is infected as well (needless to say). To find the time of the infection, check your apache logs – look for the first occurance of that nasty file in UM’s upload folder. Or look for entries related to um-image-upload.php. Good luck.

    • This reply was modified 1 year, 4 months ago by yosmc.

    After re-reading the security bulletin, it says that the exploit was around since 2015 until at least version 2.0.4 (this year).

    What it doesn’t say is that it was actually ever fixed.

    So I am assuming the current issue isn’t new – the only novelty is that there’s someone out there taking advantage of it.

    Not really. How long has this issue been around now? Since 2015?!

    https://www.cvedetails.com/cve/CVE-2018-0587/

    Now that everybody is getting hacked, you are “overhauling” security. Great! How about an immediate fix everyone can implement, like deleting that dreaded um-image-upload.php?

    You do not realize how serious this is, do you?

    It IS malware. And it puts other nasty stuff into your Worpress installation. Do a scan with an anti-malware plugin (like this one: https://de.wordpress.org/plugins/gotmls/ ) to get a better idea of your problem.

    Strange thing: I’ve been chasing this issue since yesterday, but I have (had) version 1.3.84. Can you guys confirm that you actually got INFECTED with the newest UM version installed? Possibly you upgraded after the malware was already in place?

    “Actually the plugin does scan hidden files starting with “.” (a period)”

    I can positively confirm that such a file was either not scanned or overlooked by your plugin.

    “it is ok to skip the ICO files because the malicious PHP code cannot be executed directly so it is only the include statements that call on the ICO files that are the real threat and my plugin found all those malicious includes, right?”

    That’s like the bomb squad saying, it’s ok to leave the bombs, we just went for the matches. Seriously?

    Fact is that the cleanup operation from last night was unsuccessful. So in the end, there were still bombs AND matches. Presumably, the original issue was fixed earlier, so this is about malicious code still remaining in the system.

    Are you sure you have the latest version installed? The reply by UMS strikes me as odd, as this should already be fixed:

    https://www.cvedetails.com/cve/CVE-2018-0587/

    Another one in frontend.css:

    .cf7-style input[type=”email”], .cf7-style input[type=”password”], .cf7-style input[type=”search”], .cf7-style input[type=”text”], .cf7-style input[type=”url”], .cf7-style textarea {
    width: 100%;
    }

    This can unnecessarily screw up the layout as well, and the plugin offers not option to undo this. I recommend unsetting this by adding the following to the theme’s custom CSS:

    .cf7-style input[type=”email”], .cf7-style input[type=”password”], .cf7-style input[type=”search”], .cf7-style input[type=”text”], .cf7-style input[type=”url”], .cf7-style textarea {
    width: auto;
    }

    My apologies. I absolutely hate it when people post sloppy “solutions” on the Net that go with half-assed explanations which are comprehensible to nobody. 😉

    As for the original code, leave it untouched – don’t delete anything, and don’t replace anything. That also goes for the three lines which I called “the culprit” above – leave them where they are.

    All you need to do is to ADD the five lines from the second box above (the stuff with auto_redirect_external_after_logout) somewhere to your code. Where and how you do that is a matter of taste. I assume it’ll work if you simply paste it at the end of um-logout.php – but no guarantee (just give it a try). If you do that, however, your changes might get overridden the next time you update Ultimate Member.

    It’s better practice to put your custom code and functions somewhere where they are safe from automated updating. Here are your options:

    https://www.skyverge.com/blog/add-custom-code-to-wordpress/

    • This reply was modified 1 year, 11 months ago by yosmc.
    yosmc

    (@yosmc)

    Hi,

    First of all I appreciate the fast response, that’s fantastic.

    Secondly: When I insert a print_r() – or any other type of echo – in that function I get no output on screen. When I call http://www.mysite.com/?task_scheduler_checking_actions=1 (which is how I use the plugin) all I ever see is my main page.

    Anyway, with your info, I got it right in no time at all. For anyone else looking at this, the actual variable would be:
    $_aRoutineArguments[ ‘auto_post_term_ids’ ][ ‘category’ ][1]

    Thanks again!

    So Shield supports the native Worpress contact form then?

    I don’t use Akismet (nor do I want to). Is there any recommended contact form that will tie into Shield Security, or is this a matter of Shield Security not supporting contact forms? 😉

    • This reply was modified 2 years, 3 months ago by yosmc.

    Thanks – but are you sure? I mean there’s the feature “standard newsletter” which, I guess, is for one-time mailings. However, if I can send an individual one-time mailing from within the admin interface, then obviously there must be some kind of function to do this? Thanks again.

    Speaking of odd… your claim that this is working on other (or even any other) site(s) is odd, too.

    The culprit is the following lines in um-logout.php:

    wp_logout();
    session_unset();
    exit( wp_redirect( um_user('logout_redirect_url') ) );

    Strangely, various sources and help forums on the net claim that this can’t possibly work, as wp_logout() will already have dumped you on the standard WP login page, and the redirect simply won’t happen. Those same sources recommend to use the following, which works like a charm:

    function auto_redirect_external_after_logout(){
      wp_redirect( 'http://www.somesite.com' );
      exit();
    }
    add_action( 'wp_logout', 'auto_redirect_external_after_logout');
Viewing 15 replies - 1 through 15 (of 79 total)