Security hole in file sharing (bug?)

[Massimo]

I don't know if this has already been reported.

I have a Windows XP SP2 computer, fully up-to-date with patches, which
connects to the Internet through a dial-up connection.
In the network settings for the dial-up connection, I have disabled the
"client for Microsoft networks" and "file and print sharing" components, and
I've also disabled NetBIOS on the TCP/IP settings. With this configuration,
I was quite sure my shares wouldn't have been exposed to Internet users...
but I found, instead, that they are. Altough disabled, the file sharing
services are fully accessible, and I was able to connect to them and also
use them (by supplying my username/password).

What's happening here? Are not the connection-specific settings valid
anymore?

This seems to me quite a serious bug!

Massimo

P.S.
I know I can activate the built-in firewall, or stop the server service, or
fully remove the file sharing network component, and so on... but I want to
know why I'm settings things right and they're behaving wrong!

 

[DanS]

I don't know if this has already been reported.

I have a Windows XP SP2 computer, fully up-to-date with patches, which
connects to the Internet through a dial-up connection.
In the network settings for the dial-up connection, I have disabled
the "client for Microsoft networks" and "file and print sharing"
components, and I've also disabled NetBIOS on the TCP/IP settings.
With this configuration, I was quite sure my shares wouldn't have been
exposed to Internet users... but I found, instead, that they are.
Altough disabled, the file sharing services are fully accessible, and
I was able to connect to them and also use them (by supplying my
username/password).

What's happening here? Are not the connection-specific settings valid
anymore?

This seems to me quite a serious bug!

Massimo

P.S.
I know I can activate the built-in firewall, or stop the server
service, or fully remove the file sharing network component, and so
on... but I want to know why I'm settings things right and they're
behaving wrong!

Massimo,

I'm sure there is no bug there. Did you post thru a proxy ? The posting
host header says: adsl203-153-023.mclink.it .AFAIK, dsl is not a dial-up
connection, but a network connection, either LAN or USB.

 

[Roger Abell]

What you report is now what I have experienced.
How is it that you performed your test?

 

[Massimo]

I'm sure there is no bug there. Did you post thru a proxy ?

No. I'm using no proxy.

The posting
host header says: adsl203-153-023.mclink.it .AFAIK, dsl is not a dial-up
connection, but a network connection, either LAN or USB.

That's not true, either. My DSL connection acts like a dial-up one, meaning
I have to establish it through a DSL modem. Anyway, I did some tests, and it
acts the same if I connect through a 56K or ISDN line.

Massimo

 

[Massimo]

What you report is now what I have experienced.
How is it that you performed your test?

I just established my connection, through a DSL or modem connection. I
disabled file/print sharing on the connection, but it seems to be running
anyway.

Massimo

 

[Roger Abell [MVP]]

I did mean to write it is _not_ what I have experienced.

So, with the connection established, and with the two unchecked
in the properties of the network connectoid for your DSL or
modem interface, how then did you test to see that the shares
were accessible? To test this you would have needed to use
another machine on the network to which the DSL or modem
connected (or internet as case may be).

So far I have always found that unchecking these, rebooting for
good measure, will leave no MS networking available on that
interface, whether it is ethernet, a demand driven connection,
Tcp/Ip over firewire, etc. . . .

 

[Steven L Umbach]

Now or not?? -- Steve

What you report is now what I have experienced.
How is it that you performed your test?

 

[Steven L Umbach]

When you open network connections/advanced/advanced settings does it show
file and print sharing disabled [unchecked] for all adapters/protocols
shown?? Have you rebooted the computer since you disabled fps? --- Steve

 

[Roger Abell]

not
When will someone make a free context sensitive and
aware spell/grammar checker for me !!

 

[Massimo]

I did mean to write it is _not_ what I have experienced.

Ok, sorry.

So, with the connection established, and with the two unchecked
in the properties of the network connectoid for your DSL or
modem interface, how then did you test to see that the shares
were accessible? To test this you would have needed to use
another machine on the network to which the DSL or modem
connected (or internet as case may be).

That was exactly what I did. I connected with Remote Desktop to another
machine on the Internet and from that used Windows Explorer to connect to
\\my.public.ip.address\C$.
It asked for username and password and then worked flawlessly...

So far I have always found that unchecking these, rebooting for
good measure, will leave no MS networking available on that
interface, whether it is ethernet, a demand driven connection,
Tcp/Ip over firewire, etc. . . .

I was, too, quite sure about this.
But it seems not to be the case anymore...
Can you test this again on a XP SP2 machine (maybe the bug was introduced
with some patch)?

Massimo

 

[Massimo]

When you open network connections/advanced/advanced settings
does it show file and print sharing disabled [unchecked] for all
adapters/protocols shown??

Not for *every* adapter. I also have a LAN connection, which uses (of
course!) file and print sharing. On this computer, I also created some VPN
connection in order to access my office LAN, and I have file/print sharing
enabled on these, too.
But I disabled all Microsoft networking (including NetBIOS) on the Internet
connection.

Have you rebooted the computer since you disabled fps?

I've had it always disabled on that connection; hey, it's the Internet one

And I can remember quite clearly it wasn't working, some months ago... when
I was in need for it, of course
So I'm guessing it's a SP/patch-introduced problem.

Massimo

 

[Steven L Umbach]

What I would try is to disable it on every adapter to see if that makes a
difference. While connected you could also use the netstat -n command to
view which IP address is using FPS either via port 139 or 445 TCP. After
verifying the IP address, check your network adapters to find that IP
address [ipconfig /all may help here] and check to see if it shows FPS
enabled or not. To further verify results I would physically remove all
other network adapters, and the VPN, to leave just the single adapter for
the internet connection and try to connect again after verifying that file
and print sharing is disabled and after a reboot. If it still works,
uninstall file and print sharing to see what happens. --- Steve

When you open network connections/advanced/advanced settings
does it show file and print sharing disabled [unchecked] for all
adapters/protocols shown??

Not for *every* adapter. I also have a LAN connection, which uses (of
course!) file and print sharing. On this computer, I also created some VPN
connection in order to access my office LAN, and I have file/print sharing
enabled on these, too.
But I disabled all Microsoft networking (including NetBIOS) on the
Internet connection.

Have you rebooted the computer since you disabled fps?

I've had it always disabled on that connection; hey, it's the Internet one

And I can remember quite clearly it wasn't working, some months ago...
when I was in need for it, of course
So I'm guessing it's a SP/patch-introduced problem.

Massimo

 

[Massimo]

What I would try is to disable it on every adapter to see if that makes a
difference.

It does (of course!), but I'm complaining here about the OS giving you the
option for disabling it on a single adapter basis, and then *just ignoring
it*.

While connected you could also use the netstat -n command to view which IP
address is using FPS either via port 139 or 445 TCP. After verifying the
IP address, check your network adapters to find that IP address [ipconfig
/all may help here] and check to see if it shows FPS enabled or not. To
further verify results I would physically remove all other network
adapters, and the VPN, to leave just the single adapter for the internet
connection and try to connect again after verifying that file and print
sharing is disabled and after a reboot. If it still works, uninstall file
and print sharing to see what happens. --- Steve

I know lots of ways to prevent it from sharing everything to the outside
world... I just would like to know why it doesn't work anymore like it used
to (i.e., with different settings for each adapter).

This also seems to be quite related to this issue:

http://www.pcwelt.de/know-how/extras/103039/


Massimo

 

[Steven L Umbach]

I am just trying to help you track down what is going on and verify that FPS
is disabled on the proper adapter. In my experience, it does work when
disabled on a particular adapter. --- Steve

What I would try is to disable it on every adapter to see if that makes a
difference.

It does (of course!), but I'm complaining here about the OS giving you the
option for disabling it on a single adapter basis, and then *just ignoring
it*.

While connected you could also use the netstat -n command to view which
IP address is using FPS either via port 139 or 445 TCP. After verifying
the IP address, check your network adapters to find that IP address
[ipconfig /all may help here] and check to see if it shows FPS enabled or
not. To further verify results I would physically remove all other
network adapters, and the VPN, to leave just the single adapter for the
internet connection and try to connect again after verifying that file
and print sharing is disabled and after a reboot. If it still works,
uninstall file and print sharing to see what happens. --- Steve

I know lots of ways to prevent it from sharing everything to the outside
world... I just would like to know why it doesn't work anymore like it
used to (i.e., with different settings for each adapter).

This also seems to be quite related to this issue:

http://www.pcwelt.de/know-how/extras/103039/


Massimo

 

[Massimo]

I am just trying to help you track down what is going on and verify that
FPS is disabled on the proper adapter. In my experience, it does work when
disabled on a particular adapter.

Well, it definitely shouldn't!
And I remeber it actually used to *not* work on a specific adapter, when
disabled.

Massimo

 

[Alun Jones [MSFT]]

I don't think it'll help you in this situation.

The fault lies in the English language, and the similarity between the words
"not" and "now", in their spelling and in their allowed placements.
Consider the two sentences:

I will now insult your parental lineage.
I will not insult your parental lineage.

Either is contextually correct, at least up until a subsequent line, wherein
it'd be clear as to whether I was, or was not, crafting a rude retort.

Clearly the English language needs to be changed. I'll suggest it for a
future service pack.

Alun.
~~~~

 

[Roger Abell]

Thanks Alun. I was hoping that adding that "and aware" to
emphasize that a purely context sensitive parse would be
insufficient would instill a sense of urgent need. However,
perhaps I should instead have provided a scoping delimiter
for the context, that the parse should not just consider context
in left-right order, as a simple "suggestion" for future service
pack is perhap of insufficient priority relative to the urgency
of need.

--
Roger Abell

I don't think it'll help you in this situation.

The fault lies in the English language, and the similarity between the words
"not" and "now", in their spelling and in their allowed placements.
Consider the two sentences:

I will now insult your parental lineage.
I will not insult your parental lineage.

Either is contextually correct, at least up until a subsequent line, wherein
it'd be clear as to whether I was, or was not, crafting a rude retort.

Clearly the English language needs to be changed. I'll suggest it for a
future service pack.

Alun.
~~~~

 

[Roger Abell]

Oh my. How embarassing (for MS).

It has taken me a while to find the time with the setup to
try this, but yes, I can reproduce what you are reporting.
I used my laptop (needed to wait until I could reboot it,
as I hibernate with long-lived projects for weeks at a time).

Anyway, modem dialup from laptop with both MS network
client and MS file and print unchecked on the DUN interface
connectoid. Then used TS to get remote window (from the
same laptop) on box elsewhere from which NetBIOS ports
would not be filtered between laptop and remote. Ping
check - yep, seeing laptop. Open IE back to IIS on laptop,
yep. Map drive \\<dun-ip-of-laptop>\hiddenshare$ and
bingo - it mapped.

Now, what I forgot to try is a three machine test.
That is, mapping to laptop from a machine to which there
is no RDP term services/remote desktop connection with
the laptop. Why? RDP will map drives within the RDP
session if configured. I just want to rule this out as an
interacting influence here. (I have to figure out where
I need to be for that test, including knowing that NetBIOS
ports will be available between all.)

As you stated in other post, I also know that this did
not behave this way before (but I do not believe I have
ever known for fact that this is so post SP2 of XP).

 

[Massimo]

It has taken me a while to find the time with the setup to
try this, but yes, I can reproduce what you are reporting.
I used my laptop (needed to wait until I could reboot it,
as I hibernate with long-lived projects for weeks at a time).

Anyway, modem dialup from laptop with both MS network
client and MS file and print unchecked on the DUN interface
connectoid. Then used TS to get remote window (from the
same laptop) on box elsewhere from which NetBIOS ports
would not be filtered between laptop and remote. Ping
check - yep, seeing laptop. Open IE back to IIS on laptop,
yep. Map drive \\<dun-ip-of-laptop>\hiddenshare$ and
bingo - it mapped.

Ok, so it was not my fault
It seems to be quite a serious bug; how can I send a bug report to
Microsoft?

Now, what I forgot to try is a three machine test.
That is, mapping to laptop from a machine to which there
is no RDP term services/remote desktop connection with
the laptop. Why? RDP will map drives within the RDP
session if configured. I just want to rule this out as an
interacting influence here.

I don't think it matters: the RDP client uses NetBIOS to map drives, so if
it doesn't work due to being disabled on the server, RDP can't possibly use
it. Besides, you're establishing a RDP session with the machine from which
you connect to your shares, so RDP is mapping shares on the *remote*
machine, if any.
Anyway, you don't need three machines for this test: you only need two
computers with two modems and two phone lines.

As you stated in other post, I also know that this did
not behave this way before (but I do not believe I have
ever known for fact that this is so post SP2 of XP).

Have you looked at this? It says this misbehaviour was introduced in SP1,
and worsened by SP2 which introduced a similar bug in the built-in firewall.
http://www.pcwelt.de/know-how/extras/103039/

Massimo

 

[Roger Abell]

Ok, so it was not my fault
It seems to be quite a serious bug; how can I send a bug report to
Microsoft?

So it would seem.
The public route for reporting is discussed at
https://s.microsoft.com/technet/security/bulletin/alertus.aspx
I will be finding the route to test such that RDP availability
is ruled out, posting internally with MVPs for futher confirms
and experiments, and generally this will likely raise a ruckus in
visible (internally) ways if others see as you have demonstrated.

I don't think it matters: the RDP client uses NetBIOS to map drives, so if
it doesn't work due to being disabled on the server, RDP can't possibly use
it. Besides, you're establishing a RDP session with the machine from which
you connect to your shares, so RDP is mapping shares on the *remote*
machine, if any.

all the same, despite fact that I did use a map network drive, hence a
call to the old Net cmd dll, it is possible that it was intercepted and
instead tunneled inside RDP - possible is enough for me to want to
rule out possibility

Anyway, you don't need three machines for this test: you only need two
computers with two modems and two phone lines.

Or just two if one is on LAN beside a (non-digital) telephone
from which one can get a dialup to something that routes to
within that same LAN without and NetBT filtering (it is the
non-digital phone part that is my issue for this setup, hence
my mind had traveled to ways in three box design).

Have you looked at this? It says this misbehaviour was introduced in SP1,
and worsened by SP2 which introduced a similar bug in the built-in firewall.
http://www.pcwelt.de/know-how/extras/103039/

The last part mentioned we were aware of early on and MS has
now released patch (the do not trust use of "Only local subnet"
exemption choice in the SP 2 firewall). Oddly, the patch was
only released as a critical (IIRC) update through Windows Update
but not as a security bulletin patch. Note that I was testing from
XP SP2 with this patch applied.

This article also states that the exposure exists even with the
XP firewall in use. This I found not true. In my test yesterday
I toggled the firewall on the laptop for the dial-up connection
and it was immediately effective in blocking access from the
RDP client with already existing mapped drive. Toggle firewall
back off and access resumed (note: this despite the fact that
there was a popup saying the change would not be effective
for the current dialup connection due to the in-use condition).