Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Microsoft
[Top] [All Lists]

Re: Fw: Serious Security Issue in Windows XP SP2's Firewall

Subject: Re: Fw: Serious Security Issue in Windows XP SP2's Firewall
Date: Tue, 28 Sep 2004 11:52:46 -0500
Heya Tim,

I'm not trying to bash MS, but I do have a few comments. Please see
inline.

On Mon, 2004-09-27 at 21:12, Thor wrote:
If the system is a domain member, exceptions for F&P Sharing will be enabled 
for the local subnet.  This applies to all interfaces. 

Design Flaw #1: While the approach to determine if the PC is used at
home or in a corporate setting (domain membership) seems like a sensible
way, the fact that it is treating all interfaces as equal is not.
Network interfaces, dial-up interfaces and VPN interfaces all have
different... uhm... levels of trust. I mean, you know where you stick
your network cable into, but dialing with the RAS adapter to the
Internet just is not the same. Know what I mean?

 If 
Pre-SP2, you had a dial-up interface **that had file and print sharing BOUND 
to the adapter** but, had the ICF turned on so that the bindings were 
unreachable, and it was a domain member, and you then installed SP2, the 
"global" exceptions would be applied and the firewall turned on for all 
interfaces.

Design Flaw #2: Multiple policies conflict in interface protection. The
problem here is that you apparently have ICF policies on one hand and
"exceptions" on the other. These two policy sets conflict. If you
configure your firewall to block ports, you should not expect a
different policy to override this. Which policy governs? The
purposefully set one, or an exception? How do you, as a user or admin,
know which one is in affect? There is no feedback to the admin that
displays the "effective" policy, including exceptions.

[...] people on the local subnet only will 
not have NB filtered by the firewall.  But even so, null connections don't 
work, and if an account does not have a password, it can't be used for 
network connections.  No world readable, no "blank password access," no 
issue unless you specifically CREATE the issue on purpose.

That is a very unthoughtful answer which I would not have expected from
you. Even if null connections are disabled and you don't have a user
name and password, you still have the annoyance of pop-up spam (yes, you
could argue that the Messenger and Alerter services are off now by
default, but that's not the point. Data is accepted, without a password,
and used by the system). 

More important, what about undiscovered buffer overflows in the SMB/CIFS
protocol handling? Firewalls are not there to protect us from the known
issues, but from the unknown issues. Firewalls should be configured to
block all, except allowed ports, not to allow all and block selected
ports. Are you saying that if your system requires authentication, you
don't need a firewall? I don't think so.


Microsoft were to benefit greatly if they take KISS to heart. It seems
that applying more than one policy (fw policy AND exceptions)
unnecessarily over-complicates things. Unforeseen consequences can arise
that hurt the security of a system greatly. Keeping things simple wold
be in the best interest of security.

Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>