Bugtraq mailing list archives
Re: Security hole in Win2K's FTP server
From: dleblanc () MINDSPRING COM (David LeBlanc)
Date: Tue, 18 Jul 2000 13:16:17 -0700
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
Current thread:
- SuSE Security Announcement: tnef Thomas Biege (Jul 11)
- Re: SuSE Security Announcement: tnef Rainer Link (Jul 11)
- Security hole in Win2K's FTP server Bob Kline (Jul 11)
- CONECTIVA LINUX SECURITY ANNOUNCEMENT - nfs-utils Conectiva Security (Jul 17)
- Re: Security hole in Win2K's FTP server Dan Kaminsky (Jul 17)
- Re: Security hole in Win2K's FTP server Adam Muntner (Jul 18)
- Re: Security hole in Win2K's FTP server David LeBlanc (Jul 18)
- Re: Security hole in Win2K's FTP server Darren Reed (Jul 18)
- MDKSA-2000:018 dump update Vincent Danen (Jul 11)
- Sun's Java Web Server remote command execution vulnerability stuart.mcclure () FOUNDSTONE COM (Jul 11)
- Attacking Windows 9x with Loadable Kernel Modules Solar Eclipse (Jul 12)