Re: Security hole in Win2K's FTP server

[dankamin () CISCO COM (Dan Kaminsky)]

> Microsoft has introduced a security hole in the FTP server on Windows
> 2000 Professional.

Surprisingly enough, this is true.  It's just not a hole for the reasons you
might think it is.

> The properties panel for the service has controls
> for specifying "accept" or "deny" lists, and the online help explains
> how to use these controls to explicitly prohibit specific hosts from
> connecting to the service, or restrict access to an enumerated set of
> hosts.  What the online help does not explain is that this security
> functionality has been turned off for the Professional version of
> Windows 2000.

Yes, but the most important fact is that it's *obviously* been turned off.
What you wrote above implies that I could set up an entire filter
configuration like the documentation tells me I can, and then because it's
Windows 2000 Professional, it'll silently fail.  This was enough of a
concern for me that I actually tested out the configuration, which, as
others have commented, "merely" manifests itself as greyed out tabs.

Greying out advanced functionality that's only available in more advanced
versions is a tried and true tactic among shareware authors, though I don't
remember the last time I saw it in an actual professional package(i.e.
PhotoStyler doesn't "hint" about Photoshop's advanced features).  It's not
unheard of, and in and of itself, it's not a security issue.

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.  There's quite a bit that can be
done at the perimeter of secured networks, and even at the perimeters of
particularly sensitive LANs(financial, etc.), but ideally security filters
down all the way to the desktop.  We've seen some extraordinarily expensive
and damaging infections as a result of overdependance on server security,
that much is undeniable.

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.  (Of course, it's not ideally the desktop users
that configure their own remote services, but the ideal is rarer than it
should be.  Anyway I don't think that us IT Security wonks appreciate being
told by MS that the FTP service we *have* to deploy because of user demand
also *requires* permit-all functionality.)

Considering that FTP is a remote service that involves cleartext exchange of
authentication information, removing the capability to easily prevent entire
classes from IPs from even *offering* the correct username/password shared
secrets can do much to increase site security.  Even if IPs aren't
particularly cryptographically secure, the simple knowledge of which IPs are
allowed access can be a secret unto itself, and spoofing IPs outside the
local LAN is an order of magnitude more difficult as well.

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.

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.

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.

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.  The service is too
sensitive, the server is too widely deployed, 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.  There's
no just no benefit to anyone to keep this functionality out--not even
Microsoft, interestingly enough.  (No, they don't win when their OS is
remotely compromised, not even if they had a better version that might not
have been.)

I don't think there was any malice here, just miscommunication between
security developers and product differentiators.  Miscommunications happen.
It's something we all know too well.

Yours Truly,

    Dan Kaminsky