Vulnerability detection

New in version 3.2.0.

This capability can be used to detect applications that are known to be vulnerable (affected by a CVE).

How it works

To be able to detect vulnerabilities, now agents are able to natively collect a list of installed applications, sending it periodically to the manager (where it is stored in local sqlite databases, one per agent). In addition, the manager builds a global vulnerabilities database, using public OVAL CVE repositories, using it later to cross correlate this information with agent's applications inventory data.

The global vulnerabilities database is created automatically, currently pulling data from the following repositories:

This database can be configured to be updated periodically, ensuring that the solution will check for the very latest CVEs.

Once the global vulnerabilty database (with the CVEs) is created, the detection process will look for vulnerable packages in the inventory databases (unique per agent). Alerts are generated when a CVE (Common Vulnerabilities and Exposures) affects a package that is known to be installed in one of the monitored servers.

Compatibility matrix

The following table shows the operating systems that the vulnerability detector currently supports (we are working in supporting new ones) and the OVAL configuration needed for each distribution:

Distribution

Versions

Configuration OVALs

Redhat & CentOS

6

Redhat 6 OVAL

7

RedHat 7 OVAL

Ubuntu

14

Ubuntu 14 OVAL

16

Ubuntu 16 OVAL

Amazon Linux

1

RedHat 7 OVAL

2

Use case: Running a vulnerability scan

The following example shows how to configure the necessary components to run the vulnerability detection process.

  1. Enable the agent module used to collect installed packages on the monitored system.

You can do this adding the following block of settings to your agent configuration file:

<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <packages>yes</packages>
</wodle>

Remember to restart the agent to apply changes: /var/ossec/bin/ossec-control restart

Check Syscollector settings for more details.

  1. Enable the manager module used to detect vulnerabilities.

You can do this adding the following block of settings to your manager configuration file:

<wodle name="vulnerability-detector">
  <disabled>no</disabled>
  <interval>1d</interval>
  <run_on_start>yes</run_on_start>
  <update_ubuntu_oval interval="15h" version="16,14">yes</update_ubuntu_oval>
  <update_redhat_oval interval="15h" version="7,6">yes</update_redhat_oval>
</wodle>

Remember to restart the manager to apply changes: /var/ossec/bin/ossec-control restart

Check Vulnerability detector settings for more details.

The following fields are captured in every alert:

  • CVE: The CVE identifier for the corresponding vulnerability.

  • Severity: It specifies the impact of the vulnerability in terms of security.

  • Published: Date when the vulnerability was included in the official database.

  • Reference: URL of the official database website with extra information of the vulnerability.

  • Rationale: Broad description of the vulnerability.

  • State: This field informs if it exists a patch for the vulnerability (fixed) or instead, its state.

See below an example alert:

** Alert 1518137514.5302344: - vulnerability-detector,
2018 Feb 09 00:51:54 (manager) ->vulnerability-detector
Rule: 23505 (level 10) -> 'RHSA-2018:0180: kernel-alt security and bug fix update (Important)'
vulnerability.cve: RHSA-2018:0180
vulnerability.title: RHSA-2018:0180: kernel-alt security and bug fix update (Important)
vulnerability.severity: High
vulnerability.published: 2018-01-25
vulnerability.updated: 2018-01-25
vulnerability.reference: https://access.redhat.com/errata/RHSA-2018:0180
vulnerability.rationale: The kernel-alt packages provide the Linux kernel version 4.x.
Security Fix(es):
* A flaw was found in the patches used to fix the 'dirtycow' vulnerability (CVE-2016-5195). An attacker, able to run local code, can exploit a race condition in transparent huge pages to modify usually read-only huge pages. (CVE-2017-1000405)
Red Hat would like to thank Eylon Ben Yaakov and Daniel Shapiro for reporting this issue.
Bug Fix(es):
* Due to a bug in the ixgbe and i40e drivers, the socket buffer list (skb list) in some cases got corrupted when running Red Hat Enterprise Linux 7.4 with the kernel version provided by the kernel-alt package on the POWER9 systems. Consequently, a kernel panic occurred. This update fixes ixgbe and i40e, and the kernel no longer panics due to this behavior. (BZ#1518412)
* Users can lower the max_sectors_kb setting in the sysfs file system to accommodate certain workloads. Previously, users needed to set the maximum I/O size to either the block layer default or the optional preferred I/O size reported by the device. This update fixes the scsi driver to keep the current heuristic function for the initial setting of max_sectors_kb. As a result, for subsequent invocations, the driver now only updates the current queue limit if it exceeds the capabilities of the hardware. (BZ#1518432)
* When performing full-bootme tests on Boston ESS systems running Red Hat Enterprise Linux 7.4 with the kernel version provided in the kernel-alt package, a kernel panic occurred and the operating system dropped into the XMON software. This update fixes the Multi-Queue Block IO Queueing Mechanism (blk-mq), and the kernel no longer panics in these circumstances. (BZ#1518433)
* When running the stress test on the file system with the gssstress command, and pulling one disk from one recovery group, &quot;kernel I/O error&quot; was reported, and gssstress became unresponsive. Gssstress now works as expected under the described circumstances. (BZ#1522645)
* When using the fwupdate_xl710 utility to apply updates for NVM Intel Ethernet Converged Network Adapter XL710 on machines running Red Hat Enterpise Linux 7.4 with the kernel version provided in the kernel-alt package, a deadlock sometimes occurred when the i40e driver was acquiring access to the Non-Volatile Memory (NVM) of the device. Consequently, NVM acquire timeouts occurred, the firmware update failed with the following error message: &quot;Failed Acquiring NVM resource for read err=-53    status=0xa&quot;, and left the device's memory in a corrupted state. This update fixes the i40e driver, and the firmware updates no longer fail due to this behavior. (BZ#1522843)
* Previously, on POWER9 systems with more than 100 Pstates, the cpufreq driver did not handle the cases when the NxN matrix denominated transition table (trans_table) overflowed beyond the PAGE_SIZE boundary correctly. Consequently, reading trans_table for any of the CPUs failed with the following error:
&quot;fill_read_buffer: show+0x0/0xa0 returned bad count&quot;
With this update reading trans_table for any of the CPUs now proceeds as expected under the described circumstances. (BZ#1522844)
* Previously, the /sys/firmware/opal/exports directory did not contain an export node. Consequently, a range of memory in the Open Power Abstraction Layer (OPAL) that the operating system attempted to export to user space for debugging purposes was not available. With this update the sysfs file under /sys/firmware/opal/exports is now available for each property found there, and this file can be used for debugging purposes. (BZ#1522845)
vulnerability.state: Fixed
vulnerability.affected_package: kernel-devel
vulnerability.version: 3.10.0-514.26.2.el7

The following image shows a vulnerability alert on Kibana: