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"
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:
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:
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:
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:
Choose the correct architecture and writeable path and run it against an 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!)