Voice over IP: Risks, Threats and Vulnerabilities

Angelos D. Keromytis
Symantec Research Labs Europe
Sophia-Antipolis, France

Abstract— Voice over IP (VoIP) and Internet Multimedia and to eliminate redundant equipment. Consumers have em-
Subsystem (IMS) technologies are rapidly being adopted by braced a slew of technologies with different features and costs,
consumers, enterprises, governments and militaries. These tech- including P2P calling, Internet-to-phone network bridging, and
nologies offer higher flexibility and more features than traditional
telephony (PSTN) infrastructures, as well as the potential for wireless VoIP. These new technologies and business models
lower cost through equipment consolidation and, for the con- are being promoted by a new generation of startup companies
sumer market, new business models. However, VoIP/IMS systems that are challenging the traditional status quo in telephony and
also represent a higher complexity in terms of architecture, personal telecommunications. As a result, a number of PSTN
protocols and implementation, with a corresponding increase providers have already completed or are in the process of
in the potential for misuse. Here, we begin to examine the
current state of affairs on VoIP/IMS security through a sur- transitioning from circuit-switched networks to VoIP-friendly
vey of known/disclosed security vulnerabilities in bug-tracking packet-switched backbones. Finally, as the commercial and
databases. This paper should serve as a starting point for consumer sectors go, so do governments and militaries due
understanding the threats and risks in a rapidly evolving set of to cost reduction concerns and the general dependence on
technologies that are seeing increasing deployment and use. Our Commercial Off The Shelf (COTS) equipment for the majority
goal is to gain a better understanding of the security landscape
with respect to VoIP/IMS, toward directing future research in of their computing needs.
this and other similar emerging technologies. However, higher complexity is often the price we pay for
more flexibility. In the case of VoIP/IMS technologies, a
I. I NTRODUCTION
number of factors contribute to architectural, protocol, imple-
The rate at which new technologies are being introduced mentation and operational complexity:
and adopted by society has been steadily accelerating through-
out human history. The advent of pervasive computing and • The number and complexity of the various features inte-
telecommunications has reinforced this trend. In this envi- grated in a product are perhaps the single largest source
ronment of constant innovation, individuals, governments and of complexity. For example, voice and video transmission
organizations have been struggling to manage the tension typically allow for a variety of codecs which may be used
between reaping the benefits of new technologies while un- in almost-arbitrary combinations. Since one of the biggest
derstanding and managing their risks. In this struggle, cost selling points for VoIP/IMS is feature-richness and the
reductions, convenience and new features typically overcome desire to unify personal communications under the same
security concerns. As a result, security experts (but also the umbrella, this is a particularly pertinent concern.
government and the courts of law) are often left with the task • Openness and modularity, generally considered desirable
of playing “catch up” with those who exploit flaws to further traits, allow for a number of independent implementations
their own goals. This is the situation we find ourselves in and products. Each of these comes with its own param-
with respect to one popular class of technologies, collectively eters and design choices. Interoperability concerns and
referred to as Voice over IP (VoIP). customer feedback then lead to an ever-growing baseline
VoIP, sometimes also referred to as Internet Multimedia of supported features for all products. A compounding
Subsystem (IMS), refers to a class of products that enable factor to increasing complexity for many of the open VoIP
advanced communication services over data networks. While protocols is the “design-by-committee” syndrome, which
voice is a key aspect in such products, video and other typically leads to larger, more inclusive specifications
capabilities (e.g., collaborative editing and whiteboard sharing, than would otherwise be the case (e.g., in a closed,
file sharing, calendaring) are supported. The key advantages proprietary environment such as the wireline telephony
of VoIP/IMS are flexibility and low cost. The former derives network from 20 years ago).
from the (generally) open architectures and software-based • Because VoIP systems are envisioned to operate in a
implementation, while the latter is due to new business models, variety of environments, business settings, and network
equipment and network-link consolidation, and ubiquitous conditions, they must offer considerable configurability,
consumer-grade broadband connectivity. which in turns leads to high complexity. Of particular
Due to these benefits, VoIP has seen rapid uptake in both concern are unforeseen feature interactions and other
the enterprise and consumer markets. An increasing number emergent properties.
of enterprises are replacing their internal phone switches with • Finally, VoIP are generally meant to work over a public
VoIP-based implementations, both to introduce new features data network (e.g., the Internet), or an enterprise/operator
 network that uses the same underlying technology. As a aspect of VoIP systems generally includes a comparatively
result, there is a substantial amount of (strictly speaking) simpler protocol for encapsulating data, with support for
non-VoIP infrastructure that is critical for the correct multiple codecs and (often, but not always) content security.
operation of the system, including such protocols/services A commonly used media transfer protocol is RTP [13], with
as DHCP [1], DNS [2], [3], TFTP/BOOTP [4], [5], NAT a version supporting encryption and integrity (SRTP [14])
[6] (and NAT traversal protocols such as STUN [7]), defined but not yet widely used. The RTP protocol family
NTP [8], SNMP [9], routing, the web (HTTP [10], [11], also includes RTCP, which is used to control certain RTP
TLS/SSL [12], etc.) and many others. As we shall see, parameters between communicating endpoints.
even a “perfectly secure” VoIP system can be compro- However, a variety of other features are generally also
mised by subverting elements of this infrastructure. desired by users and offered by providers as a means for differ-
Because of this complexity, which manifests itself both in entiation by competing technologies and services, such video,
terms of configuration options and size of the code base for integration with calendaring and file sharing, and bridging to
VoIP implementations, VoIP systems represent a very large at- other networks (e.g., to the “regular” telephony network). Fur-
tack surface. Thus, one should expect to encounter, over time, thermore, a number of different decisions may be made when
security problems arising from design flaws (e.g., exploitable designing a VoIP system, reflecting different requirements and
protocol weaknesses), undesirable feature interactions (e.g., approaches to addressing, billing, mobility, security and access
combinations of components that make new attacks possible or control, usability, and other issues. Consequently, there exist a
existing/known attacks easier), unforeseen dependencies (e.g., variety of different VoIP/IMS protocols and architectures. For
compromise paths through seemingly unrelated protocols), concreteness, we will focus our attention on a popular and
weak configurations, and, not least, implementation flaws. widely deployed technology: the Session Initiation Protocol
In this paper, we attempt a first effort at mapping out the (SIP) [15]. We will also discuss the Unlicensed Mobile Access
space of VoIP threats and risks by conducting a survey of (UMA) architecture [16], as a different approach to VoIP that
the “actually seen” vulnerabilities and attacks, as reported is gaining traction among wireless telephony operators. In the
by the popular press and by bug-tracking databases. Our rest of this section, we give a high-level overview of SIP and
work is by necessity of evolutionary nature, and this paper UMA, followed by a brief description of the salient points of
represents a current (and limited) snapshot of the complete a few other popular VoIP systems, such as H.323 and Skype.
space. Nonetheless, we believe that it will serve as a valuable We will refer back to this overview when discussing the threat
starting point for understanding the bigger problem, and as a space and specific vulnerabilities in Section III.
basis for a more comprehensive analysis in the future.
A. Session Initiation Protocol
Paper Organization: The remainder of this paper is
organized as follows. Section II contains a brief overview SIP is a protocol standardized by the Internet Engineering
of two major VoIP technologies, SIP and UMA. While we Task Force (IETF), and is designed to support the setup
refer to other VoIP/IMS systems throughout the discussion, of bidirectional communication sessions including, but not
we focus on the specific two technologies as they are both limited to, VoIP calls. It is similar in some ways to HTTP, in
representative, widely used, and well-documented. We discuss that it is text-based, has a request-response structure, and even
VoIP threats in Section III, placing known attacks against VoIP uses a mechanism based on the HTTP Digest Authentication
systems within the taxonomy proposed by the VoIP Security [17] for user authentication. However, it is an inherently state-
Alliance1 . We analyze our findings in Section IV, and conclude ful protocol that supports interaction with multiple network
with some preliminary thoughts on the current state of VoIP components (e.g., middleboxes such as PSTN bridges). While
security, and on possible future directions for security research its finite state machine is seemingly simple, in practice it
and practices in Section V. has become quite large and complicated — an observation
supported by the fact that the main SIP RFC [15] is one of
II. VO IP T ECHNOLOGIES OVERVIEW the longest ever defined.
In their simplest form, Voice over IP protocols simply SIP can operate over a number of transport protocols,
enable two (or more) devices to transmit and receive real-time including TCP [18], UDP [19] and SCTP [20]. UDP is gener-
audio traffic that allows their respective users to communicate. ally the preferred method due to simplicity and performance,
In general, VoIP architectures are partitioned in two main although TCP has the advantage of supporting TLS protection
components: signaling and media transfer. Signaling covers of call setup. However, recent work on Datagram TLS (DTLS)
both abstract notions, such as endpoint naming and addressing, [21] may render this irrelevant. SCTP, on the other hand,
and concrete protocol functions such as parameter negoti- offers several advantages over both TCP and UDP, including
ation, access control, billing, proxying, and NAT traversal. DoS resistance [22], multi-homing and mobility support, and
Depending on the architecture, quality of service (QoS) and logical connection multiplexing over a single channel.
device configuration/management may also be part of the In the SIP architecture, the main entities are end points
signaling protocol (or protocol family). The media transfer (whether softphones or physical devices), a proxy server, a
registrar, a redirect server, and a location server. Figure 1
1 [Link] shows a high-level view of the SIP entity interactions. The
 SIP Domain A SIP Domain B

Registrar

2
Location
Location Server
1 Server
4 6

5
Proxy Proxy
3 7

Media Transfer (RTP)

Alice Bob
8

Fig. 1. Session Initiation Protocol (SIP) entity interactions. User Alice registers with her domain’s Registrar (1), which stores the information in the Location
Server (2). When placing a call, Alice contacts her local Proxy Server (3), which may consult the Location Server (4). A call may be forwarded to another
Proxy Server (5), which will consult its domain Location Server (6) before forwarding the call to the final recipient. After the SIP negotiation terminates,
RTP is used directly between Alice and Bob to transfer media content. For simplicity, this diagram does not show the possible interaction between Alice and
a Redirection Server (which would, in turn, interact with the Location Server).

Alice Proxy/Proxies Bob

registrar, proxy and redirect servers may be combined, or they INVITE Bob
INVITE Bob@[Link]
may be separate entities operated independently. Endpoints
communicate with a registrar to indicate their presence. This TRYING TRYING
information is stored in the location server. A user may be RINGING
registered via multiple endpoints simultaneously. RINGING
OK from Bob@[Link]
OK from Bob@[Link]
During call setup, the endpoint communicates with the
proxy which uses the location server to determine where the ACK Bob, route Bob@[Link]
ACK Bob, route Bob@[Link]
call should be routed to. This may be another endpoint in the
same network (e.g., within the same enterprise), or another
proxy server in another network. Alternatively, endpoints may Media Transfer (RTP)

use a redirect server to directly determine where a call should

be directed to; redirect servers consult with the location server
in the same way that proxy servers operate during call setup. BYE Bob@[Link]
Once an end-to-end channel has been established (through one BYE Bob@[Link]

or more proxies) between the two endpoints, SIP negotiates OK

the actual session parameters (such as the codecs, RTP ports, OK

etc.) using the Session Description Protocol (SDP) [23].

Figure 2 shows the message exchanges during a two-party
call setup. Alice sends an INVITE message to the proxy server,
Fig. 2. Message exchanges during a SIP-based two-party call setup.
optionally containing session parameter information encoded
within SDP. The proxy forwards this message directly to Bob,
if Alice and Bob are users of the same domain. If Bob is
registered in a different domain, the message will be relayed mitting voice, video or other content (as negotiated) using the
to Bob’s proxy, and from there to Bob. Note that the message agreed-upon media transport protocol, typically RTP. While
may be forwarded to multiple endpoints, if bob is registered the signaling traffic may be relayed through a number of SIP
from multiple locations. While these are ringing (or otherwise proxies, the media traffic is exchanged directly between the
indicating that a call setup is being requested), RINGING two endpoints. When bridging different networks, e.g., PSTN
messages are sent back to Alice. Once the call has been and SIP, media gateways may disrupt the end-to-end nature
accepted, an OK message is sent to Alice, containing his of the media transfer. These entities translate content (e.g.,
preferred parameters encoded within SDP. Alice responds with audio) between the formats that are supported by the different
an ACK message. Alice’s session parameter preferences may networks.
be encoded in the INVITE or the ACK message. Because signaling and media transfer operate independent
Following this exchange, the two endpoints can begin trans- of each other, the endpoints are responsible for indicating to
 Registrar/Proxy Cellular Radio Access Network (RAN)
Alice Domain D1 Bob
INVITE sip:Bob@D2 Base Private Base Station
Transceiver
Network Controller
Stations
407 Authentication Required
Proxy−Authenticate:
Digest algorithm=MD5, Dual−mode
Core Mobile
realm="D1", nonce="12cc9a63" handset with
UMA support Network
Unlicensed Mobile Access Network

ACK sip:Bob@D2
WiFi UMA Network
Internet
INVITE sip:Bob@D2 Network Controller
Proxy authorization:
Digest username="Alice",
realm="D1", uri="sip:Bob@D2",
response="12acb23970af",
nonce="12cc9a63", algorithm=MD5 Fig. 4. Unlicensed Mobile Access (UMA) conceptual architecture
INVITE sip:Bob@D2

RINGING RINGING
OK OK
during a call setup. We shall later see an example where this
ACK sip:Bob@D2 ACK sip:Bob@D2 can be abused by a malicious party to conduct toll fraud in
some environments.
Media Transfer (RTP)
For more complex authentication scenarios, SIP can use
S/MIME encapsulation [24] to carry complex payloads, in-
Fig. 3. SIP Digest Authentication cluding public keys and certificates. When TCP is used as the
transport protocol for SIP, TLS can be used to protect the SIP
messages. TLS is required for communication among proxies,
the proxies that the call has been terminated, using a BYE registrars and redirect servers, but only recommended between
message which is relayed through the proxies along the same endpoints and proxies or registrars. Alternatively, IPsec [25]
path as the call setup messages. may be used to protect all communications, regardless of
There are many other protocol interactions supported by the transport protocol. However, because few implementations
SIP, that cover many common (and uncommon) scenarios integrate SIP, RTP and IPsec, it is left to system administrators
including call forwarding (manual or automatic), conference to figure out how to setup and manage such configurations.
calling, voicemail, etc. Typically, this is done by semantically
overloading SIP messages such that they can play various B. Unlicensed Mobile Access
roles in different parts of the call. We shall see in Section III UMA is a 3GPP standard for enabling transparent access
examples of how this flexibility and protocol modularity can to mobile circuit-switched voice networks, packet-switch data
be used to attack the system. networks and IMS services using any IP-based substrate.
All SIP traffic is transmitted over port 5060 (UDP or Handsets supporting UMA can roam between the operator’s
TCP). The ports used for the media traffic, however, are wireless network (usually referred to as a Radio Access
dynamic and negotiated via SDP during call setup. This poses Network, or RAN) and the Internet without losing access. For
some problems when Network Address Translation (NAT) or example, a call that is initiated over the RAN can then be
firewalls are traversed. Typically, these have to be stateful routed, without being dropped and with no user intervention,
and understand the SIP exchanges so that they can open the over the public Internet if conditions are more favorable
appropriate RTP ports for the media transfer. In the case of (e.g., stronger WiFi signal in the user’s premises, or in a
NAT traversal, endpoints may use protocols like STUN to hotel wireless hotspot while traveling abroad). For consumers,
enable communication. Alternatively, the Universal Plug-and- UMA offers better connectivity and the possibility of lower
Play (uPnP) protocol 2 may be used in some environments, cost by enabling new business models and reducing roaming
such as residential broadband networks consisting of a single charges (under some scenarios). For operators, UMA reduces
subnet behind a NAT gateway. the need for additional spectrum, cellphone towers and related
Authentication between endpoints, the registrar and the equipment. A variety of cellphones supporting UMA over
proxy typically uses HTTP Digest Authentication, as shown WiFi currently exist, along with home gateways and USB-stick
in Figure 3. This is a simple challenge-response protocol that softphones. More recently, some operators have introduced
uses a shared secret key along with a username, domain name, femtocells (ultra-low power RAN cells intended for consumer-
a nonce, and specific fields from the SIP message to compute directed deployment) that can act as UMA gateways, allowing
a cryptographic hash. Using this mechanism, passwords are any mobile handset to take advantage of UMA where such
not transmitted in plaintext form over the network. It is worth devices are deployed.
noting that authentication may be requested at almost any point The basic approach behind UMA is to encapsulate complete
GSM and 3G radio frames (except for the over-the-air crypto)
2 [Link] inside IP packets. These can then be transmitted over any IP
network, including the Internet. This means that the mobile ering security, interoperability with PSTN, teleconferencing,
operator can continue to use the existing back-end equipment; and others. Authentication may be requested at several steps
all that is needed is a gateway that decapsulates the GSM/3G during call setup, and typically depends on symmetric keys
frames and injects them to the existing circuit-switched net- but may also use digital signatures. Voice encryption is also
work (for voice calls), as can be seen in Figure 4. supported through SRTP and MIKEY [30]. Unlike SIP, H.323
To protect both signaling and media traffic confidentiality does not use a well-known port, making firewall traversal even
and integrity while traversing untrusted (and untrustworthy) more complicated.
networks, UMA uses IPsec. All traffic between the handset Skype3 is a peer-to-peer VoIP system that was originally
(or, more generally, UMA endpoint) and the provider’s UMA available as a softphone for desktop computers but has since
Network Controller (or a firewall/VPN concentrator screening been integrated into cellphones and other handheld devices,
traffic) is encrypted and integrity-protected using ESP [26]. either as an add-on or as the exclusive communication mech-
The use of IPsec provides a high level of security for the anism. It offers voice, video, and text messaging to all other
traffic, once keys and other parameters have been negotiated. Skype users free of charge, and provides bridging (typically
For that purpose, the IKEv2 key management protocol [27] for a fee) to the PSTN both for outgoing and incoming
is used. Authentication uses the EAP-SIM [28] (for GSM calls and text messages (SMS). The underlying protocol is
handsets) and EAP-AKA [29] (for UMTS handsets) profiles. proprietary, and the software itself incorporates several anti-
Authentication is asymmetric: the provider authenticates to the reverse engineering techniques. Nonetheless, some analysis
handset using digital signatures and public key certificates, [31], [32] and reverse engineering [33] have taken place,
while the handset authenticates using a SIM-embedded secret indicating both the ubiquitous use of strong cryptography and
key. It is worth pointing out that UMA provides stronger the presence of some software bugs (at the time of the work).
authentication guarantees than the baseline cellphone network, The system uses a centralized login server but is otherwise
in that the provider does not authenticate to the handset in a fully distributed with respect to intra-Skype communications.
RAN. Furthermore, the cryptographic algorithms used in IPsec A number of chat (IM) networks, such as the AOL Instant
(AES and 3DES) are considered significantly stronger than the Messenger, Microsoft’s Live Messenger, Yahoo! Messenger,
on-the-air algorithms used in GSM. and Google Talk offer voice and video capabilities as well.
Despite the use of strong cryptography and sound protocols, Although each network uses its own (often proprietary) pro-
UMA introduces some new risks in the operator networks, tocol, there exist bridges between most of them, allowing
since these now have to be connected to the public Internet in a inter-IM communication at the text level. In most of these
much more intimate fashion. In particular, the security gateway networks, users can place outgoing voice calls to the PSTN.
must process IPsec traffic, including the relatively complex Some popular IM clients also integrate SIP support.
IKEv2 protocol, and a number of UMA-related discovery and
configuration protocols. These increase the attack surface and III. VO IP T HREATS
overall security exposure of the operators significantly.
In trying to understand the threat space against VoIP, our
C. Other VoIP/IMS Systems approach is to place known vulnerabilities within a structured
H.323 is an ITU-defined protocol family for VoIP (audio framework. While a single taxonomy is not likely to be
and video) over packet-switched data networks. The various definitive, using several different viewpoints and mapping the
subprotocols are encoded in ASN.1 format. In the H.323 vulnerability space along several axis may reveal trends and
world, the main entities are terminals (software or physical areas that merit further analysis.
phones), a gateway, a gatekeeper and a back-end service. The As a starting point, we use the taxonomy provided by
gatekeeper is responsible for address resolution, controlling the Voice over IP Security Alliance (VoIPSA)4 . VoIPSA is a
bandwidth use and other management functions, while the vendor-neutral, not for profit organization composed of VoIP
gateway connects the H.323 network with other networks (e.g., and security vendors, organizations and individuals with an
PSTN, or a SIP network). The back-end service maintains interest in securing VoIP protocols, products and installations.
data about the terminals, including configuration, access and In addition, we place the surveyed vulnerabilities within the
billing rights, etc. An optional multipoint control unit may traditional threat space of confidentiality, integrity, availability
also exist to enable multipoint communications, such as a (CIA). Finally, we consider whether the vulnerabilities exploit
teleconference. To setup a H.323 call, terminals first interact bugs in the protocol, implementation or system configuration.
with the gatekeeper using the H.225 protocol over either TCP In future work, we hope to expand the number of views to the
or UDP to receive authorization and perform address resolu- surveyed vulnerabilities and to provide more in-depth analysis.
tion. Using the same protocol, they then establish the end- The VoIPSA security threat taxonomy [34] aims to define
to-end connection to the remote terminal (possibly through the security threats against VoIP deployments, services, and
one or more gateways). At that point, H.245 over TCP is end users. The key elements of this taxonomy are:
used to negotiate the parameters for the actual media transfer,
including ports, which uses RTP (as in the case of SIP). A 3 [Link]

number of other protocols within the H.323 framework cov- 4 [Link]

 1) Social threats are aimed directly against humans. For Confidentiality via a Configuration problem or bug. In some
example, misconfigurations, bugs or bad protocol inter- cases, the same underlying vulnerability may be used to
actions in VoIP systems may enable or facilitate attacks perform different types of attacks. We will be discussing all
that misrepresent the identity of malicious parties to such significant attack variants.
users. Such attacks may then act as stepping stones
to further attacks such as phishing, theft of service, or A. Disclosed Vulnerabilities
unwanted contact (spam). Threats against VoIP system availability by exploiting im-
2) Eavesdropping, interception, and modification plementation weaknesses are fairly common. For example,
threats cover situations where an adversary can some implementations where shown to be vulnerable to
unlawfully and without authorization from the parties crashes or hanging (livelock) when given empty, malformed,
concerned listen in on the signaling (call setup) or the or large volumes of [37]–[150] INVITE or other messages
content of a VoIP session, and possibly modify aspects (3, A1 , I2 ). It is worth noting that the same vulnerability may
of that session while avoiding detection. Examples of be present across similar protocols on the same platform
such attacks include call re-routing and interception of and product [44] due to code sharing and internal software
unencrypted RTP sessions. structure, or to systems that need to understand VoIP protocols
3) Denial of service threats have the potential to deny but are not nominally part of a VoIP system [151]. The
users access to VoIP services. This may be particularly reason for the disproportionately large number of denial of
problematic in the case of emergencies, or when a service vulnerabilities is because of the ease with which such
DoS attack affects all of a user’s or organization’s failure can be diagnosed, especially when the bug is discovered
communication capabilities (i.e., when all VoIP and data through automated testing tools (e.g., fuzzers). Many of these
communications are multiplexed over the same network vulnerabilities may in fact be more serious than a simple denial
which can be targeted through a DoS attack). Such of service due to a crash, and could possibly lead to remote
attacks may be VoIP-specific (exploiting flaws in the code injection and execution.
call setup or the implementation of services), or VoIP- Unexpected interactions between different technologies
agnostic (e.g., generic traffic flooding attacks). They used in VoIP systems can also lead to vulnerabilities. For
may also involve attacks with physical components (e.g., example, in some cases cross-site scripting (XSS) attacks were
physically disconnecting or severing a cable) or through demonstrated against the administrator- and customer-facing
computing or other infrastructures (e.g., disabling the management interface (which was web-based) by injecting
DNS server, or shutting down power). malicious Javascript in selected SIP messages [152]–[159]
4) Service abuse threats covers the improper use of VoIP (1, I1 , I2 ), often through SQL injection vulnerabilities [160],
services, especially (but not exclusively) in those situa- [161]. The same vulnerability could also be used to commit
tions where such services are offered in a commercial toll fraud by targeting the underlying database (4, I1 , I2 ). XSS
setting. Examples of such threats include toll fraud and attacks that are not web-oriented have also been demonstrated,
billing avoidance [35], [36]. with one of the oldest VoIP-related vulnerabilities [162] per-
5) Physical access threats refer to inappropri- mitting shell command execution (1, I1 , I2 ). Another web-
ate/unauthorized physical access to VoIP equipment, or oriented attack vector is Cross Site Request Forgery (CSRF),
to the physical layer of the network (following the ISO whereby users visiting a malicious page can be induced to
7-layer network stack model). automatically (without user intervention, and often without
6) Interruption of services threats refer to non-intentional any observable indications) perform some action on the web
problems that may nonetheless cause VoIP services to servers (in this case, VoIP web-based management interface)
become unusable or inaccessible. Examples of such that their browser is already authenticated to [163] (1, I1 , I2 ).
threats include loss of power due to inclement weather, Other privilege-escalation vulnerabilities through the web in-
resource exhaustion due to over-subscription, and per- terface also exist [164] (1, I1 , I2 ).
formance issues that degrade call quality. The complexity of the SIP finite state machine has some-
In our discussion of vulnerabilities (whether theoretical or times led to poor implementations. For example, one vulner-
demonstrated) that follows, we shall mark each item with a ability [165] allowed attackers to confuse a phone receiving
tuple (V, T, K), where: a call into silently completing the call, which allowed the ad-
versary to eavesdrop on the device’s surroundings (2, C1 , I2 ).
• V ∈ {1, 2, 3, 4, 5, 6}, where each number refers to an The same vulnerability could be used to deny call reception
element in the VoIPSA threat taxonomy from above at the target, since the device was already marked as busy
• T ∈ {C1 , I1 , A1 }, referring to Confidentiality, Integrity (3, A1 , I2 ). In other cases, it is unclear to developers what use
and Availability respectively of a specific protocol field may be, in which case they may
• K ∈ {P2 , I2 , C2 }, referring to Protocol, Implementation silently ignore it. Occasionally, such information is critical for
and Configuration respectively the security of the protocol exchange, and omitting or not
For example, an item marked as (1, C1 , C2 ) refers to a checking it allows adversaries to perform attacks such man-
vulnerability that targets the user (Social threat), violating in-the-middle or traffic interception [166] (2, C1 + I1 , I2 ), or
to bypass authentication checks [167], [168] (4, I1 , I2 ). since the boot and VoIP stacks are not necessarily tightly
Since SIP devices are primarily software-driven, they are integrated, interaction with one protocol can have adverse
vulnerable to the same classes of vulnerabilities as other soft- effects (e.g., changing the perceived location of the phone)
ware. For example, buffer overflows are possible even against in the other protocol [231] (2, C1 , I2 ). Other instances of
SIP “hardphones”, much less softphones, allowing adversaries such vulnerabilities involve improper/insufficient credential
to gain complete control of the device [40], [64], [65], [169]– checking by the registrar or proxy [232] or by the SNMP
[191] (2, I1 , I2 ). Such vulnerabilities typically arise from a server [233], which can lead to traffic interception (2, C1 , I2 )
combination of poor (non-defensive) programming practices, and user impersonation (1, I1 , I2 ).
insufficient testing, and the use of languages, such as C The integration of several capabilities in VoIP products,
and C++ that support unsafe operations. Sometimes, these e.g., a web server used for the management interface, can
vulnerabilities appear in software that is not directly used lead to vulnerabilities being imported to the VoIP environment
in VoIP but must be VoIP-aware, e.g., firewalls [192] or that would not otherwise apply. In the specific example of
protocol analyzers [193] (2, I1 , I2 ). It is also worth noting an integrated web server, directory traversal bugs [234] or
that these are not the only types of vulnerabilities that can similar problems (such as lack of proper authentication in
lead to remote code execution [59], [194]–[198]. Other input the web interface) [235], [236] can allow adversaries to read
validation failures can allow attackers to download arbitrary arbitrary files or other information from the device (1, C1 , I2 ).
files from a user’s machine (1, C1 , I2 ) or to place calls [199] SIP (or, more generally, VoIP) components integrated with
(1, I1 , I2 ) by supplying specially encoded URIs [200] or other firewalls may also interact in undesirable ways. For example,
parameters. improper handling of registration requests may allow attackers
A significant risk with VoIP devices is the ability of to receive messages intended for other users [237] (2, C1 , I2 ).
adversaries to misrepresent their identity (e.g., their calling Other such examples include failure to authenticate server
number). Such vulnerabilities [201] sometimes arise due to certificates in wireless environments, enabling man-in-the-
the lack of cross-checking of information provided across middle and eavesdropping attacks [238], [239] (2, C1 , I2 ).
several messages during call setup and throughout the session Predictability and lack of proper use (or sources) of ran-
(1, I1 , I2 ). domness is another vulnerability seen in VoIP products. For
Similar failures to cross-check and validate information example, predictable values in SIP header messages [240]
can lead to other attacks, such as indicating whether there allows malicious users to avoid registering but continue using
is pending voicemail for the user [202] (1, I1 , I2 ), or where the service (4, I1 , I2 ).
attackers may spoof incoming calls by directly connecting to Protocol responses to carefully crafted messages can reveal
a VoIP phone [203]–[205] (1, I1 , I2 ). information about the system or its users to an attacker.
Undocumented, on-by-default features are another source Although this has been long understood in limited-domain pro-
of vulnerabilities. These are often remnants from testing and tocols (e.g., remote login), with measures taken to normalize
debugging during development that were not disabled when responses such that no information is leaked, the complexity
a product shipped [206]–[210]. As a result, they often offer of VoIP (and other) protocols make this infeasible. As a
privileged access to services and data on a device that would result, information disclosure vulnerabilities abound [241],
not be otherwise available [211]–[216] (1, C1 , I2 ). One par- [242] (1, C1 , I2 ).
ticularly interesting vulnerability allowed an attacker to place Some of the most serious non-implementation type of vul-
outgoing calls through the web management interface [217], nerabilities are those where the specification permits behavior
[218] (4, I1 , C2 ). that is exploitable. For example, certain vendors permit the
A significant class of vulnerabilities in VoIP devices re- actual URI in a SIP INVITE call and the URI used as part
volves around default configurations, and in particular default of the Digest Authentication to differ, which (while arguably
usernames and passwords [216], [219]–[228] (2, C1 + I1 , C2 ). permitted by the specification) allows credential reuse and toll
Lists of default accounts are easy to find on the Internet via fraud [243], [244] (4, I1 , P2 ).
a search engine. Users often do not change these settings; While rare, protocol-level vulnerabilities also exist. These
ironically, this seems to be particularly so for administrative represent either outright bugs in the specification, or un-
accounts, which are rarely (if ever) used in the home/SOHO foreseen interaction between different protocols or protocol
environment. Other default settings involve NTP servers [229] components. For large, complicated protocols such as SIP
and DNS servers [230] (2, C1 + I1 , C2 ). and H.323, where components (code, messages, etc.) are se-
Call interception vulnerabilities are a big concern with VoIP mantically overloaded and reused, it is perhaps not surprising
systems, given the plethora of tools for decoding video and that such emergent properties exist. One good example is the
audio streams and the ease of eavesdropping network traffic, relay attack possible with the SIP Digest Authentication [245],
especially on the local subnet. Sometimes, such vulnerabilities whereby an adversary can reuse another party’s credentials to
arise from strange protocol interactions and implementation obtain unauthorized access to SIP or PSTN services (such as
decisions. For example, caching the location (address) of calling a premium or international phone line) (4, I1 , P2 ). This
a VoIP phone based on the IP address used during boot attack, depicted in Figure 5, is possible because authentication
time (using TFTP) seems a reasonable approach; however, may be requested in response to an INVITE message at any
 SIP proxy/PSTN bridge
Domain D1 Attacker Alice@D1
INVITE Alice@D1
(call setup)
OK
13%
ACK

8%
Media (RTP)

48%
INVITE Attacker (Attacker on hold) 12%
(rewrite INVITE from Alice)
INVITE +1−900−PREMIUM

407 Authentication needed

ACK
20%
(reverse rewrite, relay
authentication request)
407 Authentication needed
ACK

(rewrite INVITE from Alice) INVITE Attacker (auth)

+1−900−PREMIUM INVITE +1−900−PREMIUM Denial of Service Remote control of device
PSTN call (auth) Attack the user Access to data
Media (RTP) Access to services

Fig. 5. SIP relay attack Fig. 6. Vulnerability breakdown based on effect. Most categories are self-
explanatory; “attack the user” refers to vulnerabilities that permit attackers to
affect the user/administrator of a device, without necessarily compromising
the system or getting access to its data or services. XSS attacks and traffic
time during a call, and the responder may issue an INVITE eavesdropping attacks fall in this category, whereas attacks that compromise
message during a call either automatically (because of timer state (data) resident on the system fall in the “access to data” category.
expirations) or through a user action (e.g., placing the caller
on hold in order to do a call transfer).

IV. D ISCUSSION 4%
19%
Looking at the vulnerabilities we have considered, a few
patterns emerge. First, as we can see in our informal classi-
fication of vulnerability effects show in Figure 6, half of the
problems lead to a denial of service in either an end-device 21%
(phone, softphone) or a server (proxy, registrar, etc.). This is 57%
not altogether surprising, since denial of service (especially a
crash) is something that is easily diagnosed. In many cases, the
problem was discovered by automated testing, such as protocol
or software fuzzing; software failures are relatively easy to
determine in such settings. Some of these vulnerabilities could
in fact turn out to be more serious, e.g., a memory corruption Social threats (1) Eavesdropping, hijacking (2)
Denial of Service (3) Service Abuse (4)
leading to a crash could be exploitable to mount a code
Physical Access (5) Interruption of Services (6)
injection attack. The second largest class of vulnerabilities
allows an adversary to control the device, whether by code
injection, default passwords and services, or authentication Fig. 7. Vulnerability breakdown based on VoIPSA taxonomy
failures. Note that we counted a few of the vulnerabilities
(approximately 10%) more than once in this classification.
The same pattern with respect to the predominance of denial other observation here is that, while the VoIPSA taxonomy
of service vulnerabilities holds when we look at the breakdown covers a broad spectrum of concerns for VoIP system designers
according to the VoIPSA taxonomy, shown in Figure 7. It and operators, its categories are too perhaps too broad (and, in
should not be surprising that, given the nature of the vul- some cases, imprecise) to help with characterizing the types
nerabilities disclosed in CVE, we have no data on physical of bugs we have examined.
access and (accidental) interruption of services vulnerabilities. The vulnerability breakdown according to the traditional
Furthermore, while “Access to Services” was a non-negligible (Confidentiality, Integrity, Availability) security concerns again
component in the previous breakdown, it represents only 4% reflects the predominance of denial of service threats against
here. The reason for this apparent discrepancy is in the differ- VoIP systems, as seen in Figure 8. However, we can see that
ent definitions of service: the specific element in the VoIPSA Integrity violations (e.g., system compromise) are a sizable
taxonomy refers to VoIP-specific abuse, whereas our informal component of the threat space, while Confidentiality violations
definition covers lower-level system components which may are seen in only 15% of disclosed vulnerabilities. This repre-
not be usable in, for example, placing fraudulent calls. One sents an inversion of the perceived threats by users and admin-
 15%

7%
48% 91% 1%
36%

Confidentiality Integrity Availability

Protocol Implementation Configuration
Fig. 8. Vulnerability breakdown based on “traditional” security classification
(C1 , I1 , A1 )
Fig. 9. Vulnerability breakdown based on source (I2 , C2 , P2 )

istrators, who (anecdotal evidence suggests) typically worry

about such issues as call interception and eavesdropping. tolerance, etc.), it is less clear how to provide similar
Finally, Figure 9 shows the breakdown based on source of levels of protection at acceptable cost and usability to
vulnerability. The overwhelming majority of reported prob- end user devices. Unfortunately, the easy with which
lems arise from implementation issues, which should not mass DoS attacks can be launched over the network
be surprising given the nature of bug disclosure. Problems against client devices means that they represent an
arising from configuration represented 7% of the total space, attractive venue for attackers to achieve the same impact.
including such items as privileged services left on and default 2) Code injection attacks in their various forms (buffer
username/passwords. However, note that the true picture (i.e., overflow, cross-site scripting, SQL injection, etc.) remain
what actually happens with deployed systems) is probably a problem. While a number of techniques have been
different in that configuration problems are most likely un- developed, we need to do a better job at deploying and
dercounted: such problems are often site-specific and are not using them where possible, and devising new techniques
reported to bug-disclosure databases when discovered. On suitable for the constrained environments that some
the other hand, implementation and protocol problems are vulnerable VoIP devices represent.
prime candidates for disclosure. What is surprising is the 3) Weak default configurations remain a problem, as they
presence of protocol vulnerabilities; one would expect that do across a large class of consumer and enterprise
such problems were discovered and issued during protocol products and software. The situation is likely to be much
development, specification, and standardization. Their mere worse in the real world, considering the complexity of
existence potentially indicates high protocol complexity. securely configuring a system with as many components
The vulnerability analysis contained in this paper is, by as VoIP. Vendors must make an effort to provide secure-
its nature, static: we have presented a snapshot of known by-default configurations, and to educate users how best
problems with VoIP systems, with no correlation with (and to protect their systems. Administrators are in need
knowledge of) actual attacks exploiting these, or other vulner- of tools to analyze their existing configurations for
abilities. A complete analysis of the threat space would also vulnerabilities. While some tools that dynamically test
contain a dynamic component, whereby attacker behavior pat- network components (e.g., firewalls), we need tools that
terns and trends would be analyzed vis-a-vis actual, deployed work higher in the protocol and application stack (i.e.,
VoIP systems or, lacking access to such, simulacra thereof interacting at the user level). Furthermore, we need ways
[246]. of validating configurations across multiple components
and protocols.
V. C ONCLUSIONS
4) Finally, there is simply no excuse for protocol-level
We can draw some preliminary conclusions with respect to vulnerabilities. While there exist techniques for ana-
threats and focus areas for future research based on the data lyzing and verifying security protocols, they do not
examined so far. These can be summarized as follows: seem to cope well with complexity. Aside from using
1) The large majority of disclosed threats focused on denial such tools and continuing their development, protocol
of services attacks based on implementation issues. designers and standardization committees must consider
While fault-tolerance techniques can be applied in the the impact of their decisions on system implementers,
case of servers (replication, hot standby, Byzantine fault i.e., whether it is likely that a feature or aspect of
 the protocol is likely to be misunderstood and/or mis- [24] B. Ramsdell, “Secure/Multipurpose Internet Mail Extensions
implemented. Simpler protocols are also desirable, but (S/MIME) Version 3.1 Message Specification,” RFC 3851 (Proposed
Standard), July 2004.
seem incompatible with the trends we have observed in [25] S. Kent and K. Seo, “Security Architecture for the Internet Protocol,”
standardization bodies. RFC 4301 (Proposed Standard), Dec. 2005.
[26] S. Kent, “IP Encapsulating Security Payload (ESP),” RFC 4303
Our plans for future work include expanding the data set we (Proposed Standard), Dec. 2005.
used for our analysis to include findings from academic work, [27] C. Kaufman, “Internet Key Exchange (IKEv2) Protocol,” RFC 4306
adding and presenting more views (classifications) to the data, (Proposed Standard), Dec. 2005, Updated by RFC 5282.
and developing dynamic views to VoIP-related misbehavior. [28] H. Haverinen and J. Salowey, “Extensible Authentication Protocol
Method for Global System for Mobile Communications (GSM) Sub-
ACKNOWLEDGMENTS scriber Identity Modules (EAP-SIM),” RFC 4186 (Informational), Jan.
2006.
This work was supported by the French National Research [29] J. Arkko and H. Haverinen, “Extensible Authentication Protocol
Agency (ANR) under Contract ANR-08-VERS-017. Method for 3rd Generation Authentication and Key Agreement (EAP-
AKA),” RFC 4187 (Informational), Jan. 2006.
R EFERENCES [30] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman,
“MIKEY: Multimedia Internet KEYing,” RFC 3830 (Proposed Stan-
[1] R. Droms, “Dynamic Host Configuration Protocol,” RFC 2131 (Draft dard), Aug. 2004, Updated by RFC 4738.
Standard), Mar. 1997, Updated by RFCs 3396, 4361, 5494. [31] Tom Berson, “Skype Security Evaluation,” Tech. Rep., October 2005.
[2] P.V. Mockapetris, “Domain names - concepts and facilities,” RFC 1034 [32] S. A. Baset and H. Schulzrinne, “An Analysis of the Skype Peer-to-
(Standard), Nov. 1987, Updated by RFCs 1101, 1183, 1348, 1876, Peer Telephony Protocol,” in Proceedings of INFOCOM, April 2006.
1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4035, 4592. [33] P. Biondi and F. Desclaux, “Silver Needle in the Skype,” in
[3] P.V. Mockapetris, “Domain names - implementation and specification,” BlackHat Europe Conference, March 2006, [Link].
RFC 1035 (Standard), Nov. 1987, Updated by RFCs 1101, 1183, 1348, com/presentations/bh-europe-06/bh-eu-06-biondi/
1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2845, [Link].
3425, 3658, 4033, 4034, 4035, 4343. [34] VoIP Security Alliance, “VoIP Security and Privacy Threat Tax-
[4] K. Sollins, “The TFTP Protocol (Revision 2),” RFC 1350 (Standard), onomy, version 1.0,” [Link]
July 1992, Updated by RFCs 1782, 1783, 1784, 1785, 2347, 2348, [Link], October 2005.
2349. [35] The Register, “Two charged with VoIP fraud,” [Link]
[5] R. Finlayson, “Bootstrap loading using TFTP,” RFC 906, June 1984. [Link]/2006/06/08/voip fraudsters
[6] P. Srisuresh and K. Egevang, “Traditional IP Network Address nabbed/, June 2006.
Translator (Traditional NAT),” RFC 3022 (Informational), Jan. 2001. [36] The Register, “Fugitive VOIP hacker cuffed in Mexico,”
[7] J. Rosenberg, R. Mahy, P. Matthews, and D. Wing, “Session Traversal [Link]
Utilities for NAT (STUN),” RFC 5389 (Proposed Standard), Oct. 2008. fugitive voip hacker arrested/, February 2009.
[8] D. Mills, “Network Time Protocol (Version 3) Specification, Imple- [37] “CVE-2007-4753,” [Link]
mentation and Analysis,” RFC 1305 (Draft Standard), Mar. 1992. [Link]?name=CVE-2007-4753, 2007.
[9] D. Harrington, R. Presuhn, and B. Wijnen, “An Architecture for De- [38] “CVE-2007-0431,” [Link]
scribing Simple Network Management Protocol (SNMP) Management [Link]?name=CVE-2007-0431, 2007.
Frameworks,” RFC 3411 (Standard), Dec. 2002, Updated by RFC [39] “CVE-2007-4553,” [Link]
5343. [Link]?name=CVE-2007-4553, 2007.
[10] T. Berners-Lee, R. Fielding, and H. Frystyk, “Hypertext Transfer [40] “CVE-2003-1114,” [Link]
Protocol – HTTP/1.0,” RFC 1945 (Informational), May 1996. [Link]?name=CVE-2003-1114, 2003.
[11] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and [41] “CVE-2006-1973,” [Link]
T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” RFC 2616 [Link]?name=CVE-2006-1973, 2006.
(Draft Standard), June 1999, Updated by RFC 2817. [42] “CVE-2007-0648,” [Link]
[12] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) [Link]?name=CVE-2007-0648, 2007.
Protocol Version 1.2,” RFC 5246 (Proposed Standard), Aug. 2008.
[43] “CVE-2007-2270,” [Link]
[13] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A
[Link]?name=CVE-2007-2270, 2007.
Transport Protocol for Real-Time Applications,” RFC 3550 (Standard),
[44] “CVE-2007-4291,” [Link]
July 2003, Updated by RFC 5506.
[Link]?name=CVE-2007-4291, 2007.
[14] I. Johansson and M. Westerlund, “Support for Reduced-Size Real-Time
Transport Control Protocol (RTCP): Opportunities and Consequences,” [45] “CVE-2007-4292,” [Link]
RFC 5506 (Proposed Standard), Apr. 2009. [Link]?name=CVE-2007-4292, 2007.
[15] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, [46] “CVE-2008-3799,” [Link]
R. Sparks, M. Handley, and E. Schooler, “SIP: Session Initiation [Link]?name=CVE-2008-3799, 2008.
Protocol,” RFC 3261 (Proposed Standard), June 2002, Updated by [47] “CVE-2008-3800,” [Link]
RFCs 3265, 3853, 4320, 4916, 5393. [Link]?name=CVE-2008-3800, 2008.
[16] 3GPP, “Generic Access Network,” [Link] [48] “CVE-2008-3801,” [Link]
Specs/html-info/[Link], 2009. [Link]?name=CVE-2008-3801, 2008.
[17] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, [49] “CVE-2008-3802,” [Link]
A. Luotonen, and L. Stewart, “HTTP Authentication: Basic and Digest [Link]?name=CVE-2008-3802, 2008.
Access Authentication,” RFC 2617 (Draft Standard), June 1999. [50] “CVE-2009-1158,” [Link]
[18] J. Postel, “Transmission Control Protocol,” RFC 793 (Standard), Sept. [Link]?name=CVE-2009-1158, 2009.
1981, Updated by RFCs 1122, 3168. [51] “CVE-2004-0054,” [Link]
[19] J. Postel, “User Datagram Protocol,” RFC 768 (Standard), Aug. 1980. [Link]?name=CVE-2004-0054, 2004.
[20] L. Ong and J. Yoakum, “An Introduction to the Stream Control [52] “CVE-2001-0546,” [Link]
Transmission Protocol (SCTP),” RFC 3286 (Informational), May 2002. [Link]?name=CVE-2001-0546, 2001.
[21] E. Rescorla and N. Modadugu, “Datagram Transport Layer Security,” [53] “CVE-2002-2266,” [Link]
RFC 4347 (Proposed Standard), Apr. 2006. [Link]?name=CVE-2002-2266, 2002.
[22] M. Handley, E. Rescorla, and IAB, “Internet Denial-of-Service Con- [54] “CVE-2004-0498,” [Link]
siderations,” RFC 4732 (Informational), Dec. 2006. [Link]?name=CVE-2004-0498, 2004.
[23] M. Handley, V. Jacobson, and C. Perkins, “SDP: Session Description [55] “CVE-2004-2344,” [Link]
Protocol,” RFC 4566 (Proposed Standard), July 2006. [Link]?name=CVE-2004-2344, 2004.
[56] “CVE-2004-2629,” [Link] [93] “CVE-2007-3362,” [Link]
[Link]?name=CVE-2004-2629, 2004. [Link]?name=CVE-2007-3362, 2007.
[57] “CVE-2004-2758,” [Link] [94] “CVE-2007-3361,” [Link]
[Link]?name=CVE-2004-2758, 2004. [Link]?name=CVE-2007-3361, 2007.
[58] “CVE-2007-4429,” [Link] [95] “CVE-2007-3351,” [Link]
[Link]?name=CVE-2007-4429, 2007. [Link]?name=CVE-2007-3351, 2007.
[59] “CVE-2006-5084,” [Link] [96] “CVE-2007-3350,” [Link]
[Link]?name=CVE-2006-5084, 2006. [Link]?name=CVE-2007-3350, 2007.
[60] “CVE-2005-3267,” [Link] [97] “CVE-2007-3349,” [Link]
[Link]?name=CVE-2005-3267, 2005. [Link]?name=CVE-2007-3349, 2007.
[61] “CVE-2004-1777,” [Link] [98] “CVE-2007-3348,” [Link]
[Link]?name=CVE-2004-1777, 2004. [Link]?name=CVE-2007-3348, 2007.
[62] “CVE-2003-1108,” [Link] [99] “CVE-2007-3322,” [Link]
[Link]?name=CVE-2003-1108, 2003. [Link]?name=CVE-2007-3322, 2007.
[63] “CVE-2003-1109,” [Link] [100] “CVE-2007-3321,” [Link]
[Link]?name=CVE-2003-1109, 2003. [Link]?name=CVE-2007-3321, 2007.
[64] “CVE-2003-1110,” [Link] [101] “CVE-2007-3318,” [Link]
[Link]?name=CVE-2003-1110, 2003. [Link]?name=CVE-2007-3318, 2007.
[65] “CVE-2003-1111,” [Link] [102] “CVE-2007-3317,” [Link]
[Link]?name=CVE-2003-1111, 2003. [Link]?name=CVE-2007-3317, 2007.
[66] “CVE-2003-1112,” [Link] [103] “CVE-2007-2297,” [Link]
[Link]?name=CVE-2003-1112, 2003. [Link]?name=CVE-2007-2297, 2007.
[67] “CVE-2003-1113,” [Link] [104] “CVE-2007-1693,” [Link]
[Link]?name=CVE-2003-1113, 2003. [Link]?name=CVE-2007-1693, 2007.
[68] “CVE-2003-1115,” [Link] [105] “CVE-2007-1650,” [Link]
[Link]?name=CVE-2003-1115, 2003. [Link]?name=CVE-2007-1650, 2007.
[69] “CVE-2004-0504,” [Link] [106] “CVE-2007-1594,” [Link]
[Link]?name=CVE-2004-0504, 2004. [Link]?name=CVE-2007-1594, 2007.
[70] “CVE-2005-4466,” [Link] [107] “CVE-2007-1590,” [Link]
[Link]?name=CVE-2005-4466, 2005. [Link]?name=CVE-2007-1590, 2007.
[71] “CVE-2006-5445,” [Link] [108] “CVE-2007-1561,” [Link]
[Link]?name=CVE-2006-5445, 2006. [Link]?name=CVE-2007-1561, 2007.
[72] “CVE-2006-2924,” [Link] [109] “CVE-2007-1542,” [Link]
[Link]?name=CVE-2006-2924, 2006. [Link]?name=CVE-2007-1542, 2007.
[73] “CVE-2006-0739,” [Link] [110] “CVE-2007-1306,” [Link]
[Link]?name=CVE-2006-0739, 2006. [Link]?name=CVE-2007-1306, 2007.
[74] “CVE-2006-0738,” [Link] [111] “CVE-2007-0961,” [Link]
[Link]?name=CVE-2006-0738, 2006. [Link]?name=CVE-2007-0961, 2007.
[75] “CVE-2006-0737,” [Link] [112] “CVE-2008-0095,” [Link]
[Link]?name=CVE-2006-0737, 2006. [Link]?name=CVE-2008-0095, 2008.
[76] “CVE-2007-6371,” [Link] [113] “CVE-2008-0263,” [Link]
[Link]?name=CVE-2007-6371, 2007. [Link]?name=CVE-2008-0263, 2008.
[77] “CVE-2007-5583,” [Link] [114] “CVE-2008-1249,” [Link]
[Link]?name=CVE-2007-5583, 2007. [Link]?name=CVE-2008-1249, 2008.
[78] “CVE-2007-5537,” [Link] [115] “CVE-2008-1741,” [Link]
[Link]?name=CVE-2007-5537, 2007. [Link]?name=CVE-2008-1741, 2008.
[79] “CVE-2007-4924,” [Link] [116] “CVE-2008-1745,” [Link]
[Link]?name=CVE-2007-4924, 2007. [Link]?name=CVE-2008-1745, 2008.
[80] “CVE-2007-4459,” [Link] [117] “CVE-2008-1747,” [Link]
[Link]?name=CVE-2007-4459, 2007. [Link]?name=CVE-2008-1747, 2008.
[81] “CVE-2007-4455,” [Link] [118] “CVE-2008-1748,” [Link]
[Link]?name=CVE-2007-4455, 2007. [Link]?name=CVE-2008-1748, 2008.
[82] “CVE-2007-4382,” [Link] [119] “CVE-2008-1959,” [Link]
[Link]?name=CVE-2007-4382, 2007. [Link]?name=CVE-2008-1959, 2008.
[83] “CVE-2007-4366,” [Link] [120] “CVE-2008-2119,” [Link]
[Link]?name=CVE-2007-4366, 2007. [Link]?name=CVE-2008-2119, 2008.
[84] “CVE-2007-3445,” [Link] [121] “CVE-2008-2732,” [Link]
[Link]?name=CVE-2007-3445, 2007. [Link]?name=CVE-2008-2732, 2008.
[85] “CVE-2007-3444,” [Link] [122] “CVE-2008-2733,” [Link]
[Link]?name=CVE-2007-3444, 2007. [Link]?name=CVE-2008-2733, 2008.
[86] “CVE-2007-3443,” [Link] [123] “CVE-2008-2734,” [Link]
[Link]?name=CVE-2007-3443, 2007. [Link]?name=CVE-2008-2734, 2008.
[87] “CVE-2007-3442,” [Link] [124] “CVE-2008-2735,” [Link]
[Link]?name=CVE-2007-3442, 2007. [Link]?name=CVE-2008-2735, 2008.
[88] “CVE-2007-3441,” [Link] [125] “CVE-2008-3157,” [Link]
[Link]?name=CVE-2007-3441, 2007. [Link]?name=CVE-2008-3157, 2008.
[89] “CVE-2007-3437,” [Link] [126] “CVE-2008-3210,” [Link]
[Link]?name=CVE-2007-3437, 2007. [Link]?name=CVE-2008-3210, 2008.
[90] “CVE-2007-3369,” [Link] [127] “CVE-2008-3778,” [Link]
[Link]?name=CVE-2007-3369, 2007. [Link]?name=CVE-2008-3778, 2008.
[91] “CVE-2007-3368,” [Link] [128] “CVE-2008-4444,” [Link]
[Link]?name=CVE-2007-3368, 2007. [Link]?name=CVE-2008-4444, 2008.
[92] “CVE-2007-3363,” [Link] [129] “CVE-2008-5180,” [Link]
[Link]?name=CVE-2007-3363, 2007. [Link]?name=CVE-2008-5180, 2008.
[130] “CVE-2008-6140,” [Link] [167] “CVE-2007-3177,” [Link]
[Link]?name=CVE-2008-6140, 2008. [Link]?name=CVE-2007-3177, 2007.
[131] “CVE-2008-6574,” [Link] [168] “CVE-2007-0334,” [Link]
[Link]?name=CVE-2008-6574, 2008. [Link]?name=CVE-2007-0334, 2007.
[132] “CVE-2008-6575,” [Link] [169] “CVE-2005-4050,” [Link]
[Link]?name=CVE-2008-6575, 2008. [Link]?name=CVE-2005-4050, 2005.
[133] “CVE-2009-0871,” [Link] [170] “CVE-2007-4294,” [Link]
[Link]?name=CVE-2009-0871, 2009. [Link]?name=CVE-2007-4294, 2007.
[134] “CVE-2009-0636,” [Link] [171] “CVE-2007-4295,” [Link]
[Link]?name=CVE-2009-0636, 2009. [Link]?name=CVE-2007-4295, 2007.
[135] “CVE-2009-0630,” [Link] [172] “CVE-2004-0056,” [Link]
[Link]?name=CVE-2009-0630, 2009. [Link]?name=CVE-2004-0056, 2004.
[136] “CVE-2009-0631,” [Link] [173] “CVE-2004-0117,” [Link]
[Link]?name=CVE-2009-0631, 2009. [Link]?name=CVE-2004-0117, 2004.
[137] “CVE-2007-5591,” [Link] [174] “CVE-2005-3265,” [Link]
[Link]?name=CVE-2007-5591, 2007. [Link]?name=CVE-2005-3265, 2005.
[138] “CVE-2007-5556,” [Link] [175] “CVE-2004-1114,” [Link]
[Link]?name=CVE-2007-5556, 2007. [Link]?name=CVE-2004-1114, 2004.
[139] “CVE-2007-5369,” [Link] [176] “CVE-2003-0761,” [Link]
[Link]?name=CVE-2007-5369, 2007. [Link]?name=CVE-2003-0761, 2003.
[140] “CVE-2007-2886,” [Link] [177] “CVE-2006-4029,” [Link]
[Link]?name=CVE-2007-2886, 2007. [Link]?name=CVE-2006-4029, 2006.
[141] “CVE-2006-7121,” [Link] [178] “CVE-2006-3594,” [Link]
[Link]?name=CVE-2006-7121, 2006. [Link]?name=CVE-2006-3594, 2006.
[142] “CVE-2006-6411,” [Link] [179] “CVE-2006-3524,” [Link]
[Link]?name=CVE-2006-6411, 2006. [Link]?name=CVE-2006-3524, 2006.
[143] “CVE-2006-5233,” [Link] [180] “CVE-2006-0359,” [Link]
[Link]?name=CVE-2006-5233, 2006. [Link]?name=CVE-2006-0359, 2006.
[144] “CVE-2006-5231,” [Link] [181] “CVE-2006-0189,” [Link]
[Link]?name=CVE-2006-5231, 2006. [Link]?name=CVE-2006-0189, 2006.
[145] “CVE-2005-3989,” [Link] [182] “CVE-2007-5788,” [Link]
[Link]?name=CVE-2005-3989, 2005. [Link]?name=CVE-2007-5788, 2007.
[146] “CVE-2004-1977,” [Link] [183] “CVE-2007-3438,” [Link]
[Link]?name=CVE-2004-1977, 2004. [Link]?name=CVE-2007-3438, 2007.
[147] “CVE-2002-0882,” [Link] [184] “CVE-2007-2293,” [Link]
[Link]?name=CVE-2002-0882, 2002. [Link]?name=CVE-2007-2293, 2007.
[148] “CVE-2002-0880,” [Link] [185] “CVE-2007-0746,” [Link]
[Link]?name=CVE-2002-0880, 2002. [Link]?name=CVE-2007-0746, 2007.
[149] “CVE-2002-0835,” [Link] [186] “CVE-2008-0528,” [Link]
[Link]?name=CVE-2002-0835, 2002. [Link]?name=CVE-2008-0528, 2008.
[150] “CVE-2007-3436,” [Link] [187] “CVE-2008-0530,” [Link]
[Link]?name=CVE-2007-3436, 2007. [Link]?name=CVE-2008-0530, 2008.
[151] “CVE-2005-4464,” [Link] [188] “CVE-2008-0531,” [Link]
[Link]?name=CVE-2005-4464, 2005. [Link]?name=CVE-2008-0531, 2008.
[152] “CVE-2007-5488,” [Link] [189] “CVE-2008-2085,” [Link]
[Link]?name=CVE-2007-5488, 2007. [Link]?name=CVE-2008-2085, 2008.
[153] “CVE-2007-5411,” [Link] [190] “CVE-2007-4489,” [Link]
[Link]?name=CVE-2007-5411, 2007. [Link]?name=CVE-2007-4489, 2007.
[154] “CVE-2008-0582,” [Link] [191] “CVE-2005-2081,” [Link]
[Link]?name=CVE-2008-0582, 2008. [Link]?name=CVE-2005-2081, 2005.
[155] “CVE-2008-0583,” [Link] [192] “CVE-2003-0819,” [Link]
[Link]?name=CVE-2008-0583, 2008. [Link]?name=CVE-2003-0819, 2003.
[156] “CVE-2008-0454,” [Link] [193] “CVE-2005-1461,” [Link]
[Link]?name=CVE-2008-0454, 2008. [Link]?name=CVE-2005-1461, 2005.
[157] “CVE-2006-2925,” [Link] [194] “CVE-2008-2545,” [Link]
[Link]?name=CVE-2006-2925, 2006. [Link]?name=CVE-2008-2545, 2008.
[158] “CVE-2007-2191,” [Link] [195] “CVE-2008-1805,” [Link]
[Link]?name=CVE-2007-2191, 2007. [Link]?name=CVE-2008-1805, 2008.
[159] “CVE-2008-1251,” [Link] [196] “CVE-2007-5989,” [Link]
[Link]?name=CVE-2008-1251, 2008. [Link]?name=CVE-2007-5989, 2007.
[160] “CVE-2008-6509,” [Link] [197] “CVE-2007-3896,” [Link]
[Link]?name=CVE-2008-6509, 2008. [Link]?name=CVE-2007-3896, 2007.
[161] “CVE-2008-6573,” [Link] [198] “CVE-2008-6709,” [Link]
[Link]?name=CVE-2008-6573, 2008. [Link]?name=CVE-2008-6709, 2008.
[162] “CVE-1999-0938,” [Link] [199] “CVE-2008-1334,” [Link]
[Link]?name=CVE-1999-0938, 1999. [Link]?name=CVE-2008-1334, 2008.
[163] “CVE-2008-1250,” [Link] [200] “CVE-2006-2312,” [Link]
[Link]?name=CVE-2008-1250, 2008. [Link]?name=CVE-2006-2312, 2006.
[164] “CVE-2008-6708,” [Link] [201] “CVE-2005-2181,” [Link]
[Link]?name=CVE-2008-6708, 2008. [Link]?name=CVE-2005-2181, 2005.
[165] “CVE-2007-4498,” [Link] [202] “CVE-2005-2182,” [Link]
[Link]?name=CVE-2007-4498, 2007. [Link]?name=CVE-2005-2182, 2005.
[166] “CVE-2007-3319,” [Link] [203] “CVE-2007-5791,” [Link]
[Link]?name=CVE-2007-3319, 2007. [Link]?name=CVE-2007-5791, 2007.
[204] “CVE-2007-3347,” [Link] [241] “CVE-2006-4032,” [Link]
[Link]?name=CVE-2007-3347, 2007. [Link]?name=CVE-2006-4032, 2006.
[205] “CVE-2007-3320,” [Link] [242] “CVE-2008-3903,” [Link]
[Link]?name=CVE-2007-3320, 2007. [Link]?name=CVE-2008-3903, 2008.
[206] “CVE-2006-0305,” [Link] [243] “CVE-2007-5469,” [Link]
[Link]?name=CVE-2006-0305, 2006. [Link]?name=CVE-2007-5469, 2007.
[207] “CVE-2006-0302,” [Link] [244] “CVE-2007-5468,” [Link]
[Link]?name=CVE-2006-0302, 2006. [Link]?name=CVE-2007-5468, 2007.
[208] “CVE-2005-3804,” [Link] [245] R. State, O. Festor, H. Abdelanur, V. Pascual, J. Kuthan, R. Coeffic,
[Link]?name=CVE-2005-3804, 2005. J. Janak, and J. Floroiu, “SIP digest authentication relay attack,” draft-
[209] “CVE-2005-3724,” [Link] state-sip-relay-attack-00, Mar. 2009.
[Link]?name=CVE-2005-3724, 2005. [246] M. Nassar, R. State, and O. Festor, “VoIP Honeypot Architecture,”
[210] “CVE-2005-3715,” [Link] in Proceedings of the 10th IFIP/IEEE International Symposium on
[Link]?name=CVE-2005-3715, 2005. Integrated Network Management, May 2007, pp. 109–118.
[211] “CVE-2006-0360,” [Link]
[Link]?name=CVE-2006-0360, 2006.
[212] “CVE-2007-3439,” [Link]
[Link]?name=CVE-2007-3439, 2007.
[213] “CVE-2006-0374,” [Link]
[Link]?name=CVE-2006-0374, 2006.
[214] “CVE-2005-3723,” [Link]
[Link]?name=CVE-2005-3723, 2005.
[215] “CVE-2005-3721,” [Link]
[Link]?name=CVE-2005-3721, 2005.
[216] “CVE-2005-3718,” [Link]
[Link]?name=CVE-2005-3718, 2005.
[217] “CVE-2007-3440,” [Link]
[Link]?name=CVE-2007-3440, 2007.
[218] “CVE-2008-1248,” [Link]
[Link]?name=CVE-2008-1248, 2008.
[219] “CVE-2006-5038,” [Link]
[Link]?name=CVE-2006-5038, 2006.
[220] “CVE-2008-4874,” [Link]
[Link]?name=CVE-2008-4874, 2008.
[221] “CVE-2007-3047,” [Link]
[Link]?name=CVE-2007-3047, 2007.
[222] “CVE-2006-0834,” [Link]
[Link]?name=CVE-2006-0834, 2006.
[223] “CVE-2005-3803,” [Link]
[Link]?name=CVE-2005-3803, 2005.
[224] “CVE-2005-3719,” [Link]
[Link]?name=CVE-2005-3719, 2005.
[225] “CVE-2005-3717,” [Link]
[Link]?name=CVE-2005-3717, 2005.
[226] “CVE-2005-3716,” [Link]
[Link]?name=CVE-2005-3716, 2005.
[227] “CVE-2005-0745,” [Link]
[Link]?name=CVE-2005-0745, 2005.
[228] “CVE-2002-0881,” [Link]
[Link]?name=CVE-2002-0881, 2002.
[229] “CVE-2006-0375,” [Link]
[Link]?name=CVE-2006-0375, 2006.
[230] “CVE-2005-3725,” [Link]
[Link]?name=CVE-2005-3725, 2005.
[231] “CVE-2007-5361,” [Link]
[Link]?name=CVE-2007-5361, 2007.
[232] “CVE-2008-5871,” [Link]
[Link]?name=CVE-2008-5871, 2008.
[233] “CVE-2005-3722,” [Link]
[Link]?name=CVE-2005-3722, 2005.
[234] “CVE-2008-4875,” [Link]
[Link]?name=CVE-2008-4875, 2008.
[235] “CVE-2008-6706,” [Link]
[Link]?name=CVE-2008-6706, 2008.
[236] “CVE-2008-6707,” [Link]
[Link]?name=CVE-2008-6707, 2008.
[237] “CVE-2007-6095,” [Link]
[Link]?name=CVE-2007-6095, 2007.
[238] “CVE-2008-1114,” [Link]
[Link]?name=CVE-2008-1114, 2008.
[239] “CVE-2008-1113,” [Link]
[Link]?name=CVE-2008-1113, 2008.
[240] “CVE-2002-1935,” [Link]
[Link]?name=CVE-2002-1935, 2002.