Abusing SIP authentication

Humberto Abdelnur, Tigran Avanesov, Michael Rusinowitch, Radu State

To cite this version:

Humberto Abdelnur, Tigran Avanesov, Michael Rusinowitch, Radu State. Abusing SIP authentication.
Journal of Information Assurance and Security, 2009, Special Issue on Access Control and Protcols, 4
(4), pp.311-318. �inria-00405356�

HAL Id: inria-00405356

https://inria.hal.science/inria-00405356
Submitted on 20 Jul 2009

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
Journal of Information Assurance and Security 4 (2009) 311-318

Abusing SIP authentication

Humberto Abdelnur1, Tigran Avanesov1, Michael Rusinowitch1 and Radu State2
1
INRIA, Nancy - Grand Est
Campus Scientifique - BP 239 - 54506
Vandoeuvre-lès-Nancy Cedex, France
{Humberto.Abdelnur, Tigran.Avanesov, Michael.Rusinowitch}@loria.fr
2
University of Luxembourg
6, rue Coudenhove-Kalergi
L-1359 Luxembourg-Kirchberg
[email protected]

Abstract: The recent and massive deployment of Voice over IP prototype for practical assessment and formally proved it
infrastructures had raised the importance of the VoIP security and using automated constraint based verification. We have
more precisely of the underlying signalisation protocol SIP. In this leveraged the AVIPSA tool for this purpose.
paper, we will present a new attack against the authentication
To analyze the SIP protocol security we have used
mechanism of SIP. This attack allows to perform toll fraud and call
hijacking. We will detail the formal specification method that AVISPA, which is a state-of-the-art tool for automatic
allowed to detect this vulnerability, highlight a simple usage case verification of security protocols. AVISPA is a push-button
and propose a mitigation technique. tool for the Automated Validation of Internet Security
Protocols [1]. It provides a modular and expressive formal
Keywords: Security threat, VoIP, SIP protocol, authentication, language, HLPSL (The High-Level Protocol Specification
formal validation, AVISPA. Language) for specifying protocols and their security
properties, and integrates different back-ends that implement
a variety of state-of-the-art automatic analysis techniques.
1. Introduction Our paper is structured as follows: Section 2 gives a short
The Session Initiation Protocol (SIP) is the IETF endorsed introduction to SIP and VoIP. The modeling of a subset of
signaling protocol for VoIP. The developers of SIP leveraged some functionalities of SIP is presented in Section 3. We
well proven design concepts from HTTP to build a robust propose a mitigation in Section 4 and a validation approach
and multi-feature signaling protocol. The advance of highly in Section 5 and discuss relevant works in Section 6. We
dynamical services deployed over multimedia enabled conclude the paper in Section 7 with conclusions and
networks and end user equipment had to be matched by an pointers to future works.
appropriate signaling protocol. At the basics, SIP allows to
create, maintain and tear down a media session. The media 2. SIP Vulnerability
session is represented by an RTP encoded audio/video data.
SIP is located at the application layer of the TCP/IP model
The specific characteristics of this RTP flow are negotiated
[3] and it has been designed to be independent of the
by SIP. In the simplest case, the call establishment with SIP
underlying transport layers. It is a decentralized protocol,
has to be able to let the two communicating partners send
where the intelligence is distributed through the entities that
RTP data between their two locations. However, in the more
the network is composed of. Thus, different components
complex case, some additional features have to be supported.
have been defined in the SIP architecture playing different
Call forwarding is the simplest feature that has to be
roles in a deployed network:
supported. Renegotiating media stream parameters (RTP) is
• User Agents (UA): they are the end-user devices in a SIP
also a minimum. For instance, in case of network congestion,
network (e.g. software or hardware phones).
another codec can be used. In order to support these features
• SIP Location Sever: this server is used to store the current
the so-called re-INVITE operation has to be used. The re-
location addresses, features and other preferences of
INVITE is issued during an already existing session and in
all the users from the domain. However, UAs do no
order to avoid a call-hijacking attack, the receiver is allowed
directly interact with it but indirectly by means of
to challenge the sender to authenticate. Ironically, it is this
proxies, redirect or registrar servers.
security feature that can be abused to bypass the
authentication mechanisms used in SIP network. We will • SIP Proxy Server: used to forward requests on behalf of
show in this paper why the re-INVITE operation is a major other SIP entities. It can not initiate a request by
threat to any SIP network and how a simple grandmaster itself, but can offer additional services like for
attack is possible due to it. instance security, authentication and authorization.
We address in this paper one major vulnerability existing • SIP Registrar Server: receives the request from a UA
in the SIP specifications. This vulnerability can be used for which wants to register in its SIP domain.
massive toll frauds or caller impersonations. With all VoIP • SIP Redirect Server: used to indicate the location where
operators being vulnerable, the potential impact can be far the initial request has to be forwarded. It is mainly
reaching and important. We have developed a working useful for mobility purposes.

Received June 10, 2009 1554-1010 $ 03.50 Dynamic Publishers, Inc

312 Abdelnur et al.

In fact, the servers provide a vast range of extra forwarded or direct requests, but it is not
functionalities just to facilitate the establishment of a session necessarily a failure if the two fields are not
between two SIP UAs. Only session signaling is considered equivalent.” [9]
by SIP, however it can be used in combination with other During a testing process [2] carried out by us, we have
protocols to build a complete multimedia session. discovered a scenario in which the user is reachable by the
SIP is a Request/Response protocol. In a normal session attacker and the latest can trigger the former to generate an
many requests can be generated and for each one several INVITE + credentials1 (directed to any target destination).
provisional responses are possible and only one final This allows an attacker to impersonate the user at the Proxy
response is required. for any call. Therefore, the attacker can bypass the previous
Each request message of SIP, except CANCEL and ACK, restrictions and make this attack a real security threat.
can be challenged for authentication. Thus, the VoIP services The synopsis is as follows: an attacker will issue a call
can be protected against threats and attacks like directly to the victim, the victim answers and later on, puts
impersonation, session teardown, fraud and others [13]. the attacker on hold (transfers him to any other place or uses
Authentication in SIP has also been leveraged on the design any other method which requires a re-INVITE). Once the
of HTTP authentication. attacker receives the re-INVITE specifying the "On hold", he
When SIP is deployed without any underling will immediately request the victim to authenticate. This last
cryptographic protection mechanism, the typical man in the authentication may be used by the attacker to impersonate
middle and impersonation attacks between a caller and its the victim at its own proxy. Section 3 formalizes and
proxy, (see Figure 1) are straightforward. However, to be describes in detail this attack.
mounted such attacks are constrained by some important Note, that to perform this attack, there are two headers in
factors. the INVITE message that are essential.
Firstly, the attacker willing to impersonate the user has to The Contact header has to provide the destination that the
be in the middle of the session path and be able to attacker wants to call to, because, as specified by SIP [9] this
manipulate the session traffic. information will be used to generate the message by the user
agent.
The Record-Route header specifies that all outgoing
messages from the user entity go directly to that entity.

3. SIP in AVISPA
To analyze the security properties of SIP protocol, we made
use of AVISPA, a state-of-art tool for cryptographic protocol
verification. As an intruder model, it relies on the well-
known Dolev-Yao model [4]. This means that all the
communication channels between agents (entities) are
considered to be under the control of the intruder: the
messages sent by an agent get immediately known to the
intruder (this is a consequence of the eavesdropping
capability of the intruder). Moreover, the intruder is able to
drop the message from a channel and even forge another
message and put it in any communication channel, i.e. send it
to any agent (this is an active capability of the Dolev-Yao
intruder). The deductive power of the intruder is quite
natural: he can decompose a message (get every element
from a list of values and decrypt encrypted messages under
condition he possess the required keys) and compose
messages (create a list from elements and produce an
Figure 1. Authentication Attack encryption with any key he knows). This model seems to
give too much control to the intruder on the entire network.
Secondly, the attacker cannot trigger the user to make such But the model is valid since it is possible to forge a Record-
a call at a specific time: he has to wait for such an Route header, an intruder may force an agent to send his
opportunity. messages first to a compromised router (or to the intruder
Finally, the attacker is restricted to use the generated itself) and this will give an opportunity to realize an attack.
response just to call the entity for which the user directed the Protocols to be studied by the AVISPA tool have to be
call. In other words, the attacker is not able to call an entity specified in HLPSL (standing for High Level Protocol
of its choice. Specification Language).
However, if the nonces are not correctly checked to be one HLPSL is an expressive, modular, role-based, formal
time used, the third constraint could be relaxed since language that allows for the specification of control-flow
“... in SIP, a server MAY check that the Request-URI
in the Authorization header field value corresponds 1
http://voipsa.org/pipermail/voipsec_voipsa.org/2007-
to a user for whom the server is willing to accept
November/002475.html
Abusing SIP authentication 313

patterns, data-structures, alternative intruder models, next state as primed variables: for a variable X, X refers to
the value in current state and X' to the value in the next
state.
Figure 2. SIP scenario 1 3.1 SIP scenarios
We have formalized two typical scenarios of SIP protocol.
In both scenarios Caller wants to call Callee. The first one
is shown in Figure 2: Caller is registered on Proxy and
wants to call via his proxy, and then Proxy requests an
authentication of Caller. The authentication procedure is
based on a shared between Proxy and Caller secret,
generated during a registration phase which is out of scope
of this article. If simplify, Proxy sends a nonce and Caller
should return hashed value of that nonce concatenated with
the shared secret and some other data. Meanwhile, Caller
invokes a reciprocal authentication. With his authentication
response, he sends another nonce to Proxy and expects a
correct answer (proxy-auth-info) by the similar
algorithm.
The second case (shown in Figure 3): Callee is available
only through Proxy where he is registered: any message
sent to or sent by Callee comes first to the proxy. Caller
establishes a conversation with Callee, and Callee puts it
on hold by sending invite to Caller during the
conversation. Having received this invite, Proxy can
Figure 3. SIP scenario 2
demand an authentication of Callee. The authentication
steps here are similar to ones of scenario 1: Calee and his
Proxy share a secret. If the response of Callee is valid,
Proxy passes invite to Caller. In fact, the identity of
authentication schemes in different scenarios admits an
attack.
3.2 SIP in HLPSL
In order to describe the protocol we should specify the
actions of each kind of participant, i.e. the basic roles.
Roles are independent processes: they have a name, receive
information by parameters and contain local declarations.
Basic roles are played by an agent whose name is received
as parameter. The actions of a basic role are transitions,
describing changes in their state depending on events or
facts.
To describe both above scenarios in HLPSL we
introduce three basic roles: caller, callee, and
proxy. Each role is obtained by merging corresponding
roles from the two scenarios defined in 3.1 (this means
Caller from Scenario 1 and Caller from Scenario 2
became one role which can execute both scenarios
depending on received message, and similarly for Callee
and Proxy).
We present now the declaration of basic roles and their
complex security properties, as well as different
(typed) parameters in HLPSL:
cryptographic primitives and their algebraic properties.
These features make HLPSL well suited for specifying role caller(A,B,P : agent,
modern, industrial-scale protocols. For instance it has been Apasswd : text,
applied to ZRTP flaws discovery in [7]. SND, RCV : channel (dy))
HLPSL is based on temporal logic. We specify a protocol …
by describing initial states and changes in states. A state is role proxy(P : agent,
defined by an assignment of values to all the state variables. Keyring : (agent.text) set,
A change in states is describes by a transition predicate that Realm : text,
relates the values of variable in current state with the values SND, RCV : channel (dy))
of variable in next or future state. We refer to the variable in …
314 Abdelnur et al.

role callee(B,P : agent, State':=20 /\

Bpasswd : text, SND(A.B.CallID.ack)
SND, RCV : channel (dy))
… This transition is called getAuth and its left-hand side
means:
Here we have: “if the value of variable State equals to 10 and we receive
• A, B, P — agents playing roles caller, callee and on channel RCV a message equal to the concatenation of the
proxy respectively; values of variables A, B, CallID, constant auth and
• Apasswd, Bpasswd — passwords of agent A and B three more values that are to be assigned to the variables
respectively; Algorithm, Realm and Nonce”.
• RCV, SND are channels for sending and receiving The primed variable notation (e.g.: X') indicates that a
messages, and new value is assigned to the variable. For example, a
• Keyring — set of pairs < username, password >; statement RCV(X) will mean that a message with value
• agent, text, channel(dy), (agent.text) set equal to the value of X (X was defined in this role before) is
are the types. expected to be received via channel RCV, however statement
In HLPSL variable names start with capital letters; RCV(X') would mean that any message (but with the same
constants, keywords and types start with lower-case letters. type as X, in the case of typed model) is expected to be
received via channel RCV, and its value would be assigned to
3.2.1 Composed roles
the variable X.
To execute several roles in parallel, the composition is
The right-hand side of the transition means:
presented in HLPSL. We defined two sessions
“then assign 20 to the variable State and send via channel
(compositions): out_session (for a call by Scenario 1)
SND the concatenation of values stored in A, B, CallID
and in_session (for a call by Scenario 2). This was done
and constant ack”.
to simulate an execution of the protocol, i.e. to group several
In other words, getAuth stands for getting a hash-
roles and share some parameters to execute the
corresponding scenario. function name (Algorithm), a realm value (Realm) and a
nonce (Nonce), and as a response caller sends ack2.
role in_session(A, B, P : agent, Another authentication related transition is the
Keyring: (agent.text) set, sndResponce. In this transition caller emits an
Bpasswd : text) authentication response to proxy right after sending ack.
… As no message is expected to be received to fire this
composition transition, a special constant start is used (it is simply a
caller(A,B,P, null, SA,RA) /\ stub, as receiving of message via channel is mandatory for
callee(B,P, Bpasswd, SB,RB) /\ left-hand side of any transition in HLPSL)
proxy(P, Keyring, realm, SP,RP)
end role sndResponce.
State=20 /\
role out_session(A, B, P : agent, RCV(start)
Keyring: (agent.text) set, =|>
Apasswd : text) State':=30 /\
… Cnonce':=new() /\
composition MdC':=Algorithm(Algorithm(A.Realm.
caller(A,B,P, Apasswd, SA,RA) /\ Apasswd).Nonce.Cnonce'.
callee(B,P, null, SB,RB) /\ Algorithm(invite.B)) /\
proxy(P, Keyring, realm, SP,RP) SND(A.invite.B.CallID.Algorithm.
end role Realm.Nonce.MdC'.Cnonce')/\
witness(A,P, client_md, MdC')
Symbol /\ denotes here a parallel execution.
Now we show the transitions of roles that are responsible Here caller generates a new nonce Cnonce and
for the authentication part (as more important one). A computes a message digest value MdC (exactly like shown in
transition — is a rule that can be fired if the left-hand side HLPSL specification above). Then caller sends this value
(that is the part before “=|>”) is satisfied. together with others. The last line is an authentication event
3.2.2 Role caller witness. Here it should be read as follows:
“agent A authenticates to agent P that the value MdC' 3 is
The first transition of the role concerning authentication is
really generated by A for P”. The constant client_md is
getAuth. used to identify unambiguously a pair witness-request. The
State=10 /\ authentication-related event request will be described
RCV(A.B.CallID.auth.Algorithm'.
2
Realm'.Nonce') Notice: all the messages in our specification constantly contain from,
=|> to and CallID part. We omit mentions about this part
3
in fact, this is a message digest value
Abusing SIP authentication 315

later. SND(X.invite.Y.CallID)/\
The getProxyAuthInfo transition checks request(P,X,client_md,MdC')
authentication credentials received from the proxy. If it is
correct — sends ack signal: Transition checkAuth checks if received authentication
credentials are right and if they are, sends invite to the callee.
getProxyAuthInfo.
State=30 /\ sndProxyAuthInfo.
RCV(A.B.CallID.MdP'.ok) /\ State=41 /\
MdP'=Algorithm(Algorithm( RCV(X.Y.CallID.ok)
A.Realm.Apasswd). =|>
Nonce.Cnonce.Algorithm(B)) State':=51 /\
=|> MdP':=md5(md5(X.Realm.PasswdX)
State':=40 /\ .Nonce.Cnonce.md5(Y)) /\
SND (A.B.CallID.ack) /\ SND (X.Y.CallID.MdP'.ok) /\
request(A,P, proxy_md, MdP') witness(P, X, proxy_md,MdP')
Here we get ok from the callee and send a proxy
Here we have the second authentication-related event authentication information to the caller.
request; it means “A accepts the value MdP' and relies We skip the HLPSL-specification of the role callee and
on the guarantee that agent P exists and agrees with A on the rest of proxy's authentication related specification as it
this value”. is very similar to the one described above.
The witness-request pairs are used by AVISPA tool to 3.2.4 Role environment
detect authentication failures. If request is executed in
There is a special role environment, that it is a top-
one of the roles (by an agent who plays it), but corresponding
level one (it is “called” from HLPSL file) where we declare
witness was not executed, then it means, that the value
agents and other constants, all the sessions to be executed
whose authentication was requested was not produced by the
simultaneously and where we define an initial intruder
expected agent. More information about HLPSL semantics
knowledge set using intruder_knowledge token. Here
can be found in user manual [1].
we initially let the intruder know the following constants: a,
3.2.3 Role proxy b, p, c, invite, try, ringing, ok, ack,
Now we show some proxy's transitions responsible for auth, in other words he knows all agents names and all SIP
the authentication procedure with Caller: methods.
To make AVISPA tool search for an attack, one should
getInviteSndAuth. introduce a goals section to define security goals:
State=11 /\
RCV(X'.invite.Y'.CallID') /\ goal
in(X'.PasswdX', Keyring) authentication_on proxy_md
=|> authentication_on client_md
State':=21 /\ ...
Nonce':=new() /\ end goal
SND(X'.Y'.CallID'.auth.
md5.Realm.Nonce') For example, the first line is a command that makes
AVISPA tool look for an authentication attack for the
Transition getInviteSndAuth. At first we receive witness-request pair defined by constant proxy_md.
information about who wants to call (store it into the variable Besides the authentication goals, it is also possible to define
X') and to whom (store into the variable Y'). The next secrecy goals to check if specified value stays unrevealed by
the intruder or by any other agent not allowed knowing it.
condition tells that X' should be registered in this proxy, i.e.
Now we can start AVISPA Tool. An attack is detected
the pair X.password_of_X should belong to the keyring
when the following role composition is presented in the top-
set. This is achieved by using in(X'.PasswdX', role environment:
Keyring) statement. Here we try to find value in set of
pairs Keyring; as X' is already defined, so if there is a pair proxy(p, Keyring, realm, SP,RP) /\
X'.something in Keyring, then the result of operator in callee(a,p, alice_passwd, SB,RB)
will be true and the value of “something” is assigned to
variable PasswdX'. And Keyring contains the only pair
a.alice_passwd. But we can also use two defined
checkAuth.
compositions (which include necessary roles):
State=31 /\
out_session(a,c,p,Keyring,alice_passwd)
RCV(X.invite.Y.CallID.md5.
/\in_session(b,a,p,Keyring,alice_passwd)
Realm.Nonce.MdC'.Cnonce') /\
MdC'=md5(md5(X.Realm.PasswdX). 3.2 MSC of the attack
Nonce.Cnonce'.md5(invite.Y)) When running the AVISPA tool on our HLPSL
=|> specification of SIP we get the message: “UNSAFE”.
State':=41 /\
316 Abdelnur et al.

The tool automatically builds and displays the attack trace where resp is the actual authentication response.
shown in Figure 4. Thus, the computed authentication response will be
Here x236, x265 and x237 are variables that can take rejected if the method used for computing the response (i.e.
any values. Notation Cnonce(7) indicates an instance of a the method value for A2) is different than the one in the
Cnonce variable (the parameter is used to distinguish one challenged message.
instance of the variable from another). However, the described attack abuses that restriction due

Figure 4. Attack trace

We can see that at first the intruder impersonates a caller to the fact that SIP defines an INVITE method which can be
a when speaking to proxy. After getting an authentication used in different contexts (i.e. for initiation of a session and
challenge from proxy and sending ack, the intruder starts renegotiation). Therefore, the value of variable A2 is the
another protocol session with a. Here the intruder same in both contexts. If different methods names are used
impersonates a proxy for a callee a. Once the intruder gets for those contexts, then the generated authentication response
the necessary authentication response from callee a, he is not suitable for such an attack.
reuses it (the only change is CallID value) to answer proxy's We propose a mitigation that consists in defining the re-
challenge he got at the beginning. Here we get a security INVITE method as a proper method with a new name: RE-
violation on authentication, as an appropriate witness INVITE. Note that computed authentication for such
event was not generated to match the request event that is message will use the RE-INVITE method in the variable A2
produced. rather than INVITE. Thus, it will generate an authentication
token useful only for re-INVITEs messages.
The proposed solution is simple and it should not require
4. Mitigation too many modifications in the complete protocol
Authentication challenges in SIP are computed using specification.
pieces of information extracted from the authenticate
message plus the username and shared secret. In the simplest 5. Validation
case the authentication response is computed by:
A1 = username ":" realm ":" passwd The proposed patch changes the Scenario 2 (see Figure 3)
A2 = Method ":" Digest-URI such that every invite appearing after comment “Callee
resp = MD5(MD5(A1) ":" nonce ":" MD5(A2)), presses hold” is changed to reinvite. So it is not difficult
to change the HLPSL specification by taking into account
Abusing SIP authentication 317

the proposed patch. serous threats, because the non repudiation properties are a
We ran AVISPA tool over “patched” HLPSL side effect of the SIP authentication method. To our
specification. For the patched version we got “safe” over the knowledge, no other previous works have identified such a
sessions which were unsafe in the original version. vulnerability, where a feature interaction in the SIP is
Tables 1 and 2 represent a comparative running time in combined with serious attack against the SIP.
seconds of AVISPA-tool with CL-Atse backend [1] and the Many works have been dedicated to analysis and testing of
result of safety analysis. These results depend on the roles VoIP protocols, but dealing rather with the PSTN
executed in parallel as well as on the values passed to interconnection as in [11], or [10]. Most of the performed
instantiate them. One of the important parameters is a work has addressed the prevention of SPAM over Internet
database of registered agents for the proxy: the Keyring Telephony (SPIT) attacks [5] as well as mitigating denial of
parameter. So, for every table we presented two different service ones (DoS) [12]. Very few of them did address the
values of this parameter, whereas every table corresponds to cryptographic analysis of the protocol itself. Among the very
the different set of instantiated roles executed in parallel. The few which did, most of them are based on human-analysis of
set of instantiated roles of the first table is a minimal one to the protocol.
discover this attack, i.e. to find the attack we need these two As of today, very few works address the formal
instantiated roles to be executed in parallel: an instance of specification and analysis of security properties. Among
callee and an instance of proxy, where name and them — a thorough study of ZRTP (VoIP media transport
password of the agent playing callee are known by the layer protocol) using AVISPA tool [7], has allowed to find a
agent playing proxy. One can find, that these instances are new authentication attack. There are two families of potential
included in the set of instantiated roles presented in Table 2, attacks that can be performed against SIP. The first class of
if look at definition of in_session and out_session. attacks is possible when no cryptographic protections are
Column sip contains results for the original version of SIP used in the SIP deployment. For instance, a DoS attack on
and sip' — for the patched one. SIP protocol has also been exhibited using a Petri nets
modelling in [15] — using faked BYE message and showed
Keyring sip sip' an established conversation can be turned down prematurely
0.07s, 0.06s, [6].
a.caller_passwd Until now, the authentication and authorization
unsafe safe
a.caller_passwd, mechanisms in SIP were considered sound and such that
0.07s, 0.07s, only denial of service and brute force attacks were possible.
c.charley_passwd,
unsafe safe The second class of attacks concerns poor implementations
i.i passwd
and/or efficiency driven fallacies in the authentication
proxy(p, Keyring, realm, SP,RP) process. We have disclosed some attacks against specific
/\callee(a,p, alice_passwd, SB,RB) implementations (CVE-2007-5468, CVE-2007-5469), where
Table 1. Comparison of results. cryptographic tokens could be reused or even fixed, but these
were due to software implementation flaws and not really
Keyring sip sip' SIP specification level vulnerabilities. Our paper is the first
0.39s, 11.81s, to show a structural flaw in the SIP authentication
a.caller_passwd
unsafe safe mechanism itself due to the feature interaction in SIP.
a.caller_passwd,
0.40s, 13785.07s,
c.charley_passwd, 7. Conclusions
unsafe safe
i.i passwd
We have presented in this paper a new attack against the
out_session(a,c,p,Keyring,alice_passwd) SIP authentication mechanisms. This attack is extremely
/\in_session(b,a,p,Keyring,alice_passwd) dangerous since SIP is worldwide deployed and no solution
to mitigate this attack exists as of today. With SIP being the
Table 2. Comparison of results. de-facto standard signalization protocol in VoIP, the
consequences are far reaching. These consequences of this
6. Related work attack can range from toll fraud, caller impersonation and up
to massive deflected denial of service attacks. The essential
The comprehensive overview on VoIP security is the
weakness comes from a feature interaction between routing
reference [14] addressing the operational and deployment
information and authentication logics. This weakness cannot
aspects of VoIP security. The security mechanisms deployed
be avoided, unless the SIP standard is changed. This attack
in SIP are well described in [8] without covering the formal
is practical on any VoIP domain and the expected impact
aspect of the security architecture. As of today, the security
quite dangerous. We have developed a prototype and
of VoIP (and SIP in particular) is still in the infancy.
evaluated in laboratory conditions the applicability of the
Although strong authentication and authorization
attack.
mechanisms have been defined, the operational deployment
We have formally confirmed this vulnerability using the
is lagging behind. Simple man in middle attacks against SIP
AVISPA tool and shown that extending SIP with one more
infrastructures not using cryptographic authentication
operation can mitigate this attack. Our solution has been
mechanisms, have been known for a while and are easy to
automatically validated by AVISPA. It is a follow-up
implement. Ironically, the security mechanisms that have
activity to fully specify SIP and completely analyze its
been proposed to counter these vulnerabilities induce more
318 Abdelnur et al.

behavior, but many scalability issues must be solved to vulnerabilities”. In IEEE Network, Vol. 20, No. 6, pages 32–
achieve this task. 41, November 2006.
[12] D. Sisalem, J. Kuthan, and S. Ehlert. Denial of service
Acknowledgment attacks targeting a sip voip infrastructure: attack scenarios
The work presented in this paper was partially supported by and prevention mechanisms. Network, IEEE, 20(5):26–31,
the FP7-ICT-2007-1 Project no. 216471, “AVANTSSAR: Sept.-Oct. 2006.
Automated Validation of Trust and Security of Service- [13] P. Thermos and A. Takanen. Securing VoIP Networks:
oriented Architectures” (www.avantssar.eu). Threats, Vulnerabilities, and Countermeasures. Addison-
Wesley Professional, 2007.
References [14] Peter Thermos and Ari Takanen. Securing VoIP
[1] Avispa project. http://www.avispa-project.org. Networks: Threats, Vulnerabilities, and Countermeasures.
Addison-Wesley Professional, 2007.
[2] Humberto Abdelnur, Radu State, and Olivier Festor.
“KiF: A stateful SIP Fuzzer”. In Proceedings of Principles, [15] H. Wan, G. Su, and H. Ma. “SIP for Mobile Networks
Systems and Applications of IP Telecommunications, and Security Model”. In International Conference on
IPTComm, pages 47–56, New-York, NY, USA, JUL 2007. Wireless Communications, Networking and Mobile
ACM Press. Computing, pages 1809–1812, Shanghai, China, September
2007. IEEE Computer Society, 2007.
[3] R. Braden. Requirements for Internet Hosts -
Communication Layers. RFC 1122 (Standard), October Author Biographies
1989.
Humberto J. Abdelnur is a Research Engineer at the
[4] D. Dolev and A. Yao. On the security of public key Nancy research of INRIA, the French National Institute
protocols. 29(2):198–208, Mar 1983. for Research in Computer Science and Control. He
received his MSc in Computer Science from National
[5] D. Geneiatakis, T. Dagiuklas, G. Kambourakis, University of Cordoba (U.N.C.), Argentina, in 2005
C. Lambrinoudakis, S. Gritzalis, K.S. Ehlert, and D. Sisalem. and his doctorate on vulnerability assessment from the
Université Henry Poincaré in Nancy in 2009. His
Survey of security vulnerabilities in session initiation current research and interests are concerned with
protocol. Communications Surveys & Tutorials, IEEE, Software Reliability, Fuzzing, Intrusion Detection and
8(3):68–81, 3rd. Qtr. 2006. Network Fingerprinting.

[6] Dimitris Geneiatakis and Costas Lambrinoudakis. An Tigran Avanesov is a PhD student of Henri Poincaré
ontology description for sip security flaws. Comput. University in Nancy, France. He received his master
degree on computer science in 2005 from National
Commun., 30(6):1367–1374, 2007. Taras Shevchenko University of Kyiv, Ukraine. His
[7] P. Gupta and V. Shmatikov. “Security Analysis of main current research interests are security analysis of
cryptographic protocols using symbolic methods and
Voice-over-IP Protocols”. In 20th IEEE Computer Security automated web services composition.
Foundations Symposium (CSF), pages 49–63, Venice, Italy,
JUL 2007. IEEE Computer Society, 2007.
Michael Rusinowitch is Senior Researcher at Nancy
[8] Alan B. Johnston and David M. Piscitello. research center of INRIA, The French National Institute
for Research in Computer Science and Control. He
Understanding Voice over Ip Security (Artech House received his doctorate on automated deduction from
Telecommunications Library). Artech House, Inc., Norwood, Université Henry Poincaré in Nancy in 1987. He has
MA, USA, 2006. been working on rewrite systems, theorem-proving and
automated verification. His current research interests
[9] H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, include security analysis of protocols and web services.
R. Sparks, M. Handley, and E. Schooler. “SIP: Session He has published more than 100 articles in international journals and
Initiation Protocol”. http://www.ietf.org/rfc/rfc3261.txt, June conferences.
2002. Radu State is senior researcher with the University of
Luxembourg. Before joining the University of
[10] H. Sengar, R. Dantu, and D. Wijesekera. Securing voip Luxembourg, he was a senior researcher at INRIA,
and pstn from integrated signaling network vulnerabilities. Nancy. He holds a PhD from the university Henri
VoIP Management and Security, 2006. 1st IEEE Workshop Poincare in Nancy (2001) and MSc in engineering from
on, pages 1–7, 3 April 2006. the Johns Hopkins University (1998). His research
interests include VoIP security, security assessment and
[11] Hemant Sengar, Ram Dantu, Duminda Wijesekera, and security monitoring. He has published more then 60
articles in international journals and conferences.
Sushil Jajodia. “SS7 over IP: Signaling internetworking