[VOIPSEC] Actual Attacks

Wed Feb 23 22:30:39 CST 2005

I didn't say NAT was a security mechanism but in this case it is a
mitigating factor. I was focusing on the fact that a DoS against the
endpoint toward SIP/Media is about as close as you can get to the endpoing
via an SBC or NAT firewall on the endpoints edge...although if you are
hitting the endpoints NAT firewall then you can launch an attack directly at
that network because you know exactly where it is located... 

Through an SBC you only know about the SBC's network and can only launch the
attack against the SBC network... this mitigates any attack other than VoIP
directly against the endpoint, and only if the SBC is not defending the
media and signaling stream when it detects such an attack by not passing the
attack through to the endpoint... that would be a poor implementation at
that point. When an SBC detects an attack it should be dropping packets as a
firewall would. 

Without knowledge of the endpoints true IP address an attacker would not be
able to launch a directed attack against an endpoint if the attacker does
not know its fully routable IP address, only the address of the SBC. In this
case DoS attacks are less likely against the endpoint and its directly
connected network. There is something to say about obscurity in this case.

That was my point. (It's also dependant on the scenario, this is just one
example and obviously doesn't go into the many scenarios that could exist)

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: Wednesday, February 23, 2005 9:28 AM
> To: 'Geoff Devine'; Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
> 
> See inline
> 
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> > Behalf Of Geoff Devine
> > Sent: Tuesday, February 22, 2005 5:16 PM
> > To: Voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] Actual Attacks
> >
> > Brian Rosen writes:
> >
> > > Okay, but what is the difference between a DoS attack on the SBC
> > > and a DoS attack on the endpoint?
> >
> > The difference is that even a trivial DoS attack will take out a
> > residential broadband connection.  The pipe to the end user is easy to
> > fill and the processor on the endpoint device is easy to saturate.  All
> > the customer knows is that they can't make phone calls.  A box
> > engineered to handle multiple wire speed Gig-Es has significantly more
> > resources so it takes far more resources for the attacker to deny
> > service.  The pipes are orders of magnitude bigger.  The processors are
> > engineered so they don't saturate at full load.  The box is actively
> > monitored so the service provider is well-aware that an attack is
> > happening.
> Try it.
> 
> At least in the circumstances I am aware of, DoS attack on SBCs is about
> as
> likely, if not more likely, than DoS on end points.  Actually, of course,
> an attacker doesn't know, except for specific exploits against specific
> implementations, doesn't care.
> 
> The pipe is easier to fill unless the ratio of the processor speed to pipe
> size is very different.  But it is in many cases.  Even the embedded
> processors in phones are pretty fast these days, and most are able to keep
> up with quite a lot of signaling traffic.  SBCs tend to work only because
> the actual signaling rate they are presented with is less than the box can
> actually process, or they intentionally slow down the response rate to
> keep
> it in bounds.  A typical SBC spec is one GigE In, 300 calls per second.
> One
> easy test which is pretty hard on an SBC is to feed it a whole lot of
> long,
> properly formed, but bogus INVITE/IAM messages.  Most will choke long
> before
> their pipe size is filled.  Most endpoints will too of course.
> 
> 
> >
> > > And what makes you think that making the endpoint "anonymous", but
> > > addressable (albeit indirectly) stops a DoS attack?
> >
> > The endpoint is indirectly addressable only while a media stream service
> > flow is established and that is from one specific IP address for a
> > relatively short period of time.  The SBC has a policy to shape media
> > traffic that exceeds a specified flow spec. The SBC has policy to
> > prevent signaling from unknown SIP Proxies.  You can install a policy to
> > shape signaling traffic to limit damage from spoofing/replay attacks.
> > If you're running security on the SIP interface between the SIP Proxy
> > and the SBC, you can also protect from spoofing on the signaling
> > interface.
> Nope.  The endpoint is addressable at all times for signaling; it's just
> that the address on the Internet is different from the address on the LAN.
> DoS on media is possible, but DoS on signaling is much more likely.
> And, it's not the NAT that gives you security on the media, it's the
> pinhole
> firewall.
> 
> Media traffic shaping on SBCs is primarily to prevent fraud, not DoS.
> It's
> all in your definition, but "Denial of Service" with a very small media
> stream rate works at least as well as DoS with a large stream rate; if the
> endpoint's media channel is being used for a bogus stream, it can't be
> used
> for a legitimate stream.  DoS on signaling is pretty close to the classic
> Denial of Service attack, seeking to overwhelm the signaling element.
> 
> You definitely lose when you deploy security with SBCs, as very few of
> them
> implement the security mechanisms for VoIP security, and in fact they
> violate the specifications by modifying signaling in ways that break the
> integrity of the signaling.  Replay attacks on secured signaling is not
> possible.  Spoofing is possible to both an SBC and an endpoint or other
> proxy depending on the policy for certs.  Self signed certs are allowed in
> SIP to deal with the problem of lack of a global PKI.  If you allow a self
> signed cert, then you can spoof.  The SBC can't help you.  Of course, you
> do get some protection from spoofing from any form of public key crypto.
> 
> 
> >
> > > This is a form of security by obscurity, and does not offer any real
> > > security.
> >
> > I disagree.  Part of security is privacy.  You maintain privacy by
> > encrypting the payload and anonymizing the IP address.
> Encryption is effective, always.
> 
> Anonymizing addresses is voodoo security.  Doesn't actually do anything.
> Gives you a false sense of security where there is none.
> 
> NATs are useful when address space scarcity (whether real or economically
> induced) is present.  NATs are not security mechanisms and we'd best not
> advertise them as effective.  NAT is a very big reason VoIP doesn't work
> well today, although we're learning to cope.  What is actually happening
> is
> that we are inventing mechanisms to defeat NATs.  Right now, if you
> implement the "ICE" stuff, you can get calls through most NATs.  Some of
> it
> (TURN) is ugly, but it works.
> 
> 
> >
> > > SBCs may have some positive security benefits, but
> > > anonymization of the addresses is not one of them.  In  fact it makes
> > > the system more brittle by increasing the number of vulnerablilities
> > > (you have two chances to have a broken implementation instead of one).
> >
> >
> > The algorithm run inside an SBC isn't all that different from the
> > NAT/Firewall run in virtually every residential and corporate edge
> > router.  Are you saying the internet as it exists today is unworkable
> > because of broken implementations?
> As above, NATs are evil for VoIP because they make it very hard to get
> legitimate calls through, but we are learning to cope.  Clearly, NAT on a
> firewall and NAT on an SBC is the same function and works the same way.
> It's not a security thing; gullible people just have been told it is
> effective when it really isn't.
> 
> Brian
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org