New to the community? Start here

[Defender Pro] Improve Malware Scan

0

I got a SSRF warning today. It’s the same one that we’ve seen over the last year.

We’ve seen this issue reported by Defender before:
https://wpmudev.com/forums/topic/defender-alert-about-ssrf/
https://wpmudev.com/forums/topic/wordpress-core-vulnerability-found-in-6-1-1/
Probably elsewhere.

This SSRF issue is a year old and hasn’t been addressed in core.
https://www.cve.org/CVERecord?id=CVE-2022-3590
So any new site this year “should” have already seen a warning about it already, right?
I guess not because I just got the ping from Defender. But … the warning that this issue still exists was updated ten days ago.
https://support.plesk.com/hc/en-us/articles/12387359265815-CVE-2022-3590-WordPress-6-2-Unauth-Blind-SSRF-vulnerability

So why does it take Defender 10 days to warn an admin about an issue like this? I kinda don’t care. I’m just pointing out the obvious.

What I think has happened is that WPMUDEV just subscribes to a service that lets them know about things like this – or maybe they scrape some site for it. And that process ain’t polling or scraping as often as it should.

Look, I’ve said this before and it’s Really important : Either do security (malware, backups) at a professional level, or leave it to others who are really invested in this specialty area. Security is not a passive field where we can wait days to be notified about vulnerabilities or backup issues. This is not at the same level as a form or marketing plugin. You either “got our backs” or you don’t.

This specific SSRF is associated with pingbacks and XMLRPC :
– Thanks Defender for not mentioning anything about that to the admin, and not linking to any data about the issue. Really? Yeah, I know, it’s only “Medium” severity, but does that determine how much information is provided?
– And we have pingbacks and XMLRPC disabled. Alfredo Galano Loyola said : “If you disable XMLRPC and Pingback features the site will be more secure but still show that warning”.
https://wpmudev.com/forums/topic/wordpress-core-vulnerability-found-in-6-1-1/#post-4185414
Thanks Alfredo, and for the code there, really.
But while Defender Security Recommendations says “XML-RPC is disabled, great job!”, Malware scan is Still warning about an issue that does not apply to the system – 11 months later.

Why am I bent out of shape about this? Because once again WPMUDEV is wasting my time with issues that keep coming back over a period of years. Stop doing that. Please.

Happy Holidays :grin:

Fri, 1 Dec 2023 21:22:48
More Defender Pro discussions
Defender Pro
  • Patrick Freitas
    • FLS

    Hi Tony G

    I hope you are doing well.

    Defender uses the Patchstack database for the reports, this is described on https://wpmudev.com/blog/security-defender-pro-patchstack/ so even though it is an old report, patchstack updated adding the 6.4.1: https://patchstack.com/database/vulnerability/wordpress/wordpress-6-1-1-unauth-blind-ssrf-vulnerability which made the report show up in Defender interface again as soon as it was updated on their database and a new scan is made.

    Best Regards
    Patrick Freitas

  • Tony G
    • Mr. LetsFixTheWorld

    > which made the report show up in Defender interface again as soon as it was updated on their database and a new scan is made.

    No, that’s what I’m saying. Patchstack updated that page and it took Defender 10 days to report it on a site. DEV polling of the Patchstack data needs to be more frequent … or the link with Hub sites needs to be more frequent. Whatever the problem, we don’t have “Security” when the time difference between awareness and alert is over a week.

    To confirm: See my OP link to support.plesk.com. That was posted (now) 14 days ago. Plesk was aware of the status change 14 days ago. Defender reported the issue 4 days ago. Ten days went by before Defender communicated a security issue to a site where the information May have been valuable.

    I don’t care about the severity of the issue, if it was a warning or a critical issue. I’m focused on the delay between cause and effect.

    Thank you my friend!

  • Adam
    • Support Gorilla

    Hi Tony G

    I’m sorry for late response but since it’s an important subject I was doing some testing on my end and I also needed to confirm a few things with both our Defender and Hub Teams.

    That being already done, I can say that the “10 days” delay (more or less) with such detection is not possible – except two scenarios to which I will get later on in this post.

    But let me start with explanation how this works – and it is pretty simple actually.

    1. When Defender scans the site against know vulnerabilities it sends information about detected WP core/plugin/themes and their versions to the Hub (that’s only “technical” data necessary to identify such vulnerabilities).

    2. Hub checks those internally against the vulnerability database (based on PatchStack) and returns results.

    That happens “on the fly” when the scan is done.

    Now about the vulnerability DB: this is fetched via API from PatchStack. This is checked about every hour each day. Which means that once the vulnerability/issue is published by PatchStack and made available in their API – it is a matter of up to about 1 hour until it is reflected on our end.

    There may be a slight delay with when Defender will see it due to internal Hub caching but that’s, again, only a matter of up to a few hours and never days. A few days or more delay in detection wouldn’t be possible here – unless given vulnerability was not really disclosed by PatchStack yet.

    —–

    Now why such a long delay may possibly happen in some cases?

    1. rarely – but not impossible – if there are issues with API communication between your site and our Hub (either way). To confirm if this is/was the case we would need to know

    a) which of your sites was/were affected
    b) and when about the detection actually happened (so we could check logs before that; provided it wasn’t delay of e.g. 30 days – we may not have such long logs)

    2. or – and that is quite often but is not in any way a bug of Defender or Hub – if scan was actually not performed. In Defender you have option to set scheduled scans – e.g. daily or weekly etc. If they are not scheduled, nothing will happen and nothing will be reported until next scan is run manually. If you set scheduled to eg weekly there may be even days delay indeed; for example:

    – you set scheduled to weekly and it’s bound to run on Dec 7th
    – it runs on 7th and there’s no vulnerability disclosed yet
    – then a few hours after the scan was run vulnerability is disclosed
    – next scheduled scan is on Dec 14th and that’s when it will be “detected” in Defender because that’s when the check happens.

    This is related to plugin settings only.

    What may also be possible – if scheduled scans are already set and they are frequent enough (e.g. daily) – could possibly be that the scan either failed for some reason or that the site is affected by some sort of a very “stubborn” server-side cache that kinda “fed” Defender with outdated data. But that is rarely a case and again, it would be specific to the site.

    An additional issue is whether the “Known vulnerabilities” option was is enabled in malware scan settings – but by default it would be and if it eventually reported vulnerability it would mean this is not the case here.

    —

    So all in all:

    1. if you did not have scheduled malware scan or you have it set to weekly or even less frequently: delay would be possible; how long – that depends on the scan frequency set or on when you manually run scan (if there are no scans scheduled); but this is a matter of configuration and it’s up to you how you decide to set it up.

    2. if you do have scheduled scans configured and they are daily then

    a) you need to make sure that the “Know vulnerabiliteis” toggle swtich is eanbled; as well as “Scan core files” / “Scan plugin files” (that depends on what you want to check)

    b) and if they are enabled and yet there are days-long (like 10 days in your case) delays – this needs to be individually investigated in context of particular site(s) affected. For that we’d need separate regular support tickets open so we could check it and identify the cause.

    Kind regards,
    Adam

  • Tony G
    • Mr. LetsFixTheWorld

    Adam Czajczyk I very sincerely appreciate your effort and trust your findings. You have investigated this matter deeply and that’s all I can ask.
    Given that time has passed it’s possible that conditions have changed and we will not know what actually happened. I will look into it further as time permits, but I accept your response and am comfortable that something on my site must have affected reporting.

    I will diligently note settings and events, and will report back if anything like this happens again.

    Thanks again. Really. I’m comfortable with this result and, as always, appreciate your/DEV support.