Setting up Wazuh Vulnerability Detector

Setting up wazuh vulnerability detector

Due to it’s high performance cost the vulnerability detector is disabled by default on Wazuh installs. To enable it we will modify the config file.

NVD local copy

The vulnerability detector module is broken on the version installed on enough. We need to either update it, or to use an offline version of the NVD database. A script to download an offline copy of the database is available here.

You have to run all commands as super user.

We create a folder for the national vunerability database.

$ cd /var/ossec/
$ mkdir nvm-database
$ cd nvm-database

We download the provided script that copies the database.

$ wget https://raw.githubusercontent.com/wazuh/wazuh/v3.13.2/tools/vulnerability-detector/nvd-generator.sh
$ chmod +x nv-generator.sh

Let us run it and extract the results.

$ ./nvd-generator.sh 2002 . # The first argument is the starting date of the cves, 2002 is the oldest.
$ gzip -d *.gz

Good we should have our local version of the nvm database.
We should probably automate this task in the future.
Having an offline version of the database reduces the cost of the scan operation and we could configure it to operate at night where less bandwith is needed.

Configuration

We will need to do some modifications to the vulnerability detector configuration:

  • enable the syscollector:
<wodle name="syscollector">
    <disabled>no</disabled>
  • switch to the non deprecated version of the detector and activate it:
 <vulnerability-detector>
    <enabled>yes</enabled>
  </vulnerability-detector>
  • Add support for debian buster:
<provider name="debian"> 
        <enabled>yes</enabled>
        <os>buster</os>
        <update_interval>1h</update_interval>
</provider>
  • Add support for our local NVD copy:
<provider name="nvd">
        <enabled>yes</enabled>
        <path>/var/ossec/nvm-database/nvd-feed.*json$</path>
        <update_interval>1h</update_interval>
</provider>

To modify the config file use:

$ vim /var/ossec/etc/ossec.conf

Or any other editor. (I’m kidding use vim)

Search for System inventory and delete the System inventory section and replace it by our modified version below.

  <!-- System inventory -->
  <wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <scan_on_start>yes</scan_on_start>
    <hardware>yes</hardware>
    <os>yes</os>
    <network>yes</network>
    <packages>yes</packages>
    <ports all="no">yes</ports>
    <processes>yes</processes>
  </wodle>
  <vulnerability-detector>
    <enabled>yes</enabled>
    <interval>5m</interval>
    <ignore_time>6h</ignore_time>
    <run_on_start>yes</run_on_start>
    <provider name="debian"> 
        <enabled>yes</enabled>
        <os>buster</os>
        <update_interval>1h</update_interval>
    </provider>
    <provider name="nvd">
        <enabled>yes</enabled>
        <path>/var/ossec/nvm-database/nvd-feed.*json$</path>
        <update_interval>1h</update_interval>
    </provider>
  </vulnerability-detector>

We now restart the service.

$ service wazuh-manager restart

And check the alert logs to see if we detect some vulnerabilities

$ tail -1000 /var/ossec/logs/alerts/alerts.log | grep -i “vuln” -A 30

** Alert 1607084451.1353695: - vulnerability-detector,gdpr_IV_35.7.d,pci_dss_11.2.1,pci_dss_11.2.3,tsc_CC7.1,tsc_CC7.2,
2020 Dec 04 12:20:51 (wazuh-host.the.re) 127.0.0.1->vulnerability-detector
Rule: 23504 (level 7) -> 'CVE-2019-20446 affects librsvg2-common'
{"vulnerability":{"package":{"name":"librsvg2-common","source":"librsvg","version":"2.44.10-2.1","architecture":"amd64","condition":"Package unfixed"},"cvss":{"cvss2":{"vector":{"attack_vector":"network","access_complexity":"medium","authentication":"none","confidentiality_impact":"none","integrity_impact":"none","availability":"partial"},"base_score":4.3},"cvss3":{"vector":{"attack_vector":"network","access_complexity":"low","privileges_required":"none","user_interaction":"required","scope":"unchanged","confidentiality_impact":"none","integrity_impact":"none","availability":"high"},"base_score":6.5}},"cve":"CVE-2019-20446","title":"CVE-2019-20446","rationale":"In xml.rs in GNOME librsvg before 2.46.2, a crafted SVG file with nested patterns can cause denial of service when passed to the library for processing. The attacker constructs pattern elements so that the number of final rendered objects grows exponentially.","severity":"Medium","published":"2020-02-02","updated":"2020-07-28","cwe_reference":"CWE-400","references":["http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00024.html","https://gitlab.gnome.org/GNOME/librsvg/issues/515","https://lists.debian.org/debian-lts-announce/2020/07/msg00016.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6IOHSO6BUKC6I66J5PZOMAGFVJ66ZS57/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/X3B5RWJQD5LA45MYLLR55KZJOJ5NVZGP/","https://usn.ubuntu.com/4436-1/","https://nvd.nist.gov/vuln/detail/CVE-2019-20446","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20446"],"assigner":"cve@mitre.org","cve_version":"4.0"}}
vulnerability.package.name: librsvg2-common
vulnerability.package.source: librsvg
vulnerability.package.version: 2.44.10-2.1
vulnerability.package.architecture: amd64
vulnerability.package.condition: Package unfixed
vulnerability.cvss.cvss2.vector.attack_vector: network
vulnerability.cvss.cvss2.vector.access_complexity: medium
vulnerability.cvss.cvss2.vector.authentication: none
vulnerability.cvss.cvss2.vector.confidentiality_impact: none
vulnerability.cvss.cvss2.vector.integrity_impact: none
vulnerability.cvss.cvss2.vector.availability: partial
vulnerability.cvss.cvss2.base_score: 4.300000
vulnerability.cvss.cvss3.vector.attack_vector: network
vulnerability.cvss.cvss3.vector.access_complexity: low
vulnerability.cvss.cvss3.vector.privileges_required: none
vulnerability.cvss.cvss3.vector.user_interaction: required
vulnerability.cvss.cvss3.vector.scope: unchanged
vulnerability.cvss.cvss3.vector.confidentiality_impact: none
vulnerability.cvss.cvss3.vector.integrity_impact: none
vulnerability.cvss.cvss3.vector.availability: high
vulnerability.cvss.cvss3.base_score: 6.500000
vulnerability.cve: CVE-2019-20446
vulnerability.title: CVE-2019-20446
vulnerability.rationale: In xml.rs in GNOME librsvg before 2.46.2, a crafted SVG file with nested patterns can cause denial of service when passed to the library for processing. The attacker constructs pattern elements so that the number of final rendered objects grows exponentially.
vulnerability.severity: Medium
vulnerability.published: 2020-02-02
vulnerability.updated: 2020-07-28

Great we get an alert !
Next step is to get it working on an app in a docker container, next next step is to try to reduce the heavy workload of this operation.

Debugging

By putting wazuh_modules.debug=2 in /var/ossec/etc/local_internal_options.conf and restarting the service we can get debug logs which are very helpful.

1 Like

Excellent that you got it working despite the bug, congrats.

Dare I suggest inverting the steps ? The heavy workload problem is a blocker. If it cannot be resolved, there will be less incentive to figure out how to help wazuh investigate docker based applications.

You are right it’s smarter, let’s do it this way then.

1 Like

Updated version:

Setting up wazuh vulnerability detector

Due to it’s high performance cost the vulnerability detector is disabled by default on wazuh installs. To enable it we will modify the config file.

Configuration

Agents

FIrst we need to enable the syscollector on every agents.

  • enabling the syscollector:
  <wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <scan_on_start>yes</scan_on_start>
    <hardware>yes</hardware>
    <os>yes</os>
    <network>yes</network>
    <packages>yes</packages>
    <ports all="no">yes</ports>
    <processes>yes</processes>
  </wodle>

Local conf

To configure each agent locally we just need to add the above xml inside every agents ossec.conf.

Global conf

To apply a global conf to each agent from the manager we can add in:

/var/ossec/etc/local_internal_options.conf

the value:

wazuh_command.remote_commands=1

And by enabling the syscollector by adding the above xml in /var/ossec/etc/shared/default/agent.conf.
(The agent.conf may exist in each group folder at /var/ossec/etc/shared)

Manager

  • switch to the non deprecated version of the detector and activate it:
 <vulnerability-detector>
    <enabled>yes</enabled>
  </vulnerability-detector>
  • Add support for debian buster:
<provider name="debian"> 
        <enabled>yes</enabled>
        <os>buster</os>
        <update_interval>1h</update_interval>
</provider>
  • Add support for our local NVD copy:
<provider name="nvd">
    <enabled>yes</enabled>
    <update_from_year>2010</update_from_year>
    <update_interval>6h</update_interval>
  </provider>

To modify the config file use:

$ vim /var/ossec/etc/ossec.conf

Or any other editor. (I’m kidding use vim)

Search for System inventory and delete the System inventory section and replace it by our modified version below.

  <!-- System inventory -->
  <vulnerability-detector>
    <enabled>yes</enabled>
    <interval>5m</interval>
    <ignore_time>6h</ignore_time>
    <run_on_start>yes</run_on_start>
    <provider name="debian"> 
        <enabled>yes</enabled>
        <os>buster</os>
        <update_interval>1h</update_interval>
    </provider>
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_from_year>2010</update_from_year>
    <update_interval>6h</update_interval>
  </provider>
  </vulnerability-detector>

We now restart the service.

$ service wazuh-manager restart

And check the alert logs to see if we detect some vulnerabilities

$ tail -1000 /var/ossec/logs/alerts/alerts.log | grep -i “vuln” -A 30

** Alert 1607084451.1353695: - vulnerability-detector,gdpr_IV_35.7.d,pci_dss_11.2.1,pci_dss_11.2.3,tsc_CC7.1,tsc_CC7.2,
2020 Dec 04 12:20:51 (wazuh-host.the.re) 127.0.0.1->vulnerability-detector
Rule: 23504 (level 7) -> 'CVE-2019-20446 affects librsvg2-common'
{"vulnerability":{"package":{"name":"librsvg2-common","source":"librsvg","version":"2.44.10-2.1","architecture":"amd64","condition":"Package unfixed"},"cvss":{"cvss2":{"vector":{"attack_vector":"network","access_complexity":"medium","authentication":"none","confidentiality_impact":"none","integrity_impact":"none","availability":"partial"},"base_score":4.3},"cvss3":{"vector":{"attack_vector":"network","access_complexity":"low","privileges_required":"none","user_interaction":"required","scope":"unchanged","confidentiality_impact":"none","integrity_impact":"none","availability":"high"},"base_score":6.5}},"cve":"CVE-2019-20446","title":"CVE-2019-20446","rationale":"In xml.rs in GNOME librsvg before 2.46.2, a crafted SVG file with nested patterns can cause denial of service when passed to the library for processing. The attacker constructs pattern elements so that the number of final rendered objects grows exponentially.","severity":"Medium","published":"2020-02-02","updated":"2020-07-28","cwe_reference":"CWE-400","references":["http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00024.html","https://gitlab.gnome.org/GNOME/librsvg/issues/515","https://lists.debian.org/debian-lts-announce/2020/07/msg00016.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6IOHSO6BUKC6I66J5PZOMAGFVJ66ZS57/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/X3B5RWJQD5LA45MYLLR55KZJOJ5NVZGP/","https://usn.ubuntu.com/4436-1/","https://nvd.nist.gov/vuln/detail/CVE-2019-20446","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20446"],"assigner":"cve@mitre.org","cve_version":"4.0"}}
vulnerability.package.name: librsvg2-common
vulnerability.package.source: librsvg
vulnerability.package.version: 2.44.10-2.1
vulnerability.package.architecture: amd64
vulnerability.package.condition: Package unfixed
vulnerability.cvss.cvss2.vector.attack_vector: network
vulnerability.cvss.cvss2.vector.access_complexity: medium
vulnerability.cvss.cvss2.vector.authentication: none
vulnerability.cvss.cvss2.vector.confidentiality_impact: none
vulnerability.cvss.cvss2.vector.integrity_impact: none
vulnerability.cvss.cvss2.vector.availability: partial
vulnerability.cvss.cvss2.base_score: 4.300000
vulnerability.cvss.cvss3.vector.attack_vector: network
vulnerability.cvss.cvss3.vector.access_complexity: low
vulnerability.cvss.cvss3.vector.privileges_required: none
vulnerability.cvss.cvss3.vector.user_interaction: required
vulnerability.cvss.cvss3.vector.scope: unchanged
vulnerability.cvss.cvss3.vector.confidentiality_impact: none
vulnerability.cvss.cvss3.vector.integrity_impact: none
vulnerability.cvss.cvss3.vector.availability: high
vulnerability.cvss.cvss3.base_score: 6.500000
vulnerability.cve: CVE-2019-20446
vulnerability.title: CVE-2019-20446
vulnerability.rationale: In xml.rs in GNOME librsvg before 2.46.2, a crafted SVG file with nested patterns can cause denial of service when passed to the library for processing. The attacker constructs pattern elements so that the number of final rendered objects grows exponentially.
vulnerability.severity: Medium
vulnerability.published: 2020-02-02
vulnerability.updated: 2020-07-28

Great we get an alert !
Next step is to get it working on a docker container.

Debugging

By putting wazuh_modules.debug=2 in /var/ossec/etc/local_internal_options.conf and restarting the service we can get debug logs which are very helpful.

With your instructions I was able to activate the vulnerability detector. The YAML stanza you suggest translates into ansible variables for the wazuh-manager role.

        wazuh_manager_vulnerability_detector:
          enabled: 'yes'
          interval: '5m'
          ignore_time: '6h'
          run_on_start: 'no'
          providers:
            - enabled: 'yes'
              os:
                - 'buster'
              update_interval: '1h'
              name: '"debian"'
            - enabled: 'yes'
              update_from_year: '2010'
              update_interval: '1h'
              name: '"nvd"'

and when running tox -e wazuh I can manually observe that /var/ossec/logs/alerts/alerts.log contains alerts such as:

** Alert 1607673718.1786604: mail  - vulnerability-detector,gdpr_IV_35.7.d,pci_dss_11.2.1,pci_dss_11.2.3,tsc_CC7.1,tsc_CC7.2,
2020 Dec 11 08:01:58 (wazuh-host.gy2dsmjxgy3tanrr.test.enough.community) 127.0.0.1->vulnerability-detector
Rule: 23506 (level 13) -> 'CVE-2019-20367 affects libbsd0'
...
vulnerability.package.name: libbsd0
vulnerability.package.source: libbsd
vulnerability.package.version: 0.9.1-2

Since it is a level 13 alert and all alerts above level 12 trigger a message, the sysadmin will be notified there is a vulnerability that needs fixing. However, there is nothing they can do about it. The Debian GNU/Linux repositories, including the security repository, do not have a newer package:

# apt-get update
Hit:1 http://security.debian.org/debian-security buster/updates InRelease
Hit:2 http://deb.debian.org/debian buster InRelease                                                                                 
Hit:3 http://deb.debian.org/debian buster-backports InRelease    
# apt-cache policy libbsd0
libbsd0:
  Installed: 0.9.1-2
  Candidate: 0.9.1-2
  Version table:
 *** 0.9.1-2 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

This means the sysadmin will be notified about vulnerabilities they cannot fix. It’s not completely useless because they can report this upstream and hope to get it fixed eventually. But it’s not what is expected in the context of and IDS used by a sysadmin.

Do you have any suggestion on how we could address this problem?

1 Like

So I’ve been looking into it and, we might be able to do it using a custom integration which is basically a python script that could check if the vulnerable package is the latest package for our distribution before sending the mails. However it seems overly complicated and might introduce problems, is the noise created by those alerts significant ? Another option would be to add this behavior to wazuh, as this option might not be desired it would also mean adding handling an additional option for the detector.
TLDR: Can certainly be done but is a lot of work, does the problem justifies putting in the time and effort ?

As a sysadmin I want to be notified if an accident happened that prevented a CVE from being fixed. It could be that security updates silently stopped being applied for some reason, for instance. What I don’t want are notifications about events that I cannot fix, such as the one above (no package).

If I get notifications and have to sort which ones to act upon manually, that may be useful. But I would rather subscribe to the security updates feed of the distribution I’m using for that purpose. Since I will have to look it up anyway, every time I get a notification, to figure out if I received it because of a problem on my end or because the distribution has no fix yet.

Ok i’ll try to fix it ! :wink:

1 Like

Maybe people on the wazuh mailing list will want to share how they handle CVE notifications?

Since there does not seem to exist an API endpoint for the vulnerability detector, I wonder how to verify if it is working. Except for waiting 6h :slight_smile:

It creates the file /var/ossec/queue/vulnerabilities/cve.db. This is not proof that it works as intended, but it is proof it is active.