[VOIPSEC] Actual Attacks
Andrew Graydon
agraydon at admin.borderware.com
Fri Feb 25 22:09:17 CST 2005
Wow ! What an excellent conversation ! I am also involved and lurk on a
lot of other mailing lists , some of which are supposed to be setting
the standards, and this is the best discussion I have seen yet. I think
this is the power we have here at VOIPSA, we are not constrained by any
preconceptions and look at this from an industry and implementation
perspective, utilising our experiences and knowledge from trying to DO
this stuff.
I fully agree with the comments below on the current solutions on the
market not addressing the issues. There are limitations in most of the
concepts I have seen so far even discussed. The emphatic 'war' currently
ongoing about the usefulness of different solutions is not focussing on
the issues at hand, what we are trying to work with has been around a
long time, in internet terms, and has never hit the main stream due to
the issues described. Now we really have now choice but to wake up and
solve the problem the best way we can as implementation are now live
around the world in long distance, IM, conferencing software,
collaboration software and the ventures into IMS ! We have seen on this
list verification of real hacks to the system, and as Brian points out,
while the 'script kiddies' are a pain, the real hacks are monetary
based.
Some people on this list have seen a draft of a new way of dealing with
the security issues I put on a separate list for the board as a starting
point for discussion which will look at the application layer attacks,
i.e. registrar DOS, eavesdropping, man-in-the-middle, etc, while also
providing a good point in the SIP conversation for transport layer
security also. By combining the multiple layers, more control of the
security aspects are achieved while also allowing policies and other
administrative rules to be put in place. For those interested, the
discussion draft (submitted to the IETF) is here
http://www.borderware.com/sip_edge_proxy.php
For those who have already seen this, I apologise for the repeat, for
anyone interested, as I said, it is a discussion draft :)
Andrew
________________________________________________________________________
Andrew Graydon Phone: 905-804-1855 x289
V.P. Technology Fax: 905-804-1865
Borderware Technologies Inc. http://www.borderware.com
-----Original Message-----
From: Thomas Howe [mailto:howethomas at aol.com]
Sent: February 25, 2005 11:10 AM
To: Brian Rosen
Cc: Chris at sip1.com; voipsec at voipsa.org
Subject: RE: [VOIPSEC] Actual Attacks
Hi all -
Excellent exchange.
One important thing about endpoint vs. SBC security that I didn't see
mentioned here, and that's money. The real big money to be made for
hackers in VoIP is in extortion, not in the petty cyber-vandelism of
VoIP script kiddies. In order to make money at extortion, there's got
to be a whole bunch of victim's money at risk. At the residence, or
even at the small to medium enterprise, there's just simply not enough
money at stake to make it worthwhile. However, if you are talking about
a service provider of any appreciable size, how much would they pay not
to be taken out of service for a day or two? DDOS is not a good thing
for them, and it's really easy to get a 10,000 element botnet up and
going. If anyone disagrees with this pessimistic view of the future, I
will only point to the current problems suffered by online gambling
sites, and mention that their effective revenue is one-tenth that of a
mid-level carrier. Therefore, because the money is there, and that's
where the real hackers go, SBC and service provider firewalls are the
places we need to concentrate.
Just my opinion.
Tom
Brian Rosen wrote on 2/24/2005, 1:11 PM:
> 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
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
More information about the Voipsec
mailing list