Vulnerability Scanner

[Andrew A]

Hey all, 

    I'm running vulnerability scans on assets I have hosted in AWS. Both Windows and Linux. 

When the scan runs -- it runs for almost no time at all and then says it successfully finished scanning...  And they're reporting zero vulnerabilities for ANY of my assets. 

I'm guessing that this isn't accurate because there's always some info or low vulnerabilities or any asset in existence. Any insight would be great. 

Thanks, 

Andrew

[Andrew A]

Here's the ossec log: 

2022/06/30 12:24:14 wazuh-modulesd:vulnerability-detector: INFO: (5400): Starting 'Ubuntu Focal' database update.
2022/06/30 12:24:29 wazuh-modulesd:vulnerability-detector: INFO: (5430): The update of the 'Ubuntu Focal' feed finished successfully.
2022/06/30 12:24:29 wazuh-modulesd:vulnerability-detector: INFO: (5400): Starting 'Amazon Linux 1' database update.
2022/06/30 12:24:29 wazuh-modulesd:vulnerability-detector: INFO: (5430): The update of the 'Amazon Linux 1' feed finished successfully.
2022/06/30 12:24:29 wazuh-modulesd:vulnerability-detector: INFO: (5400): Starting 'Amazon Linux 2' database update.
2022/06/30 12:24:29 wazuh-modulesd:vulnerability-detector: INFO: (5430): The update of the 'Amazon Linux 2' feed finished successfully.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5431): Starting vulnerability scan.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '000' vulnerabilities.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '000'
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '001' vulnerabilities.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '001'
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '002' vulnerabilities.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '002'
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '003' vulnerabilities.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '003'
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '004' vulnerabilities.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '004'
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '005' vulnerabilities.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '005'
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '006' vulnerabilities.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '006'
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '007' vulnerabilities.
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '007'
2022/06/30 12:24:30 wazuh-modulesd:vulnerability-detector: INFO: (5472): Vulnerability scan finished.

This is what all my scans look like -- however I have zero results. Also the scans seem to finish instantly. I can't believe that my aws instances would be that good that they wouldn't even have a low vulnerability somewhere. The baseline scan seemed to finish quickly and also deliver no results. 

[Miguel Angel Cazajous]

Hello Andrew,

First some questions

- What Wazuh version are you using for your manager and agents?
- Are you using a cluster environment? if that is the case, consider that the vulnerability detector module must be configured in the manager to which the agents are directly connected to.
- Is this a fresh install? Was this working and then it started to give you this result? Did you upgrade your environment? if that is the case, take into account that the manager should be newer or equal than your agents.

Please configure debug 2 for modulesd

Put this line wazuh_modules.debug=2

in your /var/ossec/etc/local_internal_options.conf configuration file and restart your manager.

After the restart vulnerability detector should start the scan if the run_on_start is enabled (it is by default)

Send me the logs you collected from /var/ossec/logs/ossec.log so I can take a look at this issue.

In between the logs you send must be more information about why this is not working.

Regards!

[Tech Master]

Hi Miguel,

for the following:
https://feed.wazuh.com
https://nvd.nist.gov
I was having trouble downloading because I use FortiGate deep packet inspection.
After installing the FortiGate certificate in the Wazuh Manager container I solved.

The problem persists with downloading Ubuntu feeds:

2022/07/04 19:00:27 wazuh-modulesd: download [31595] wm_download.c: 230 at wm_download_dispatch (): DEBUG: Downloading 'https://security-metadata.canonical.com/oval/com.ubuntu. focal.cve.oval.xml.bz2 'to' tmp / req-253105734 '
2022/07/04 19:00:27 wazuh-modulesd [31595] url.c: 152 at wurl_get (): DEBUG: CURL ERROR: SSL certificate problem: unable to get local issuer certificate

In the Wazuh Manager container:

root @ wazuh: / # openssl s_client -connect ubuntu.com:443 -CApath / usr / share / ca-certificates / mozilla
CONNECTED (00000003)
depth = 2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error: num = 20: unable to get local issuer certificate
verify return: 1
depth = 1 C = US, O = Let's Encrypt, CN = R3
verify return: 1
depth = 0 CN = ubuntu.com
verify return: 1
---

Could you let me know if you encounter the same problem?

The commands I used in the container are:

curl -iv https://ubuntu.com/security
openssl s_client -connect ubuntu.com:443 -prexit
openssl s_client -connect ubuntu.com:443 -CApath / usr / share / ca-certificates / mozilla

[Miguel Angel Cazajous]

Hi,

So tech you still are having issues? Where do you have installed your Wazuh manager, is it a docker environment? Did you follow some guide to do that?

Regards!

[Andrew A]

Miguel, 

   Sorry this took so long. I have attached the debug log for vuln detector: 

[Andrew A]

Honestly wouldn't be able to tell you if a 'baseline' scan was ever ran.... is there a way to trigger one manually?

[Andrew A]

btw amazon linux 2 is what im trying to scan. 

[Miguel Angel Cazajous]

Hi Andrew,

First some questions:
- What Wazuh version are you using for your manager and agents?

- Does this occur for all your agents? cause I also see you are downloading feed information for ALAS1 and Ubuntu Focal

- Is this a fresh install? Was this working and then it started to give you this result? Did you upgrade your environment?

Please execute this query and share the output. Replace <agent_id> by your ALAS2 agent ID (without <>)

sqlite3 /var/ossec/queue/db/<agent_id> 'select count(*) from vuln_cves'

Then it would be nice if you force a baseline scan and share the logs you get.

To force a baseline scan you have to set the last_full_scan value to 0.

- Stop your manager (wazuh-control stop)
- Execute the following query sqlite3 /var/ossec/queue/db/001.db 'update vuln_metadata set last_full_scan = 0'
- Start the manager service again (wazuh-control start)

You should be able to see something like this.


I don't see anything "bad" in the logs. Hope we can find the issue here.

Regards!

[Andrew A]

Miguel, 

This is a fresh install of 4.3.5 -- so scans have been automatically finishing in seconds and saying 'scan successful' with nothing reported the entire time.

I have amazon linux 2 agents and windows agents. I just never turned the other download feeds. This also is happening on the windows agent with 'hotfix' included on the agent configuration 

 

I have ran the steps you said and it appears that the scan is running and saying that I have no vulnerabilities: The windows machine has entries like this:

2022/07/25 14:38:24 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector_nvd.c:3582 at wm_vuldet_check_hotfix(): DEBUG: (5453): Agent '001' has installed 'KB5013941' that corrects the vulnerability 'CVE-2019-0758'
2022/07/25 14:38:24 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector_nvd.c:3582 at wm_vuldet_check_hotfix(): DEBUG: (5453): Agent '001' has installed 'KB5013941' that corrects the vulnerability 'CVE-2019-1277'
2022/07/25 14:38:24 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector_nvd.c:3582 at wm_vuldet_check_hotfix(): DEBUG: (5453): Agent '001' has installed 'KB5013941' that corrects the vulnerability 'CVE-2020-0678'
2022/07/25 14:38:24 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector_nvd.c:3582 at wm_vuldet_check_hotfix(): DEBUG: (5453): Agent '001' has installed 'KB5013941' that corrects the vulnerability 'CVE-2020-0679'
2022/07/25 14:38:24 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector_nvd.c:3582 at wm_vuldet_check_hotfix(): DEBUG: (5453): Agent '001' has installed 'KB5013941' that corrects the vulnerability 'CVE-2020-0680'
2022/07/25 14:38:24 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector_nvd.c:3582 at wm_vuldet_check_hotfix(): DEBUG: (5453): Agent '001' has installed 'KB5013941' that corrects the vulnerability 'CVE-2020-0681'

I also have quite a few "we haven't found a hotfix that solves CVE**** so its not possible to know it is vulnerable" 

 

I have some linux entries like this: 

2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2017-5062' since it don't meet its 'sibling' dependency on package with ID '1970649'
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2017-5063' since it don't meet its 'sibling' dependency on package with ID '1970656'
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2016-6217' since it don't meet its 'sibling' dependency on package with ID '1443097'
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2017-5066' since it don't meet its 'sibling' dependency on package with ID '1970670'
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2017-5067' since it don't meet its 'sibling' dependency on package with ID '1970677'
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2017-5068' since it don't meet its 'sibling' dependency on package with ID '1970681'
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2017-5069' since it don't meet its 'sibling' dependency on package with ID '1970685'
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1864 at wm_vuldet_linux_rm_nvd_not_affected_packages(): DEBUG: (5462): Package 'openldap' not vulnerable to 'CVE-2020-25709' since it is not affected (feed 'OVAL').
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2020-3973' since it don't meet its 'sibling' dependency on package with ID '1670264'
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1864 at wm_vuldet_linux_rm_nvd_not_affected_packages(): DEBUG: (5462): Package 'sqlite' not vulnerable to 'CVE-2018-8740' since it is not affected (feed 'OVAL').
2022/07/25 14:38:30 wazuh-modulesd:vulnerability-detector[23008] wm_vuln_detector.c:1967 at wm_vuldet_linux_rm_nvd_not_dependencies_met_packages(): DEBUG: (5463): Package 'linux_kernel' not vulnerable to 'CVE-2018-7268' since it don't meet its 'sibling' dependency on package with ID '1514588'

I assume it is working and I just have the most secure machines in the history of computing...?

Here's my problem. I've had tenable scans detect vulnerabilities in the last month or so while I have had this on -- and wazuh has returned zero vulns. Just simple things like doing a yum update on openssl, etc. This was never detected over 24 hours. Just concerned with how much trust I should be putting into this scanner. 

[Miguel Angel Cazajous]

Hi,

- For the Windows agent, it is expected that zero vulnerabilities are reported if you have all the KBs installed. We obtain the Windows information from NVD (CVEs), the Microsoft Windows API (Where we get the patch that fixes specific vulnerabilities), and the Microsoft catalog (that has the supersedence KB information). Sometimes the patch data is not complete and including a vulnerability without that information leads to false positives, although sometimes we are given false negatives, we are evaluating alternatives for those cases.

That is what explains the log you mentioned

"I also have quite a few "we haven't found a hotfix that solves CVE**** so its not possible to know it is vulnerable" "

To check if your scenario is expected, you could try to install a well-known vulnerable package (like Wireshark 2.4.5/3.0.2).



I also have vulnerabilities due to a missing patch.



- For the ALAS2 agent, I would like to dig a little deeper cause I find this more strange to happen because it is working as expected in my environment.

You can see it detects 675 vulnerabilities.



And some of them are for common packages, if you don't have any of these packages ( I doubt you don't have bash) please install them.



After a baseline scan, please show me the outputs of the following grep commands.

grep -o "The OVAL found.*'001'" ossec.log
grep -o "The NVD found.*'001'" ossec.log
grep -o "A total.*potential vulnerabilities have been discarded.*'001'" ossec.log

Change 001 with the correct agent ID.

I would expect to see something like this.

[Andrew A]

I had zero for OVAL, and 2977 for NVD. All 2977 were 'discarded' 

[Miguel Angel Cazajous]

Mmm well, that seems to be the issue, we discard the packages affected by the NVD that the OVAL says they are not affected. The question is why the OVAL has 0 potential vulnerabilities.

- How did you configure the ALAS feed? is that an online or offline feed update? Could you share the vulnerability detector configuration block?
- What is the output of the following command?
sqlite3 /var/ossec/queue/vulnerabilities/cve.db 'select target,count(*) from vulnerabilities group by target'
- Please share the output of the following grep command after a baseline scan
grep "wm_vuldet_linux_oval_vulnerabilities" /var/ossec/logs/ossec.log
- What is the output of this command? (replace agent_id with your correct agent ID (without <>))
sqlite3 /var/ossec/queue/db/global.db 'select * from agent where id = <agent_id>'

[Andrew A]

Config: 

  <vulnerability-detector>
    <enabled>yes</enabled>
    <interval>5m</interval>
    <min_full_scan_interval>3h</min_full_scan_interval>
    <run_on_start>yes</run_on_start>

    <!-- Ubuntu OS vulnerabilities -->
    <provider name="canonical">
      <enabled>yes</enabled>
      <os>focal</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Debian OS vulnerabilities -->
    <provider name="debian">
      <enabled>no</enabled>
      <os>stretch</os>
      <os>buster</os>
      <os>bullseye</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- RedHat OS vulnerabilities -->
    <provider name="redhat">
      <enabled>no</enabled>
      <os>5</os>
      <os>6</os>
      <os>7</os>
      <os>8</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Amazon Linux OS vulnerabilities -->
    <provider name="alas">
      <enabled>yes</enabled>
      <os>amazon-linux-2</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Arch OS vulnerabilities -->
    <provider name="arch">
      <enabled>no</enabled>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Windows OS vulnerabilities -->
    <provider name="msu">
      <enabled>yes</enabled>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Aggregate vulnerabilities -->
    <provider name="nvd">
      <enabled>yes</enabled>
      <update_from_year>2010</update_from_year>
      <update_interval>1h</update_interval>
    </provider>

  </vulnerability-detector>

First command: 

Amazon-Linux-2|23653
FOCAL|32039

Output of the grep command is just hundreds of this: 

2022/07/28 15:30:35 wazuh-modulesd:vulnerability-detector[14225] wm_vuln_detector.c:2323 at wm_vuldet_linux_oval_vulnerabilities(): DEBUG: (5460): Package 'vim-common' not vulnerable to 'CVE-2022-0156'. Version (2:8.2.5172-1.amzn2.0.1) not 'less than' '8.2.4314-1.amzn2.0.1' (feed 'OVAL').

potential vulnerabilities is still '0' when grepping "The OVAL found.*"

other output: 

2|servername|ip address|any|77d87d71e04afc5fda6f444b05e3ffbe63919b00e0c2d937f7a4eb153f7ae9e3|Amazon Linux|2|2||||amzn|Linux |server name |4.14.287-215.504.amzn2.x86_64 |#1 SMP Wed Jul 13 21:34:43 UTC 2022 |x86_64|x86_64|Wazuh v4.3.5|bfb7e830371c4465c8e261ca8c719622|a3b87761d2bbbba9ea4cfc6bf4d0d27e|wazuh-server-name|node01|1656535433|1659022844|Linux-Dev|synced|active|0

[Miguel Angel Cazajous]

Hi Andrew,

I would like to take a look at the grep output, if you could attach a file with that information I think it would be very helpful.
It is strange that you are getting 0 vulnerabilities, but I'm not seeing anything wrong with the scan yet.

[Andrew A]

Thanks for the help. I think we are deciding to disable the vulnerability scanner and just use other products specifically for that. 

Even the systems that have successful scans are just firing way too many false positives. I just wouldn't be able to fully trust this scanner even if we get these working. 

[Miguel Angel Cazajous]

Hi,

I understand your concerns, we are working to improve the scan https://github.com/wazuh/wazuh/issues/14153 to mitigate these related problems of false positives and negatives reported.

Regards!