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: [email protected] [mailto:full-disclosure- >[email protected]] On Behalf Of StenoPlasma @ >www.ExploitDevelopment.com >Sent: Thursday, December 09, 2010 5:07 PM >To: [email protected]; [email protected] >Cc: [email protected] >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/
