Cve-2022-30190

Does greenbone community have cve’s for CVE-2022-30190 - FOLLINA?

1 Like

I don’t think so. I just checked the CVEs on my system today (after updating the feeds), there is no CVE-2022-30190.

1 Like

Hi @rgarza4 and @Eric :slight_smile:

It’s been implemented and will be included with the next feed update (Feed-Version: 202206031133) appearing later this afternoon (CET timezone).

4 Likes

Great, thanks!

I update my feed/scap and unfortunately, greenbone still does not have the Follina cve’s :frowning:

Hi @rgarza4,

Yep, I just checked on my install using the Community Feed and don’t see it either. I’ll report it to the developers. It’s a holiday with a long weekend here so there might be a delay.

To see your current feed number and information about it, in Greenbone Security Assistant go to:

Administration → Feed Status and it should display a page with the current feed types, origin and number.

I currently show for the NVT feed : Greenbone Community Feed 20220603T1038 status Current (and not finding Follina).

Thanks for letting us know, I’ll post a followup when I get more information (or it could be someone else from Greenbone following up).

1 Like

Just a quick followup- I got different results with different installs. What I would advise for the time being is that for anyone updated to a current Greenbone Community Feed who is not seeing the information for CVE-2022-30190 in Greenbone Security Assistant on a local install to give it a try with the trial edition (Greenbone Enterprise Trial)
https://www.greenbone.net/en/testnow/
It will default to the Greenbone Community Feed and that one worked for me.

1 Like

Its still not updated.

I can confirm the observations of @DeeAnn that CVE-2022-30190 is showing up in the GSA GSM TRIAL 21.04.18 using the Greenbone Community Feed version 20220603T1038 here:

SecInfo → NVTs

It does NOT show up here:

SecInfo → CVEs

But this is currently expected because the Greenbone Community SCAP Feed has a version 20220601T0040 while https://nvd.nist.gov/vuln/detail/CVE-2022-30190 has been published on 06/01/2022 (see later points for some additional background info).

Please also note that both views are independent from each other and “filled” differently. That’s why you’re seeing differences.

SecInfo → NVTs

  • This shows all available VTs on the GVM/GSM and their coverage
  • If you search for a CVE in this view you will get all VTs showing up covering that CVE
  • The VT feed needs to be up to date for this
    • On the enterprise appliances / GSM: Feed synchronization needs to be enabled and working, see 7 Managing the Greenbone Operating System — Greenbone Enterprise Appliance 21.04.18 documentation
    • On the source/package based installation: The “sync” of this is done via greenbone-nvt-sync and your setup needs to be “fully” working (e.g. ospd-openvas and gvmd needs to be running and have finished a sync of the VTs, …). If you have a package manager based installation please consult the documentation of the packages how the sync is done “correctly” (e.g. correct used user) on the used environment.

SecInfo → CVEs

  • This is a “global” CVE database filled by the data feed provided by nvd.nist.gov
  • If a CVE doesn’t show up there it doesn’t mean that there is no CVE coverage via VTs
  • If you’re looking for CVE coverage via VTs use the SecInfo -> NVTs view
  • There is always at least one day delay between a CVE published on nvd.nist.gov until it is showing up there
  • Some of the CVEs listed there might show up with a 0.0 (Log) severity. This is unrelated to VT coverage and the severity is updated once the assessment of the severity was done and published in the NVD data feed. This takes a few days up to a few weeks.
  • The SCAP data feed needs to be up to date for this
    • On the enterprise appliances / GSM: Feed synchronization needs to be enabled and working, see 7 Managing the Greenbone Operating System — Greenbone Enterprise Appliance 21.04.18 documentation
    • On the source/package based installation: The “sync” of this is done via greenbone-feed-sync --type SCAP and your setup needs to be “fully” working (e.g. gvmd needs to be running and has to finish a sync of the SCAP data, …). If you have a package manager based installation please consult the documentation of the packages how the sync is done “correctly” (e.g. correct used user) on the used environment.
  • The previous mentioned sync might take a good amount of time depending on the available resources on the host system (e.g. CPU, drive i/o, …)

Hope this gives some background info on the seen differences and the differences between both views within the GSA.

1 Like

When will we have this cve in greenbone security assistant community version? @greenbone.net

The CVE is already included / covered by a VT (Vulnerability Test) in the 20220603T1038 feed version (from Friday last week) of the community version as previously explained.

If you want an estimation when the CVE will show up via SecInfo -> CVEs please open a new thread at Feed Services (GCF & GSF) - Greenbone Community Portal as this is unrelated to VTs.

I dont believe this is accurate. After running scans, greenbone has found 0 vulns for this vuln. That cannot be.

Microsoft don’t have a patch but a workaround. Deploy in your GPO to ensure all servers and end points have this removed.

To disable the MSDT URL Protocol

Disabling MSDT URL protocol prevents troubleshooters being launched as links including links throughout the operating system. Troubleshooters can still be accessed using the Get Help application and in system settings as other or additional troubleshooters. Follow these steps to disable:

  1. Run Command Prompt as Administrator.
  2. To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename
  3. Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.

How to undo the workaround

  1. Run Command Prompt as Administrator.
  2. To restore the registry key, execute the command “reg import filename”

I know about the work around. I was referring to @cfi , I dont believe his statement is accurate, because I have ran scans, and greenbone is not detecting this vulnerability, and I KNOW my environment is vulnerable to this attack.

This topic has been continued in Follina Not Detected and it is probably / most likely an environmental / target configuration issue not allowing access to the checked registry key.

Also note that the related updates have been published by Microsoft on the last Patch Tuesday and the flaw is now also checked via a wide range of version checks:

https://www.greenbone.net/en/follina-update/