Home page logo
/

bugtraq logo Bugtraq mailing list archives

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)
From: Kurt Dillard <kurtdillard () msn com>
Date: Mon, 13 Dec 2010 16:09:00 -0300

So far I agree with Thor. Did I miss something? Has anyone demonstrated
using the locally cached credentials to access resources across the network?
So far I haven't seen anything new or interesting in this thread:

1. StenoPlasma claims that a local admin can access and reuse the cached
credentials of other users.
2. Stefan, Thor, et al yawn.
3. Joyce, Andrea, and perhaps others seem to be conflating local access
(what StenoPlasma was talking about) with gaining domain admin privileges on
domain controllers and other resources on separate machines (which nobody
appears to have shown is possible using locally cached credentials).

If I've missed something obvious please educate me.

Regards,

Kurt Dillard 




-----Original Message-----
From: kattrap () gmail com [mailto:kattrap () gmail com] On Behalf Of Andrea Lee
Sent: Monday, December 13, 2010 2:12 PM
To: Thor (Hammer of God)
Cc: 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)

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/



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault