Frequent malware in WP Super Cache cached pages

  • Resolved Floris

    (@florismk)


    2 months, 2 weeks ago

    Since I started using WP Super Cache, it happens often (almost monthly) that WordFence finds malware (PD9) in cached pages. It’s good news that it’s getting caught, of course, but bad news that it’s there at all. WordFence never found malware on my sites before I installed WP Super Cache. And the malware is always only found in cached pages.

    How and why does this happen, and how do I keep it from happening?

    Reports are like this (filename varies, of course):

    /mnt/web003/e2/70/511363570/htdocs/floriskleijne.nl/wp-content/cache/supercache/www.floriskleijne.nl/meta-wp-cache-3c685ba0ad8c85ade50e389730ed2748.php

Backdoor: PHP/PD9.5376 (A backdoor known as PD9).

    PS: Previously posted in the WP Super Cache forum, they refer me to WorfFence as they are not aware of a vulnerability in the plugin, and if there was a plugin vulnerability, there would be way higher incidence of this issue.

    The page I need help with: [log in to see the link]

Viewing 14 replies - 1 through 14 (of 14 total)
  • Thread Starter Floris

    (@florismk)

    2 months, 2 weeks ago

    PS: This is the WP Super Cache topic that referred me here: https://wordpress.org/support/topic/frequent-malware-in-cached-pages/

    Plugin Support wfmargaret

    (@wfmargaret)

    2 months, 2 weeks ago

    Hi @florismk,

    Thank you for reaching out.  The last version of WP Super Cache with a reported vulnerability was in 1.8, so please ensure you have WP Super Cache fully updated.

    The “meta-wp-cache-….php” files in WP Super Cache hold information about requests like the URL and cookies, so this may be a false positive due to an attempt to access a malicious URL being cached.  While Wordfence will automatically protect you from these attempts, the page visit attempt may still be cached.  If this is the case, you can check your web server access logs and you should see the same matched text appear there sometime in the last few days.

    To have our team take a look, please send a copy of the files to samples @ wordfence . com with the pasted scan result information and a link to this topic. Remember to remove any passwords, keys, or salts from any files you send to us, if applicable. 

    Thanks,
    Margaret

    Thread Starter Floris

    (@florismk)

    2 months, 2 weeks ago

    Next time it happens, I’ll submit the files. I’ve already deleted them this time around. Can we leave this open, or do I need to submit a new ticket?

    dimal

    (@dimalifragis)

    2 months, 2 weeks ago

    @florismk PAGE Caching plugins and Wordfence are not a good idea. At least switch WP Super cache to LATE INIT settings.

    Thread Starter Floris

    (@florismk)

    2 months, 2 weeks ago

    Thanks @dimalifragis. I’m taking your advice to the WP Super Cache thread.

    Donncha O Caoimh (a11n)

    (@donncha)

    2 months, 2 weeks ago

    Jumping over here from the WPSC thread. Hi! 🙂

    @dimalifragis if Wordfence notices something odd about the current request, be it query params for a backdoor or something, does it set a constant or flag for other plugins to recognise there’s something wrong? If so, I can add support for that in WPSC so it doesn’t cache the page.

    I agree with @wfmargaret that this is very likely a false positive, as we’ve had this happen many times over the years but there is a way for Wordfence to stop the caching. If it sets the constant DONOTCACHEPAGE it will stop WPSC from caching the page entirely. The meta file would not be created, and this problem would be avoided.

    WPSC won’t need to run on “late init”, as Wordfence will have, I presume, detected the malware trigger attempt and stopped the process and caching of the page.

    dimal

    (@dimalifragis)

    2 months, 2 weeks ago

    @donncha Hi,

    If WPSC (or any PAGE caching plugin) works in mod_rewrite mode, the pages are served BEFORE anything else.

    BEFORE Wordfence php prepend waf.

    It is unclear what happens related to that. As i posted in WF forum, using ANY page caching, both in php or mod_rewrite mode, overcomes several Wordfence features. Like RATE LIMITING for example.

    So, better to be safe and not use page caching with Wordfence. Maybe use some object plugin like Redis, that doesn’t seem to conflict.

    Anyways, this is what i have found and thanks for your time to reply.

    Thread Starter Floris

    (@florismk)

    2 months, 2 weeks ago

    @dimalifragis If WPSC worded in mod_rewrite mode, I assume this would be visible in .htaccess? If so, WPSC is not using mod_rewrite, because .htaccess shows no trace of it.

    Also, @donncha ‘s question is interesting: does WordFence signal request warnings for other plugins to notice?

    And @donncha, do you know the answer to the implied mod_rewrite question?

    Donncha O Caoimh (a11n)

    (@donncha)

    2 months, 2 weeks ago

    mod_rewrite can be used to serve cached files, but if Wordfence can detect the request is dodgy before the page is cached then it won’t matter what way cached files are served (mod_rewrite or PHP or late_init) as we can stop the page being cached entirely.

    I can see there’s a tension between using a full page cache and Wordfence, especially when attempting to rate limit requests. The cache is designed to allow more requests to be served, not have them rate limited.

    I guess we’ll find out a lot more when the next false positive happens and @florismk sends the offending file to you for analysis.

    dimal

    (@dimalifragis)

    2 months, 2 weeks ago

    @florismk WPSC mod_rewrite mode is called Advanced mode and YES you should see it in your modified .htaccess.

    Please note that mod_rewrite has the HIGHEST priority in execution of .htaccess.

    (This is not an issue only for Wordfence but for all security plugins, bots fighting plugins also. And tests MUST be done AFTER all the pages are cached and not with a clear/empty cache).

    Thread Starter Floris

    (@florismk)

    2 months, 2 weeks ago

    Thanks, @dimalifragis. I use Simple mode, so that explains why I don’t see any trace in .htaccess. I take it that means cached pages are not served before anything else?

    dimal

    (@dimalifragis)

    2 months, 2 weeks ago

    @florismk Well, i have to guess here, since i’m not a Wordfence developer 🙂

    If you use Wordfence optimized firewall, that prepends WF waf in your .htaccess (BEFORE WordPress loads), logically Wordfence is checking the requets BEFORE any caching (php mode) happens IN WordPress.

    BUT in reality even with that, for example, Rate Limiting doesn’t work. I have no idea why. It should, since Wordfence sits infront of WordPress requests. Also i have no idea what else could be not working, since it is very hard to debug this. Very hard for a webmaster.

    That is why i posted, it is a grey/unclear zone and better refrain from using PAGE caching with Wordfence. Better safe than sorry that is.

    Plugin Support wfmargaret

    (@wfmargaret)

    2 months, 2 weeks ago

    Hi @florismk,

    Thanks for following up. In the future, you can submit any samples you’re unsure of to samples @ wordfence . com and our team can review them without you opening a topic on the forums. In the future, you can combat this if you are sure the content is harmless by either choosing “Ignore” after a scan or telling Wordfence not to scan the specific cache meta files. You can do the latter by visiting Wordfence > All Options > Scan Options > Advanced Scan Options > Exclude files from scan that match these wildcard patterns (one per line) and adding wp-content/cache/supercache/www.floriskleijne.nl/meta-wp-cache-*.php on a new line.

    @dimalifragis, you are correct that some caching plugins can interfere with Wordfence blocks by displaying a cached page instead of the block page. This is typically safe to ignore unless there is a reason to prevent blocked visitors from seeing cached content. Wordfence will continue to block any malicious actions and display a block page on uncached pages.

    @donncha, there are no constants set that WP Super Cache can use to prevent caching in this case.

    The URL and query string in the cache file may include code that would be malicious in another context. Since the site was previously hacked (as mentioned in an older forum thread), the original attacker may try to reach their old scripts, triggering this periodically, or it could be an attacker targeting an old vulnerability that the site may not even have.

    Thanks,
    Margaret

    Thread Starter Floris

    (@florismk)

    2 months, 1 week ago

    Thanks, you’ve been immensely helpful, @wfmargaret !

Viewing 14 replies - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.