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)
Correct me if I'm wrong, but here is what I think of that : A Domain user that is a Local admin of his workstation is different than a Domain user which is Domain Admin. Then, a local admin whose account is an AD account can run scripts *on his local machine* in the name of the domain admin. This includes the possibility of dumping the Domain Admin password hash and even *all the domain accounts password hashes* (ie: psexec + pwdump against the DC, with the privileges of the domain admin). An exploitation scenario could be the following for an unprivileged domain user: - Become local admin of his workstation (bunch of methods out there) - Run script ad the Domain Admin with this technique) - Recover Domain admin or Domain Users password hashes. - Crack the passwords and become Domain Admin (ie: Administrator of all workstations and servers in the domain). My two cents ! J- On 10/12/2010 15:37, Jeffrey Walton wrote: On Thu, Dec 9, 2010 at 10:07 PM, Thor (Hammer of God) t...@hammerofgod.com wrote: What do you mean by regular local administrator? You're a local admin, or you're not. I believe the OP's intent was to differentiate between Local Administrators and Domain (or Enterprise) Administrators. Corrections from StenoPlasma are welcomed. There are not degrees of local admin. But there are different accounts, both domain and local, which have administrator rights and privileges on the local machine. [SNIP] Jeff ___ 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/
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)
If a bad guy got the local admin password, then the computer is in it's control at 100%. No need to run script as a domain user, as the local admin can already format the drive, or remove all security mesure. The cached credential is a hash of a hash. (kinda long to crack) Any good network admin would use a account that can only join a computer in the domain, and use the local admin account to install software or a helpdesk account that got local admin right. The only case maybe that case is a security hole that I can think of, I told maybe because I didn't tested it. It's if the computer got a local mssql with mixed mode authentification. Does the trick permit the login to the database if you installed it with a domain user, that is cached on the computer? (But who care, as the local admin can just copy the data dir anyway) My .02 cent -phil Correct me if I'm wrong, but here is what I think of that : A Domain user that is a Local admin of his workstation is different than a Domain user which is Domain Admin. Then, a local admin whose account is an AD account can run scripts *on his local machine* in the name of the domain admin. This includes the possibility of dumping the Domain Admin password hash and even *all the domain accounts password hashes* (ie: psexec + pwdump against the DC, with the privileges of the domain admin). An exploitation scenario could be the following for an unprivileged domain user: - Become local admin of his workstation (bunch of methods out there) - Run script ad the Domain Admin with this technique) - Recover Domain admin or Domain Users password hashes. - Crack the passwords and become Domain Admin (ie: Administrator of all workstations and servers in the domain). My two cents ! J- On 10/12/2010 15:37, Jeffrey Walton wrote: On Thu, Dec 9, 2010 at 10:07 PM, Thor (Hammer of God) t...@hammerofgod.com wrote: What do you mean by regular local administrator? You're a local admin, or you're not. I believe the OP's intent was to differentiate between Local Administrators and Domain (or Enterprise) Administrators. Corrections from StenoPlasma are welcomed. There are not degrees of local admin. But there are different accounts, both domain and local, which have administrator rights and privileges on the local machine. [SNIP] Jeff ___ 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/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
Jeremy SAINTOT jeremy.sain...@gmail.com wrote: Correct me if I'm wrong, but here is what I think of that : You are wrong! A Domain user that is a Local admin of his workstation is different than a Domain user which is Domain Admin. A local administrator has all the powers on his computer, while a domain administrator as all the powers in the domain/AD. Typically domain administrators are members of the Administrators group too. Then, a local admin whose account is an AD account can run scripts *on his local machine* in the name of the domain admin. Right. The local machine but MUST NOT be able to query the AD, else the cached credentials are not used. This includes the possibility of dumping the Domain Admin password hash and even *all the domain accounts password hashes* (ie: psexec + pwdump against the DC, with the privileges of the domain admin). WRONG! Read the OP again. CAREFULLY. The computer needs to be unplugged from the network. There is NO POSSIBILITY to access OTHER domain members with cached credentials. An exploitation scenario could be the following for an unprivileged domain user: - Become local admin of his workstation (bunch of methods out there) - Run script ad the Domain Admin with this technique) - Recover Domain admin or Domain Users password hashes. - Crack the passwords and become Domain Admin (ie: Administrator of all workstations and servers in the domain). My two cents ! That's inflation: 2 cents worth nothing. Stefan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
-Original Message- From: katt...@gmail.com [mailto:katt...@gmail.com] On Behalf Of Andrea Lee Sent: Monday, December 13, 2010 9:12 AM To: Thor (Hammer of God) Cc: George Carlson; bugt...@securityfocus.com; full- disclos...@lists.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) I hope I'm not just feeding the troll... No, you are perpetuating inaccurate vulnerability claims. A local admin is an admin on one system. The domain admin is an admin on all systems in the domain, including mission critical Windows servers. With temporary domain admin privs, the local admin could log into the AD and change permissions / passwords for another user or another user, thus getting full admin rights on all systems for a long period of time. Plus whatever havoc might be caused by having the ability to change rights on fileshares to allow the new domain admin to see confidential files.. People, PLEASE at least take the time to read the OP before just adding comments. You don't get any temporary domain admin privileges. Period. Authenticating against cached domain credentials on a local system cannot be used for ANYTHING other than logging on to the local system when a controller is not available. Period. Now, please read this part carefully: *You must be a local administrator to use utilities to overwrite the cached verifier of cached credentials.* The most you can do is to allow yourself to log on as an account that has local admin. YOU ARE ALREADY A LOCAL ADMIN AT THIS POINT. 1) You MUST be local admin to access the cached domain credentials. 2) You can't log on to any network resources as the cached user. 3) You can't long on to another workstation as the cached user. 4) You can't access any EFS or other user-based data as the cached user. 5) Bottom line, you can't do a single thing more than you could already do. If anyone still thinks you this has any escalation properties at all, then try it yourselves. t I would expect that the intent is to use another flaw for a normal user to become a local admin, and then jump to domain admin via this. So yes. In an enterprise environment, the domain administrator is bigger. Cheers, On Fri, Dec 10, 2010 at 4:15 PM, Thor (Hammer of God) t...@hammerofgod.com wrote: Wow. I guess you didn't read the post either. I'm a bit surprised that a Sr. Network Engineer thinks that Group Policies differentiate between local and Domain administrators. You're making it sound like you think Group Policy application has some magic permissions or something, or that a domain administrator is a bigger administrator than the local administrator. Group Policy loads from the client via the Group Policy Client service. If I'm a local admin, I can just set my local system to not process group policy via the GPExtensions hive. Done. If I take the domain admin out of my local administrators, they can't do anything. Done. How exactly do you think this is problematic for shops that differentiate between desktop support and AD support? (whatever that means). t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of George Carlson Sent: Friday, December 10, 2010 10:12 AM To: bugt...@securityfocus.com; full-disclosure@lists.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) Your objections are mostly true in a normal sense. However, it is not true when Group Policy is taken into account. Group Policies differentiate between local and Domain administrators and so this vulnerability is problematic for shops that differentiate between desktop support and AD support. George Carlson Sr. Network Engineer (804) 423-7430 -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Friday, December 10, 2010 11:30 AM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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.
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)
I hope I'm not just feeding the troll... A local admin is an admin on one system. The domain admin is an admin on all systems in the domain, including mission critical Windows servers. With temporary domain admin privs, the local admin could log into the AD and change permissions / passwords for another user or another user, thus getting full admin rights on all systems for a long period of time. Plus whatever havoc might be caused by having the ability to change rights on fileshares to allow the new domain admin to see confidential files.. I would expect that the intent is to use another flaw for a normal user to become a local admin, and then jump to domain admin via this. So yes. In an enterprise environment, the domain administrator is bigger. Cheers, On Fri, Dec 10, 2010 at 4:15 PM, Thor (Hammer of God) t...@hammerofgod.com wrote: Wow. I guess you didn't read the post either. I'm a bit surprised that a Sr. Network Engineer thinks that Group Policies differentiate between local and Domain administrators. You're making it sound like you think Group Policy application has some magic permissions or something, or that a domain administrator is a bigger administrator than the local administrator. Group Policy loads from the client via the Group Policy Client service. If I'm a local admin, I can just set my local system to not process group policy via the GPExtensions hive. Done. If I take the domain admin out of my local administrators, they can't do anything. Done. How exactly do you think this is problematic for shops that differentiate between desktop support and AD support? (whatever that means). t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of George Carlson Sent: Friday, December 10, 2010 10:12 AM To: bugt...@securityfocus.com; full-disclosure@lists.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) Your objections are mostly true in a normal sense. However, it is not true when Group Policy is taken into account. Group Policies differentiate between local and Domain administrators and so this vulnerability is problematic for shops that differentiate between desktop support and AD support. George Carlson Sr. Network Engineer (804) 423-7430 -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Friday, December 10, 2010 11:30 AM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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. Wrong. The local administrator is already local administrator. There's nothing the elevate any more. 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. There is no need to masquerade: the local administrator can perform all these modifications, and if s/he wishes, hide the tracks: turn off auditing before, clear audit/event logs afterwards, change the SID in the ACEs of all objects touched (SubInACL.Exe comes handy), ... Or: just change the NoDefaultAdminOwner setting. After that, all Administrators masquerade as Administrators. uh-oh. This includes creating scripts to run as the Domain Admin account the next time that they log in. Ridiculous. A local administrator can add any script/executable s/he wants to any autostart (scheduled task, registry, logon script, userinit, shell, ...). There's ABSOLUTELY no need to masquerade. All files created will not be linked to your domain account in file and folder access lists. ACEs can always be edited by a local administrator, see SubInACL.Exe, or TakeOwn.Exe. All security access lists will
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)
Since when do local admins become domain admins!?!?!?!?! Domain Admins are added to the Local Admins group when a computer joins a network. How do Local Admins on a computer become Domain Admins!?!?!!?!? -Original Message- From: jco...@winwholesale.com [mailto:jco...@winwholesale.com] Sent: Friday, December 10, 2010 2:45 PM To: Stefan Kanthak Cc: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk; stenopla...@exploitdevelopment.com 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 are completely missing the point.. Local admins become Domain Admins. From: Stefan Kanthak stefan.kant...@nexgo.de To: bugt...@securityfocus.com, full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com Date: 12/10/2010 01:08 PM 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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. Wrong. The local administrator is already local administrator. There's nothing the elevate any more. 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. There is no need to masquerade: the local administrator can perform all these modifications, and if s/he wishes, hide the tracks: turn off auditing before, clear audit/event logs afterwards, change the SID in the ACEs of all objects touched (SubInACL.Exe comes handy), ... Or: just change the NoDefaultAdminOwner setting. After that, all Administrators masquerade as Administrators. uh-oh. This includes creating scripts to run as the Domain Admin account the next time that they log in. Ridiculous. A local administrator can add any script/executable s/he wants to any autostart (scheduled task, registry, logon script, userinit, shell, ...). There's ABSOLUTELY no need to masquerade. All files created will not be linked to your domain account in file and folder access lists. ACEs can always be edited by a local administrator, see SubInACL.Exe, or TakeOwn.Exe. 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). A local administrator can turn audit/event logs off, clear or modify them. Stefan * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. * --- DISCLAIMER: This e-mail and any files transmitted with it are intended only for the use of the addressee and may contain information that is legally privileged and confidential. The e-mail may not be forwarded without permission of the sender. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. Please notify the sender electronically or by telephone immediately by calling QNB Bank at 800-491-9070 if you have received this
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)
So far I agree with Thor. Did I miss something? Has anyone demonstrated using the locally cached credentials to access resources across the network? So far I haven't seen anything new or interesting in this thread: 1. StenoPlasma claims that a local admin can access and reuse the cached credentials of other users. 2. Stefan, Thor, et al yawn. 3. Joyce, Andrea, and perhaps others seem to be conflating local access (what StenoPlasma was talking about) with gaining domain admin privileges on domain controllers and other resources on separate machines (which nobody appears to have shown is possible using locally cached credentials). If I've missed something obvious please educate me. Regards, Kurt Dillard -Original Message- From: katt...@gmail.com [mailto:katt...@gmail.com] On Behalf Of Andrea Lee Sent: Monday, December 13, 2010 2:12 PM To: Thor (Hammer of God) Cc: George Carlson; bugt...@securityfocus.com; full-disclosure@lists.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) I hope I'm not just feeding the troll... A local admin is an admin on one system. The domain admin is an admin on all systems in the domain, including mission critical Windows servers. With temporary domain admin privs, the local admin could log into the AD and change permissions / passwords for another user or another user, thus getting full admin rights on all systems for a long period of time. Plus whatever havoc might be caused by having the ability to change rights on fileshares to allow the new domain admin to see confidential files.. I would expect that the intent is to use another flaw for a normal user to become a local admin, and then jump to domain admin via this. So yes. In an enterprise environment, the domain administrator is bigger. Cheers, On Fri, Dec 10, 2010 at 4:15 PM, Thor (Hammer of God) t...@hammerofgod.com wrote: Wow. I guess you didn't read the post either. I'm a bit surprised that a Sr. Network Engineer thinks that Group Policies differentiate between local and Domain administrators. You're making it sound like you think Group Policy application has some magic permissions or something, or that a domain administrator is a bigger administrator than the local administrator. Group Policy loads from the client via the Group Policy Client service. If I'm a local admin, I can just set my local system to not process group policy via the GPExtensions hive. Done. If I take the domain admin out of my local administrators, they can't do anything. Done. How exactly do you think this is problematic for shops that differentiate between desktop support and AD support? (whatever that means). t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of George Carlson Sent: Friday, December 10, 2010 10:12 AM To: bugt...@securityfocus.com; full-disclosure@lists.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) Your objections are mostly true in a normal sense. However, it is not true when Group Policy is taken into account. Group Policies differentiate between local and Domain administrators and so this vulnerability is problematic for shops that differentiate between desktop support and AD support. George Carlson Sr. Network Engineer (804) 423-7430 -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Friday, December 10, 2010 11:30 AM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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. Wrong. The local administrator is already local administrator. There's
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)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Dillard said the following on 13/12/10 20:09: So far I agree with Thor. Did I miss something? Has anyone demonstrated using the locally cached credentials to access resources across the network? So far I haven't seen anything new or interesting in this thread: Since the procedure involves the disconnection from network, IMHO this flaw only demonstrates that the physical access is equal to the root/Administrator access. Ciao, luigi - -- / +--[Luigi Rosa]-- \ You talk like a Minbari, Commander. Perhaps there was some small wisdom in letting your species survive. --Neroon, Legacies -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0Gd6oACgkQ3kWu7Tfl6ZRGugCfcbXguUKxEoG7pNtr18gWp+gt rtEAoJhq6+Xg89/dn5vbXL6yjlC/H+nG =urN/ -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
Everyone. Please read my original post. I never claimed to gain access to networked resources using the masqueraded account. My method merely shows that you can modify the SAM and SECURITY hives without using DLL injection or any other advanced technique that security Admins are currently looking for when it comes to advanced persistent threats. On Dec 13, 2010 11:54 AM, Kurt Dillard kurtdill...@msn.com wrote: So far I agree with Thor. Did I miss something? Has anyone demonstrated using the locally cached credentials to access resources across the network? So far I haven't seen anything new or interesting in this thread: 1. StenoPlasma claims that a local admin can access and reuse the cached credentials of other users. 2. Stefan, Thor, et al yawn. 3. Joyce, Andrea, and perhaps others seem to be conflating local access (what StenoPlasma was talking about) with gaining domain admin privileges on domain controllers and other resources on separate machines (which nobody appears to have shown is possible using locally cached credentials). If I've missed something obvious please educate me. Regards, Kurt Dillard -Original Message- From: katt...@gmail.com [mailto:katt...@gmail.com] On Behalf Of Andrea Lee Sent: Monday, December 13, 2010 2:12 PM To: Thor (Hammer of God) Cc: George Carlson; bugt...@securityfocus.com; full-disclosure@lists.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) I hope I'm not just feeding the troll... A local admin is an admin on one system. The domain admin is an admin on all systems in the domain, including mission critical Windows servers. With temporary domain admin privs, the local admin could log into the AD and change permissions / passwords for another user or another user, thus getting full admin rights on all systems for a long period of time. Plus whatever havoc might be caused by having the ability to change rights on fileshares to allow the new domain admin to see confidential files.. I would expect that the intent is to use another flaw for a normal user to become a local admin, and then jump to domain admin via this. So yes. In an enterprise environment, the domain administrator is bigger. Cheers, On Fri, Dec 10, 2010 at 4:15 PM, Thor (Hammer of God) t...@hammerofgod.com wrote: Wow. I guess you didn't read the post either. I'm a bit surprised that a Sr. Network Engineer thinks that Group Policies differentiate between local and Domain administrators. You're making it sound like you think Group Policy application has some magic permissions or something, or that a domain administrator is a bigger administrator than the local administrator. Group Policy loads from the client via the Group Policy Client service. If I'm a local admin, I can just set my local system to not process group policy via the GPExtensions hive. Done. If I take the domain admin out of my local administrators, they can't do anything. Done. How exactly do you think this is problematic for shops that differentiate between desktop support and AD support? (whatever that means). t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of George Carlson Sent: Friday, December 10, 2010 10:12 AM To: bugt...@securityfocus.com; full-disclosure@lists.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) Your objections are mostly true in a normal sense. However, it is not true when Group Policy is taken into account. Group Policies differentiate between local and Domain administrators and so this vulnerability is problematic for shops that differentiate between desktop support and AD support. George Carlson Sr. Network Engineer (804) 423-7430 -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Friday, December 10, 2010 11:30 AM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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
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)
There is no local admin on a DC. t From: Peter Setlak [mailto:peterset...@me.com] Sent: Monday, December 13, 2010 12:06 PM To: Andrea Lee Cc: Thor (Hammer of God); George Carlson; bugt...@securityfocus.com; full-disclosure@lists.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) ? OK, wrap up, are we talking about Domain Admins having local admin privs? Of course they do - that's the joy of having a domain, centralized management... OR Are we talking about local admins having domain admin privs? The local admin would only have temporary domain admin privs if said local system was a DC. This is a given that the DC's local admin has equiv to domain admin, thus, you can only log in to a DC as domain admin to begin with once it has become a DC. I'm not sure of any situation where a local admin to say a member server would have domain admin privs unless the local admin were to be added to the domain admins group on that machine. Which, of course, one would need domain admin equiv privs in order to make such a change in the first place... Perhaps in older, NT pre-SP4 boxes, if the local admin to all the boxes had the same username/password, and that same username/password combo were to have been on the NT box prior to it becoming the PDC, and, in turn, after the NT box became PDC, that username was added to the domain admins group then, perhaps all local admins across the domain would share in the delight of being mistaken as a domain admin but even then, I just gave myself a headache - we are talking pre or post WINS here? Are we getting workgroups confused with domains? Definitely, 2k and XP do not have this issue as accounts are stored in the AD using SSID's which are unique across machines - so - even if machine A B the DC had the same local admin username password, local admin A doesn't have actual privs on B or the DC. It may appear as such because the user would type in the same username/password combo, but, the account itself is just a local admin on A, and B's is on B, and the DC, well, that is a domain admin (see above). Maybe I should refrain from jumping in mid-thread? Peter Setlak peterset...@me.commailto:peterset...@me.com (315) 371-6611 Skype Me!skype:petersetlak?chat (Get Skypehttp://www.skype.com/go/download) ** SAVE A TREE! (Please consider the environment before printing this email or its attachments...) On Dec 13, 2010, at 12:12 PM, Andrea Lee wrote: I hope I'm not just feeding the troll... A local admin is an admin on one system. The domain admin is an admin on all systems in the domain, including mission critical Windows servers. With temporary domain admin privs, the local admin could log into the AD and change permissions / passwords for another user or another user, thus getting full admin rights on all systems for a long period of time. Plus whatever havoc might be caused by having the ability to change rights on fileshares to allow the new domain admin to see confidential files.. I would expect that the intent is to use another flaw for a normal user to become a local admin, and then jump to domain admin via this. So yes. In an enterprise environment, the domain administrator is bigger. Cheers, On Fri, Dec 10, 2010 at 4:15 PM, Thor (Hammer of God) t...@hammerofgod.commailto:t...@hammerofgod.com wrote: Wow. I guess you didn't read the post either. I'm a bit surprised that a Sr. Network Engineer thinks that Group Policies differentiate between local and Domain administrators. You're making it sound like you think Group Policy application has some magic permissions or something, or that a domain administrator is a bigger administrator than the local administrator. Group Policy loads from the client via the Group Policy Client service. If I'm a local admin, I can just set my local system to not process group policy via the GPExtensions hive. Done. If I take the domain admin out of my local administrators, they can't do anything. Done. How exactly do you think this is problematic for shops that differentiate between desktop support and AD support? (whatever that means). t -Original Message- From: full-disclosure-boun...@lists.grok.org.ukmailto:full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of George Carlson Sent: Friday, December 10, 2010 10:12 AM To: bugt...@securityfocus.commailto:bugt...@securityfocus.com; full-disclosure@lists.grok.org.ukmailto:full-disclosure@lists.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) Your objections are mostly true in a normal sense. However, it is not true when Group Policy is taken into account. Group
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)
Andrea Lee and...@kattrap.net wrote: I hope I'm not just feeding the troll... No. You just made a complete fool of yourself.-P Read the initial post again. CAREFULLY. Especially that part about unplugging from the network. A local admin is an admin on one system. The domain admin is an admin on all systems in the domain, including mission critical Windows servers. Correct so far. With temporary domain admin privs, What are temporary domain admin privs? If you meant to say cached credentials, just use cached credentials. the local admin could log into the AD A local admin (or better: a local user account) CAN'T log into the AD. Only domain user accounts can. Cached credentials are stored for domain accounts only, and are only used when the AD is NOT available during login. They are NEVER used to login to another computer! and change permissions / passwords for another user or another user, thus getting full admin rights on all systems for a long period of time. Plus whatever havoc might be caused by having the ability to change rights on fileshares to allow the new domain admin to see confidential files.. I would expect that the intent is to use another flaw for a normal user to become a local admin, and then jump to domain admin via this. You got wrong expectations. And: there is no jump! So yes. In an enterprise environment, the domain administrator is bigger. GIGO! Stefan [ braindead fullquote removed ] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
? OK, wrap up, are we talking about Domain Admins having local admin privs? Of course they do - that's the joy of having a domain, centralized management... OR Are we talking about local admins having domain admin privs? The local admin would only have temporary domain admin privs if said local system was a DC. This is a given that the DC's local admin has equiv to domain admin, thus, you can only log in to a DC as domain admin to begin with once it has become a DC. I'm not sure of any situation where a local admin to say a member server would have domain admin privs unless the local admin were to be added to the domain admins group on that machine. Which, of course, one would need domain admin equiv privs in order to make such a change in the first place... Perhaps in older, NT pre-SP4 boxes, if the local admin to all the boxes had the same username/password, and that same username/password combo were to have been on the NT box prior to it becoming the PDC, and, in turn, after the NT box became PDC, that username was added to the domain admins group then, perhaps all local admins across the domain would share in the delight of being mistaken as a domain admin but even then, I just gave myself a headache - we are talking pre or post WINS here? Are we getting workgroups confused with domains? Definitely, 2k and XP do not have this issue as accounts are stored in the AD using SSID's which are unique across machines - so - even if machine A B the DC had the same local admin username password, local admin A doesn't have actual privs on B or the DC. It may appear as such because the user would type in the same username/password combo, but, the account itself is just a local admin on A, and B's is on B, and the DC, well, that is a domain admin (see above). Maybe I should refrain from jumping in mid-thread? Peter Setlak peterset...@me.com (315) 371-6611 Skype Me! (Get Skype) ** SAVE A TREE! (Please consider the environment before printing this email or its attachments...) On Dec 13, 2010, at 12:12 PM, Andrea Lee wrote: I hope I'm not just feeding the troll... A local admin is an admin on one system. The domain admin is an admin on all systems in the domain, including mission critical Windows servers. With temporary domain admin privs, the local admin could log into the AD and change permissions / passwords for another user or another user, thus getting full admin rights on all systems for a long period of time. Plus whatever havoc might be caused by having the ability to change rights on fileshares to allow the new domain admin to see confidential files.. I would expect that the intent is to use another flaw for a normal user to become a local admin, and then jump to domain admin via this. So yes. In an enterprise environment, the domain administrator is bigger. Cheers, On Fri, Dec 10, 2010 at 4:15 PM, Thor (Hammer of God) t...@hammerofgod.com wrote: Wow. I guess you didn't read the post either. I'm a bit surprised that a Sr. Network Engineer thinks that Group Policies differentiate between local and Domain administrators. You're making it sound like you think Group Policy application has some magic permissions or something, or that a domain administrator is a bigger administrator than the local administrator. Group Policy loads from the client via the Group Policy Client service. If I'm a local admin, I can just set my local system to not process group policy via the GPExtensions hive. Done. If I take the domain admin out of my local administrators, they can't do anything. Done. How exactly do you think this is problematic for shops that differentiate between desktop support and AD support? (whatever that means). t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of George Carlson Sent: Friday, December 10, 2010 10:12 AM To: bugt...@securityfocus.com; full-disclosure@lists.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) Your objections are mostly true in a normal sense. However, it is not true when Group Policy is taken into account. Group Policies differentiate between local and Domain administrators and so this vulnerability is problematic for shops that differentiate between desktop support and AD support. George Carlson Sr. Network Engineer (804) 423-7430 -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Friday, December 10, 2010 11:30 AM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com Subject: Re: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin
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)
So you are saying that the use can perform action on the domain? Things like create/delete user accounts. Your initial statement does not say anything about taking action on any network resources. I find it hard to believe that would be the case because user would not have a valid kerberos ticket because they did not log into the domain. Jason Lang From: jcoyle () winwholesale com Date: Fri, 10 Dec 2010 14:44:35 -0500 You are completely missing the point.. Local admins become Domain Admins. From: Stefan Kanthak stefan.kanthak () nexgo de To: bugtraq () securityfocus com, full-disclosure () lists grok org uk Cc: stenoplasma () exploitdevelopment com Date: 12/10/2010 01:08 PM 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) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
Vendor Notified: December 7, 2010 Vendor Fixed: N/A Vendor Dismissed: December 9, 2010 Law #6: A computer is only as secure as the administrator is trustworthy http://technet.microsoft.com/en-us/library/cc722487.aspx#EFAA ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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) t...@hammerofgod.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:stenopla...@exploitdevelopment.com] Sent: Thursday, December 09, 2010 6:13 PM To: Thor (Hammer of God); full-disclosure@lists.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) t...@hammerofgod.com Sent: Thursday, December 09, 2010 6:07 PM To: stenopla...@exploitdevelopment.com stenopla...@exploitdevelopment.com, full-disclosure@lists.grok.org.uk full-disclosure@lists.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-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of StenoPlasma @ www.ExploitDevelopment.com Sent: Thursday, December 09, 2010 5:07 PM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.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
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)
No, but I am :) -Original Message- From: Bob Wilkinson [mailto:rwilkin...@messagelabs.com] Sent: Friday, December 10, 2010 3:32 AM To: Thor (Hammer of God) Cc: Mike Hale; full-disclosure@lists.grok.org.uk; stenopla...@exploitdevelopment.com 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) On Fri, Dec 10, 2010 at 03:28:05AM +, Thor (Hammer of God) wrote: No rouge user, only administrators. Are the rouge users red-faced? :-) Bob __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
Hey Marsh - I think he meant LSA not SAM. With the SAM, you can brute force the local accounts. But with the LSA, you can get NTLM hashes for active users and attempt to use those. You'll typically see those types of attacks against XP boxes or Win2000 where NTLM is still being used as the default authentication protocol. Nowadays, in the enterprise anyway, network auth will be Kerberos, and if not, NTLMv2. But yes, PTH is a different animal than what is being described my StenoPlasma. t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Marsh Ray Sent: Thursday, December 09, 2010 11:34 PM To: Mike Vasquez Cc: full-disclosure@lists.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) On 12/09/2010 09:36 PM, Mike Vasquez wrote: You can dump the local cached hashes, take a domain admins, My understanding is that after the target user has logged off, the hashes which remain are only sufficient to validate a correct password. I.e., they're like the classic /etc/passwd hashes but with decent salts. They could be used for dictionary attacks, but not with precomputed rainbow tables. 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 My understanding is that PTH is a technique allowing you to easily use a different kind of hash. The password-equivalent kind that would be copied from the credentials of a live logged-in session. In that sense, PTH on its own may not meet the formal definition of an 'attack', since you still need a way to capture the password-equivalent. 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. If you're a local admin, you can replace explorer.exe and access resources with the credentials of the logged-in user. If you're a local admin, you can install a keylogger and trivially capture anyone's freaking plaintext password (local console or RDP sessions). So don't type your Domain Admin password into an untrusted system. Duh! Note that any system to which an untrusted party has unsupervised physical access is untrusted. - Marsh ___ 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/
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)
Hey Jeff - StenoPlasma and I took the conversation off-line, and I'm clear about what he is illustrating. As far as the local machine is concerned, there is no difference between the local admin and the domain admin or any other admin in the Administrators group. The paper illustrates how one admin can pretend to be another admin by masquerading as his SID.Of course, the admin could masquerade as a normal user too, but there's no point in that. That said, there's no point in one admin pretending to be another admin. There is no down-range network access to this, and as StenoPlasma pointed out, you have to have the network cable unplugged to do this. Not taking away from SP's find, but at the end of the day, this doesn't allow an administrator to do anything he couldn't already do. If repudiation is the concern, the one admin can simply create another admin user, log in as them, and do whatever they want logging activities as that user. I've been counting, and now this is 1 million four: If it starts with If I'm admin... then what comes next doesn't matter. t -Original Message- From: Jeffrey Walton [mailto:noloa...@gmail.com] Sent: Friday, December 10, 2010 6:38 AM To: Thor (Hammer of God) Cc: stenopla...@exploitdevelopment.com; full-disclosure@lists.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) On Thu, Dec 9, 2010 at 10:07 PM, Thor (Hammer of God) t...@hammerofgod.com wrote: What do you mean by regular local administrator? You're a local admin, or you're not. I believe the OP's intent was to differentiate between Local Administrators and Domain (or Enterprise) Administrators. Corrections from StenoPlasma are welcomed. There are not degrees of local admin. But there are different accounts, both domain and local, which have administrator rights and privileges on the local machine. [SNIP] Jeff ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
Your objections are mostly true in a normal sense. However, it is not true when Group Policy is taken into account. Group Policies differentiate between local and Domain administrators and so this vulnerability is problematic for shops that differentiate between desktop support and AD support. George Carlson Sr. Network Engineer (804) 423-7430 -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Friday, December 10, 2010 11:30 AM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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. Wrong. The local administrator is already local administrator. There's nothing the elevate any more. 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. There is no need to masquerade: the local administrator can perform all these modifications, and if s/he wishes, hide the tracks: turn off auditing before, clear audit/event logs afterwards, change the SID in the ACEs of all objects touched (SubInACL.Exe comes handy), ... Or: just change the NoDefaultAdminOwner setting. After that, all Administrators masquerade as Administrators. uh-oh. This includes creating scripts to run as the Domain Admin account the next time that they log in. Ridiculous. A local administrator can add any script/executable s/he wants to any autostart (scheduled task, registry, logon script, userinit, shell, ...). There's ABSOLUTELY no need to masquerade. All files created will not be linked to your domain account in file and folder access lists. ACEs can always be edited by a local administrator, see SubInACL.Exe, or TakeOwn.Exe. 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). A local administrator can turn audit/event logs off, clear or modify them. Stefan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
You are completely missing the point.. Local admins become Domain Admins. From: Stefan Kanthak stefan.kant...@nexgo.de To: bugt...@securityfocus.com, full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com Date: 12/10/2010 01:08 PM 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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. Wrong. The local administrator is already local administrator. There's nothing the elevate any more. 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. There is no need to masquerade: the local administrator can perform all these modifications, and if s/he wishes, hide the tracks: turn off auditing before, clear audit/event logs afterwards, change the SID in the ACEs of all objects touched (SubInACL.Exe comes handy), ... Or: just change the NoDefaultAdminOwner setting. After that, all Administrators masquerade as Administrators. uh-oh. This includes creating scripts to run as the Domain Admin account the next time that they log in. Ridiculous. A local administrator can add any script/executable s/he wants to any autostart (scheduled task, registry, logon script, userinit, shell, ...). There's ABSOLUTELY no need to masquerade. All files created will not be linked to your domain account in file and folder access lists. ACEs can always be edited by a local administrator, see SubInACL.Exe, or TakeOwn.Exe. 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). A local administrator can turn audit/event logs off, clear or modify them. Stefan * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. * ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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)
StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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. Wrong. The local administrator is already local administrator. There's nothing the elevate any more. 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. There is no need to masquerade: the local administrator can perform all these modifications, and if s/he wishes, hide the tracks: turn off auditing before, clear audit/event logs afterwards, change the SID in the ACEs of all objects touched (SubInACL.Exe comes handy), ... Or: just change the NoDefaultAdminOwner setting. After that, all Administrators masquerade as Administrators. uh-oh. This includes creating scripts to run as the Domain Admin account the next time that they log in. Ridiculous. A local administrator can add any script/executable s/he wants to any autostart (scheduled task, registry, logon script, userinit, shell, ...). There's ABSOLUTELY no need to masquerade. All files created will not be linked to your domain account in file and folder access lists. ACEs can always be edited by a local administrator, see SubInACL.Exe, or TakeOwn.Exe. 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). A local administrator can turn audit/event logs off, clear or modify them. Stefan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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 whose universe? Did you even read the post? Local admins become LOCAL ADMINS by using a cached domain account who is a LOCAL ADMIN. You have to do it with the network cable unplugged. There is no privilege escalation here. StenoPlasma's intent was to educate people on how things worked, and while there isn't a security issue here, he was completely correct in that you guys really need to learn what you are talking about. t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of jco...@winwholesale.com Sent: Friday, December 10, 2010 11:45 AM To: Stefan Kanthak Cc: stenopla...@exploitdevelopment.com; full-disclosure@lists.grok.org.uk; bugt...@securityfocus.com 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) You are completely missing the point.. Local admins become Domain Admins. From: Stefan Kanthak stefan.kant...@nexgo.de To: bugt...@securityfocus.com, full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com Date: 12/10/2010 01:08 PM 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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. Wrong. The local administrator is already local administrator. There's nothing the elevate any more. 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. There is no need to masquerade: the local administrator can perform all these modifications, and if s/he wishes, hide the tracks: turn off auditing before, clear audit/event logs afterwards, change the SID in the ACEs of all objects touched (SubInACL.Exe comes handy), ... Or: just change the NoDefaultAdminOwner setting. After that, all Administrators masquerade as Administrators. uh-oh. This includes creating scripts to run as the Domain Admin account the next time that they log in. Ridiculous. A local administrator can add any script/executable s/he wants to any autostart (scheduled task, registry, logon script, userinit, shell, ...). There's ABSOLUTELY no need to masquerade. All files created will not be linked to your domain account in file and folder access lists. ACEs can always be edited by a local administrator, see SubInACL.Exe, or TakeOwn.Exe. 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). A local administrator can turn audit/event logs off, clear or modify them. Stefan *** ** This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *** ** ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia -
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)
Wow. I guess you didn't read the post either. I'm a bit surprised that a Sr. Network Engineer thinks that Group Policies differentiate between local and Domain administrators. You're making it sound like you think Group Policy application has some magic permissions or something, or that a domain administrator is a bigger administrator than the local administrator. Group Policy loads from the client via the Group Policy Client service. If I'm a local admin, I can just set my local system to not process group policy via the GPExtensions hive. Done. If I take the domain admin out of my local administrators, they can't do anything. Done. How exactly do you think this is problematic for shops that differentiate between desktop support and AD support? (whatever that means). t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of George Carlson Sent: Friday, December 10, 2010 10:12 AM To: bugt...@securityfocus.com; full-disclosure@lists.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) Your objections are mostly true in a normal sense. However, it is not true when Group Policy is taken into account. Group Policies differentiate between local and Domain administrators and so this vulnerability is problematic for shops that differentiate between desktop support and AD support. George Carlson Sr. Network Engineer (804) 423-7430 -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Friday, December 10, 2010 11:30 AM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com 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) StenoPlasma @ www.ExploitDevelopment.com wrote: Much ado about nothing! TITLE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts There is NO privilege escalation. A local administrator is an admistrator is an administrator... 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. Wrong. The local administrator is already local administrator. There's nothing the elevate any more. 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. There is no need to masquerade: the local administrator can perform all these modifications, and if s/he wishes, hide the tracks: turn off auditing before, clear audit/event logs afterwards, change the SID in the ACEs of all objects touched (SubInACL.Exe comes handy), ... Or: just change the NoDefaultAdminOwner setting. After that, all Administrators masquerade as Administrators. uh-oh. This includes creating scripts to run as the Domain Admin account the next time that they log in. Ridiculous. A local administrator can add any script/executable s/he wants to any autostart (scheduled task, registry, logon script, userinit, shell, ...). There's ABSOLUTELY no need to masquerade. All files created will not be linked to your domain account in file and folder access lists. ACEs can always be edited by a local administrator, see SubInACL.Exe, or TakeOwn.Exe. 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). A local administrator can turn audit/event logs off, clear or modify them. Stefan ___ 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:
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-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of StenoPlasma @ www.ExploitDevelopment.com Sent: Thursday, December 09, 2010 5:07 PM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.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.
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) t...@hammerofgod.com Sent: Thursday, December 09, 2010 6:07 PM To: stenopla...@exploitdevelopment.com stenopla...@exploitdevelopment.com, full-disclosure@lists.grok.org.uk full-disclosure@lists.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-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of StenoPlasma @ www.ExploitDevelopment.com Sent: Thursday, December 09, 2010 5:07 PM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.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
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)
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:stenopla...@exploitdevelopment.com] Sent: Thursday, December 09, 2010 6:13 PM To: Thor (Hammer of God); full-disclosure@lists.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) t...@hammerofgod.com Sent: Thursday, December 09, 2010 6:07 PM To: stenopla...@exploitdevelopment.com stenopla...@exploitdevelopment.com, full-disclosure@lists.grok.org.uk full-disclosure@lists.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-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of StenoPlasma @ www.ExploitDevelopment.com Sent: Thursday, December 09, 2010 5:07 PM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.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
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)
No rouge user, only administrators. And no, if I remove domain accounts from my local system (again, as administrator) then I can avoid having GP change anything. Hell, I could put deny permission on the entire registry if I wanted to. There's no magic about domain admins - they're just another account that have default ACLs set. The local admin can always change it. If you need repudiation, don't let people be local admins. Plain and simple. This is why many audits (SOX, SAS70, etc) require that all administrators be accounted for (change logs, etc) for access... t -Original Message- From: Mike Hale [mailto:eyeronic.des...@gmail.com] Sent: Thursday, December 09, 2010 7:20 PM To: Thor (Hammer of God) Cc: stenopla...@exploitdevelopment.com; full-disclosure@lists.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) t...@hammerofgod.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:stenopla...@exploitdevelopment.com] Sent: Thursday, December 09, 2010 6:13 PM To: Thor (Hammer of God); full-disclosure@lists.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) t...@hammerofgod.com Sent: Thursday, December 09, 2010 6:07 PM To: stenopla...@exploitdevelopment.com stenopla...@exploitdevelopment.com, full-disclosure@lists.grok.org.uk full-disclosure@lists.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-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of StenoPlasma @ www.ExploitDevelopment.com Sent: Thursday, December 09, 2010 5:07 PM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.com Subject: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows Local
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)
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.des...@gmail.com] Sent: Thursday, December 09, 2010 7:20 PM To: Thor (Hammer of God) Cc: stenopla...@exploitdevelopment.com; full-disclosure@lists.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) t...@hammerofgod.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:stenopla...@exploitdevelopment.com] Sent: Thursday, December 09, 2010 6:13 PM To: Thor (Hammer of God); full-disclosure@lists.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) t...@hammerofgod.com Sent: Thursday, December 09, 2010 6:07 PM To: stenopla...@exploitdevelopment.com stenopla...@exploitdevelopment.com, full-disclosure@lists.grok.org.uk full-disclosure@lists.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-boun...@lists.grok.org.uk [mailto:full-disclosure- boun...@lists.grok.org.uk] On Behalf Of StenoPlasma @ www.ExploitDevelopment.com Sent: Thursday, December 09, 2010 5:07 PM To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk Cc: stenopla...@exploitdevelopment.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)
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)
On 12/09/2010 09:36 PM, Mike Vasquez wrote: You can dump the local cached hashes, take a domain admins, My understanding is that after the target user has logged off, the hashes which remain are only sufficient to validate a correct password. I.e., they're like the classic /etc/passwd hashes but with decent salts. They could be used for dictionary attacks, but not with precomputed rainbow tables. 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 My understanding is that PTH is a technique allowing you to easily use a different kind of hash. The password-equivalent kind that would be copied from the credentials of a live logged-in session. In that sense, PTH on its own may not meet the formal definition of an 'attack', since you still need a way to capture the password-equivalent. 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. If you're a local admin, you can replace explorer.exe and access resources with the credentials of the logged-in user. If you're a local admin, you can install a keylogger and trivially capture anyone's freaking plaintext password (local console or RDP sessions). So don't type your Domain Admin password into an untrusted system. Duh! Note that any system to which an untrusted party has unsupervised physical access is untrusted. - Marsh ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
