Unquoted Service Path Enumeration Issue

I'm still very confused with your response.

The fix I posted works fine for our environment. That path may never change so you're asking about something that might never happen.

If and when it does, I will address it. We'll cross that bridge *IF* we get there.

At the moment , it works. That's our priority. Apply a fix to address the now. Who knows, in the near future Microsoft might publish a permanent fix.

I would much rather have a temporary fix that works now, than spend countless hours wasting my time trying to find a solution for a scenario that might never occur.

Good luck with your endeavours!

Alan,

I completely understand your issue, because in my past as both an administrator and later a security professional, I sat on both sides of this particular fence, with the primary difference being that as you've seen here, unlike many with the now ubiquitous CISSP tag, I was personally able to think.

Unfortunately, I've been unable to confirm my suspicion that the true problem is now resolved with these recent changes to privilege for both folders and registry, but if that's truly what Microsoft has done, I don't expect them to continue to support a need to quote the registry value.

However, expecting those other than Qualys (I was certified in their products) or other such organizations to understand something so apparently complex, but truly very simple, has been a problem for the industry forever, since it's apparently not possible for many of these supposedly trained people to actually read and understand the very documentation they're supposedly responsible for.

Please understand, I'm only a volunteer here and in no way official, I'm just utterly aghast at the types of people we choose to call security professionals nowadays and really think most of that structure needs to be purged and replaced with a more effective AI as quickly as possible before the US is destroyed by those taking advantage of the much more critical, relatively simple attacks these 'highly trained' individuals just plain don't understand.

In case it isn't clear, I spent hours carefully examining such technical information for the many financial and other customers I supported, trying to aid them in understanding which of these were truly critical and which could be safely set aside due to such convoluted or confusing details. The key difference being that my background as an administrator took precedence over the useless word 'compliance' that the now nearly pointless 'security profession' in the US lives by.

In truth 'compliance; is simply another word for 'pay up'.

Rob

Let me try this again after researching this old issue in more detail.

After reading up on the original issue it became clear that this particular vulnerability related specifically to the ability to write a file into the folder found at the path listed up to and including the portion preceding the space, named as the word immediately following the space and preceding the following slash "/" character.

In this particular example, that would be accomplished as follows:

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

C:\ProgramData\Microsoft\Windows[Defender.exe]

Examining this folder within my own much older Windows 10 system, I found it to only allow Read & Execute access to either the EVERYONE or Users groups, while both SYSTEM and Administrators of course have Full Control.

Since the focus of this particular vulnerability is to allow a local user to install a Trojan horse executable which is then used to gain privileges, it appears from what I found that this simply isn't possible, since the target folder itself would be unwritable unless a local user already had the Administrator privileges necessary to write into that specific folder.

However, if the corresponding registry item related to that same detection were able to be written by an unprivileged user, they might modify this path in order to point at another unprotected folder into which they could copy their Trojan executable, creating the same potential issue in reverse.

So from what I see, I'm guessing it's likely that at least with Windows 11, the folders containing critical driver files may have been better secured by default, precluding the ability for less privileged users to copy a Trojan, while along with this, the recent change in Windows 11 23r2 removes the ability for nearly anyone to modify these critical registry path entries as well.

In other words, it's not truly the way that Windows interprets the path that's the issue, but rather the ability to manipulate it and insert rogue files into the corresponding folder, so Microsoft has focused on removing those issues instead, first by securing the respective folders in Windows 10 and now by securing the potential manipulation of the registry entries pointing to their location in Windows 11 23r2.

Note that this is only my speculation, but it fits both what I'm seeing, and you are describing quite well.

I understand the potential issues this creates with auditing until this speculation is confirmed, but that's something I'd dealt with for many years with the relatively rigid structures these people operate within.

Rob

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

GOOD NEWS. It looks like the GPO solution I devised is working. Nessus is no longer reporting C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.23100.2009-0\MpDefenderCoreService.exe as an unquoted vulnerability

I had another idea but its a bit messy and I haven't tried it. Use powershell in a scheduled task to remotely change the registry on the affected machines every X minutes or hours or after the computer reboots or on logon. Like I said, I haven't tested it so do try and edit it accordingly

# List of remote computer names

$computers = "Computer1", "Computer2"

# Registry path

$registryPath = "HKLM:\SYSTEM\ControlSet001\Services\MDCoreSvc"

# ImagePath value

$imagePathValue = "C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.23100.2009-0\MpDefenderCoreService.exe"

# Script block to add the registry entry

$scriptBlock = {

**param($registryPath, $imagePathValue)** 

 ****     

**# Create a new registry key if it doesn't exist** 

**if (-not (Test-Path $registryPath)) {** 

    **New-Item -Path $registryPath -Force** 

**}** 

**# Set the ImagePath value** 

**Set-ItemProperty -Path $registryPath -Name "ImagePath" -Value $imagePathValue** 

}

# Use Invoke-Command to run the script block on each remote computer

Invoke-Command -ComputerName $computers -ScriptBlock $scriptBlock -ArgumentList $registryPath, $imagePathValue -Credential (Get-Credential)

Regards,

Michael

Rob,

Thanks for the reply.

If you use Procmon, you can see that services.exe checks the C:\ProgramData\Microsoft\Windows directory, but it doesn't try and load anything from it, it only loads C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.23100.2009-0\MpDefenderCoreService.exe

This would imply that the vulnerability isn't possible.

However, trying to explain that to a PCI Compliance assesor....you might as well smash your head against a brick wall.

I'm in the UK, whereby we get assesed under a Cyber Essentials Plus certification, and this is exactly one that would get flagged up.

Luckily, the CVSS for this is 6.8, where anything over 6.9 is an immediate fail, but if it was PCI, it's a fail.

As an admin with a bit of OCD, this grates on me, as I like to have every possible *potential* vulnerability resolved where possible.

As you mention...most of these assesors take the easy option, without understanding the true issue, but still, by quoting the service, it just wouldn't be an issue in the first place.

I very much doubt Microsoft will read or action this, and it is far too painful to raise a support issue with them also.

Alan