RE: SSL

[Bruce Platt <Bruce () ei3 com>]

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
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.

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
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 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.

Since I have neither the skill the write such a piece of code, nor the
desire to encourage one to do it, I am going to stop here.

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

Regards

-----Original Message-----
From: Paul D. Robertson [mailto:proberts () patriot net]
Sent: Thursday, October 18, 2001 11:37 PM
To: R. DuFresne
Cc: Bruce Platt; Crumrine, Gary L; firewall-wizards () nfr com
Subject: RE: [fw-wiz] SSL


On Thu, 18 Oct 2001, R. DuFresne wrote:

> This was enlightening, more so then what I'd read and seen privious to
> going over this, thanks.
>
> Reading through the document, it seems perhaps one can block the infection
> of nimda by not letting tftp traffic through?!  Would others agree this
> would be a way to block infections under the SSL schema Gary outlined?

The HTTP/HTTPS vector is sort of self-contained for the wormy part and
for the virus part.  At the point you go from worm to virus (server to 
client) the client machine is infected rather aggressively (ok- *very*
aggressively.)  Unless I missed some special pre-condition in
Gary's explaination, blocking tftp doesn't help one bit for server->client
infection (only server->server.)

The non-worm viral vector happily infects shares, documents, tries to mail
itself with OE, etc.  Fortunately the first version didn't seem to cross 
vectors except at the .eml/.nws infection of Web pages.

If you're worrying about the class of problem, it's a lot more serious
that it *could* cross vectors trivially using either http/https, share
hunting, mass mailing, or viral spreading.  If all the infected clients had 
crossed back to the worm vector via HTTP/S to uninfected servers things
would have been significantly worse.

> Two further tags one might well key on would be the Admin.dll and
> README.EML files this worm tries to pushout.  This is all assuming of
> course that the attack vector does not traverse the SSL path to the
> infected server, which I did not see anything to indicate such in the pdf
> document.

It infects files that would go via SSL (server to client, not the other
way unless you're pushing content to the server via https.)

The good news for the specific nimda problem is that you get the URL via
the CONNECT method, so you can URL filter on *.eml (and *.nws) if your
proxy allows that.  Unfortunately, you've only stopped .eml/.nws-using
worms, and there are a few more auto-executable content types in the
Microsoft world. What you really need is to block everything but
htm/html/asp (assuming there's not an .eml rendering trick that you can do
in-frame.)  I'm still not 100% sure that you couldn't get the EML/NWS
through via something else like the class-id thing though.

(I'm not sure it ever used .nws for server<->client infection, but it did
for client infection, so I'd cover that base anyway.)

You don't even get the chance to catch the MIME mismatch via SSL.


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