RE: [Full-disclosure] Flaw in Microsoft Domain Account Caching
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 loca=
l and Domain administrators." You're making it sound like you think Group =
Policy application has some "magic permissions" or something, or that a "do=
main administrator" is a "bigger" administrator than the local administrato=
r.
Group Policy loads from the client via the Group Policy Client service. I=
f I'm a local admin, I can just set my local system to not process group po=
licy via the GPExtensions hive. Done. If I take the domain admin out of m=
y local administrators, they can't do anything. Done. =20
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-bounces@lists.grok.org.uk [mailto:full-disclosure-
>bounces@lists.grok.org.uk] On Behalf Of George Carlson
>Sent: Friday, December 10, 2010 10:12 AM
>To: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
>Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Al=
lows
>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 tru=
e
>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.kanthak@nexgo.de]
>Sent: Friday, December 10, 2010 11:30 AM
>To: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
>Cc: stenoplasma@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 not=
hing
>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 th=
ese
>modifications, and if s/he wishes, hide the tracks: turn off auditing befo=
re,
>clear audit/event logs afterwards, change the SID in the ACEs of all objec=
ts
>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/
討論串 (同標題文章)
完整討論串 (本文為第 2 之 3 篇)：