Click here to get back home

Shares, Named Pipes, and Registry for Anonymous Remote Access
 Home | NewsGroups | Search | About
Login Password
Register Now!
 microsoft.public.windows.server.security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Shares, Named Pipes, and Registry for Anonymous Remote Access Will 02-23-2007
Posted by Will on February 23, 2007, 2:24 am
Please log in for more thread options
 I have a trojan I am fighting that replicates by establishing a null
connection to IPC$ on any member server that has File & Printer Sharing
enabled. It then repeatedly tries to invoke one of several buffer
overloads in order to execute code in the SYSTEM context of the targeted
machine. I would like to know how can I safely prevent null connections on
IPC$. I have all five of the enable/disable settings in GPO security set
that forbid anonymous access. Setting those to forbid anonymous is NOT
preventing the trojan from successfully establishing the null connection.
I can see this quite clearly by following its progress in a sniffer on the
attacking machine, and then when the IPC$ connection is established, on the
Windows 2003 DC I quite clearly get an eventviewer message that shows
ANONYMOUS CONNECTION, and the IP of the eventviewer message matches the
attacker's IP.

Group Policy for Windows XP/2003 contains the following Security Settings
(these names are approximate):

Named Pipes that can be accessed anonymously

Remote access registry paths

Remote access registry paths and subpaths

Shares that can be accessed anonymously

I have the following questions regarding the above:

1) For a domain controller, is it required that any of these be enabled, and
what is the minimum subset of entities that must be exposed?

2) For a member server, same question

3) For Windows 2000 DCs, are most of these just enabled by default and you
cannot change the specific settings?

4) When you deselect the checkbox on this group policy, and simply fail to
define any entities, then what are the defaults that will be in effect?
When I ran RSOP.MSC on one Windows 2003 DC, it had none of these defined
even through its local policy and GPO did not select checkboxes for any of
these.

If the lack of any settings in RSOP.MSC means that nothing is being allowed
for anonymous access, then would I get the same result by enabling the
checkbox, and simply forcing the list of each GPO setting above to be empty?

I'm not clear on what steps if any I should take here to absolutely be sure
that there are no anonymous connections allowed to the member server / DC.
Any insights on this are appreciated.

--
Will



Posted by S. Pidgorny on February 23, 2007, 5:41 am
Please log in for more thread options
 You cannot really prevent null-connection attempts... So the question is -
how system responds? The GPO that you need is "Named Pipes that can be
accessed anonymously", and it must e set to Disable. I don't quite remember
what the default value is, think it's now secure.

And most recently (W2K3 SP1) there are no named pipes you can possibly
connect to anonymously:

https://blogs.msdn.com/spatdsg/archive/2006/05/15/598260.aspx

Now, get rid of that trojan.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

>I have a trojan I am fighting that replicates by establishing a null
> connection to IPC$ on any member server that has File & Printer Sharing
> enabled. It then repeatedly tries to invoke one of several buffer
> overloads in order to execute code in the SYSTEM context of the targeted
> machine. I would like to know how can I safely prevent null connections
> on
> IPC$. I have all five of the enable/disable settings in GPO security
> set
> that forbid anonymous access. Setting those to forbid anonymous is NOT
> preventing the trojan from successfully establishing the null connection.
> I can see this quite clearly by following its progress in a sniffer on the
> attacking machine, and then when the IPC$ connection is established, on
> the
> Windows 2003 DC I quite clearly get an eventviewer message that shows
> ANONYMOUS CONNECTION, and the IP of the eventviewer message matches the
> attacker's IP.
>
> Group Policy for Windows XP/2003 contains the following Security Settings
> (these names are approximate):
>
> Named Pipes that can be accessed anonymously
>
> Remote access registry paths
>
> Remote access registry paths and subpaths
>
> Shares that can be accessed anonymously
>
> I have the following questions regarding the above:
>
> 1) For a domain controller, is it required that any of these be enabled,
> and
> what is the minimum subset of entities that must be exposed?
>
> 2) For a member server, same question
>
> 3) For Windows 2000 DCs, are most of these just enabled by default and you
> cannot change the specific settings?
>
> 4) When you deselect the checkbox on this group policy, and simply fail to
> define any entities, then what are the defaults that will be in effect?
> When I ran RSOP.MSC on one Windows 2003 DC, it had none of these defined
> even through its local policy and GPO did not select checkboxes for any of
> these.
>
> If the lack of any settings in RSOP.MSC means that nothing is being
> allowed
> for anonymous access, then would I get the same result by enabling the
> checkbox, and simply forcing the list of each GPO setting above to be
> empty?
>
> I'm not clear on what steps if any I should take here to absolutely be
> sure
> that there are no anonymous connections allowed to the member server / DC.
> Any insights on this are appreciated.
>
> --
> Will
>
>



Posted by Will on February 23, 2007, 5:25 pm
Please log in for more thread options
> You cannot really prevent null-connection attempts... So the question is -
> how system responds? The GPO that you need is "Named Pipes that can be
> accessed anonymously", and it must e set to Disable. I don't quite
remember
> what the default value is, think it's now secure.

It's not a disable and enable setting. Rather, the states are no checkbox
(which I take to be a third state of "not set") and a checkbox, which when
selected lets you specify specific null named pipes including IPC$.

I could specify the checkbox and then empty out the list. Is this what I
should be doing?

And for my education, when I do not select the checkbox, what is the default
behavior?

And, also, when I do or do not select the checkbox, does either setting have
any effect on a Windows 2000 DC?

--
Will



Posted by Roger Abell [MVP] on February 24, 2007, 10:20 am
Please log in for more thread options

>> You cannot really prevent null-connection attempts... So the question
>> is -
>> how system responds? The GPO that you need is "Named Pipes that can be
>> accessed anonymously", and it must e set to Disable. I don't quite
> remember
>> what the default value is, think it's now secure.
>
> It's not a disable and enable setting. Rather, the states are no
> checkbox
> (which I take to be a third state of "not set") and a checkbox, which when
> selected lets you specify specific null named pipes including IPC$.
>
> I could specify the checkbox and then empty out the list. Is this what I
> should be doing?
>

This is what one should be doing provided one does want to not
have any available to null sessions / anonymous user
and this is what the hardening guide recommends on to do, again,
provided that there should be no such shares or named pipes available,
ie. check it for only these and use an empty list

> And for my education, when I do not select the checkbox, what is the
> default
> behavior?

There is none. When not checked there is no change to what is
already in existence. While Windows installs with default values
in the corresponding reg values, there is no guarantee that those
are still as at install, and it is whatever is in them that will be
effective if there is no policy (not checked) impacting them.

>
> And, also, when I do or do not select the checkbox, does either setting
> have
> any effect on a Windows 2000 DC?
>
Sorry, cannot answer, as now W2k DC free.
However, IIRC these settings, as policies, came about later, but
they may be making use of reg vals that W2k already had in which
case they would have effect.


In your inital post you covered the resultant view in your question 4
<quote>
4) When you deselect the checkbox on this group policy, and simply
fail to define any entities, then what are the defaults that will be in
effect?
When I ran RSOP.MSC on one Windows 2003 DC, it had none of
these defined even through its local policy and GPO did not select
checkboxes for any ofthese.

If the lack of any settings in RSOP.MSC means that nothing is being
allowed for anonymous access, then would I get the same result by
enabling the checkbox, and simply forcing the list of each GPO
setting above to be empty?
</quote>

Hopefully you are now clear on "defaults" when policy is unused to
effect a change from the current (on box) settings - they are whatever
is otherwise current settings.

You say rsop on a W2k3 DC showed none checked "even though"
local policy and GPO had none checked.
Isn't that what one would expect ?? (also, there is no local policy
for a DC except for use in a DS restore mode boot)

The lack of any settings in the rsop means either the rsop in not
accurate, or that there is no policy effecting what is set for those,
and so they are at whatever they are otherwise (outside of policy)
set. Remember there is a "op" at the end of rsop - it only shows
the result of all relevant policies - not all policies plus machine
state (ie. if no policy effective on something it is not showing
the machine state that is being left unchanged).

Now Will, notice that I hung back not replying initially to your
post. That is because there tends to be a behavior that posts with
replies get less attention, and I really want to see MS respond to
you on this issue of getting rid of all null sessions - per our exchange
in some other thread(s).
Anyway, I notice you have not mentioned the policy
Network access: Restrict anonymous access to named pipes and shares
which for W2k3 exists and controls whether the two separate lists
of anonymously available named pipes and of shares are even used.
If this value is not defined to be used the lists are not used and there
is no restriction being imposed.
I mention that as the docs seem to speak as if this set of three policies
exist and work this way in Wk23 and in XP, but in XP the policy that
toggles the two lists does not seem to exist as a settable policy when
using the default sceregvl.inf file.

As you know, no one in these newsgroups has been providing a
definitive list of the necessary named pipes that must be available
from a DC for anonymous access if the DC is going to support the
default set of authentication protocols; of when such as samr can
be removed (i.e. what one looses - precisely what), etc..
Earlier we when through the ones that obviously are present only
for the sake of supporting layered products (IBM mainframe interop,
etc.) but the info dries up after going very far down the road. As Joe
initially commented in prior thread, this may in part be evidence that
no one in MS really knows any longer what some of these are/were
for - precisely that is. I tend to think of this area as on that has been
getting incremental refinement attention from MS over the past few
years, but which still needs further such attention / documentation.

Roger



Posted by Will on February 24, 2007, 2:30 am
Please log in for more thread options
> You cannot really prevent null-connection attempts... So the question is -
> how system responds? The GPO that you need is "Named Pipes that can be
> accessed anonymously", and it must e set to Disable. I don't quite
remember
> what the default value is, think it's now secure.
>
> And most recently (W2K3 SP1) there are no named pipes you can possibly
> connect to anonymously:
>
> https://blogs.msdn.com/spatdsg/archive/2006/05/15/598260.aspx

The behavior of the four GPOs that allow you to specify anonymous access to
named pipes, shares, and registry paths are very misleading. You select a
checkbox to make an explicit selection. You then delete the contents and
apply or save. Now when you open it again, Windows has AUTOMATICALLY
populated it for you!!

So by doing the above action, you incorrectly believe you are explicitly
setting these to null values, when in fact your action has 180 degrees the
opposite effect and blanking the list implicitly enables every anonymous
access! It's a very bad UI design.

I guess the absence of any setting means a null list? That's also not
clear.

--
Will



Similar ThreadsPosted
Explanation of Anonymous Named Pipes Security Policy August 20, 2006, 9:28 pm
Anonymous folder access December 13, 2006, 9:14 pm
Enterprise Ca authority anonymous access January 16, 2007, 4:07 pm
Anonymous Access to Shared Folder November 5, 2007, 1:13 pm
Outlook Compatibility issue with Disabling Anonymous Access September 13, 2007, 2:22 pm
user cannot access shares October 21, 2005, 12:30 pm
Re: user cannot access shares October 25, 2005, 10:23 pm
How can admin not have access to certain shares? February 16, 2008, 12:36 pm
Trusted NT domain users have full access to 2K3 server shares January 23, 2007, 6:51 am
Controlling access through a remote access policy August 19, 2005, 7:00 am

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap