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)

[Peter Setlak <petersetlak () me com>]

Thor,

You know your M$ stuff. I wasn't sure of the specifics but yes, I was aware they are not the same actual account - that 
the local account no longer exists. What I was getting at was that if the username (Administrator) and password was the 
same across multiple machines, including domain admin, then user might be getting cornfused as to who they are actually 
authenticating as.

Peter Setlak
petersetlak () me com
(315) 371-6611

Skype Me! (Get Skype)

** SAVE A TREE!
(Please consider the environment before printing this email or its attachments...)

On Dec 13, 2010, at 3:56 PM, Thor (Hammer of God) wrote:

> To be pedantic, it is NOT the same account.  Let’s say you have a local computer, and you logon with 
> Administrator\password.  Let’s say you’ve EFS’d some files somewhere.
>  
> You then create a domain controller that is the first DC in the forest.   The local SAM is deleted, and Active 
> Directory is created.  The password you’ve set for local admin is now the password for the Domain admin.  However, 
> they are 2 different accounts.  Not only is there no SAM, there is no local admin.  If, as the Domain Admin, you try 
> to open the EFS files created when you were local admin, it will fail.  They are two different accounts, with 2 
> different SIDS. 
>  
> Regarding the “vulnerability,” this is strictly within the context of a local machine.  There’s no issue, but I’m 
> glad StenoPlasma posted this, and it truly shows how people should get their basics down.
>  
> t
>  
>  
> From: Peter Setlak [mailto:petersetlak () me com] 
> Sent: Monday, December 13, 2010 12:42 PM
> To: Thor (Hammer of God)
> Cc: Andrea Lee; George Carlson; bugtraq () 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)
>  
> Thor,
>  
> That's what I said - once that server becomes a DC, the local admin becomes the domain admin - it is the same account 
> - the local admin of a DC server IS the domain admin - i.e. the local admin account "goes away"... Unlike member 
> servers which keep their local admin and also allow domain admin to log in.
>  
> I'm just trying to find out what vulnerability (if any) is being talked about here - if perhaps the person was 
> cornfused and thought they logged in to a DC server as "local" admin.
>  
> Like I said, I probably shouldn't start adding to the mess half-way through the stream...
>  
> Peter Setlak
> petersetlak () me com
> (315) 371-6611
>  
> Skype Me! (Get Skype)
>  
> ** SAVE A TREE!
> (Please consider the environment before printing this email or its attachments...)
>  
> On Dec 13, 2010, at 3:20 PM, Thor (Hammer of God) wrote:
>
>
> There is no “local admin” on a DC.
>  
> t
>  
> From: Peter Setlak [mailto:petersetlak () me com] 
> Sent: Monday, December 13, 2010 12:06 PM
> To: Andrea Lee
> Cc: Thor (Hammer of God); George Carlson; bugtraq () 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)
>  
> ?
>  
> OK, wrap up, are we talking about Domain Admins having local admin privs? Of course they do - that's the joy of 
> having a domain, centralized management...
>  
> OR
>  
> Are we talking about local admins having domain admin privs?
>  
> The local admin would only have "temporary" domain admin privs if said local system was a DC. This is a given that 
> the DC's local admin has equiv to domain admin, thus, you can only log in to a DC as domain admin to begin with once 
> it has become a DC. I'm not sure of any situation where a local admin to say a member server would have domain admin 
> privs unless the local admin were to be added to the domain admins group on that machine. Which, of course, one would 
> need domain admin equiv privs in order to make such a change in the first place...
>  
> Perhaps in older, NT pre-SP4 boxes, if the local admin to all the boxes had the same username/password, and that same 
> username/password combo were to have been on the NT box prior to it becoming the PDC, and, in turn, after the NT box 
> became PDC, that username was added to the domain admins group then, perhaps all local admins across the domain would 
> share in the delight of being mistaken as a domain admin but even then, I just gave myself a headache - we are 
> talking pre or post WINS here? Are we getting workgroups confused with domains? Definitely, 2k and XP do not have 
> this issue as accounts are stored in the AD using SSID's which are unique across machines - so - even if machine A & 
> B & the DC had the same local admin username & password, local admin A doesn't have actual privs on B or the DC. It 
> may appear as such because the user would type in the same username/password combo, but, the account itself is just a 
> local admin on A, and B's is on B, and the DC, well, that is a domain admin (see above).
>  
> Maybe I should refrain from jumping in mid-thread?
>  
> Peter Setlak
> petersetlak () me com
> (315) 371-6611
>  
> Skype Me! (Get Skype)
>  
> ** SAVE A TREE!
> (Please consider the environment before printing this email or its attachments...)
>  
> On Dec 13, 2010, at 12:12 PM, Andrea Lee wrote:
>
>
>
> I hope I'm not just feeding the troll...
>
> 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..
>
> 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)
> <thor () 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-bounces () lists grok org uk [mailto:full-disclosure-
> bounces () lists grok org uk] On Behalf Of George Carlson
> Sent: Friday, December 10, 2010 10:12 AM
> To: bugtraq () 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.kanthak () nexgo de]
> Sent: Friday, December 10, 2010 11:30 AM
> To: bugtraq () securityfocus com; full-disclosure () lists grok org uk
> Cc: stenoplasma () 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/