Message-ID: <1C78A670E0209548BE6F28FA7A882215278578C0@QNBE3.qnb.com>
Date: Mon, 13 Dec 2010 14:03:54 -0500
From: Steve Cobb <SCOBB@....com>
To: "'jcoyle@...wholesale.com'" <jcoyle@...wholesale.com>, Stefan Kanthak
	<stefan.kanthak@...go.de>
Cc: "stenoplasma@...loitdevelopment.com" <stenoplasma@...loitdevelopment.com>,
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.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)

Since when do local admins become domain admins!?!?!?!?!

Domain Admins are added to the Local Admins group when a computer joins a network. How do Local Admins on a computer become Domain Admins!?!?!!?!?
 
-----Original Message-----
From: jcoyle@...wholesale.com [mailto:jcoyle@...wholesale.com] 
Sent: Friday, December 10, 2010 2:45 PM
To: Stefan Kanthak
Cc: bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk; stenoplasma@...loitdevelopment.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)

You are completely missing the point..
Local admins become Domain Admins.





From:       "Stefan Kanthak" <stefan.kanthak@...go.de>
To:         <bugtraq@...urityfocus.com>,
            <full-disclosure@...ts.grok.org.uk>
Cc:         <stenoplasma@...loitdevelopment.com>
Date:       12/10/2010 01:08 PM
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




*********************************************************************************************
This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information.  If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies.  All unauthorized direct or indirect use or disclosure of this message is strictly prohibited.  No right to confidentiality or privilege is waived or lost by any error in transmission. 
*********************************************************************************************

-------
DISCLAIMER: This e-mail and any files transmitted with it are intended only for the use of the addressee and may contain information that is legally privileged and confidential. The e-mail may not be forwarded without permission of the sender. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. Please notify the sender electronically or by telephone immediately by calling QNB Bank at 800-491-9070 if you have received this e-mail in error.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists