Troubles with vulnerability-detector for windows systems

Torsten Vielhak

unread,

Jan 20, 2022, 2:05:02 AM1/20/22

to Wazuh mailing list

HI,

we just installed a vanilla wazuh 4.2.5 on Debian 10.

Set the following configuration options:

/var/ossec/etc/internal_options.conf:

wazuh_modules.debug=2

/var/ossec/etc/ossec.conf

<vulnerability-detector>

<provider name="canonical">
<enabled>yes</enabled>

<provider name="debian">
<enabled>yes</enabled>

<provider name="redhat">
<enabled>yes</enabled>

<provider name="msu">
<enabled>yes</enabled>

<provider name="nvd">
<enabled>yes</enabled>

on the WindowsAgents:

<wodle name="syscollector">
<disabled>no</disabled>
<packages>yes</packages>
<hotfixes>yes</hotfixes>

For testing there is a Win10, Windows Server 2019, Windows 7 and Debian Buster agent connected.
Everything looks OK:

# for i in $(ls /var/ossec/queue/db/00*db); do echo $i; sqlite3 $i "select * from sys_osinfo; select count(*) from sys_programs; select count(*) from sys_hotfixes" -header; done
/var/ossec/queue/db/000.db
scan_id|scan_time|hostname|architecture|os_name|os_version|os_codename|os_major|os_minor|os_patch|os_build|os_platform|sysname|release|version|os_release|checksum
0|2022/01/20 06:31:16|wazuh|x86_64|Debian GNU/Linux|10 (buster)|buster|10||||debian|Linux|5.11.22-3-pve|#1 SMP PVE 5.11.22-6 (Wed, 28 Jul 2021 10:51:12 +0200)||1642660275677470903
count(*)
375
count(*)
0
/var/ossec/queue/db/001.db
scan_id|scan_time|hostname|architecture|os_name|os_version|os_codename|os_major|os_minor|os_patch|os_build|os_platform|sysname|release|version|os_release|checksum
0|2022/01/20 06:31:05|win10-test|x86_64|Microsoft Windows 10 Enterprise|10.0.19043||10|0||19043|||||2009|1642660263778705200
count(*)
298
count(*)
9
/var/ossec/queue/db/002.db
scan_id|scan_time|hostname|architecture|os_name|os_version|os_codename|os_major|os_minor|os_patch|os_build|os_platform|sysname|release|version|os_release|checksum
0|2022/01/20 06:13:40|win7-test|x86_64|Microsoft Windows 7 Professional|6.1.7601||6|1||7601|||||sp1|1642659219084677700
count(*)
288
count(*)
5880
/var/ossec/queue/db/003.db
scan_id|scan_time|hostname|architecture|os_name|os_version|os_codename|os_major|os_minor|os_patch|os_build|os_platform|sysname|release|version|os_release|checksum
0|2022/01/20 05:47:30|buster-test|x86_64|Debian GNU/Linux|10 (buster)|buster|10||||debian|Linux|4.19.0-18-amd64|#1 SMP Debian 4.19.208-1 (2021-09-29)||1642657648771837409
count(*)
1800
count(*)
0
/var/ossec/queue/db/004.db
scan_id|scan_time|hostname|architecture|os_name|os_version|os_codename|os_major|os_minor|os_patch|os_build|os_platform|sysname|release|version|os_release|checksum
0|2022/01/20 06:32:36|win19-test|x86_64|Microsoft Windows Server 2019 Standard|10.0.17763||10|0||17763|||||1809|1642660352370074300
count(*)
38
count(*)
46

So the syscollector got all data?!

If we look at the cve.db there are a lot of entries (sum(ncell) is very dirty approx. the number of entries); so I think the cve.db is "complete" and there are no error messages in the ossec.log, too.

But there are no entries for the windows agents in /var/ossec/logs/alerts/alerts.log. The Linux Buster Agent works like a charm.

Does the Win10 os_release problem (2009 vs 20H2,etc) also affect the other windows agents!?

Where can we troubleshoot any further? Any help is appreciated!

Thanks and best regards,
Torsten

Marcel Kemp

unread,

Jan 20, 2022, 7:06:31 AM1/20/22

to Wazuh mailing list

Hi Torsten,

With the information you have shared, we can confirm that everything is configured correctly and there do not seem to be any problems.

> So the syscollector got all data?! 

Yes, since all the OSs have some package [count (*) from sys_programs] and the fact that the Debian agents do not contain any hotfixes is normal, since this field only affects Windows agents, and all of them are correctly obtaining the patches that has the system [count(*) from sys_hotfixes] installed.

> Does the Win10 os_release problem (2009 vs 20H2,etc) also affect the other windows agents!?

No, that problem would only affect OSs that had changed their version to something like 20H2, 21H1, etc.
In this case, we can observe with the os_info information, that the os_release field in the other two Windows agents are different from 2009:
Windows 10: 2009
Windows 7: sp1
Windows Server 2019: 1809
So the only one affected in this case is the Windows 10 agent, which will not obtain system vulnerabilities (although it will continue to scan the installed packages with the translations found in the CPE_Helper). 
This case has been fixed with the following PR: #10168
And it will be available in the next version of Wazuh (4.3).

According to Windows 7 and Windows Server 2019 agents, there should be no problem detecting system vulnerabilities or package vulnerabilities. 
If they are not reporting any vulnerabilities, it may be because the system is up-to-date and contains all the patches that resolve the vulnerabilities for those systems, so the manager has nothing to report.

Even so, to confirm it, I would like you to share the logs related to vulnerability-detector so that I can check the trace of those agents and if there is any problem, help you to fix it.
As I have already seen that you have activated the debug mode (wazuh_modules.debug=2), then the logs should come out with additional debug messages (if not, then restart the manager, and they should already appear).
Once the debug logs appear, simply check that a full scan has been performed for agents 002 and 004, and share them so that we can help you better (the full scan will be performed once the ignore_time set in the configuration expires).
You can use the following command to dump all vulnerability detector logs to a 'vuln-detector.log' file:  cat /var/ossec/logs/ossec.log | grep vuln >> vuln-detector.log

Finally, I recommend that once you get the necessary debug data, set the debug line to 0 and restart again the manager to avoid disk space problems.

If you have any questions, don't hesitate to ask.
I am looking forward to your response.

Best regards,
Marcel

Torsten Vielhak

unread,

Jan 20, 2022, 7:51:08 AM1/20/22

to Wazuh mailing list

Hi Marcel,

thanks for your fast reply.

I think I attached the relevant lines from the logs.

IMHO it is very unlikely that client 002 is fully patched.

"wm_vuldet_request_hotfixes(): ERROR: (5503): SQL error: 'UNIQUE constraint failed: AGENT_HOTFIXES.AGENT_ID, AGENT_HOTFIXES.HOTFIX'" looks suspicious?!

Best regards,

Torsten

vuln.txt

Marcel Kemp

unread,

Jan 20, 2022, 12:56:45 PM1/20/22

to Torsten Vielhak, Wazuh mailing list

Hi again Trosten,

As you mentioned, it seems that there is a problem in the database of agent '004', since it is finding duplicate patches, causing that ERROR to appear when scanning the agent.

Since it cannot get the patches and packages contained in the agent, then it is not running the scan correctly, and therefore it does not show any vulnerabilities.

I've been researching the issue, and apparently reworking from C to C++ in Syscollector has removed a condition that prevented duplicate hotfixes.

Specifically, this is the condition that has disappeared: https://github.com/wazuh/wazuh/blob/7ceed61be3ebaeebc8e2e1087bdb9629ac4cf6c4/src/wazuh_modules/syscollector/syscollector_windows.c#L1019
However, this problem has already been resolved in this other PR: #11159
Which will be released with version v4.3.

In addition to that error, there seems to be another similar ERROR with the database on agent 002 as well:

2022/01/20 08:07:50 wazuh-modulesd:vulnerability-detector[97608] wm_vuln_detector.c:4556 at wm_vuldet_get_software_info(): ERROR: (5550): The hotfixes of the agent '002' could not be requested.
2022/01/20 08:07:50 wazuh-modulesd:vulnerability-detector[97608] wm_vuln_detector.c:2195 at wm_vuldet_check_agent_vulnerabilities(): ERROR: (5507): The software of the agent '002' could not be obtained.

To try to fix the problem, try the following steps:

Delete the databases of agents 002 and 004 (you can use the following command in the manager: rm -f /var/ossec/queue/db/002.db /var/ossec/queue/db/004.db ).
Restart the agents.
Check the logs again, so that after synchronizing the databases with syscollector, the recently deleted databases will be created again, and it only remains to check if the problem persists after running a full scan on the agents.

After completing the above steps, if either or both agents ('002' and/or '004') still do not get the vulnerabilities, then a solution to this problem (until v4.3 is released), would be to rollback to version v4.1.5 of the Windows agents that have this problem.

I hope it helps, and I am very sorry for the inconvenience 😓

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/b72e6de8-f499-49cc-9755-58d9539c47aen%40googlegroups.com.

Octavio Valle López

unread,

Jan 20, 2022, 1:59:11 PM1/20/22

to Wazuh mailing list

Hi Trosten, I hope you are well.

It seems strange to me that this error comes from syscollector, since the constraint fails should have appeared much earlier in E2E, in the case of having a duplicate (it should appear in the agent logs).
Can you send me the content of the hotfixes table for agent 004?

Manager DB:
sqlite3 /var/ossec/queue/db/004.db "select * from sys_hotfixes;"

Agent DB -> you can use sqlitebrowser for windows.
sqlite3 /var/ossec/queue/syscollector/db/local.db "select * from dbsync_hotfixes;"

It is important to clarify that issue https://github.com/wazuh/wazuh/pull/11159 resolves a problem that was added in 4.3 itself, therefore it should not affect 4.2.5.

Torsten Vielhak

unread,

Jan 21, 2022, 2:55:43 AM1/21/22

to Wazuh mailing list

Hi Marcel,

after deleting the databases it seems to work. At the beginning there were a lot of vulnerabilities detected because the there were no hotfixes in the manager databases (002.db and 004.db) But after a while the tables filled up and now it looks ok.
Very strange because we had the same issue before (this is the third installation of the wazuh server ;)) It looks like there is a "bootstrap" problem with a vanilla 4.2.5 install!?
Nevertheless, it seems to work at least for the win7 and win2K19 server. Still the same displayversion problem with win10 client. So we will wait for 4.3 ;)

Thanks for your support(!!) and best regards,

Torsten

Reply all

Reply to author

Forward