[VOIPSEC] Actual Attacks

[Brian Rosen]

So, before the specifics, an opportunity to vent:
<rant>
I've been involved in work that seeks to allow distributed teams of people
to work cooperatively with one another while separated by distance.  My team
has produced tools which are quite effective.  One of the interesting
aspects of "effective" is how you define it.  Our definition is "you behave
the same using the tool as you do when you are in the same room with your
team".  We have also sought to use tools produced by others to expand our
own work.

In the 6 or 8 years I've been working on this problem, we have had exactly
two sustained, relatively unsolvable-by-us problems.  One is the cost of
bandwidth.  It was dropping like a stone, but it hasn't been lately.  

The other is the "security teams" in the enterprises where we worked (sorry
Britt).

These guys have stopped us cold.  They simply will not allow us to deploy
the tools.

Let me get into a specific.  One of the most effective tools out there is
the applications sharing tool in Netmeeting.  It's been out, available, and
free for 10 years.  Yet, today, 90% of the deployed firewalls stop it.

So, what have we done?  I'll tell you what we did; we changed the protocol
to HTTP, that's what we did.  See WebEx.

WebEx is not quite as good as Netmeeting, and it costs a heck of a lot more,
but it goes through the firewall because it runs on HTTP.

Is that the right answer? NO! It is the wrong answer.  HTTP is not an
appropriate protocol for real time application sharing.  The result of the
stupidity of not allowing dynamic UDP ports running T.120 in any reasonable
way is to force people to get on planes and fly to meetings rather than sit
in their office and have the meeting distributed (or pay through the nose to
make an end-to-end problem a service provider business opportunity while
bypassing the firewall).  

I'll go farther.  Firewalls are a very bad idea.  They have become a crutch
that has two significant, unfixable problems:
	1. It breaks end to end connectivity that is the basis of the
Internet
	2. It provides a convenient short cut to avoid fixing problems
The latter is the real issue.  The former is just a consequence.  By using
the firewall to stop known attacks, you push off the need to fix the
endpoints.  That's a bad approach because there is always a back door.
WebEx is an example of a back door.  IP over HTTP is available.

The right way is to fix the endpoints.  We're dealing with this in IE and
Outlook and ..., because the firewalls don't stop the problems.  We should
deal with it in all the applications.  I know it sounds harder, but
actually, these days, it's not really.  We should give up on walled gardens.
It's getting too easy to breach the walls.  We should deploy systems that
are secure end to end (although getting that with a hop by hop mechanism is
more likely).

The security teams must hate the fact that VoIP is a reality in most
enterprises that are upgrading their phone service.  They haven't gotten to
the real problem yet, but they are about to.  VoIP peering is coming on
fast.  That means instead of just having to allow VoIP within the
enterprise, they have to allow it between enterprises.  And that traffic is
all going to be SIP.  SIP is the interchange protocol for domains that do
not have bilateral arrangements.  All carrier peering is going to SIP.  They
may accept H.323 at the boundary (SBC), so the enterprise could maintain all
H.323 interfaces, if they are content to pay carriers to make all their
interconnections.  But, like Email, why would they?  If you can make a SIP
call over the Internet, and you can receive one, why would you pay a carrier
to connect you to someone else who can do that?

</rant>

And now we return to our regularly scheduled program -- comments inline

> -----Original Message-----
> From: Christopher A. Martin [mailto:chris at sip1.com]
> Sent: Wednesday, February 23, 2005 11:03 PM
> To: 'Brian Rosen'; 'Simon Horne'; voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
> 
> I would like clarification regarding your comment below:
> 
> "> SBCs and firewalls are very unfriendly to any signaling security,
> because
> > they want to peer into the signaling, and sometimes alter it.  They
> could
> > be
> > more visible in the process; for example, a firewall or SBC could be a
> > real
> > SIP proxy server, in the routing path, and thus be a hop in the TLS
> path."
> 
> The fact that an organization or individual places the trust on SIP
> endpoints, in this case, to basically bypass security measures (which you
> stated are unfriendly to signaling security) is ludicrous to me.
Maybe so, but if I got a sips: call from a domain who's cert I was
reasonably sure of, I think I'm a heck of a lot better off than getting a
sip call that passed someone's firewall.

Firewalls (and SBCs) are unable to do anything really useful with respect to
creating SECURE connections.  They hurt.  They can stop some kinds of
problems, but secure connections from an open port are probably a heck of a
lot more useful than insecure connections from a firewalled port.

YMMV.

> 
> Firewalls and border controllers are not merely in place to facilitate
> VoIP,
> :) well at least not the former. They are in place to protect the
> infrastructure from unauthorized use of resources at various levels,
> whether
> it is a home user, enterprise application, or carrier service. But they
> are
> not the silver bullet either.
Well, as above, I think they are an ill-conceived crutch.  They are there
however.  Denying reality rarely gets you anywhere.  If they are there, then
they either have to do one of two things:
1. Be an active participant in a TLS hop-by-hop signaling path, so that they
can look at the signaling and do their thing with it.  This breaks if S/MIME
is used to protect the end-to-end stuff, but it's better than nothing.
2. Pass all TLS protected signaling and sRTP protected media through with no
inspection.

There is a third option, see below.


> 
> Firewalls are becoming more intelligent as they evolve to meet the needs
> of
> these new protocols and applications and because they have to in order to
> provide the protection that they were originally intended for. They are a
> fact of life that will not go away. IDS's and IPS's are also going to have
> to evolve in this direction too.
Actually, what I see happening in the wild is that people are deploying SBCs
in parallel with the firewalls, because the firewalls are not evolving fast
enough to keep up.  I don't like most SBCs either, but they are being
deployed.  I don't see many firewalls that have full SIP support being
deployed.

But to reiterate, neither of them correctly deals with secure connections,
and I have big problems with that.

> 
> SIP and other peer to peer protocols like it pose a very real threat to
> these environments. The very fact that we developed the enablement of
> these
> protocols through these security mechanisms means that the dynamic
> pinholes,
> port redirections, and what have you, are now fully authorized conduits of
> whatever mischief can be thought up unless the security mechanism can
> "peer"
> into the signaling and/or media to determine authorization and
> authentication is not being attacked.
Nope. The idea that you have to "peer" into the signaling is the wrong
approach.  You make the endpoints secure, and depend on them.  You can never
make the walled garden secure.

The firewall vendors have not been very supportive of the "midcom" stuff
that seeks to have intelligent signaling devices be able to tell them how to
open the pinhole.  Probably an economic issue, as well as a control-freak
kind of thing.  Reality is that there is no other way to correctly determine
how to open the pinhole.  

I'm not a fan of pin hole firewalls, but if you want to do it, do it right.
That means having the endpoint tell you which ports it needs.  There is no
other way, because the intermediaries can't look into S/MIME protected SDP.
Telling me not to protect my signaling with S/MIME is an unacceptable
answer.


> 
> What we have to do is determine how to find the middle ground to an
> acceptable risk and develop this so that there can be confidence in using
> the applications derived from it.
Sure, but that means the firewall is active, and not passive, if it is there
at all.

> 
> Signaling security should also be designed with these things in mind, not
> just the other way around...infrastructures are built of many components,
> some are standards based, and some are for survival. You have to look at
> the
> whole picture.
Well, in some sense I agree with you.  For some time the signaling protocol
folks have been wishing firewalls and NATs would go away, and designing
systems that assume they are not there.

But then the firewall guys have not been exactly cooperative about making it
possible to do the right thing, as above.  Endpoint signaling of pinholes
for example.


Brian