Message-ID: <AANLkTi=9QUbkq__zFaQ9uGbK_i9vzSgBPRqoD8j5wr_M@mail.gmail.com>
Date: Thu, 9 Dec 2010 19:20:25 -0800
From: Mike Hale <eyeronic.design@...il.com>
To: "Thor (Hammer of God)" <thor@...merofgod.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"StenoPlasma@...loitdevelopment.com" <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)

"In fact, I can just make the Domain Admin a "guest" on my workstation
if I want to and there is nothing they can do about it."
With the caveat that they can readd themselves using GP anytime they
want...but you know.  I just wanted to throw that out there.

I think the key vulnerability in this is the non-repudiation one the
OP mentioned.  Being able to run stuff under the domain admin's
account is something a rogue user could potential abuse.

I don't think this issue is particularly critical, but something a
good admin should be aware of, IMO.

On Thu, Dec 9, 2010 at 7:07 PM, Thor (Hammer of God)
<thor@...merofgod.com> wrote:
> What do you mean by "regular local administrator"?  You're a local admin, or you're not.  There are not degrees of local admin.  Why are you under the impression that there are things on a local system that the local admin should not have access to?  They can do anything they want to by design.  Are you under the impression that the Domain Administrator has different permissions on a local machine than the local administrator does?   The only reason a Domain Admin has admin rights by default on a domain workstation is because they simply belong to the local Administrators group.  If I, as a local admin, remove the domain admin account from my local Administrators group, then they will not be local admins.  In fact, I can just make the Domain Admin a "guest" on my workstation if I want to and there is nothing they can do about it.
>
> Sorry to be the bearer of bad news for you, but the local admin can do what they want to by design, and there is nothing that was "not intended by the software developer" here.  This is, of course, why the people at MSFT dismissed it as noted.
>
> t
>
> -----Original Message-----
> From: StenoPlasma @ ExploitDevelopment [mailto:StenoPlasma@...loitdevelopment.com]
> Sent: Thursday, December 09, 2010 6:13 PM
> To: Thor (Hammer of God); full-disclosure@...ts.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)
>
> T,
>
> My article describes how to use the SECURITY registry hive to trick the Microsoft operating system in to performing an action that has a result that is not intended by the software developer.  This action is performed on the Active Directory logon account cache that regular local administrators should not have access to.  There are always other ways of doing things when it comes to this type of work.
>
>
> Thank you,
>
> -----------------------------------------------------
> StenoPlasma at ExploitDevelopment.com
> www.ExploitDevelopment.com
> -----------------------------------------------------
>
> -------- Original Message --------
>> From: "Thor (Hammer of God)" <thor@...merofgod.com>
>> Sent: Thursday, December 09, 2010 6:07 PM
>> To: "stenoplasma@...loitdevelopment.com"
> <stenoplasma@...loitdevelopment.com>, "full-disclosure@...ts.grok.org.uk"
> <full-disclosure@...ts.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)
>>
>> Why all the trouble?  Just change the log files directly when logged
>> in
> as the local admin.  It's a whole lot simpler, and you don't even need the domain administrator to have interactively logged into your workstation.
> Or is your point that local administrators are, um, local administrators?
>>
>> t
>>
>> >-----Original Message-----
>> >From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-
>> >bounces@...ts.grok.org.uk] On Behalf Of StenoPlasma @
>> >www.ExploitDevelopment.com
>> >Sent: Thursday, December 09, 2010 5:07 PM
>> >To: bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
>> >Cc: stenoplasma@...loitdevelopment.com
>> >Subject: [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)
>> >
>>
>>-----------------------------------------------------------------------
>>---
>
>
>> >www.ExploitDevelopment.com 2010-M$-002
>>
>>-----------------------------------------------------------------------
>>---
>
>
>> >
>> >TITLE:
>> >Flaw in Microsoft Domain Account Caching Allows Local Workstation
>> >Admins
> to
>> >Temporarily Escalate Privileges and Login as Cached Domain Admin
> Accounts
>> >
>> >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.
>> >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. This
> includes
>> >creating scripts to run as the Domain Admin account the next time
>> >that
> they
>> >log in. All files created will not be linked to your domain account
>> >in
> file and
>> >folder access lists. 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).
>> >
>> >DETAILS:
>> >Prerequisites to exploit:
>> >
>> >#1: The user has a "Domain User" account that has administrative
> privileges on
>> >his/her workstation (This is a common configuration for both small
>> >and enterprise networks).
>> >#2: The Microsoft Windows Active Directory domain has not disabled
>> >the
> use
>> >of Group Policy "Interactive logon: Number of previous logons to
>> >cache
> (in
>> >case domain controller is not available)". The default value for this
> setting is
>> >"10 logons".
>> >#3: A domain/enterprise/schema/privileged administrator has logged in
>> >to
> the
>> >user's workstation at any time in the past (It would be very
>> >difficult
> to not
>> >have some type of admin from the domain login to a workstation for a
>> >number of reasons).
>> >
>> >Use the following steps to exploit this vulnerability:
>> >
>> >Step 1: Log in to your workstation using your Active Directory domain
> account.
>> >This account only needs to have administrative access to your
> workstation.
>> >Step 2: Create an interactive scheduled task to run a minute after
> creating it.
>> >This scheduled task brings up a command prompt as the NT
> Authority\SYSTEM
>> >account on Windows XP, and 2003. 'at 11:24 /interactive cmd.exe'. If
> using
>> >Windows Vista, 7, or 2008 Server, the attacker can use the psexec
>> >tool
> (psexec
>> >-i -s cmd.exe).
>> >Step 3: Once the SYSTEM command prompt comes up, open regedit from
>> >the command line.
>> >Step 4: Browse to 'HKEY_LOCAL_MACHINE\SECURITY\Cache'
>> >Step 5: The list of "NL$1-10" records contain the cached active
> directory
>> >domain account sessions. To identify which account is yours, perform
> the
>> >following steps. Take note of all NL$ entries and entry content.
>> >Change
> your
>> >domain account password. Leave the SYSTEM shell and regedit
>> >application open. Log off the workstation, and then log back in to
>> >your domain
> account.
>> >Refresh the NL$ list. The NL$ line item that has been updated is your
> domain
>> >user's cached session.
>> >Step 6: For this example, we will assume that your NL$ record is "NL$4"
>> >Step 7: Double click on "NL$4". Take note of the four hex characters
> that are
>> >located in positions 1, 2, 3, and 4 on line 3 of the hex data.
>> >Step 8: For this example, the hex characters are "5a 04". This number
>> >is
> the
>> >Active Directory octet string representation of your domain account's
>> >objectSID (The user account unique section of your AD Security
> Identifier).
>> >Step 9: For this example, there is only one other cached account
>> >listed
> in the
>> >NL$ listing (NL$3). Double click on "NL$3". Take note of the four hex
> characters
>> >that are located in positions 1, 2, 3, and 4 on line 3 of the hex data.
>> >Step 10: For this example, the hex characters are "59 04". This user
> account is
>> >"Domain\DomainAdminAcct".
>> >Step 11: Double click on "NL$4". Replace your SID hex representation
>> >"5a
> 04",
>> >with DomainAdminAcct's SID hex representation "59 04".
>> >Step 12: *Important* Disconnect all physical network connections from
> the
>> >workstation.
>> >Step 13: Log off of the domain account, then log back in to your
>> >domain account.
>> >Step 14: You will now be logged in to your modified cached account
>> >that
> is
>> >really the Domain Admin's account.
>> >Step 15: You are now free to modify system files and user account
> profiles
>> >using the identity of the Domain Admin's account. This includes
> creating
>> >scripts to run as the Domain Admin account the next time that they
>> >log
> in. All
>> >files created will not be linked to your domain account. All security
> access lists
>> >will only show the Domain Admin's account once you log out of the
> modified
>> >cached account.
>> >Step 16: All actions taken are indeed logged in the Security Event
>> >Log,
> but all
>> >actions are shown as being completed by "Domain\DomainAdminAcct".
>> >Deeper inspection of event logs will show inside the login and logout
> events
>> >for your modified cached account, your actual user name is listed
>> >inside
> the
>> >event, but not in the Security Event Log Viewer listing. 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). These
> events will
>> >be listed as being performed as "Domain\DomainAdminAcct" in the event
> log
>> >viewer, but deeper inspection will show your true user name.
>> >
>> >VULNERABLE PRODUCTS:
>> >All patch levels of Windows 2003 Server, Windows XP, Windows Vista,
>> >Windows 7, and Windows 2008 Server.
>> >
>> >REFERENCES AND ADDITIONAL INFORMATION:
>> >N/A
>> >
>> >CREDITS:
>> >StenoPlasma (at) ExploitDevelopment.com
>> >
>> >TIMELINE:
>> >Discovery: December 4, 2010
>> >Vendor Notified: December 7, 2010
>> >Vendor Fixed: N/A
>> >Vendor Dismissed: December 9, 2010
>> >Vendor Notified of Disclosure: December 9, 2010
>> >Disclosed: December 9, 2010
>> >
>> >VENDOR URL:
>> >http://www.microsoft.com
>> >
>> >ADVISORY URL:
>> >http://www.ExploitDevelopment.com/Vulnerabilities/2010-M$-002.html
>> >
>> >VENDOR ADVISORY URL:
>> >N/A
>> >
>> >
>> >-------------------------------------------------------------
>> >StenoPlasma at ExploitDevelopment.com www.ExploitDevelopment.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/
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

_______________________________________________
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