How to surpress false positives for debian-security packages?

Moritz Throne

unread,

Jun 29, 2022, 4:48:23 AM6/29/22

to Wazuh mailing list

Hey Community!

We're just starting with Wazuh and are really impressed by its complexity and ability to help us responding to incidents and have a better overview over everything.

Therefore we enabled the vulnerability-detector module.

However, we don't have a clue on how to set it up properly. We're getting LOTS of false positives for our Debian Buster machines like this one:

{"vulnerability":{"package":{"name":"aspell","version":"0.60.7~20110707-6+deb10u1","architecture":"amd64","condition":"Package less than 0.60.8-1"},"cvss":

[...]

vulnerability.package.version: 0.60.7~20110707-6+deb10u1

vulnerability.package.architecture: amd64

vulnerability.package.condition: Package less than 0.60.8-1

The installed package version is considered fixed, as it is listed on the security tracker by debian: https://security-tracker.debian.org/tracker/CVE-2019-17544

Is there any way to get these infos to the wazuh-manager? We have like 100 critical + 400 high events and it looks like most of them are just false-positives.

Thank you in advantage! We really love Wazuh and its capabilites <3

Best,

Moritz

Jonathan Martín Valera

unread,

Jun 29, 2022, 7:38:50 AM6/29/22

to Wazuh mailing list

Hi,

We love that you like Wazuh!

Regarding what you report, let’s see if we find the possible reason or if it can be investigated.

As you say, that package should not be considered as vulnerable, since OVAL says that this particular version is fixed. To summarize, in this case, two feeds are used to analyze if the package you mention is vulnerable or not.

Vendor’s own feed, in this case, Debian buster’s feed
NVD feed

If for any reason the package is not found within the vendor, the information from the NVD feed will be used (in addition to the correlations that are performed internally), and it seems that it is in this feed where it says that this version is vulnerable, giving this as the result.

Now you have to find the reason why it was not linked to the vendor’s feed, perhaps because the package was installed from a non-vendor source?

In any case, I will ask you for information so that the team can study your case.

(1) Which version of Wazuh are you using (wazuh-manager and wazuh-agent)?

(2) System information collected by Wazuh about the agent you are analyzing. To do this you can make a query to the API and get this information using the GET /syscollector/{agent_id}/os endpoint. More info at https://documentation.wazuh.com/current/user-manual/api/reference.html#operation/api.controllers.syscollector_controller.get_os_info

For example, if I run the query from localhost for wazuh-agent 001:
```
curl -k -H "Authorization: Bearer $TOKEN" https://localhost:55000/syscollector/001/os
```
Note: TOKEN=$(curl -u : -k -X GET “https://localhost:55000/security/user/authenticate?raw=true“)
(3) Information about the packages of that agent. Again, you can get this information through the GET /syscollector/{agent_id}/packages API endpoint. More info at https://documentation.wazuh.com/current/user-manual/api/reference.html#operation/api.controllers.syscollector_controller.get_packages_info

For example, if I run the query from localhost for wazuh-agent 001:
```
curl -k -H "Authorization: Bearer $TOKEN" https://localhost:55000/syscollector/001/packages
```
Note: This returns all the information, if you want to filter the output yourself and send the related information to the packages you want.
(4) Information about the vulnerabilities reported for that agent. Again, you can get this information through the GET /vulnerability/{agent_id} API endpoint. More info at https://documentation.wazuh.com/current/user-manual/api/reference.html#operation/api.controllers.vulnerability_controller.get_vulnerability_agent

For example, if I run the query from localhost for wazuh-agent 001:
```
curl -k -H "Authorization: Bearer $TOKEN" https://localhost:55000/vulnerability/001/
```

(5) Configuration of the vulnerability detector module. Again, you can get this information through the API endpoint GET /manager/configuration. More info at https://documentation.wazuh.com/current/user-manual/api/reference.html#operation/api.controllers.manager_controller.get_configuration
```
curl -k -H "Authorization: Bearer $TOKEN" https://localhost:55000/manager/configuration?section=vulnerability-detector
```

Please, provide all the information requested in (1), (2), (3), (4) and (5) to see what may be going on in your case, and if it is necessary to open any issues to fix what is needed, or to tell you what may be the fault you are having.

Best regards.

Nils Broge

unread,

Jul 7, 2022, 4:50:15 AM7/7/22

to Wazuh mailing list

Hi Jonathan,

Thanks for the fast reply, I'm sorry that I took a while.

Our version number for the agent is 4.3.1 and the managers is 4.3.5 (Revision 40317).

I attached the OS, Packages, Vulnerabilities and Manager Info as JSON export from the API.

Maybe we've got a misconfiguration on the vulnerability detector? Hope you can help.

Kind Regards,

Nils

(3)_PACKAGES.json

(5)_MANAGER.json

(4)_VULNERABILITIES.json

(2)_OS.json

Jonathan Martín Valera

unread,

Jul 12, 2022, 10:19:40 AM7/12/22

to Wazuh mailing list

Hi,

Sorry for taking so long to reply, I was on vacation :P

I have been analyzing the information provided and I have seen that in the configuration of the vulnerability detector module you do not have the Debian provider enabled, but the only one enabled is the NVD one. This may cause the problem you have reported, as either you are not using the OVAL feed for Debian, or you are using an outdated version of the feed.

I ask you to activate the Debian provider and try again:

<provider name="debian">
    <enabled>yes</enabled>
    <os>stretch</os>
    <os>buster</os>
    <os>bullseye</os>
    <update_interval>1h</update_interval>
</provider>

Note: You can delete the tag lines that you do not need.

This will download the corresponding feeds and they will be used to further analyze the vulnerabilities of the indicated system.

Then restart the wazuh-manager to apply the changes in the configuration.

systemctl restart wazuh-manager

From now on, when the next full scan of vulnerability detection is performed, everything should be rescanned again. Check here if you get those false positives again. If you don’t know what a full scan is, I advise you to read this section of the documentation where it is explained https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html#scan-types and if you have any doubt ask us.

To find out when the last full scan was performed, you can consult the vulnerability inventory within the Wazuh application, for example:

Note: Remember that the date must be after the restart date to apply the new configuration, and that the full scan interval is configurable in the ossec.conf file.

Try it and let us know the results.

Best regards.

Nils Broge

unread,

Jul 15, 2022, 7:22:25 AM7/15/22

to Wazuh mailing list

Hi Jonathan,

no worries, thanks for your help!

Although we see the NVD Feed somehow being displayed differently in the providers section, the other feeds (e.g. Debian) should still be enabled as they are configured this way in the ossec.conf.

Attached you can find a picture of our providers section in wazuh aswell as the matching json file, and our ossec.conf.

Kind Regards

Nils

ossec.conf

vulnerability_providers.json

Providers.png

Jonathan Martín Valera

unread,

Jul 18, 2022, 10:51:20 AM7/18/22

to Wazuh mailing list

Hi,

Ok, so if you have all the providers enabled, then you should have all the feeds downloaded and updated.

I have been analyzing the vulnerability inventory you shared (file (4)_VULNERABILITIES.json), and notice that the false positive vulnerability you comment (CVE-2019-17544) does not appear, so that vulnerability is not really being reported.

Maybe in the past, this vulnerability had been reported for some reason (outdated feed, some update…), but note that currently this vulnerability is not being reported because it does not appear in the inventory.

Also, all the vulnerabilities shown in the inventory seem to correspond to what the OVAL feed indicates, (apparently in no case there is a version that fixes the vulnerability, that’s why it shows as condition “Package Unfixed”). Ex:

That is, by analyzing your vulnerability inventory, nothing unusual has been found.

Please check again your vulnerability inventory and see if you find any vulnerability you gave regarding the OVAL feed.