Message-ID: <AANLkTikuX-tC66BRi1huA0u74NneG33Da0_27Nku5UMN@mail.gmail.com>
Date: Thu, 9 Dec 2010 20:36:38 -0700
From: Mike Vasquez <mike@...ihax.com>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
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 can dump the local cached hashes, take a domain admins, and use a pass
the hash attack, which has been around for a while, such as:  Hernan Ochoa /
http://oss.coresecurity.com/projects/pshtoolkit.htm

I don't see this being any more concerning.  Whatever you do in the above,
is under the other account.  Granted, I may be missing something, so
enlighten me.


> -----Original Message-----
> From: Mike Hale [mailto:eyeronic.design@...il.com]
> Sent: Thursday, December 09, 2010 7:20 PM
> To: Thor (Hammer of God)
> Cc: StenoPlasma@...loitdevelopment.com; 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)
>
> "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/
>

Content of type "text/html" skipped

_______________________________________________
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