Security reduction FTP service on NT4

• To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
• Subject: Security reduction FTP service on NT4
• From: Tim Chilton <Tim_ChiltonSFI.CO.UK>
• Date: Fri, 4 Sep 1998 16:03:44 +0100
• Reply-To: Tim Chilton <Tim_ChiltonSFI.CO.UK>
• Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>

I've just found what I consider a major reduction in overall security
resulting from the implementation differences of FTP under 3.51 vs 4.0
Under NT 3.51, with FTP installed, any user with a valid account can
connect via FTP and exercise the privileges they would have if they were
connected via a share, subject to the overriding read/write flags set on
each disk from the FTP control panel. This is fairly logical since both
shares and FTP are file sharing across the network, just using different
protocols.
Under NT4, with FTP from IIS installed, you need an additional "log on
locally" privileges before you can even connect to the server - (look at
the default privs for the I_USR_<hostname> account). -- Initially this
seems like a good idea, since you can filter who can use the FTP service,
but the "log on locally" priv is also used to allow physical "logon at the
console" access, so if you've any access to the server room (or have remote
control software installed), you can get physical access to the system, and
once you've got that, your'e half way there to the increased access used
for many other eploits. eg -- You've bypassed share level security and have
physical access to the disks - including %SystemRoot%, the registry, and
everything else.
Now, many organisations use FTP for automatic data transfer between their
different internal environments since it's the only common file transfer
protocol  between UNIX, AS/400, Mainframes, NetWare, etc.

As all system admin's generally share access to computer rooms and by
definition an admin has access to the scripts on their own platforms, they
can read the ID/password combination, or even pull it from the wire in
cleartext from the wire since an FTP session is unencrypted. Armed with
this information the admin now has everything needed to get physical access
to an NT box.

I know this comes down to "trusting the administrators" again, but I can't
see any way of using FTP without compromising physical security of the box.

:: Microsoft ::

Why was this change necessary -- As far as I can see it's just opened up
FTP even further for no good reason.

How do I prevent mis-use of this type of access ? -- Why not separate the
real "local" access from the "network" access -- IMHO FTP and SMB are both
"network" access, A local NT session and Telnet are "local" access.

Tim Chilton

_______________________________________________________


This E.Mail is confidential and intended for its addressee only.
If you have received this in error, please delete it from your PC and
inform us by telephone.

No reliance may be placed upon this E.Mail without written confirmation
of its contents and any liability arising from such reliance without
written confirmation is hereby excluded.

Copyright in this E.Mail remains with Sumitomo Finance International plc

• Prev by Date: Re: ISS Security Advisory: Executable Directories in IIS 4.0
• Next by Date: SL-Mail ver 3.0.2423 security
• Prev by thread: Information about the Norton AntiVirus causing BSOD on WINNT4.0 SP3...
• Next by thread: Re: Security reduction FTP service on NT4
• Index(es):
  • Date
  • Thread