Re: what should I do when....

[Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>]

On 2008-07-15 Adriel Desautels wrote:
> I almost feel like you are trying to create an argument just for the
> sake of creating an argument. You didn't answer my initial question
> which was, can you show me a firewall that does *secure* a network?

If you ask me to show you a "secure" network I'd have to ask "secure
against what?"

It ist clearly impossible to ultimately secure any system or network
against all kinds of attacks, because any such system or network would
become unusable. So the basic questions for any security concept are:
against which risks do you want to take countermeasures? On which level
(host/firewall)? And which risks do you accept (because the counter-
measures would be too costly or whatever)?

[...]
> Secondly, I never asked for any method to prevent the attack scenario
> that I described, it was a real world example.

And I described ways to thwart this kind of attack in the real world, to
make clear that these attacks a) aren't irresistible and b) can very
well be dealt with on a firewall-level.

> Your method for preventing the attack would be great in an ideal
> world, but *this* is not an ideal world.

This has nothing to do with ideal or real world. Security measures exist
because someone implemented them. An http-proxy with https-whitelisting
is as easy to set up as a packet filter. You just have to *do* it.

> The fact of the matter is that *most* businesses do not restrict
> outbound SSL traffic and even less of them decrypt and re-encrypt
> traffic for the sake of outbound monitoring.

Yes. So? Just because most people don't do something doesn't mean it
can't be done.

> Not to mention not all of our outbound connections are established
> over port 443, we can use any port,

Have a filtering proxy and a packet filter transparently redirecting all
outbound traffic to ports 80/tcp and 443/tcp to the proxy.

from LAN to any port 80 tcp redirect to proxy
from LAN to any port 443 tcp redirect to proxy
from LAN to any deny
from proxy to any port 80 tcp allow
from proxy to any port 443 tcp allow
from proxy to any deny

And now?

> hell we can even use ICMP or UDP.

What makes you think a firewall couldn't handle (inspect/filter/proxy)
ICMP or UDP packets?

> There are *much* better solutions to the problem of reverse
> connections anyway.
>
> http://www.cs.uit.no/~daniels/PingTunnel/ <-- cool stuff.

I'm very well aware of the fact that connections can be tunneled through
other protocols. That doesn't mean that there aren't countermeasures
against it.

> With respect to your solution, I don't like it.

Well, you're the attacker. You're not supposed to like it. ;)

> You are creating latency by decrypting, inspecting, and re-encrypting
> outbound traffic

Latency can be handled, and hardware nowadays is fast enough to handle
that kind of load. A far greater problem with this method is that it
breaks SSL.

> (and do you really think that your *monitoring appliance* will detect
> our reverse tunnel??).

That depends on its patterns/heuristics, don't you think? And I'm not
talking about appliances. Firewall appliances are boxed devices with
pre-defined functionality. There are lots of other ways to set up
firewalls, and I am definitely not limiting myself to what some vendor
thinks my firewall should be doing.

> You are creating more work for your employees by setting up
> white-lists for outbound browsing instead of doing the inverse.

Ummm... yes, securing something can make things more difficult for the
users. So?

And what do you mean by "doing the inverse"? In your example you were
creating an outbound encrypted connection as a reverse tunnel. How would
one intercept the reverse tunnel without being able to inspect the
content? You do realize that whitelisting was one option, and breaking
SSL to allow for content inspection a second one, don't you?

> Lastly, you are creating what some may consider a vulnerability by
> decrypting and re-encrypting traffic.

It's software. Software may have vulnerabilities, Vulnerabilities may be
exploitable. Duh.

Of course you'd harden (and monitor) a host running the kind of proxy.

> What if someone hacks the proxy? Then all of that *secure* ssl content
> is clear text and theirs for the taking.

Yes. That's why I'd usually avoid breaking SSL. Still, doing so is one
option to thwart the attack vector you used in your example.

> The *better* way to prevent people from being compromised is to use 
> something like OSSEC or Cisco's CSA to control the targeted system and
> limit the possibility of/ease of exploitation. The second thing that
> should be done is to implement proper security policies and personnel
> training. You can monitor outbound traffic, but your IDS/IPS devices
> can only detect what they know to look for, and I know that our
> attacks and payloads are generally very evasive (IDS is flawed
> technology and frankly doesn't work as advertised). If you prevent the
> exploit from working in the first place with OSSEC or CSA then you've
> defeated most, but not all of the issue.

As you say yourself, intrusion detection is a flawed technology (because
it is labor-intensive and will still give false positives and/or false
negatives). I seriously doubt that an IDS is worth the trouble setting
it up in most scenarios.

However, I'm was never arguing against host-security in the first place.
You presented an attack scenario that penetrated a certain firewall
setup. I presented several ways how a firewall could have thwarted that
attack. Nothing more, nothing less.

> Firewalls do not secure networks! People who tell people that they 
> do are doing an injustice (its almost a lie).

A claim this broad is obviously wrong. As I explained in the my previous
mail you achieve security by identifying attack vectors and implementing
countermeasures against them. If you decide against implementing one
countermeasure you won't be secure from that particular attack vector,
but you'll still be secure from others. Security is only binary on a per
attack vector level.

> I break into networks for a living, I bypass your security
> technologies, I circumvent your policies, and I social engineer your
> people, firewalls aren't a challenge.

You haven't bypassed our security technologies. You haven't circumvented
our policies. And you haven't social engineered our employees.

And firewalls can absolutely be a challange if configured restrictively
enough.

Regards
Ansgar Wiechers
-- 
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq