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)

[Mike Hale <eyeronic.design@xxxxxxxxx>]

"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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, December 09, 2010 6:13 PM
> To: Thor (Hammer of God); full-disclosure@xxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx>
>> Sent: Thursday, December 09, 2010 6:07 PM
>> To: "stenoplasma@xxxxxxxxxxxxxxxxxxxxxx"
> <stenoplasma@xxxxxxxxxxxxxxxxxxxxxx>, "full-disclosure@xxxxxxxxxxxxxxxxx"
> <full-disclosure@xxxxxxxxxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxx
> [mailto:full-disclosure-
>> >bounces@xxxxxxxxxxxxxxxxx] On Behalf Of StenoPlasma @
>> >www.ExploitDevelopment.com
>> >Sent: Thursday, December 09, 2010 5:07 PM
>> >To: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx
>> >Cc: stenoplasma@xxxxxxxxxxxxxxxxxxxxxx
>> >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/