Shares, Named Pipes, and Registry for Anonymous Remote Access

[Will]

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.

[S. Pidgorny <MVP>]

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 =-

Post by Will
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
Named Pipes that can be accessed anonymously
Remote access registry paths
Remote access registry paths and subpaths
Shares that can be accessed anonymously
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

[Will]

Post by S. Pidgorny <MVP>
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?

[Roger Abell [MVP]]

Post by S. Pidgorny <MVP>

Post by S. Pidgorny <MVP>
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

Post by S. Pidgorny <MVP>
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

Post by S. Pidgorny <MVP>
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.

Post by S. Pidgorny <MVP>
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

[Will]

Post by S. Pidgorny <MVP>
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
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.

[Roger Abell [MVP]]

Post by S. Pidgorny <MVP>

Post by S. Pidgorny <MVP>
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

Post by S. Pidgorny <MVP>
what the default value is, think it's now secure.
And most recently (W2K3 SP1) there are no named pipes you can possibly
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.

I believe that is a known bug - at what OS rev do you experience as such?
Not sure, but I thought I saw a KB related some time back.

Roger

[Will]

Post by Roger Abell [MVP]

Post by Will
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

Post by Roger Abell [MVP]

Post by Will
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.

I believe that is a known bug - at what OS rev do you experience as such?
Not sure, but I thought I saw a KB related some time back.

I saw this behavior on Windows 2003 with SP1 and all Windows Update patches
through last Friday applied.

So at this point I am pretty much baffled. The only way to null out the
lists of anonymous entities through GPO is to select the checkboxes and
explicitly empty the contents of the lists (of anonymous pipe, shares,
registry paths and subpaths). But doing that has precisely the opposite
effect and the entities are silently repopulated and in fact you end up
forcing the exposure of anonymous entities by virtue of the checkbox. I
can't imagine a more serious bug, short of one that stops the OS from
booting.

It almost feels safer to run with nothing selected since GPO has a bug
(apparently) and empty out the registry entries manually. Does anyone
know which four registry entries contain the lists that correspond to those
GPOs? I'll go look for those in Windows 2000 as well and post the result
of what happens when I empty those on a Windows 2000 DC. Probably
something there will break. Fortunately, we do not have multi-domain
forests and I could even live without trusts if push came to shove.

[Roger Abell [MVP]]

Post by Will

Post by Roger Abell [MVP]

Post by Will
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

Post by Roger Abell [MVP]

Post by Will
a
checkbox to make an explicit selection. You then delete the contents

and

Post by Roger Abell [MVP]

Post by Will
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

Post by Roger Abell [MVP]

Post by Will
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.

I believe that is a known bug - at what OS rev do you experience as such?
Not sure, but I thought I saw a KB related some time back.

I saw this behavior on Windows 2003 with SP1 and all Windows Update patches
through last Friday applied.
So at this point I am pretty much baffled. The only way to null out the
lists of anonymous entities through GPO is to select the checkboxes and
explicitly empty the contents of the lists (of anonymous pipe, shares,
registry paths and subpaths). But doing that has precisely the opposite
effect and the entities are silently repopulated and in fact you end up
forcing the exposure of anonymous entities by virtue of the checkbox. I
can't imagine a more serious bug, short of one that stops the OS from
booting.
It almost feels safer to run with nothing selected since GPO has a bug
(apparently) and empty out the registry entries manually. Does anyone
know which four registry entries contain the lists that correspond to those
GPOs? I'll go look for those in Windows 2000 as well and post the result
of what happens when I empty those on a Windows 2000 DC. Probably
something there will break. Fortunately, we do not have multi-domain
forests and I could even live without trusts if push came to shove.

I am not sure but that the repopulation is just happening when the
policy is edited but that the edit emptying it saves correctly.

Remember, these are saved into sce's persisted structures, and will
only show in registry after policy is applied.

The keys for almost anything in the Security Settings section of
policy can be located by use on notepad with sceregvl.inf file.
Worse come to worse, search on the display string used in UI,
then on its %substitution string% in strings section then search
on that

MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymous,4,%RestrictAnonymous%,0
MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM,4,%RestrictAnonymousSAM%,0
MACHINE\System\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths\Machine,7,%AllowedPaths%,4
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes,7,%NullPipes%,4
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionShares,7,%NullShares%,4

[Roger Abell [MVP]]

Post by Roger Abell [MVP]

Post by Will

Post by Roger Abell [MVP]

Post by Will
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

Post by Roger Abell [MVP]

Post by Will
a
checkbox to make an explicit selection. You then delete the contents

and

Post by Roger Abell [MVP]

Post by Will
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

Post by Roger Abell [MVP]

Post by Will
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.

I believe that is a known bug - at what OS rev do you experience as such?
Not sure, but I thought I saw a KB related some time back.

I saw this behavior on Windows 2003 with SP1 and all Windows Update patches
through last Friday applied.
So at this point I am pretty much baffled. The only way to null out the
lists of anonymous entities through GPO is to select the checkboxes and
explicitly empty the contents of the lists (of anonymous pipe, shares,
registry paths and subpaths). But doing that has precisely the opposite
effect and the entities are silently repopulated and in fact you end up
forcing the exposure of anonymous entities by virtue of the checkbox.
I
can't imagine a more serious bug, short of one that stops the OS from
booting.
It almost feels safer to run with nothing selected since GPO has a bug
(apparently) and empty out the registry entries manually. Does anyone
know which four registry entries contain the lists that correspond to those
GPOs? I'll go look for those in Windows 2000 as well and post the result
of what happens when I empty those on a Windows 2000 DC. Probably
something there will break. Fortunately, we do not have multi-domain
forests and I could even live without trusts if push came to shove.

I am not sure but that the repopulation is just happening when the
policy is edited but that the edit emptying it saves correctly.
Remember, these are saved into sce's persisted structures, and will
only show in registry after policy is applied.
The keys for almost anything in the Security Settings section of
policy can be located by use on notepad with sceregvl.inf file.
Worse come to worse, search on the display string used in UI,
then on its %substitution string% in strings section then search
on that
MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymous,4,%RestrictAnonymous%,0
MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM,4,%RestrictAnonymousSAM%,0
MACHINE\System\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths\Machine,7,%AllowedPaths%,4
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes,7,%NullPipes%,4
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionShares,7,%NullShares%,4

Here is the other, which is curiously not present in the XP sceregvl.inf
and hence not available for use in an editing governed by it
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\RestrictNullSessAccess,4,%RestrictNullSessAccess%,0
I find that omission troubling as it is the enabling setting for the
ones that are present.

Notice the comment in the Threats and Countermeasures Guide about it
<quote>
When enabled, this policy setting restricts anonymous access to only those
shares and pipes that are named in the Network access: Named pipes that
can be accessed anonymously and Network access: Shares that can be a
ccessed anonymously settings. This policy setting controls null session
access to shares on your computers by adding RestrictNullSessAccess
with the value 1 in the registry key
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters.
This registry value toggles null session shares on or off to control whether
the server service restricts unauthenticated clients' access to named
resources.
</quote>
http://www.microsoft.com/technet/security/guidance/serversecurity/tcg/tcgch05n.mspx

You might want to read comment on some of the others, as for a couple
the W2k equivalents are mentioned. Also, the list of named pipes the
Guide shows (incomplete) is termed the "Default Named Pipes",
whatever that is actually intended to mean (populate policy setting
whenever edited in a GPO despite it having previously been edited
and set to empty by intent).

The comment on the default setting being same as recommended setting
for anonymously accessible shares is also wrong, if you notice.

Needless to say, next time there is a call for review of the Guide, getting
more clarity on these types of questions is on my list of things to push for
(most of last time did result in some changes so perhaps it will improve).

[Will]

Roger a brief summary:

1) You were completely correct that if I select the checkbox for the lists
of anonymous shares, pipes, and registry entries and then empty them, the
null setting does take effect on next application of the GPO. The bug
where these repopulate is simply within the GPO editor. It's still nasty,
but less serious than it looked at first.

2) Even after you take out ALL anonymous shares, pipes, and registry
settings, and set the authentication level to refuse LM and NTLM, you will
still get eventid 540 and NTLMSSP anonymous connections from every member
server that is seeking to renew a Kerberos ticket. This is at least true
with a Windows 2003 DC and W2K member servers. Not sure if this changes
with Windows 2003 member servers (I would like to know).

I would sure like to understand what the NTLMSSP anonymous logon is used
for. Perhaps that eventID 540 Anonymous Logon is a pre-Kerberos
authentication just to ask the domain controller what authentication methods
it supports using NTLM 2? If anyone has specifics on what it is used for
I would appreciate details.

3) I looked at all of this with a sniffer, and what is quite strange to me
is during the prenegotiation period before the member server attempts to do
any SMB to the DC, the member server is listing the protocols it would like
to work with. It lists very unsecure protocols including Windows for
Workgroups 3.1, early LANMAN protocols, etc. It is the server that comes
back and lists only two acceptable protocols as Kerberos and NTLMSSP. Why
is the W2K member server asking for unsecure protocols when the
authentication level is set to the highest. Strange.

Obviously I don't understand it too well yet, but would like to change that.
Is there a newsgroup that specializes in programmers using Windows
authentication APIs?

[Roger Abell [MVP]]

Post by Will
1) You were completely correct that if I select the checkbox for the lists
of anonymous shares, pipes, and registry entries and then empty them, the
null setting does take effect on next application of the GPO. The bug
where these repopulate is simply within the GPO editor. It's still nasty,
but less serious than it looked at first.

Yes, it is very pernicious.
I think I did see a KB warning about this though,
but I certainly cannot locate it currently.

Post by Will
2) Even after you take out ALL anonymous shares, pipes, and registry
settings, and set the authentication level to refuse LM and NTLM, you will
still get eventid 540 and NTLMSSP anonymous connections from every member
server that is seeking to renew a Kerberos ticket. This is at least true
with a Windows 2003 DC and W2K member servers. Not sure if this changes
with Windows 2003 member servers (I would like to know).

I think it remains so with members also.
I only see those go away for example on my IIS w2k3 r2 members when
the IPsec cloak leaves only tpc 80, 443 open to the authentication attemps,
hence blocking this (what?) residual successful anonymous login.

Post by Will
I would sure like to understand what the NTLMSSP anonymous logon is used
for. Perhaps that eventID 540 Anonymous Logon is a pre-Kerberos
authentication just to ask the domain controller what authentication methods
it supports using NTLM 2? If anyone has specifics on what it is used for
I would appreciate details.

I have not seen details, and would similarly appreciate MS providing
more clarity on this entire topic for their customer base.

As I stated in a different thread with yourself, my present working
assumption is that the event recorded is the initial SSPI negotiation,
which of course by definition must be prior to any authenticated
access. It is of course only my current hypothesis, but I do recognize
what you are reporting, that one cannot remove all successful logon
events for anonymous.
PS.
my weak point on the hypotheis is why we see SPNEGO events
that are separate from the NT Authority\Anonymous Logon
success events

Post by Will
3) I looked at all of this with a sniffer, and what is quite strange to me
is during the prenegotiation period before the member server attempts to do
any SMB to the DC, the member server is listing the protocols it would like
to work with. It lists very unsecure protocols including Windows for
Workgroups 3.1, early LANMAN protocols, etc. It is the server that comes
back and lists only two acceptable protocols as Kerberos and NTLMSSP.
Why
is the W2K member server asking for unsecure protocols when the
authentication level is set to the highest. Strange.

IIRC the SSPI negotiation starts with the requestor listing
the protocols it is capable of using (you said ones it would
like to use). Sever responds with its preference. It is after
all a negotiation, so requestor may not support servers first
choice, etc..

Post by Will
Obviously I don't understand it too well yet, but would like to change that.
Is there a newsgroup that specializes in programmers using Windows
authentication APIs?

http://msdn2.microsoft.com
specifically digging in at
http://msdn2.microsoft.com/en-us/library/default.aspx
(and do not overlook the DDK - driver dev kit)

When I was first charged with exploring MS Windows for its
fit/misfit in our environment, the SDK (via MSDN) was THE
(as in only) location for any realistic, meaningful, and not
outdated, info about Windows operation (and hence rigorous
administration/management).
Things have improved greatly, but there is still gap.

Roger

[Roger Abell [MVP]]

Post by Will
Obviously I don't understand it too well yet, but would like to change that.
Is there a newsgroup that specializes in programmers using Windows
authentication APIs?

Sorry Will, I misread, missing that you were asking about forums,
not API docs. MSDN has its own forums,
http://forums.microsoft.com/msdn
and there are some other resources like lists of Developmentor
(http://discuss.develop.com/) which are now-a-days more shifted
toward web services.
I am sure you can google out others.