We would like to create an override for a particular vulnerability that references a particular executable path, but only want it to apply to that particular instance (path) of the reported vulnerability (on ALL workstations within the target). We’ve created the override using the OID from the scan, but are concerned that this override may apply to ANY instances of this vulnerability, not just the one with that path. In the override settings, we see there is a ‘Result’ filter where a ‘UUID’ can be specified - would this reference the actual instance of the path reported that we’d like to override? If so, how can we retrieve that ID? Thanks in advance for any assistance provided!
Here is a link to the python-gvm function for create_override(). Here you can see from the docs the result UUID. However, this certainly will not accomplish your goal going forward to scan new hosts. Furthermore, whether it will accomplish your goal for an already completed scan with an existing result (UUID) depends on whether the vulnerability test (OID) in question is creating individual results for each location of the file.
For example, say the VT found 5 instances of httpd on your server and created a separate results for each one, you could override a specific one with the file path you want to ignore. However, UUID for a scan result cannot be predicted beforehand.
Thanks for the feedback. In our case, the scan is reporting a particular service path (which is uniform across all hosts) that contains spaces is not enclosed in quotes. We’ve verified in every instance that this is not the case in the registry, so were hoping to override only that reported path (we would of course want to be notified of any others in the future so wouldn’t want the override to apply unconditionally).
Are you saying the VT has a false positive report when encountering paths with spaces? If so, can you specify this VT OID? Sorry, I’m just not following.
Sorry if I wasn’t being clear. A scan is returning an instance of the following vulnerability on multiple workstations (I’ve replaced the actual software name with ‘ABC’):
Microsoft Windows Unquoted Path Vulnerability (SMB Login) OID: 1.3.6.1.4.1.25623.1.0.107303
Detection Result
The following services are using an ‘unquoted’ service path:
DisplayName|Name|PathName
ABC Device Agent|ABCDeviceAgent|“C:\Program Files\ABC\ABCAgent\ABCagent.exe” agent service run
ABC Updater|ABCUpdater|“C:\Program Files\ABC\ABCAgent\deviceagent.exe” updater service run
The actual result shows that the path is surrounded by quotes, and upon review of the registry entries (and running command line scripts on the specified workstations to identify service paths not surrounded by quotes), we have not found any instances where the path specified in the detection result is NOT enclosed in quotes.
Not entirely sure why this one program is being flagged, but we were hoping to omit it from our scans given the results of our investigation, however we wouldn’t want to override ANY future instances of this vulnerability should a DIFFERENT unquoted service path (for a different program) be detected in the future.
Is it possible that maybe there is some character encoding problem with your Registry Keys?
The quotation characters in your text above is not compliant with Windows service paths.
When you query this with reg query or Get-ItemProperty, you should see normal straight quotes ("). Windows expects straight quotes. It does not normalize or “sanitize” other quote characters (like curly quotes or Unicode look-alikes). So, these registry keys could appear to be quoted, but in fact are not, and are thus still vulnerable. Could you verify this potential cause?
So upon review, it appears that the correct quotes are surrounding the service path in question. I’ve verified the quotes being used via a reg query, copied and pasted the paths in question into a text editor and displayed all symbols/encoding, manually replaced the key value with a manually typed path (and quotes), and in looking at the binary data of the actual registry key, the quotes in question are showing a hex value of ‘22’ - the same as all the other quoted service paths that aren’t triggering a detection result, but it still came back on the next scan . I ran multiple command line/PS scripts again to check for such ‘unquoted’ paths but they all came back with no results..
OK, thanks for verifying this! I will look at the VT source code today and forward this on to the VT dev team in case they can determine why this happens. As for configuring an override to specifically address only these service paths, unfortunately I don’t see a way to accomplish this because the create_override() function does not allow advanced filtering to say, filter out the result description for the service path.
However, just a final thought. I think you don’t need overrides for this task. You could use a regular results filter to remove items with the specified paths in the result description:
description!~"C:\Program Files\ABC\ABCAgent\deviceagent.exe" and description!~"C:\Program Files\ABC\ABCAgent\ABCagent.exe"
However, filters cannot be grouped together with () so there are some limitations.
Thanks I will see if that works for us. Just to confirm - would that expression just be concatenated to whatever is currently in our results filters’ ‘Term’ field?
Thanks. I added it to saved filter, and with that saved filter selected, I can see that it populates the ‘Filter’ box at the top of the results page, but it didn’t seem to filter out the vulnerability in question. What does the ‘description’ operand refer to? The ‘PathName’ portion of the result?
I have to apologize, I’m answering your questions quickly in between tasks. I assumed that the service paths would be listed in the “description” section of the detection result.
Also note that the filter strings are case sensitive unless you use the regex option.
But this should be noted with the caveat - since all the service path detection are consolidated into a single result, using a filter would ignore even true positive results if these service paths are found. Therefore, this is not an advisable approach since it could block true positives whenever this service path is included in the result.
Finally, after inspecting the VT code, I would consider this to be a false positive and I will forward this question to the VT developers. I don’t see how unquoted arguments passed to the service path could be abused. In your case, it’s the agent service run and updater service run that trigger the detection. These are technically not the service path, but arguments being passed to the executable.
Thanks for the links to the resources - definitely helpful. One thing I did make a point to verify was the existence of other quoted service paths that are passed unquoted arguments - these do exist and didn’t trigger a detection, so possibly the word ‘service’ being included in the unquoted arguments (in this scenario) are contributing to it.
@JustinK I can verify that it is not the word “service” causing the false positive detection. Also, I can relay that there is currently an internal ticket to address the false positives triggered by this VT.
Once the VT is updated, it will be automatically included in a future feed update.
.
. I ran multiple command line/PS scripts again to check for such ‘unquoted’ paths but they all came back with no results..