First of all, I do agree with your suggestion about isolating the web
server, but the eEye vulnerability is another ball game.
A properly secured IIS server would not be vulnerable to the Unicode
exploits, or eEye vulnerability for couple of reasons. One is the ACL on the
cmd.exe, which prohibits the user IUSR_MACHINE accessing it. The other is a
simple file move. By default the cmd.exe is in the Winnt\System32 folder.
Just create a new folder, like %any drive%:\Stayaway, and move most of the
executables there from the System32 folder. The local execution of the
commands are also disabled by the move, however they can be executed from
the new folder. A small inconvenience at the most.
The Unicode, which depends on those executables being in at the default
location, becomes useless. Even if the proper location of the cmd.exe
becomes known, the ACL would prevent the execution. Every web server has
exploits, however, leaving the server unpached should be blamed on the admin
not on the actual server.
Otto
----- Original Message -----
From: "D. Clyde Williamson" <[EMAIL PROTECTED]>
To: "Brian Steele" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, February 02, 2001 11:55 AM
Subject: Re: Configuration Arguments... In House...
>
> Let's use the example of the eEye vulnerability. With this attack, the
> webserver on port 80 could be dumped and a hacked copy of netcat
> could replace it... the proxy would still permit this traffic, (if the
> proxy is set to look for specific http stuff in the stream... a
> hacked copy of netcat client could pass commands wrapped in what looks
> like http, and the server could strip the http, and execute the
> commands) and the attacker would be sitting at an Administrator
> prompt. From there he could telnet to other servers in the network, or
> install a packet sniffer, or L0phtcrack, or work on the proxy server
> from behind, and attempt to install a backdoor on the proxy
> itself. Then he would be able to connect to the proxy directly, and
> gain access to the network.
>
> It is always best to use the idea of isolation, any system touched by
> 'untrusted' users or networks should be quarantined from the corporate
> network.
>
> Brian Steele writes:
> > Hmm.. Can someone give an example of how a "compromise" that opens the
> > internal network to the attacker could work, if the proxy server is
passing
> > only HTTP traffic on port 80 between the internal server and the
Internet
> > client?
> >
> >
> > Brian
> >
> >
> > ----- Original Message -----
> > From: "Paul Cardon" <[EMAIL PROTECTED]>
> > To: "Kelly Slavens" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Friday, February 02, 2001 11:55 AM
> > Subject: Re: Configuration Arguments... In House...
> >
> >
> > > Kelly Slavens wrote:
> > > >
> > > > I have a situation where I have a Server, which will host
web
> > > > content from "Internal" Data to the external world. This Server
Needs
> > only
> > > > have web services accessible to the outside world beyond our
network.
> > Our
> > > > current configuration is a Cisco Hardware Nat/Router Packet filter
> > directly
> > > > connected to the Internet connection. Connected to that is our
MSProx2.0
> > > > (Being replaced with ISA Server soon)... One individual wishes to
place
> > this
> > > > new web server directly behind the NAT alongside the Prox, With a
so
> > called
> > > > "one way" push only network connection to the internal network.
This
> > seems
> > > > like a bad idea to me. My suggestion was Place the Web server
behind the
> > > > prox and use Reverse prox to redirect all web traffic to only this
> > single
> > > > internal Web server. This to me seems to be more secure than a
second
> > > > machine sitting in the DMZ with a connection to the internal
network.
> > >
> > > With the web server behind the Proxy, if the web server is
compromised
> > > (eg. IIS Unicode vulnerability) then the entire internal network is
open
> > > to the attacker. The other configuration is better but it isn't the
> > > only solution.
> > >
> > > -paul
> > > -
> > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > > "unsubscribe firewalls" in the body of the message.]
> >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
