Security Basics mailing list archives
Re: what should I do when....
From: Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
Date: Tue, 15 Jul 2008 21:50:00 +0200
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
Current thread:
- Re: what should I do when...., (continued)
- Message not available
- Re: what should I do when.... Adriel Desautels (Jul 12)
- RE: what should I do when.... Nick Vaernhoej (Jul 11)
- RE: what should I do when.... Sergio Castro (Jul 11)
- Re: what should I do when.... Adriel Desautels (Jul 11)
- Message not available
- Message not available
- Fwd: what should I do when.... Eric Starace (Jul 11)
- Re: Fwd: what should I do when.... Adriel Desautels (Jul 12)
- Re: what should I do when.... ॐ aditya mukadam ॐ (Jul 11)
- Re: what should I do when.... Adriel Desautels (Jul 11)
- Message not available
- Message not available
- Re: what should I do when.... Ansgar -59cobalt- Wiechers (Jul 15)
- Re: what should I do when.... Adriel Desautels (Jul 15)
- Re: what should I do when.... Ansgar -59cobalt- Wiechers (Jul 15)
- Re: what should I do when.... Dan Anderson (Jul 15)
- RE: what should I do when.... Scott Race (Jul 15)
- Re: what should I do when.... Adriel Desautels (Jul 15)
- RE: what should I do when.... Rivest, Philippe (Jul 10)
- Re: what should I do when.... Ansgar -59cobalt- Wiechers (Jul 10)
- Re: what should I do when.... Adriel Desautels (Jul 11)
- Message not available
- Re: what should I do when.... Ansgar -59cobalt- Wiechers (Jul 11)
- RE: what should I do when.... Worrell, Brian (Jul 11)
- Re: what should I do when.... Adriel Desautels (Jul 07)
- Re: what should I do when.... Dave Koontz (Jul 08)