Microsoft Windows 'Diagnostics Tracking' service privilege escalation

In May last year, Microsoft released a somewhat controversial update for Windows 7, Windows 8.1, Server 2008 and Server 2012 that introduced a feature already rolled out in Windows 10.  Microsoft summarised this as: “A tracking service that collects data about functional issues in Windows.” but many were concerned about the lack of information around what type of data were being sent back to Redmond. Some feathers were rightfully ruffled by this and folk were soon falling over themselves to turn it off.

Looking inside one of the dlls that the service uses gives you an idea of the kind of information being gathered:

So, just in case this doesn't bother you enough, then follow along..... :)

Back in 2012 an issue with the IKEEXT service was discovered that allowed - under certain circumstances a regular user to escalate to SYSTEM by taking advantage of a missing dll that was called for during the boot process. Microsoft never bothered to fix it, as technically, an ‘Out-Of-The-Box’ clean install of Windows wouldn't be vulnerable; rather it relied on installing some other software to introduce weak permissions into the %systempath%. The trouble is, this is quite common - especially in software that creates their program paths in the root of c:\ and fails to harden the default permissions (directories added in the root of c:\ give authenticated users write access).
Since then malware authors, bad guys and penetration testers alike have been abusing this to either privilege escalate (coming up) or have a convenient location to plant their files to be run at boot time, remain hidden and persistent.


For those not familiar with these kinds of bugs then have a read of this . These sorts of bugs are everywhere – especially within working directory paths -HD Moore released an awesome tool to find those.
You will often see 'dll high-jacking' and 'dll planting' used interchangeably; however, I think 'high-jacking' is best used for 'search order' issues and 'planting' for missing dlls. With that, let's continue with some dll planting...

I  disclosed this to Microsoft back in December and they responded back this week with the following response:
"They (MS) determined that this is a won't fix class issue.  The reason remains firm: it requires a user to have access to one of the PATH directories that requires admin.  The logic is, if you are already an admin you could do a lot more damage already"

I kind of expected this response, although considering the bad reputation this tracking service has I did for a moment think they might address it.


So, to start with, you will need to download Process Monitor from Sysinternals  and set up the following filter to catch calls for dlls that weren't found  by the System account:

You will also need a writeable location in your path to simulate the second part of the attack. If you have python installed you may already have one, but in this example I'm using another common example - Java. Certain versions of Java have been known to add a location in the system path (C:\ProgramData\Oracle\Java\JavaPath) that gives users write access to that folder. Modify the PATH variable like so:

Give yourself full permissions to the JavaPath directory and go back to process monitor and set it to enable boot logging: options ->enable boot logging.
Restart your machine and load up procmon again, you should get a popup asking you to save the data it captured during boot. It should then work its way through the file applying your filter.
Scrolling down the results you should see under the path column a number of requests to the javapath folder by the service host (svchost.exe). Once diagtrack.dll has been loaded there are three statically linked dlls that get called - but they don’t exist:

• diagtrack_wininternal.dll
• diagtrack_win.dll
• diagtrack_internal.dll

You should see these in procmon:

Looking inside diagtrack.dll you can see them be called for:

Now, I'm not sure why Microsoft didn't include these in the earlier Windows versions - I guess it was designed for Windows 10 then ported over:

Windows 10

So, all that's left for us to do now is ‘fix’ this poorly service and provide it with its missing dlls (because we’re kind folk right?)

You can use Metasploit to create dll payloads easy enough, or if you prefer: I've modified the ikeext_service module to work with this: just copy the module below into your /usr/share/metasploit-framework/modules/exploits/windows/local directory:

diagtrack_service.rb

Choose the correct architecture and writeable path and run it against a low-privileged Metasploit session. If the tracking service doesn't allow a restart by a regular user (default) then the module will restart the machine to carry out its task (so be aware!)

Recommendations?

I've not tried but i guess you could copy over the missing dlls from a windows 10 system. Or better still, just turn it off like so: