Unquoted Service Path Enumeration Issue

Hi, Please see the solution I posted yesterday. It works for me. Regards, Michael

Hi, please see my solution which I posted yesterday. Regards, Michael

Hi,

I have had mixed success so far in adding quotes to C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.23110.3-0\MpDefenderCoreService.exe

Solutions for adding quotes to unquoted services. Some helpful resources for other Windows services

https://isgovern.com/blog/how-to-fix-the-windows-unquoted-service-path-vulnerability/ https://raw.githubusercontent.com/NetSecJedi/FixUnquotedPaths/master/FixUnquotedPaths.ps1

C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.23100.2009-0\MpDefenderCoreService.exe issues

The above solutions do not work for this service.

When I physically sit at the device and try to add the quotes into the device's registry details for this service, I get a permissions error that I cannot seem to get around

I can only add quotes to this service via remote registry for the device that is affected. But, after adding the quotes via remote registry, they are removed when the device reboots

Potential workaround

So I had an idea to automate the remote registry operation I was doing, by using a GPO and force a gpupdate using gpupdate/force

I will reply back with the results after a few days

Regards,

Michael

Alan,

Per your own investigation, I found this other thread in the Microsoft TechCommunity regarding this vulnerability that seems to confirm the basic problem still exists per the post I'm directing to via the following link.

Re: Windows Unquoted Service Path Enumeration - Is this still a case in modern Windows (10, 11) ? - Microsoft Community Hub

If you were to manually create a file named Defender.exe (that other poster renamed a copy of Calc.exe) within that ProgramData folder, you could prove whether the core path handling issue itself still exists, though proving that only an Administrator or another given that privilege could actually copy a file within that particular folder should provide proof as well.

After all, the ability to perform privilege escalation is the entire point of this vulnerability, thus anyone already having Administrator privilege simply has no reason to leverage this vulnerability in the first place.

I typically find that pure logic is the best way to cut the legs out from under someone using outdated information to support an argument.

However, if I were to choose an argument against Microsoft here, it would be that they should either provide proper documentation for the apparent fix(es) to Windows they've applied for this ancient vulnerability or simply assign someone to update the information relating to the official CVE documentation itself, since that's the actual problem all of you here are truly running up against.

In other words, this no longer appears to be a vulnerability, but rather simply inadequate documentation both from Microsoft as well as the CVE repository.

Rob

< EDIT > As a side note, I recall seeing a few threads here earlier this year where this same path enumeration issue was being abused using the 'Program.exe' file naming mentioned by the poster in that other thread.

I wonder if the changes to the registry modification and apparently related security changes to the core Windows folder structure we've discovered were in relation to that more recent abuse of the true vulnerability, rather than the legacy ones found in these 3 CVE references provided by the Nessus and Qualys scanning?

Rob,

I take your point, but at the end of the day, this is just sheer laziness and bad practice from Microsoft.

Every other Defender service is Quoted properly, but this "new" service isn't. No end user can fix this issue. You can....but will be unfixed on a reboot.

Yes, it may be that it isn't actually possible for the flagged vulnerability to actual be possible with *this* issue, but the end result is the same.....Both Qualys and Nessus flag this as an Unquoted service.

When audit time/PCI compliance etc comes around, with assesors it's a mixed bag on having to *prove* this being a false positive.

At the end of the day, Microsoft should as good practice have it Quoted, then this would never happen anyway.

Bottom line, Microsoft should resolve this issue......