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)

From: Stefan Kanthak <stefan.kanthak@nexgo.de>
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)
Date:


"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





Copyright © 1995-2018 LinuxRocket.net. All rights reserved.