Re: Security hole in Win2K's FTP server

[dleblanc () MINDSPRING COM (David LeBlanc)]

At 04:09 PM 7/17/00 -0700, Dan Kaminsky wrote:
> > Microsoft has introduced a security hole in the FTP server on Windows
> > 2000 Professional.

> The problem is, they've disabled a defensive mechanism against illicit
> usage.  In terms of security posture, there's really nothing weaker than the
> security of a user's desktop--it's a machine built to fulfill the needs of
> an average user, not a security engineer.

Agreed.

> but ideally security filters
> down all the way to the desktop.

Strongly agree.

> That's why I'll go so far as to say this is a security hole, if not
> intrinsically, at least eventually.  Microsoft has really worked so hard to
> make their system network-secure, and yet here they are forcing desktop
> users, the least security conscious of all, to utilize a permit-all rule for
> their desktop FTP servers.

Not quite true.

> There is, incidentally, a work around.  FTP operates on TCP port 21(for
> control, anyway), and W2K Professional does support some degree of internal
> firewalling through the Local Security Settings admin control panel.  There
> are some strange constraints to it--there's some perverse humor in a
> security policy selector that, by default, has no concept of blocking
> access--but it should suffice.

Here's where I'd like to clarify things.  The most flexible way to
configure port filters on Win2k is through an IPSec policy, which can also
be enforced via propogation from the DC (saving you from having to run
around to each workstation).  Take care to put all affected machines in a
"OU" (Organizational Unit) so you don't get all your servers, too.

The UI is a little tricky, so take some time to play with it, test and
understand.  First thing to remember is that there is _not_ an implicit
deny all.  It is primarily meant to allow you to set up IPSec, not shut the
machine off from the network.  A policy is composed of filter sets combined
with actions. To wrap FTP, you'd make a filter of port 21, my system to
allowed subnet (mirrored), and then apply an action of either allow or if
you have passwords flying around in the clear and clients who can also use
IPSec, force IPSec. You then make a new filter of port 21, my system to any
(also mirrored) and associate it with a block action. You do have to go
create a block action - it won't show up on the default list. Now apply
this. Something else to remember is that the rules get applied in order of
most specific to least specific, NOT the order in which you entered them.
Any to any is least, single IP to single IP is most specific.

> The end result, then, is not that Microsoft has effectively disabled FTP
> access permissions, but that they made it much more difficult and obfuscated
> to effectively implement those permissions.  Making it much more
> inconvenient to implement security can be a very covert and extraordinarly
> damaging strategy--see RProcess' writings on Selective DoS.  It's not
> something that's safe to do on a whim.

I'd argue that this isn't really the case - shoving a security policy down
on a system from the DC, on an OU basis, when it joins the domain, or
merely boots thereafter (or at the refresh interval for those systems up
for months - I normally have 90+ day uptimes on my desktops) is far more
convenient and effective than trying to run around to each machine, even if
you're doing it via script.

> There's such a dearth of security implemented on the side of the desktop,
> and with this server code having the potential to be *so* widely deployed in
> *so* many otherwise clueless environments...it isn't really fair to call the
> attempted total removal of this functionality just petty or even ill
> advised.

Actually, it is somewhat rare to see FTP servers on the desktop. But then,
what do I know - I only deal with one of the largest NT-Win2k networks
around, most of which is Win2k. FTP isn't cranked up by default, and most
end-users don't know what it is. You could well have different end-users
than I do.

> It's a judgement call, and it's kinda surprising me to say it, but yeah.
> This is a security hole and it should be patched.

I disagree.  I think IPSec policies are actually more effective and easier
to admin. (Note - this is IMNSHO, and it isn't my decision one way or
another, just my $0.02)

> The service is too
> sensitive, the server is too widely deployed,

I disagree, but YMMV.

> the functionality is too
> standard(is there a shareware FTP server that *doesn't* support some kind of
> IP blocking nowadays?), and the code is far, far, far too written.

What's wrong with doing it in one place, enforcing it at the domain level
and being done with it? From an operational standpoint, it makes sense to
me. Why should every app in the world have to write their own filters and
screw around with trying to do it right? Plus, unless you really know what
you're doing and use the extended (Win32-specific, nonportable) version of
accept(), you can DoS most services by tying them up with a 7-packet
initial handshake and shutdown. If you do it at the IPSec filter level, the
OS just drops the incoming SYN on the floor, and the app never even sees
it. Much cleaner and more efficient.

> There's
> no just no benefit to anyone to keep this functionality out--not even
> Microsoft, interestingly enough.

I'm in ops, not the product group that made this decision, so I can't say
why they did it.  But from the ops POV, I have to disagree.

David LeBlanc
dleblanc () mindspring com