"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) <[email protected]> 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:[email protected]] > Sent: Thursday, December 09, 2010 6:13 PM > To: Thor (Hammer of God); [email protected] > 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)" <[email protected]> >> Sent: Thursday, December 09, 2010 6:07 PM >> To: "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]> >> 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: [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/ > -- 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/
