[VOIPSEC] Actual Attacks

[Andrew Graydon]

I think that we are all saying the same thing, just using the same words
for slightly different things :) One of the earlier comments I made, and
now I'm not even sure if it was on this list, was that we should focus
on the functionality we need and where we need it, and not, at this
stage, get hung up on the current solutions that are on the market or
what they are called. We know that we need transport security, we know
that we need some functionality on the SIP protocol itself and we know
that we need to protect these devices in implementations. 

The concept that every endpoint or UA should be able to protect itself
is a great idea, but one that we have not seen implemented in other
areas of internet protocols, look at SMTP for example in the SPAM,
virus, malformed message space. The concept of a security 'box' is not
uncommon, whether we call it a firewall or anything else.

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: Christopher A. Martin [mailto:chris at infravast.com] 
Sent: February 28, 2005 9:11 PM
To: 'Brian Rosen'; 'Porter, Thomas (Tom)'; 'Andrew Graydon'; 'Thomas
Howe'
Cc: voipsec at voipsa.org
Subject: RE: [VOIPSEC] Actual Attacks

The latest firewall products do protect against payload attachments
(.exe's, zip, etc...) but I agree are not the silver bullet and can be
bypassed...just my 2 cents.

:)

Christopher A. Martin
P.O. Box 1264
Cedar Hill, Texas 75106
Chris at InfraVAST.com

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] 
> On Behalf Of Brian Rosen
> Sent: Monday, February 28, 2005 2:34 PM
> To: 'Porter, Thomas (Tom)'; 'Andrew Graydon'; 'Thomas Howe'
> Cc: voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
> 
> Please explain how a firewall protects against the latest Internet
virus.
> 
> Our experience is that firewalls protect against yesterday's problems,

> not today's problems.  The hackers have learned to bypass firewalls, 
> using IE or email attacks.  We still see script kiddies trying, no 
> doubt.
> I expect we'll have SIP firewalls.  So long as they appear to be 
> passive except when a known attack is detected, no problem.
> The idea that they can detect and REPAIR problems, is, I think, not a 
> worthwhile avenue.  The idea that they will somehow proactively 
> protect against the next problem is, in my experience, unlikely.
> 
> I think firewalls are here to stay, and we have to deal with them, but

> I think they are not the best way to create secure systems.
> 
> Your Mileage May Vary.
> 
> Maybe we can agree on the idea that end devices and proxy servers 
> should be immune to attack.  When exploits are discovered, devices 
> should be updated rapidly.  Firewalls are likely to be deployed as a 
> check against such hardening, and may provide some protection when 
> devices are not updated.
> Such firewalls should not interfere with "normal" communications.
> 
> Brian
> 
> > -----Original Message-----
> > From: Porter, Thomas (Tom) [mailto:tporter at avaya.com]
> > Sent: Monday, February 28, 2005 3:13 PM
> > To: Brian Rosen; Andrew Graydon; Thomas Howe
> > Cc: voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] Actual Attacks
> >
> > While I agree with you about S/MIME, I'm puzzled by the last
sentence...
> > A firewall is a "special box", that while not fixing vulnerabilities

> > in other boxes, does protect vulnerable boxen from a host of 
> > problems. And while I agree that "ALL VOIP devices *should* be able 
> > to ward off attacks", the fact is, is that they won't, and they will

> > have to be protected by additional hardware/software just as other 
> > user endpoints are.
> >
> > Best Regards,
> > Tom
> >
> >
> > Thomas Porter, PHD, CISSP
> > Security Architect
> > Avaya Global Managed Services
> > [O] 919-967-2909
> > [C] 919-593-3130
> > [IM] AvayaTPorter
> > tporter at avaya.com
> >
> >
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]

> > On Behalf Of Brian Rosen
> > Sent: Monday, February 28, 2005 9:28 AM
> > To: 'Andrew Graydon'; 'Thomas Howe'
> > Cc: Chris at sip1.com; voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] Actual Attacks
> >
> > I think that the incoming and outgoing proxy servers in any domain 
> > bear responsibility for assessing conformance of calls to the policy

> > of the domain.  In IETF-speak, that functionality is local to the 
> > box, and not the subject of standardization.  We don't standardize 
> > boxes, we standardize protocols, and specification of which box does

> > what thing is only done with respect to the role played by an entity

> > implementing a protocol.
> >
> > Seen in that way, the vast majority of this draft would be 
> > considered out of scope for the IETF.  Other organizations could do 
> > work in that area, of course.
> >
> > The draft also violates several aspects of the Internet in general 
> > and SIP in particular as it calls for a proxy to among other things,

> > modify the SDP.
> > Proxies don't do that, because it breaks the end to end nature of
SIP.
> > If the SDP were protected with S/MIME, this function would fail.  I 
> > for one do not believe we should be in a position where we advocate 
> > some mechanism that causes an end-to-end security mechanism such as 
> > S/MIME to not work.  It isn't necessary, and it's bad security.
> >
> > But mostly, this is yet another band-aid.  It doesn't get at the 
> > real problems; it inserts a box that supposedly is better than the 
> > other boxes in the path at addressing security threats.  To my way 
> > of thinking, this is a bad idea.  We would be much better off 
> > identifying the characteristics that ALL VoIP devices should have to

> > ward off attacks, and demand they be implemented.  This doesn't 
> > obviate passive monitoring devices that seek to confirm that only 
> > good traffic is allowed past a checkpoint (trust, but verify).
> >
> > I'm not a believer in the idea that some special box can fix 
> > vulnerabilities in other boxes.
> >
> > Brian
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Voipsec-bounces at voipsa.org 
> > > [mailto:Voipsec-bounces at voipsa.org]
> > > On Behalf Of Andrew Graydon
> > > Sent: Friday, February 25, 2005 11:09 PM
> > > To: Thomas Howe; Brian Rosen
> > > Cc: Chris at sip1.com; voipsec at voipsa.org
> > > Subject: RE: [VOIPSEC] Actual Attacks
> > >
> > > 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
> > >  >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > >
> >
> >
> >
> >
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> 
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org