Inventory data does not get full package's path information

[HanesSciarrone]

Wazuh version	Install type	Install method	Platform	Module
4.2.0	Agent	Packages/Sources	Windows	Data provider

Description

Data provider module does not find package path information for specific packages. This was found during a community case analysis (Reference link). During the test, the issue was reproduced following steps mentioned below:

1. Install VirtualBox over Agent host.
2. Install Wazuh Agent 4.2 on Windows 10 with default configuration (all syscollector providers on).
3. Register agent with manager and start agent.
4. Wait for the scan of the syscollector and go to Tools -> API console option on Kibana. See the image below as an example.

5. Execute command GET /syscollector/009/packages where 009 should be ID Agent of interest and export JSON resulting.

On the test was checked that some package on JSON file has a location field meanwhile another not. An example of this is shown below.

[jnasselle]

Hey team! Please add your planning poker estimate with ZenHub @HanesSciarrone @MiguelazoDS @pereyra-m

[HanesSciarrone]

Research

After some searches about the keys and values in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall registry. I found that only five properties are mandatories for every Windows installation.

• ProductCode
• ProductLanguage
• Manufacturer
• ProductVersion
• ProductName

Required Properties

The keys that depend on these properties and therefore always have a value are:

• Language
• Publisher
• DisplayVersion
• VersionMinor
• VersionMajor
• Version
• DisplayName

Windows Installer Properties for the Uninstall Registry Key

I have tried to compare how some programs get the path but, for example, CCleaner doesn't get that information.

I have also tested the InstalledPackagesView program to see how and what information it gets. After some checks, I have been able to validate that the information ti provides is in summary the same that sysInfo collects with some more keys.

Possible workaround

We have 3 possible solutions to fix the way that we are getting path installation packages:

• We can use the InstallSource field if it isn't empty and we have to check if the path exists.
• We can use the UninstallString field. The only thing to note is that the field doesn't always contain the path to the binary because the definition of the registry is the command or binary needed to uninstall the package. If the registry contains an executable the target of the registry is the directory of this binary, we have to parse the registry and keep only the directory.
• When the package has .exe binary some programs create a registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Path and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths with the same name of the registry read in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and concatenated the .exe string.

[Damian-Mangold]

Introduction

A more complete analysis was carried out to evaluate the different alternatives and implement a generic solution. For this, five software were analyzed: Chrome, Notepad++, VirtualBox, Wazuh and VMWare.

The following is the information currently being retrieved from the InstallLocation field:

Result

``` Chrome `"location": "C:\\Program Files\\Google\\Chrome\\Application"` Notepad ++ `location": ""` VirtualBox `"location": ""` Wazuh `"location": ""` VMWare `"location": "C:\\Program Files\\VMware\\VMware Tools\\"` ```

As can be seen, three of the five software do not have information about the installation folder.

Analysis of the different proposals

InstallSource field

The first proposal is to use the InstallSource field to get the installation folder information, the results are as follows:

Result

``` Chrome `"install_source": ""` Notepad ++ `"install_source": ""` VirtualBox `"install_source": "C:\\Users\\AGENT1~1\\AppData\\Local\\Temp\\kzykrlherrwziqq2unkj8pdr\\"` Wazuh `"install_source": "C:\\Users\\Agent1-W10\\Downloads\\"` VMWare `"install_source": "C:\\Program Files\\Common Files\\VMware\\InstallerCache\\"` ```

As can be seen, this field has no information indicating where the program is installed.

UninstallString field

The second proposal is to use the UninstallString field to get the destination folder information, the results are as follows:

Result

``` Chrome `"uninstall": "\"C:\\Program Files\\Google\\Chrome\\Application\\106.0.5249.62\\Installer\\setup.exe\" --uninstall --channel=stable --system-level --verbose-logging"` Notepad ++ `"uninstall": "\"C:\\Program Files\\Notepad++\\uninstall.exe\""` VirtualBox `"uninstall": "MsiExec.exe /I{62A30AE6-8596-4C61-A5B8-1C3B45C25C72}"` Wazuh `"uninstall": "MsiExec.exe /X{98576589-3B39-44F1-871B-42E0FD9F0623}"` VMWare `"uninstall": "MsiExec.exe /I{1FF5D624-5515-4343-837A-E54C101573E6}"` ```

Only in the case of Notepad++ does it seem to show data of interest.

Registry

The third proposal is to look for the information in other registries.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Path

Result

``` Chrome `"Path": "C:\Program Files\Google\Chrome\Application"` Notepad ++ `"(Predeterminado)": "C:\Program Files\Notepad++\notepad++.exe"` VirtualBox No info Wazuh No info VMWare No info ```

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths

Result

``` Chrome `"Path": "C:\Program Files\Google\Chrome\Application"` Notepad ++ `"(Predeterminado)": "C:\Program Files\Notepad++\notepad++.exe"` VirtualBox No info Wazuh No info VMWare No info ```

Information is only observed in two of the five programs. In the case of Notepad++, this is the same path that we see in the UninstallString field.

Conclusions

For some programs, the installation path information cannot be obtained. It is proposed to apply the following search sequence to obtain the most available information:

InstallLocation -- if empty -> UninstallString

Other analyzes

Searched for information on how other software resolves the install path and found that the install path is obtained using an MSI functionality that allows the install path to be obtained from the product code. But I understand that this possibility cannot be used and we just have to get the information from the windows logs.

[Dwordcito]

As a conclusion, we close the issue, since there is no feasibility to be able to obtain this information in a reliable and consistent way between the different ways of obtaining the information. Priority is removed, to continue investigating in the future.