[VOIPSEC] Actual Attacks

[Brian Rosen]

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