[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58DB1B68E62B9F448DF1A276B0886DF16EB6F2D9@EX2010.hammerofgod.com>
Date: Fri, 10 Dec 2010 02:05:58 +0000
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: "stenoplasma@...loitdevelopment.com" <stenoplasma@...loitdevelopment.com>,
"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)
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/
Powered by blists - more mailing lists