Full Disclosure mailing list archives

Previous By Date Next
Previous By Thread Next

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: Mike Vasquez <mike () digihax com>
Date: Thu, 9 Dec 2010 20:36:38 -0700
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.design () gmail com]
Sent: Thursday, December 09, 2010 7:20 PM
To: Thor (Hammer of God)
Cc: StenoPlasma () 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) <thor () 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:StenoPlasma () 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)" <thor () hammerofgod com>
Sent: Thursday, December 09, 2010 6:07 PM
To: "stenoplasma () exploitdevelopment com"

<stenoplasma () 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-bounces () lists grok org uk

[mailto:full-disclosure-

bounces () lists grok org uk] On Behalf Of StenoPlasma @
www.ExploitDevelopment.com
Sent: Thursday, December 09, 2010 5:07 PM
To: bugtraq () securityfocus com; full-disclosure () lists grok org uk
Cc: stenoplasma () 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". Take note of the four
hex

characters

that are located in positions 1, 2, 3, and 4 on line 3 of the hex data.
Step 10: For this example, the hex characters are "59 04". This user

account is

"Domain\DomainAdminAcct".
Step 11: Double click on "NL$4". Replace your SID hex representation
"5a

04",

with DomainAdminAcct's SID hex representation "59 04".
Step 12: *Important* Disconnect all physical network connections
from

the

workstation.
Step 13: Log off of the domain account, then log back in to your
domain account.
Step 14: You will now be logged in to your modified cached account
that

is

really the Domain Admin's account.
Step 15: You are now free to modify system files and user account

profiles

using the identity of the Domain Admin's account. This includes

creating

scripts to run as the Domain Admin account the next time that they
log

in. All

files created will not be linked to your domain account. All
security

access lists

will only show the Domain Admin's account once you log out of the

modified

cached account.
Step 16: All actions taken are indeed logged in the Security Event
Log,

but all

actions are shown as being completed by "Domain\DomainAdminAcct".
Deeper inspection of event logs will show inside the login and
logout

events

for your modified cached account, your actual user name is listed
inside

the

event, but not in the Security Event Log Viewer listing. Event log

entries for

object access will only be created if administrators are auditing

successful

access to files (This will lead to enormous event log sizes). These

events will

be listed as being performed as "Domain\DomainAdminAcct" in the
event

log

viewer, but deeper inspection will show your true user name.

VULNERABLE PRODUCTS:
All patch levels of Windows 2003 Server, Windows XP, Windows Vista,
Windows 7, and Windows 2008 Server.

REFERENCES AND ADDITIONAL INFORMATION:
N/A

CREDITS:
StenoPlasma (at) ExploitDevelopment.com

TIMELINE:
Discovery: December 4, 2010
Vendor Notified: December 7, 2010
Vendor Fixed: N/A
Vendor Dismissed: December 9, 2010
Vendor Notified of Disclosure: December 9, 2010
Disclosed: December 9, 2010

VENDOR URL:
http://www.microsoft.com

ADVISORY URL:
http://www.ExploitDevelopment.com/Vulnerabilities/2010-M$-002.html

VENDOR ADVISORY URL:
N/A


-------------------------------------------------------------
StenoPlasma at ExploitDevelopment.com www.ExploitDevelopment.com
-------------------------------------------------------------

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/




_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/





--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Previous By Date Next
Previous By Thread Next

Current thread: