Hi Theo,
Am 20.02.2009 16:36 Uhr, schrieb Theo Zourzouvillys:
On Fri, Feb 20, 2009 at 9:46 AM, Nils Ohlmeier<[email protected]> wrote:
I think the whole "attack scenario" which is described in the draft works
only if the attacker uses the proxy/registrar of the victim as a relay.
Reason 1): because the attacker hopefully does not know which UDP port of
the victim is currently "open" to accept incoming UDP packets. And if their
is a NAT or firewall in between the UA it will hopefully only accept UDP
packets from the proxy/registrar. If the UA of the victim runs on a public
IP without any "protection" it might accept SIP requests from anywhere,
although I would call this a very bad UA implementation.
A victim does not need to have an open UDP port; An attack can easily
be launched against any IP address, even a non SIP related one.
Yes, similar to the DNS server aplimifaction attacs which are going on
right now. I think should you should spend an extra section on the
scenario to seperate it from the pure SIP scenario.
A device behind NAT on the end of a link additionally has no
protection at an IP level, as the link would easily become saturated
as a reflector starts sending failure response retransmits from a IST
every time timerG fires.
Ok, I fear a shortage of you draft caused some confusion here:
IMHO you should differentiate between the attacker, the amplifier and
the victim.
I was referring here to a UAC behind a NAT being the amplifier. You
seemed to refer to the real victim here.
With this said I think it would be good if you seperate in your draft
between UA aplimifers and proxy amplifiers, because they result in
different traffic numbers if I'm not wrong.
Thus my original though was and still is, that it is most likely easier
to mis-use any SIP proxy as amplifier. But a proxy will most likely
"only" re-send any error response 11 times to the victim.
I still believe a UAC should be harder to mis-use as an amplifier (see
original reasons 1 and 2).
Reason 2): when the UA of the victim registeres itself it provides a Contact
URI. I general I believe UA should only accept incoming requests from their
registrar IP and port which contains the Contact URI which they provided at
the registration. This prevents very easily that someone sends drive by
requests just with the AOR of the victim as R-URI to the UA of the victim.
If a registrar forwards requests to registered UAs with the AOR of the user
in the R-URI the registrar is broken in my opinion.
as above - a victim does not need to be a SIP UA - it doesn't even
need to talk SIP. The attacker may well be trying to attack a non SIP
entity, for example a web, DNS, or mail server.
On the flip side, a UA that "only accept"s requests from it's
registrar if of course good practice, but is only a step in stopping
SPIT, not denial of service (which this draft tries to tackle), unless
the "only accept" is limited by routability. Note even NAT doesn't
stop a denial of service attack being launched against the NAT
gateway, causing it's connectivity to become saturated.
See above.
As a victim it makes for sure no difference under which criterias a SIP
implementation (if it speeks SIP at all) accepts messages. But as an
amplifier it might make a difference. E.g. if the UA rejects the spoofed
INVITE with a 305 Use Proxy (although this reply is ambigious), the
victim will receive only 11 replies within 32 seconds. But if the UA
accepts the INVITE and starts to ring, and the user accepts... your
worst case scenario comes into play.
This draft is specifically trying to stopping a SIP server transaction
being used as an amplifying reflector in a (distributed) denial of
service attack. The victim of the attack does not need to be a SIP
endpoint (it doesn't even need to have any ports open!)
Now the question is of the proxy/registrar accepts requests from its users
from anywhere. I guess that is what you mean with no authentication, right?
Yes - any SIP server (note a UAS or proxy are both servers for this)
which allows an unauthenticated, untrusted user to create an invite
server transaction (even for failure delivery) is vulnerable.
Agreed. Although a failed server transaction results in a lot less harm
then an accepted call. Maybe some calculations about the amount of bytes
would be helpfull here.
One bigger concern for the whole approach is: if the attacker knows about
this cookie extension he will for sure not put an empty cookie in the Via
header of the request. But how does the proxy of the victim handle requests
without the cookie extension?
Any proxy that does wish to be used as an amplifier should reject
requests without cookies with a stateless 4XX, or send a stateless
401/407 if knows it can authenticate it's user.
Of course this is not going to be realistic from day 1, but this
document is a start in finding solutions to some of the DOS problems
we're currently susceptible to by putting a SIP server "on the net".
Right now, there are a large number of SIP endpoints out there that
will amplify a single UDP packet sent to them, and the initiator of
the attack isn't even traceable!
Yep. Like with this DNS amplification attack here:
http://isc.sans.org/diary.html?storyid=5713
(And that only uses the amplification of bytes from a 1:1
request:response transaction... SIP is worse.)
(i'm starting to sound like a scaremonger, so i'll stop now :))
If the proxy of the victim does not care about backward compatibility (maybe
because attack previntion is more important), wouldn't the need a way to
tell the sender of the request that the cookie extension is required to
successfully relay requests? So wouldn't we need a new value for the
Required header, or would a new 4XX response already be enough.
I did briefly consider an option tag but the problem is a SIP UA does
not need to implement anything for it to potentially work - for
example a proxy can implement it on behalf of a group of trusted users
(for example, a corporate proxy or an outbound proxy that has
authenticated the inbound request).
There would additionally be no mechanism for recovery if the server
refuses to process UDP requests without cookie support. The 4XX would
provide a code that allows a machine to understand that it failed due
to cookies (if it knew about, but didn't implement the extension) -
and could for example try upgrading to TCP, [D]TLS etc. The reason
phrase provides something descriptive for devices that don't
understand it. For those that don't, it'll fall back to treating it
like a 400.
Ok, accepted.
Cheers
Nils
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
