Jonathan Rosenberg wrote:
Rafael and others,
Thanks for putting this together.
Considering for a moment figure 1, this attack is possible only if UAs
accept incoming requests from any place, and not just their proxy. In
practice, this is seldom allowed.
Hi Jonathan,
I see two things with this argument: first being a practical, the
other normative. on contrary to what you have observed, in the SIP
deployments I'm aware of the SIP UA accept SIP from everywhere.
That I consider a poor practice, but it seems to be the case.
(perhaps a differnet market segment experience?)
It has been also utilized in the DE attack last year -- attacker
sent SIP packets directly to UAs.
www.ipcom.at/fileadmin/public/2008-10-22_Analysis_of_a_VoIP_Attack.pdf
I should be in position to do a live measurement of a quite
SIP-UA-wise heterogenous SIP service, should we need more accurate
field intelligence.
The normative argument is that a SIP UA must be prepared to receive
traffic for a dialog setup by an RFC3261 proxy, which has no
obligation to record-route, and the traffic can therefore come
from anywhere. Unless we standardize that the UAs
are behind NATs, deprecate record-routing as optional or more
seriously document BCPs (don't talk with strangers), a SIP-compliant
UA is an open invitation for unsolicited traffic.
I'm under impression that folks in this threads feel easy about
the problem because they have all sorts of workarounds -- these
however do not rely on any sort of normative reference and seem
thus rather brittle.
Possibly addressing some of these practices in a BCP could
help to sort out some of that. Actually some ITSPs I know have been
privately approaching their UA vendors and felt they have never
made progress because there was no reference for such behaviour.
-jiri
Indeed, if it is allowed, there are
worse attacks than this which can be launched (free phone calls, spam
calling, etc.). Using the SIP recommended TLS between UA and proxy also
mitigates that.
So really figure 2 is the interesting one. However, this attack assumes
that Alice has credentials on multiple systems. Again, in practice, this
is extremely uncommon. Certainly none of the existing deployed
enterprise or service provider consumer deployments are of this nature.
As such, I dont think this attack is likely in practice. However, in
theory it is possible. The essence of the attack is that the victim is
providing credentials to an unauthenticated server (since the attacker
is acting like a server, asking for credentials). In that way, as others
have pointed out, it is similar to baiting attacks that have been
previously documented. With SIP it is most easily remedied by a rule
which says, 'don't pass credentials for domain X to a server that is not
domain X'. Server identity can be verified by normal server-only auth
between a client and its server, but even that is not needed. A client
will know which domain its proxy is representing, and once connected, it
only provides credentials for that domain.
-Jonathan R.
Raphael Coeffic wrote:
Hello,
a new internet draft has been published concerning the relay attack on
digest authentication and SIP. The attack itself has been first
disclosed 2 years ago by the maydnes team from the french INRIA. Until
now, no document has been pushlished that documents the attack and
provides guidance to SIP operators or handset manufacturers.
http://tools.ietf.org/html/draft-state-sip-relay-attack-00
The appropriate mitigations of problem resolutions are still not 100%
clear. We hope that this draft can help start a discussion on how to
best resolve this problem.
Regards,
Raphael Coeffic.
(on behalf of all the authors of this draft)
---------------------------------------------------------------------------------------------------
Filename: draft-state-sip-relay-attack
Version: 00
Staging URL:
http://www3.ietf.org/proceedings/staging/draft-state-sip-relay-attack-00.txt
Title: SIP digest authentication relay attack
Creation_date: 2009-03-02
WG ID: Indvidual Submission
Number_of_pages: 18
Abstract:
The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism
for creating, modifying, and terminating sessions with one or more
participants. This document describes a vulnerability of SIP
combined with HTTP Digest Access Authentication [RFC2617] through
which an attacker can leverage the victim's credentials to send
authenticated requests on his behalf. This attack is different from
the man-in-the-middle (MITM) attack and does not require any
eavesdropping, DNS or IP spoofing.
_______________________________________________
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
_______________________________________________
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
