Vulnerability Detector Refactor: No vulnerability alerts were triggered for agents previously registered

[Rebits]

Wazuh version	Commit
4.8.0 - dev-14153-vulndet-refactor	f70167f

Packages

• Agent: https://packages-dev.wazuh.com/warehouse/test/4.8/rpm/var/wazuh-agent-4.8.0-qa.vr.vd.testing.03012024.2.x86_64.rpm
• Manager: https://packages-dev.wazuh.com/warehouse/test/4.8/deb/var/wazuh-manager_4.8.0-qa.vr.vd.testing.03012024.2_amd64.deb
• Indexer: https://packages-dev.wazuh.com/warehouse/test/4.8/deb/wazuh-indexer_4.8.0-qa.vr.vd.testing.03012024.2_amd64.deb

Environment

manager1:
    roles: [manager, filebeat, indexer]
    os: ubuntu_22
    type: master

manager2:
    roles: [manager, filebeat]
    os: ubuntu_22
    type: worker

agent1:
    roles: [agent]
    os: centos_7
    manager: manager1

Description

No vulnerability alerts were generated for agents that were previously registered prior to activating the vulnerability detector scan.

root@ip-172-31-8-235:/home/qa# curl -k -u USER:PASS https://INDEXER-IP:9200/wazuh-states-vulnerabilities/_search?pretty=true
{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  }
}

root@ip-172-31-8-235:/home/qa# cat /var/ossec/logs/alerts/alerts.json  | grep CVE
{"timestamp":"2024-01-04T09:00:29.217+0000","rule":{"level":3,"description":"CIS Ubuntu Linux 22.04 LTS Benchmark v1.0.0.: Ensure only strong Ciphers are used.","id":"19008","firedtimes":56,"mail":false,"groups":["sca"],"gdpr":["IV_35.7.d"],"pci_dss":["2.2"],"nist_800_53":["CM.1"],"tsc":["CC7.1","CC7.2"],"cis":["5.2.13"],"cis_csc_v8":["3.10"],"cis_csc_v7":["14.4"],"hipaa":["164.312(a)(2)(iv)","164.312(e)(1)","164.312(e)(2)(i)","164.312(e)(2)(ii)"],"iso_27001-2013":["A.10.1.1","A.13.1.1"],"mitre_mitigations":["M1041"],"mitre_tactics":["TA0006"],"mitre_techniques":["T1040","T1557"],"nist_sp_800-53":["AC-17(2)","SC-8","SC-8(1)"]},"agent":{"id":"000","name":"ip-172-31-8-235"},"manager":{"name":"ip-172-31-8-235"},"id":"1704358829.515590","cluster":{"name":"wazuh","node":"master"},"decoder":{"name":"sca"},"data":{"sca":{"type":"check","scan_id":"2109513703","policy":"CIS Ubuntu Linux 22.04 LTS Benchmark v1.0.0.","check":{"id":"28644","title":"Ensure only strong Ciphers are used.","description":"This variable limits the ciphers that SSH can use during communication. Note: - Some organizations may have stricter requirements for approved ciphers. - Ensure that ciphers used are in compliance with site policy. - The only \"strong\" ciphers currently FIPS 140-2 compliant are: o aes256-ctr o aes192-ctr o aes128-ctr - Supported ciphers in openSSH 8.2: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com chacha20-poly1305@openssh.com.","rationale":"Weak ciphers that are used for authentication to the cryptographic module cannot be relied upon to provide confidentiality or integrity, and system data may be compromised. - The Triple DES ciphers, as used in SSH, have a birthday bound of approximately four billion blocks, which makes it easier for remote attackers to obtain clear text data via a birthday attack against a long-duration encrypted session, aka a \"Sweet32\" attack. - Error handling in the SSH protocol; Client and Server, when using a block cipher algorithm in Cipher Block Chaining (CBC) mode, makes it easier for remote attackers to recover certain plain text data from an arbitrary block of cipher text in an SSH session via unknown vectors.","remediation":"Edit the /etc/ssh/sshd_config file add/modify the Ciphers line to contain a comma separated list of the site approved ciphers. Example: Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128- gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr.","compliance":{"cis":"5.2.13","cis_csc_v8":"3.10","cis_csc_v7":"14.4","cmmc_v2":{"0":"AC.L2-3.1.13,AC.L2-3.1.17,IA.L2-3.5.10,SC.L2-3.13.11,SC.L2-3.13.15,SC.L2-3.13.8"},"hipaa":"164.312(a)(2)(iv),164.312(e)(1),164.312(e)(2)(i),164.312(e)(2)(ii)","iso_27001-2013":"A.10.1.1,A.13.1.1","mitre_mitigations":"M1041","mitre_tactics":"TA0006","mitre_techniques":"T1040,T1557","nist_sp_800-53":"AC-17(2),SC-8,SC-8(1)","pci_dss_v3":{"2":{"1":"2.1.1,4.1,4.1.1,8.2.1"}},"pci_dss_v4":{"0":"2.2.7,4.1.1,4.2.1,4.2.1.2,4.2.2,8.3.2"}},"references":"https://nvd.nist.gov/vuln/detail/CVE-2016-2183,https://www.openssh.com/txt/cbc.adv,https://nvd.nist.gov/vuln/detail/CVE-2008-5161","command":["sshd -T"],"result":"passed"}}},"location":"sca"}
{"timestamp":"2024-01-04T09:04:31.191+0000","rule":{"level":7,"description":"CIS CentOS Linux 7 Benchmark v3.1.2.: Ensure only strong Ciphers are used.","id":"19007","firedtimes":102,"mail":false,"groups":["sca"],"gdpr":["IV_35.7.d"],"pci_dss":["2.2"],"nist_800_53":["CM.1"],"tsc":["CC7.1","CC7.2"],"cis":["5.3.13"],"cis_csc_v8":["3.10"],"cis_csc_v7":["14.4"],"hipaa":["164.312(a)(2)(iv)","164.312(e)(1)","164.312(e)(2)(i)","164.312(e)(2)(ii)"],"iso_27001-2013":["A.10.1.1","A.13.1.1"],"nist_sp_800-53":["AC-17(2)","SC-8","SC-8(1)"]},"agent":{"id":"001","name":"agent1"},"manager":{"name":"ip-172-31-8-235"},"id":"1704359071.1488016","cluster":{"name":"wazuh","node":"master"},"decoder":{"name":"sca"},"data":{"sca":{"type":"check","scan_id":"952006326","policy":"CIS CentOS Linux 7 Benchmark v3.1.2.","check":{"id":"6165","title":"Ensure only strong Ciphers are used.","description":"This variable limits the ciphers that SSH can use during communication. Note: Some organizations may have stricter requirements for approved ciphers. Ensure that ciphers used are in compliance with site policy.","rationale":"Weak ciphers that are used for authentication to the cryptographic module cannot be relied upon to provide confidentiality or integrity, and system data may be compromised. - The DES, Triple DES, and Blowfish ciphers, as used in SSH, have a birthday bound of approximately four billion blocks, which makes it easier for remote attackers to obtain cleartext data via a birthday attack against a long-duration encrypted session, aka a \"Sweet32\" attack - The RC4 algorithm, as used in the TLS protocol and SSL protocol, does not properly combine state data with key data during the initialization phase, which makes it easier for remote attackers to conduct plaintext-recovery attacks against the initial bytes of a stream by sniffing network traffic that occasionally relies on keys affected by the Invariance Weakness, and then using a brute-force approach involving LSB values, aka the \"Bar Mitzvah\" issue - The passwords used during an SSH session encrypted with RC4 can be recovered by an attacker who is able to capture and replay the session - Error handling in the SSH protocol; Client and Server, when using a block cipher algorithm in Cipher Block Chaining (CBC) mode, makes it easier for remote attackers to recover certain plaintext data from an arbitrary block of ciphertext in an SSH session via unknown vectors.","remediation":"Edit the /etc/ssh/sshd_config file add/modify the Ciphers line to contain a comma separated list of the site approved ciphers Example: Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128- gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr.","compliance":{"cis":"5.3.13","cis_csc_v8":"3.10","cis_csc_v7":"14.4","cmmc_v2":{"0":"AC.L2-3.1.13,AC.L2-3.1.17,IA.L2-3.5.10,SC.L2-3.13.11,SC.L2-3.13.15,SC.L2-3.13.8"},"hipaa":"164.312(a)(2)(iv),164.312(e)(1),164.312(e)(2)(i),164.312(e)(2)(ii)","iso_27001-2013":"A.10.1.1,A.13.1.1","nist_sp_800-53":"AC-17(2),SC-8,SC-8(1)","pci_dss_v3":{"2":{"1":"2.1.1,4.1,4.1.1,8.2.1"}},"pci_dss_v4":{"0":"2.2.7,4.1.1,4.2.1,4.2.1.2,4.2.2,8.3.2"}},"references":"https://nvd.nist.gov/vuln/detail/CVE-2016-2183,https://nvd.nist.gov/vuln/detail/CVE-2015-2808,https://www.kb.cert.org/vuls/id/565052,https://www.openssh.com/txt/cbc.adv,https://nvd.nist.gov/vuln/detail/CVE-2008-5161,https://nvd.nist.gov/vuln/detail/CVE-2013-4548","command":[" sshd -T -C user=root"],"result":"failed"}}},"location":"sca"}

After removing and registering the agent again, we can see that vulnerability alerts were correctly triggered:

0    "hits" : {
221    "total" : {
9k      0      "value" : 4236,
 --:--:--       "relation" : "eq"

Steps to reproduce

• Deploy the proposed environment
• Enable vulnerability detector

Vulnerability Detector Configuration

  <indexer>
    <enabled>yes</enabled>
    <hosts>
      <host>https://INDEXER-IP:9200</host>
    </hosts>
    <username>admin</username>
    <password>changeme</password>
    <ssl>
      <certificate_authorities>
        <ca>/etc/pki/filebeat/root-ca.pem</ca>
      </certificate_authorities>
      <certificate>/etc/pki/filebeat/node-2.pem</certificate>
      <key>/etc/pki/filebeat/node-2-key.pem</key>
    </ssl>
  </indexer>


<vulnerability-detection>
    <enabled>yes</enabled>
    <index-status>yes</index-status>
    <feed-update-interval>10h</feed-update-interval>
</vulnerability-detection>

• Check that no matter how much we wait, alerts will never be triggered for that agent
• Remove the agent, and register it again
• Check that vulnerability alerts now are triggering correctly

Evidences

• Logs.zip

[pereyra-m]

Update

The new vulnerability detector is waiting for syscollector events to scan packages, it doesn't collect periodically all the active agents and scan them as the legacy module.

All the synchronization messages that happened before the module was enabled are lost and the only way to recover them is to manually remove the agents' DBs in the manager. There isn't a manual trigger to scan all packages of an agent.

The situation described in this issue might happen for example after an upgrade from v4.7x to v4.8.0, where there are previously registered and synced agents that won't be scanned. Only the new syscollector events after enabling the new module will be listened to.

@Dwordcito should define if this is expected or not.

[sebasfalcone]

Changed ETA to give time for review and testing

[sebasfalcone]

Pending final review - Moved ETA