Exploit the possiblities

Microsoft Windows COM Session Moniker Privilege Escalation

Microsoft Windows COM Session Moniker Privilege Escalation
Posted Jul 14, 2017
Authored by James Forshaw, Google Security Research | Site metasploit.com

Microsoft Windows has a bad fix for the COM session moniker that can allow for elevation of privilege.

tags | advisory
systems | windows
advisories | CVE-2017-0298
MD5 | 3415ad73c8d69869f7f6b54856151c87

Microsoft Windows COM Session Moniker Privilege Escalation

Change Mirror Download
Windows: Bad Fix for COM Session Moniker EoP 

CVE-2017-0298


Windows: Bad Fix for COM Session Moniker EoP

So....

The previous fix for CVE-2017-0100 sounds wrong on the face of it. Rather than fixing the underlying Session creation bug you "fixed" the HxHelpPane class. Even if this was a correct fix ultimately it just requires you to find an alternative COM object to abuse.

However looking at the fix in HelpPane.exe you can see that the fix isn't actually sufficient. The bug is in the check.

if ( imp_token_il >= process_token_il
&& (imp_token_il >= SECURITY_MANDATORY_HIGH_RID
|| EqualSid(process_token_user, imp_token_user)))
{
ShellExecuteW(NULL, L"open", path, NULL, NULL, SW_SHOW);
}

This first checks if the impersonation token IL is < process token IL which is to prevent a sandbox escape. However we then get a new check, it will also fail if the process user is not the same as the impersonation user AND the impersonation token IL is < High. This is the problem. IL is not generally considered much of a security boundary as it doesn't indicate a user is an administrator, it just indicates that user has a High IL.

Confused? Well one case where a user will gain an elevated IL is in UAC elevation. While administrators will get High IL so will UI Access programs. Unfortunately UI access programs are easy for a normal user to hijack (in the general case). For example <a href="https://bugs.chromium.org/p/project-zero/issues/detail?id=220" title="" class="" rel="nofollow">https://bugs.chromium.org/p/project-zero/issues/detail?id=220</a> was never fixed down level so Windows 7 and 8.X are vulnerable to a normal user being able to get trivial UI access execution (and by extension Win2008 and 2012 servers). Even on Windows 10 where this is fixed (AFAIK) there's still alternative ways of getting UI access execution through DosDevices abuse to hijack DLL loading of a valid UI access binary.

Now of course you only get High IL when running as a split token admin (which means there's ways to just get admin on those machines anyway) but for a normal user you only get Medium + 16. However I'd draw your attention to comment 4 in the previously linked report. You can ratchet the IL up in 16 byte increments if you control the process as the logic of UI access elevation is it will increase IL if UI access is not enabled on the token. As turning off UI access is a non-privileged operation (though setting to true is privileged) then you can spawn the UI access process, turn off UI access in the token then respawn adding another 16 to the IL until you reach High IL. It's just case of doing this through whatever means are available.

Perhaps this is just due to trying to avoid some compatibility issue I don't know about, or just represents a misunderstanding of Windows security. Either way it really should probably bypass the user check only if the token has the administrators group. Ideally you'd fix the session issue itself, but that is clearly too hard a task.

Also before you say this is a UAC bypass, just don't even start on that. I warned you about this sort of behavior with things like UI access and the IL ratchet before and you ignored it.

I've not provided a PoC as imo the bug is self evident. I've proven it myself manually, at least on Windows 7. If you _really_ need me to prove it with a PoC I will.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.




Found by: forshaw

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

November 2017

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    22 Files
  • 2
    Nov 2nd
    28 Files
  • 3
    Nov 3rd
    10 Files
  • 4
    Nov 4th
    1 Files
  • 5
    Nov 5th
    5 Files
  • 6
    Nov 6th
    15 Files
  • 7
    Nov 7th
    15 Files
  • 8
    Nov 8th
    13 Files
  • 9
    Nov 9th
    9 Files
  • 10
    Nov 10th
    9 Files
  • 11
    Nov 11th
    3 Files
  • 12
    Nov 12th
    2 Files
  • 13
    Nov 13th
    15 Files
  • 14
    Nov 14th
    17 Files
  • 15
    Nov 15th
    19 Files
  • 16
    Nov 16th
    15 Files
  • 17
    Nov 17th
    19 Files
  • 18
    Nov 18th
    0 Files
  • 19
    Nov 19th
    0 Files
  • 20
    Nov 20th
    0 Files
  • 21
    Nov 21st
    0 Files
  • 22
    Nov 22nd
    0 Files
  • 23
    Nov 23rd
    0 Files
  • 24
    Nov 24th
    0 Files
  • 25
    Nov 25th
    0 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    0 Files
  • 28
    Nov 28th
    0 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close