>-----Original Message----- >From: katt...@gmail.com [mailto:katt...@gmail.com] On Behalf Of Andrea >Lee >Sent: Monday, December 13, 2010 9:12 AM >To: Thor (Hammer of God) >Cc: George Carlson; bugt...@securityfocus.com; full- >disclos...@lists.grok.org.uk >Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows >Local Workstation Admins to Temporarily Escalate Privileges and Login as >Cached Domain Admin Accounts (2010-M$-002) > >I hope I'm not just feeding the troll...
No, you are perpetuating inaccurate vulnerability claims. >A local admin is an admin on one system. The domain admin is an admin on all >systems in the domain, including mission critical Windows servers. With >temporary domain admin privs, the local admin could log into the AD and >change permissions / passwords for another user or another user, thus >getting full admin rights on all systems for a long period of time. Plus >whatever >havoc might be caused by having the ability to change rights on fileshares to >allow the new domain admin to see confidential files.. People, PLEASE at least take the time to read the OP before just adding comments. You don't get any "temporary domain admin privileges." Period. Authenticating against cached domain credentials on a local system cannot be used for ANYTHING other than logging on to the local system when a controller is not available. Period. Now, please read this part carefully: *You must be a local administrator to use utilities to overwrite the cached verifier of cached credentials.* The most you can do is to allow yourself to log on as an account that has local admin. YOU ARE ALREADY A LOCAL ADMIN AT THIS POINT. 1) You MUST be local admin to access the cached domain credentials. 2) You can't log on to any network resources as the cached user. 3) You can't long on to another workstation as the cached user. 4) You can't access any EFS or other user-based data as the cached user. 5) Bottom line, you can't do a single thing more than you could already do. If anyone still thinks you this has any escalation properties at all, then try it yourselves. t >I would expect that the intent is to use another flaw for a normal user to >become a local admin, and then jump to domain admin via this. > >So yes. In an enterprise environment, the "domain administrator" is "bigger". > >Cheers, > >On Fri, Dec 10, 2010 at 4:15 PM, Thor (Hammer of God) ><t...@hammerofgod.com> wrote: >> Wow. I guess you didn't read the post either. I'm a bit surprised that a >> Sr. >Network Engineer thinks that Group Policies "differentiate between local and >Domain administrators." You're making it sound like you think Group Policy >application has some "magic permissions" or something, or that a "domain >administrator" is a "bigger" administrator than the local administrator. >> >> Group Policy loads from the client via the Group Policy Client service. If >> I'm >a local admin, I can just set my local system to not process group policy via >the >GPExtensions hive. Done. If I take the domain admin out of my local >administrators, they can't do anything. Done. >> >> How exactly do you think this is problematic for "shops that differentiate >between desktop support and AD support"? (whatever that means). >> >> t >> >>>-----Original Message----- >>>From: full-disclosure-boun...@lists.grok.org.uk >>>[mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of >>>George Carlson >>>Sent: Friday, December 10, 2010 10:12 AM >>>To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk >>>Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account >>>Caching Allows Local Workstation Admins to Temporarily Escalate >>>Privileges and Login as Cached Domain Admin Accounts (2010-M$-002) >>> >>>Your objections are mostly true in a normal sense. However, it is not >>>true when Group Policy is taken into account. Group Policies >>>differentiate between local and Domain administrators and so this >>>vulnerability is problematic for shops that differentiate between >>>desktop support and AD support. >>> >>> >>>George Carlson >>>Sr. Network Engineer >>>(804) 423-7430 >>> >>> >>>-----Original Message----- >>>From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] >>>Sent: Friday, December 10, 2010 11:30 AM >>>To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk >>>Cc: stenopla...@exploitdevelopment.com >>>Subject: Re: Flaw in Microsoft Domain Account Caching Allows Local >>>Workstation Admins to Temporarily Escalate Privileges and Login as >>>Cached Domain Admin Accounts (2010-M$-002) >>> >>>"StenoPlasma @ www.ExploitDevelopment.com" wrote: >>> >>>Much ado about nothing! >>> >>>> TITLE: >>>> Flaw in Microsoft Domain Account Caching Allows Local Workstation >>>> Admins to Temporarily Escalate Privileges and Login as Cached Domain >>>> Admin Accounts >>> >>>There is NO privilege escalation. A local administrator is an >>>admistrator is an administrator... >>> >>>> SUMMARY AND IMPACT: >>>> All versions of Microsoft Windows operating systems allow real-time >>>> modifications to the Active Directory cached accounts listing stored >>>> on all Active Directory domain workstations and servers. This allows >>>> domain users that have local administrator privileges on domain >>>> assets to modify their cached accounts to masquerade as other domain >>>> users that have logged in to those domain assets. This will allow >>>> local administrators to temporarily escalate their domain privileges >>>> on domain workstations or servers. >>> >>>Wrong. The local administrator is already local administrator. There's >>>nothing the elevate any more. >>> >>>> If the local administrator masquerades as an Active Directory Domain >>>> Admin account, the modified cached account is now free to modify >>>> system files and user account profiles using the identity of the >>>> Domain Admin's account. >>> >>>There is no need to masquerade: the local administrator can perform >>>all these modifications, and if s/he wishes, hide the tracks: turn off >>>auditing before, clear audit/event logs afterwards, change the SID in >>>the ACEs of all objects touched (SubInACL.Exe comes handy), ... >>> >>>Or: just change the "NoDefaultAdminOwner" setting. After that, all >>>"Administrators" masquerade as "Administrators". uh-oh. >>> >>>> This includes >>>> creating scripts to run as the Domain Admin account the next time >>>> that they log in. >>> >>>Ridiculous. >>>A local administrator can add any script/executable s/he wants to any >>>"autostart" (scheduled task, registry, logon script, userinit, shell, ...). >>>There's ABSOLUTELY no need to masquerade. >>> >>>> All files created will not be linked to your domain account in file >>>> and folder access lists. >>> >>>ACEs can always be edited by a local administrator, see SubInACL.Exe, >>>or TakeOwn.Exe. >>> >>>> All security access lists >>>> will only show the Domain Admin's account once you log out of the >>>> modified cached account. This leads to a number of security issues >>>> that I will not attempt to identify in the article. One major issue >>>> is the lack of non-repudiation. Editing files and other actions will >>>> be completed as another user account. Event log entries for object >>>> access will only be created if administrators are auditing >>>> successful access to files (This will lead to enormous event log sizes). >>> >>>A local administrator can turn audit/event logs off, clear or modify them. >>> >>>Stefan >>> >>>_______________________________________________ >>>Full-Disclosure - We believe in it. >>>Charter: http://lists.grok.org.uk/full-disclosure-charter.html >>>Hosted and sponsored by Secunia - http://secunia.com/ >> _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
