Bugtraq mailing list archives
Re: Security hole in Win2K's FTP server
From: dankamin () CISCO COM (Dan Kaminsky)
Date: Mon, 17 Jul 2000 16:09:45 -0700
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
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)