RE: SSL

["Paul D. Robertson" <proberts () patriot net>]

On Fri, 19 Oct 2001, Bruce Platt wrote:

> I'm not so sure about blocking the readme.eml part.  One could have a web
> proxy block access to a url like http://www.evil-server.com/readme.eml just
> by disallowing a connection on content.  Or, one could just drop packets
> containing readme.eml delivered via http.   But, if one was browsing in at
> that same site by SSL, for example,
> https://www.evil-server.com/hottips.htm, and that page had the
> window.open("readme.eml") script in it, it just got past your firewall.  SSL

I haven't played with nimda server->client since the day it hit, so maybe
my recollections are fuzzy, but it was my impression that the window open
in hottips.htm would create another GET request for readme.eml-  If it
wasn't readme.eml, it was readme.exe.  In either case, that GET request
would expose its URL to an HTTPS proxy.  The quick (HTTP not
HTTPS) window.open test I just did locally via my home proxy confirms this
behaviour, so please let me know if I'm missing something.

Once we realized it wasn't just a worm, but was viral on the client I
stoped my poking and left it to our real AV researchers to 
disassemble/test (I just happened to be up at ICSA Labs that day, so I
could at least do some playing.)  Unlike the pdf's assertion of rareity, I
found .nws files were created every time it ran.  

> is end to end, right, so the contents of the packets aren't normally
> scannable by the proxy.  And, you couldn't even drop the packets based on
> the content.  This defeats all the neat little packet filter gateways and
> clever tools like hogwash.

That's always been one of my arguments against packet filtering firewalls
for sole protection for organizations who are concerned about active
content issues.  There's no surprise here for anyone who's gamed this out
before.  A proxy however is a different beast- since the packets are
reassembled and parsed as such- the anti-javascript patches to http-gw are
an example of how to do this (though the code is very, very ugly), it just
needs an MITM attack to get the content in the clear (which was one of my
goals in life at one point that Fred so fondly remembers.)

> Apparently Nimda infects web servers via the Admin.dll vector and as best as
> I can tell, it only looks to use http not https.  Unless I misread the

Server->server that's true, server->client the pages will serve just as
well over https as they do over HTTP, but that javascript-nuking http
proxy won't be effective in the least if you connect to the server via
HTTPS without an MITM attack.  The server->server stuff is straight worm,
the server->client stuff isn't auto-replicating, once a client is
infected, it's viral with some wormy bits.  Some Web servers were infected
by clients updating over shares, or people updating by pushing entire
directories up to the server (where the readme.eml would also get
propogated.)

> forensics Nimda spreading by file share vulnerabilities wont't use that
> route to infect a web server.  But I see no reason why someone cannot craft

A Web server or staging server that's sharing out a writable directory to
developers/designers will most certainly be infected via that vector, as
will one where the content is pushed en-masse to the server from the
developer/designer's workstation.  Forensics in the real world showed this
to happen, I haven't poured over the PDF cited, just scanned it- but if it
misses that, it's a shame.

> a verminous piece of code that could use other attack vectors to infect a
> secure site by taking advantage of some of the tactics used in Nimda.

That's the usual progression in modification of subsequent malicious code
after a successful virus/worm.

> I do know that every defense we have should be applied in depth as we all
> know.

The point however is that at least thus far, people haven't been willing
to even ask for "every defense" when it comes to encrypted traffic, and
the balance between "privacy" for users and "security" for networks is
increasingly going to become an issue.  

The reason I popped up in this thread is that I was pretty vocal in the
past with "we do proxies because they're more secure"-type vendors who'd
do a fairly good job of proxying HTTP and giving the ability to block
executable content, but who'd also turn right around and tunnel SSL right
through their products.  At one point at least some of them were waiting
for the KRA's key escrow "solutions" before attempting to MITM SSL.

It's been a few years since I went to the mat with a vendor over this
issue, but IMO, Gary's right to worry over this because we still don't
have an effective protection layer off of the client platform from most
vendors (I have yet to check the links I've been sent as a result this
thread.)  

Look at Web server test tools and then count how many of them even check
SSL as a vector and you'll see that this blindsides a *lot* of
otherwise savvy people who haven't thought the problem through.

Fortunately, we create our own tools for significant events, so we don't
tend to have that problem.

Paul 
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards