full-disclosure - 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)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 10 Dec 2010 17:29:40 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>,
	<full-disclosure@...ts.grok.org.uk>
Cc: stenoplasma@...loitdevelopment.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/