Microsoft failed to fix InetMgr.exe autoelevation exploit. Looking on the fix they implemented it seems they do not understand the root of the problem.
InetMgr.exe from 14372 build.
Location: InetMgr.exe from system32\inetsrv folder.
General explanation: http://www.kernelmode.info/forum/viewto ... 167#p27167
The folder system32\inetsrv\ is EMPTY
by default. But InetMgr whitelisted and it full path hardcoded inside APPINFO in g_lpExemptedAutoApproveExes
Code: Select all
and used in AipInitializeSecureWindowsDirectories
InetMgr is part of IIS (nobody from target audience is using). This file and rest of IIS installed only by user request as additional Windows component.
So most of the time this folder is EMPTY.
As you see above on screenshot, MS hardcoded loading of one dll, so InetMgr will always load it from the given path. From EMPTY directory. Why?
InetMgr.exe component is compressed in DCS (Win10, DCN for win8/8.1) container format (see https://github.com/hfiref0x/SXSEXP
winsxs files expander) and stored in WinSxS folder. Nothing is preventing attacker from extracting it from there (or using copy) and moving it to the inetsrv directory (which will be empty by default). Next attacker will place there malicious dlls and do usual dll hijacking, and even use dll from that "fix". This is exactly what method 19 of uacme is doing.
There should be no simple way to write to this folder or InetMgr should not be auto-elevated.
as rinn suggested this fix is cumulative with sysprep fix of uacme #17, when MS expected similar technique to be used with InetMgr as target.