Vulnerability Detector (PuTTY)

[Daniel]

Hi All,

I've been evaluatng Wazuh 3.13 as part of the Security Onion 2.3 distribution. I've been working on setting up the vulnerability detector. The test setup is comprised of a Windows machine running the Wazuh agent, and the SO machine which has the manager. I've been installing a few known vulnerable software packages to see if they alert as expected. So far so good with the Wazuh agent itself (CVE-2021-41821), and Mozilla Firefox 3.6.8 -- which is reporting alot.

I've found one piece of software that I can't get to alert however, and that is PuTTY. I’ve installed version 0.74 on the test machine, hoping to trigger alerts for CVE-2021-36367, and CVE-2021-33500, however neither of these are alerted.

I assume it has nothing to do with syscollector and the basic setup, because I’m getting alerts for other packages, and I’ve also looked at the agent database in the ‘sys_programs’ table and I see PuTTY in there, so the manager should at least be aware of it.The NVD database is being updated offline, and the Wazuh vulnerability reported is of the 2021 vintage, so I have reason to believe that is all being handled correctly.

For reference, the ‘sys_programs’ entry has the following (product|version|vendor) information:

PuTTY release 0.74 (64-bit)|0.74.0.0|Simon Tatham

 

My latest avenue of investigation was CPE mapping with ‘cpe_helper.json’. On the SO VM, I’ve found this in the location ‘/nsm/wazuh/queue/vulnerabilities/dictionaries/cpe_helper.json’, but have also validated that this configuration also finds itself onto the so-wazuh container. The name, version, vendor information for the ‘sys_programs’ entry shown above doesn’t map very well to the CPEs referenced by the CVEs I want to alert. For reference, the CPE for putty 0.74 is ‘cpe:2.3:a:putty:putty:0.74:*:*:*:*:*:*:*’. So as I understand it I need to use ‘cpe_helper.json’ to specify some patterns / replacements:

• If I match ‘PuTTY’ in the product name, it should replace the product name with ‘putty’.

• If I match ‘Simon Tatham’ in the vendor name, it should repace the vendor name with ‘putty’’.

• Match and extract (with a group) the first two version fields (delimited by a ‘.’), and replace the version with the extracted version if a match occurred.

Below is the object I’ve tried to use to achieve the above. 

        {

            "target": "windows",

            "source": {

                "vendor": [

                    "^Simon Tatham"

                ],

                "product": [

                    "^PuTTY"

                ],

                "version": [

                    "^([0-9]+\\.*[0-9]+)"

                ]

            },

            "translation": {

                "vendor": [

                    "putty"

                ],

                "product": [

                    "putty"

                ]

            },

            "action": [

                "replace_vendor",

                "replace_product",

                "set_version_if_matches"

            ]

        }

I've tried various iterations of the version regex, but no luck. Each time I change cpe_helper.json, I give the so-wazuh container a restart. Making sure that all the required files are still there afterwards (NVD feeds etc..)

I’m wondering if anyone here can spot anything wrong with what I’m doing, or tell me If I’m barking up the wrong tree and should be looking elsewhere. Any help appreciated.

[Miguel Angel Cazajous]

Hi Daniel,

I took a look at this issue and I found something.

I don't think there's anything wrong with your approach.

What I did is the following.

I use this snippet to translate the PuTTY package. As you can see is just a simplified version of yours.



The issue is that partial scans don't trigger alerts and the vulnerability detector finds that the vulnerabilities database is up to date so doesn't update the information with the new data in the cpe_helper.

The steps I followed are:

- Stop the Wazuh service in your manager.

- Modify the timestamp field in the metadata table from the /var/ossec/queue/vulnerabilities/cve.db database.
sqlite3 /var/ossec/queue/vulnerabilities/cve.db 'update metadata set timestamp = 0'
You can check that with:
sqlite3 /var/ossec/queue/vulnerabilities/cve.db 'select timestamp from metadata'

- Restart the last_scan value from vuln_metadata table in the agent database.
sqlite3 /var/ossec/queue/db/001.db 'update vuln_metadata set last_scan = 0'
To check that use:
sqlite3 /var/ossec/queue/db/001.db 'select last_scan from vuln_metadata'

- Start your service again.

You should see a full scan starts.


After that, it is possible to see the alert generated.



Anyway, I will talk with my teammates to verify this behavior. I don't think this is working as expected.

Thank you for asking, I hope this was useful. I will keep you informed once I get more information about this.

Regards!

[Daniel]

Hi Miguel,

Thankyou for you for looking into this, much appreciated. I'll be sure to stay tuned regarding the issue with partial scans.

I'm happy to report that after following your instructions I did get an alert for CVE-2021-36367. However, I didn't get one for CVE-2021-33500 as I expected (NVD has cpe:2.3:a:putty:putty:0.74:*:*:*:*:*:*:* as a matching CPE).

Just wondering if you observed this alert during your test? Or am I missing something else? 

A fundamental difference I see between the two CVEs, is that according to the NVD, CVE-2021-33500 features a 'running on/with CPE' as well as the main product CPE:

cpe:2.3:o:microsoft:windows:-:*:*:*:*:*:*:*

The vulnerable software is actually running on Windows, so are there some additional steps I need to take to make it trigger an alert on this one?

If it's of any use, the generated CPE I have for my CVE-2021-36367 alert looks to match yours "a:putty:putty:0.74.0.0::::::x86_64:".

[Miguel Angel Cazajous]

Hi Daniel,

Sorry for the late response. I'm experiencing the same as you. The CVE-2021-33500 is stored in the cve.db database but for some reason when it performs the correlation,
does not detect that the putty package is vulnerable to that.

I think, once again, you're right. I found this in the log.

2021/10/21 00:03:46 wazuh-modulesd:vulnerability-detector[60155] wm_vuln_detector.c:5251 at wm_vuldet_insert_agent_data(): DEBUG: (5446): The CPE 'o:microsoft:windows_server_2019:1809:::::::' from the agent '001' was indexed.

I tried to perform something similar to the steps I did before because I suspect we should translate both. But no success.

With respect to the partial scan that should be able to trigger an alert, I'm pretty sure that it is due to the package is not new in the system inventory, and because of that, we need a full scan.

I did the same tests on a newer version of Wazuh with the same results.

I will insist on this and I will let you know how it goes.

[Miguel Angel Cazajous]

Hi Daniel,

Confirmed that we have a flaw in the partial scan because it is not detecting new vulnerabilities on already installed packages.

About the cpe_helper changes, initially, this helper was not thought to be changed manually and because of that, it doesn't work as the normal feeds.
Also, I was not taking into account that any change in this file will be lost if you decided to upgrade your manager.

Finally, the issue with the CVEs 33500 will need a little more work because as discussed with the team, performing a translation could lead to reporting vulnerabilities from other Windows systems.

For all these cases I created the following issues for tracking and they will be addressed according to our roadmap priorities.

https://github.com/wazuh/wazuh/issues/10631
https://github.com/wazuh/wazuh/issues/10632
https://github.com/wazuh/wazuh/issues/10633

Sorry for the inconvenience and thank you for reporting this with detailed information.

Regards!