Basic Security Questions

[Guest]

1. I have a standalone, single user notebook and realize that cookies can and
will be used against me by bad guys on the net. My concern is what MSAS calls
"Tracks". Are they a net hazard too or just a privacy issue for multiple user
PCs?

2. MS Baseline Analyzer 2 is not happy with the number of shares on my PC
and would like me to change permissions or eliminate a few. When I go to
Control Panel/ Administrative Tools/ Computer Management, each share I "open"
says "This has been shared for Administrative purposes. The share permissions
and file security cannot be set". My four shares are: ADMIN$, C$, E$ and
IPC$. What should I do?

Thank You.
BobW

 

[Colin Nash [MVP]]

1. I have a standalone, single user notebook and realize that cookies can
and
will be used against me by bad guys on the net. My concern is what MSAS
calls
"Tracks". Are they a net hazard too or just a privacy issue for multiple
user
PCs?

2. MS Baseline Analyzer 2 is not happy with the number of shares on my PC
and would like me to change permissions or eliminate a few. When I go to
Control Panel/ Administrative Tools/ Computer Management, each share I
"open"
says "This has been shared for Administrative purposes. The share
permissions
and file security cannot be set". My four shares are: ADMIN$, C$, E$ and
IPC$. What should I do?

Thank You.
BobW

1. Cookies aren't necessarily a bad thing. Basically, they are text files
that web sites can save on your hard drive and only that site is able to
access the file. The file usually contains settings or preferences for that
site... for example some sites that require logins/passwords might save that
info there. It's important to note that cookies only save information that
the web site was already able to learn about you. They exist to allow sites
to recognize you after you repeated visits... basically to prevent the site
from treating you as a brand new visitor each time. By "tracking", MSAS is
referring to the fact that sites could potentially use a cookie to determine
if you have visited there before. Advertising sites (sites that embed there
banners into other web pages) often use cookies to track what types of web
pages you go to, usually for statistical or marketing purposes. So unless
you have some privacy concerns, you are pretty safe to just ignore cookies
completely... it's a privacy concern for some people, but cookies themselves
are not a threat your PC. You can set the browser to block cookies, but
this may make some web sites stop working.

2. Those shares are completely normal and are usually left alone. Only
people who know the name and password to an "administrator"-level account on
the system can access the C$, E$ etc drive shares, and file sharing usually
will not work over the Internet (especially if you have a firewall.) So
it's a concern only if you have other systems on a local network. If you
want to prevent these shares from being created, look here:
http://support.microsoft.com/?kbid=288164 (title is for NT4.0 Server, but
this will work on Windows XP as well.)

 

[Guest]

Colin Nash,
Thanks for the detailed response to my questions. I have been confused on
both issues for some time. I printed your post.

Thanks again,
BobW

 

[cquirke (MVP Windows shell/user)]

On Fri, 14 Oct 2005 22:25:01 -0700, "BobW"

2. MS Baseline Analyzer 2 is not happy with the number of shares on my PC
and would like me to change permissions or eliminate a few. When I go to
Control Panel/ Administrative Tools/ Computer Management, each share I "open"
says "This has been shared for Administrative purposes. The share permissions
and file security cannot be set". My four shares are: ADMIN$, C$, E$ and
IPC$. What should I do?

It's not "how many" shares, but what is exposed.

In this respect, c$ is a bloody menace! It exposes several startup
points into which malware can drop code, so that this code will run
the next time the PC starts up.

XP Home is said to disable these admin shares.

XP Pro is said to disable access to these shares if the account
password is null, but will expose them if password is not null. So
your "defence" then may hinge on the strength of that password.

If possible, don't bind File and Print Sharing to untrusted networks.
The Internet is the mother of all of these.

You can kill c$, e$ etc. (but not IPC$) via this .REG...


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
"AutoShareServer"=dword:00000000
"AutoShareWks"=dword:00000000


....but this setting can be reversed by malware, malware clean-up, and
various "just re-install" etc. scenarios.

 

[cquirke (MVP Windows shell/user)]

"BobW" <[email protected]> wrote in message

1. Cookies aren't necessarily a bad thing. Basically, they are text files
that web sites can save on your hard drive and only that site is able to
access the file.

We've been telling folks "cookies are just text files" for years.
And we've been lying...

"By design, it is left to the web site to determine what
information to store in a cookie and how to store it. Because
of this, a site can choose to store any information in any way
in a cookie, including HTML scripting information."

See:

http://www.microsoft.com/technet/security/bulletin/MS02-015.mspx

http://www.microsoft.com/technet/security/bulletin/MS02-023.mspx

http://www.ciac.org/ciac/bulletins/m-063.shtml

....as per Google(cookies microsoft.com patch Internet Zone)

2. Those shares are completely normal and are usually left alone. Only
people who know the name and password to an "administrator"-level account on
the system can access the C$, E$ etc drive shares

Passwords are a pathetically weak defense, especially for "services"
for which no legitimate use exists (as applies when one has a
stand-alone system, to which NO "remote admin" should gain access):
- passwords can be cracked
- malware can tail in via some already-logged-in process

file sharing usually will not work over the Internet (especially if you
have a firewall.) So it's a concern only if you have other systems
on a local network.

Concerns arise if you are forced to bind File and Print Sharing to the
network adapter that leads to the Internet (e.g. one PC is Internet
Connection Sharing host, through which other PCs access the 'net via
the same LAN card used for F&PS), or if your LAN is not cable-bound
(i.e. WiFi, Bluetooth, IR, etc.)

Even if it is "only" your own LAN that uses F&PS, it's best to avoid
full-sharing any code or any part of the startup axis, so that if one
PC is infected, infection can't spread to other PCs.

 

[Colin Nash [MVP]]

On Sat, 15 Oct 2005 02:40:40 -0400, "Colin Nash [MVP]"


We've been telling folks "cookies are just text files" for years.
And we've been lying...

"By design, it is left to the web site to determine what
information to store in a cookie and how to store it. Because
of this, a site can choose to store any information in any way
in a cookie, including HTML scripting information."

See:

http://www.microsoft.com/technet/security/bulletin/MS02-015.mspx

http://www.microsoft.com/technet/security/bulletin/MS02-023.mspx

http://www.ciac.org/ciac/bulletins/m-063.shtml

...as per Google(cookies microsoft.com patch Internet Zone)

True, there are some exploits in IE relating to cookies, which have been
patched. (Although they are text files, regardless of the contents. Any
scripts embedded are supposed to be treated as if they were scripts on the
web page itself, and there were some exploits that got around this.)... but
I'll still say that cookies are generally safe to leave enabled. Yes, the
more you disable, the more you reduce the attack surface but the question is
whether the functionality of cookies is useful enough to keep. I think it
is.

Passwords are a pathetically weak defense, especially for "services"
for which no legitimate use exists (as applies when one has a
stand-alone system, to which NO "remote admin" should gain access):
- passwords can be cracked
- malware can tail in via some already-logged-in process


Concerns arise if you are forced to bind File and Print Sharing to the
network adapter that leads to the Internet (e.g. one PC is Internet
Connection Sharing host, through which other PCs access the 'net via
the same LAN card used for F&PS), or if your LAN is not cable-bound
(i.e. WiFi, Bluetooth, IR, etc.)

Even if it is "only" your own LAN that uses F&PS, it's best to avoid
full-sharing any code or any part of the startup axis, so that if one
PC is infected, infection can't spread to other PCs.

I agree that disabling file and print sharing, or at least the default drive
shares, is part of hardening a system. That's why MBSA reports this. My
original reply was intended to say that what BobW is seeing is the normal
out-of-the-box configuration for XP Pro and doesn't indicate an exploit or
problem right now. As an aside, most large ISPs block the ports used by
Windows file sharing from crossing the Internet, but obviously one shouldn't
rely on this protection.

 

[cquirke (MVP Windows shell/user)]

There are exploits in IE relating to cookies, which have been patched.

Even AFTER patching, scripts can be hidden in cookies, by design.
That means they represent a higher risk than "text files".

Any scripts embedded are supposed to be treated as if they were
scripts on the web page itself

Why would one want to facilitate this, given realities such as banner
ads that are common across domains, etc.?

I'll still say that cookies are generally safe to leave enabled.

I do too - but I no longer claim they are as harmless as "just text
files". If I could trust the OS to not run them as scripts, I'd be
happier, but to rely on a "protection" mechanism that has already
failed and had to be patched, is ungood.

The more you disable, the more you reduce the attack surface but is
whether the functionality of cookies is useful enough to keep

Generally I agree, though there is a case to be made for limiting
cookies in various ways, e.g...
- killing cookies from known bad guys, a la Spyware Blaster
- possibly limiting cookies to Trusted Zone
- using a web browser that doesn't run scripts in cookies

I'm also bracing myself for the need to revise this assessment, i.e.
if malware begins to explit cookies as a way of dropping scripts.

I agree that disabling file and print sharing, or at least the default drive
shares, is part of hardening a system. That's why MBSA reports this. My
original reply was intended to say that what BobW is seeing is the normal
out-of-the-box configuration for XP Pro and doesn't indicate an exploit

That is true, yes. I don't consider MS duhfaults to be compatible
with safe computing practice, even post-SP2, but your point that these
settings don't indicate interference (unless the user had applied
non-default settings as protection, and this has been reverted) is
well made. IMO, unless you have some dependency on those c$, d$, e$
etc. admin shares, I would most definitely disable them.

There's no way to disable IPC$ beyond the current runtime, and the
associated RPC risk is more effectively managed in other ways
(firewall, patching the RPC service, preventing RPC failures from
restarting the whole system)

As an aside, most large ISPs block the ports used by Windows file
sharing from crossing the Internet, but obviously one shouldn't
rely on this protection.

That's nice to know, and may be a new practice, given Opaserv mileage
(Opaserv spreads purely via F&PS, and spread well) and more recent
mileage (my bro-in-law hooked into his home PC via the Internet from
his iPaq in the field, and that worked via F&PS as recently as 2004).