While performing registry queries for something not exactly related, I saw an application on my personal machine with an unquoted service path.  Since this is a commonly used application, I've contacted the developer and I've submitted the CVE to secure an ID -- that whole "responsible disclosure" thing.  Seriously though, this isn't an obscure application and I would go so far as to say it's heavily used.  The mitigation technique would be to quote the path but that's something the average user wouldn't be capable of doing.  So while we wait, I'll explain the problem in detail.

Here we have the Google Update Service.  When we look at the Path to the executable, we see:  "C:\Program Files\Google\Update\GoogleUpdate.exe"

That is a quoted service path.  





Now we look at another application that has an unquoted service path:

It's literally missing the open and close double quotes.  Before I explain why this is a problem, let me show you a quick way of finding these little gems:

Normally, I'd use a longer string but it ran off the screen too far and it wrapped funny.  Regardless, you can see how it's easy to isolate what we want in the vast number of quoted services.

Before I press on, let me say that in order to successfully exploit this vulnerability, there are some variables that need to exist like the ability write into c:\ or c:\program files which is unlikely.  But maybe permissions are incorrectly?  Then we lead into...

Here's the problem, when it's unquoted, Windows will attempt to guess the location.  First, it will look for c:\Program.exe

Next, it will look for c:\Program File\LightManagerFree.exe

And so forth until it finds a match. 

If we drop a reverse shell into one of those locations where Windows is hunting, we can restart the service, or reboot the system, to get our shell to pop.

With our handler setup:

We're going to set auto migrate because the service will fail and our shell not long after.  Truth is, we don't need to auto migrate because we would have enough time to get to a prompt and paste the following:

net user vince p4ssw0rd /add && net localgroup administrators vince /add

Or if you're a regular user and you're just escalating, you only need the portion where you add your account to the local administrators group.  

Anyway, moving on to how I'm going about it, we run, we restart the service, and:

And here's where the service fails but we've already migrated.

Granted, someone is complaining that I'm using a meterpreter shell and there's no a/v on this system.  That's true -- so let's go about it another way.  Here we have a PowerShell reverse shell:

Using this handy tool from Microsoft, we can convert our PowerShell to an executable.  What's even more interesting is that we eliminate the ExecutionPolicy annoyance. 

We feed it our PowerShell, the output name, and we hit Compile:

When it's finished compiling:

We move this into the root of C :

We change our payload in Metasploit:

We run and we restart the service:

This one won't auto migrate so you need to move quickly.  Or go about it another way -- there are a number of ways.

But wait, still no a/v... I know. 

We place the two malicious files into a folder:

When we scan the folder and the meterpreter shell gets snagged but the other remains.  It's just PowerShell and what could be wrong with that???  :|

Instead of scanning the folder, I scan the file specifically and still:

It's kind of interesting because I put the Program.exe file in the root of C again and the a/v didn't even blink.  I then restarted the service, caught my shell but then the a/v thought something was suspicious and alerted me.  I'm thinking this was because it was in root and suspicious because I moved it into Program Files as LiteManagerFree.exe :

When I restarted the service, the a/v did NOT trigger this time and:

This is a local privilege escalation technique which means you're ON the local machine.  You have plenty of time to work out the oddities of your malicious executable, the system, and the a/v.  Not all are the same.  We were previously using a different a/v product until I repeatedly evaded it effortlessly.  We don't use Avast but it's solid... and free.  Obviously, I got around it but it takes some work.  We just need to find the right combination of this and that.