Message-ID: <AANLkTi=OLHOCkWNzTXd=UPSfcfnp3xphiPCosCN+9LQt@mail.gmail.com>
Date: Thu, 9 Dec 2010 17:06:31 -0800
From: "StenoPlasma @ www.ExploitDevelopment.com"
	<exploitdevelopmentdotcom@...il.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Cc: stenoplasma@...loitdevelopment.com
Subject: 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/

Powered by blists - more mailing lists