Abstract-VoIP has increasingly been adopted as a

preferred method of communication and continues to

gain popularity. With operators looking to move to a

converged service delivery platform, many are turning to

IMS deployments to provide such services. Security is an

essential part of any deployment, and it is beneficial to

be aware of possible vulnerabilities, so they may be dealt

with accordingly. This paper describes a method of

locating vulnerabilities within an IMS deployment. It

focuses on the Open Source IMS Core, and describes the

discovery, analysis, and impact of vulnerabilities within.

A technique called ‘fuzzing’ is used throughout for the

discovery of vulnerabilities.

Index Terms— ims, ims security, open source ims

core, sip, sip security

I. INTRODUCTION

Internet Multimedia Subsystem or IMS implementations

provide a unified service delivery platform for various Voice

and Media related services. Voice over Internet Protocol P

(VoIP) being one of the most prominent services. This

would usually be complemented by a number of value-added

services such as Video on Demand or streaming Internet

Protocol TV (IPTV) media delivery features. As these are

likely paid services, a network operator cannot afford to

overlook the aspect of security within their own deployment.

Security encompasses a vast number of different areas,

including authorisation, authentication, integrity protection

and privacy. Intrusion and attack detection and prevention

systems are often also employed. These protection

mechanisms operate at various layers within a given

architecture. While the 3rd

Generation Partnership Project

(3GPP) has taken care to clearly define the requirements for

security on various layers, protocol implementation is left to

the developers of a particular IMS implementation. With

careful programming and code auditing practices, security

risks can be minimised.

It is however extremely difficult to account for absolutely

all possible conditions, and as such fuzzing provides a useful

tool to discover remaining problems. Fuzzing involves the

automated generation of random, unexpected or out of

bounds data. [7]

This paper begins by providing an overview of IMS

security features and related protocols in sections I through

V. Methods of attack and a means for discovering

vulnerabilities are then discussed in sections VI and VII.

Results are then presented after applying this technique to

the Open Source IMS Core in section VIII and IX.

II. IMS ARCHITECTURE

The IMS architecture can be divided into 3 distinct layers

[1]:

1. The Application or Service Layer which contains

Application Servers (AS) that provide services

over the IMS, and the Home Subscriber Server

(HSS)

2. The Control Layer which contains a number of

service subsystems, including the IMS core

3. The Transport or Connectivity Layer, which refers

to the underlying mechanism via which the user

equipment connects to the IMS network.

Examples include IP, Multiprotocol Label

Switching (MPLS), or even the Public Switched

Telephone Network (PSTN) when making use of

legacy devices and interworking functions.

A. IMS Signalling Core

The IMS Signalling Core falls within the Control Layer,

and is depicted by the Call/Session Control Functions

(CSCFs) block in the diagram above. The signalling core

consists of the three entities described below.

Proxy-CSCF: The P-CSCF is the first point of contact for

the User Equipment (UE) within the IMS. Its responsibilities

include authenticating user agents (UAs), and servicing

requests by from UAs for access to services. [3] It acts as a

Vulnerability Discovery and Analysis within the Open

Source IMS Core Denver D. Abrey and Neco Ventura

Department of Electrical Engineering

University of Cape Town, Private Bag X3, Rondebosch 7700, South Africa

Tel: +27 21 6502699, Fax: +27 21 6503782

email: {neco, dabrey}@crg.ee.uct.ac.za

Fig. 1. Simplified view of IMS Layered Architecture [2].

proxy, in that it may forward requests or service them

internally. [4]

Serving-CSCF: The S-CSCF performs session control

services for the UE, and maintains session states as needed

to support services for the network. [6] It also maintains

direct interfaces to Home Subscriber Server (HSS) and other

core elements such as charging or billing application servers.

[5]

Interrogating-CSCF: The I-CSCF facilitates peering

between different carriers’ networks. Its functions include

allocating an S-CSCF to a user performing a registration

using the Session Initiation Protocol (SIP), and generating

call records. [4] [5]

B. IMS Security Architecture

The IMS Security architecture is presented to provide

insight into the interactions between the CSCFs and both

internal and external components of the IMS.

The diagram above shows the 5 different security

associations present in a simple IMS deployment. These are

described below.

1. Provides mutual authentication between UE and

IMS. The process is delegated to the S-CSCF, but

the HSS generates the keys and challenges. [5]

2. Secure link and security association between UE

and P-CSCF facilitating authentication of data

origin.

3. Provides security within the core network for the

interface between HSS and S-CSCF.

4. Provides security between P-CSCF and SIP

capable nodes in other networks when UE is

roaming.

5. Provides security between P-CSCF and other SIP

nodes when UE is not roaming.

Security associations 2-5 are of interest as they correspond

well to the network interfaces between the HSS and CSCF

components, and are thus useful attack vectors.

III. ATTACK VECTORS

By analysing the IMS Core and Security Architecture

described in section II, a number of attack vectors have been

identified.

This paper focuses only on the CSCF components within

the signalling core. While Diameter interfaces are also

present within the signalling core, only SIP interfaces are

examined in this paper.

A. External Attack Vectors

As shown in Figure 2, Security Association 2 is present

between the UA and P-CSCF. This corresponds directly to

the SIP dialogue established between the UA and P-CSCF.

Within the Open Source IMS Core, this dialogue makes use

of the user datagram protocol (UDP), and the P-CSCF

communicates using port 4060 to the UA when using the

default configuration. Port 4060 of the P-CSCF IP address

therefore presents an external attack vector.

B. Internal Attack Vectors within Control Layer

While the IMS Core will generally be secured from

external networks, internal attack vectors still need to be

considered, as malicious data may originate internally too,

for example from mischievous employees of a carrier.

Internal interfaces may also be available to other carriers for

roaming purposes, meaning that access to these interfaces is

granted to peering networks.

As shown in Figure 2, interfaces between I-, S-, and P-

CSCF exist. These again correspond to SIP dialogs,

established over UDP. All interfaces on CSCFs listen are

available as attack vectors within the Control Layer.

C. Application/Service Layer Attack Vectors

As Application Servers (AS) require an interface to the

IMS infrastructure, they will generally have to speak to the

CSCF within the control layer. This usually happens as

requests are routed to their appropriate AS via the S-CSCF.

[4] This presents the S-CSCF interface to the Application

layer as an attack vector. These attack vectors are listed in

the table below, including port numbers.

TABLE I

ATTACK VECTOR SUMMARY

Component Attackable from Protocol Port

P-SCSCF External networks SIP/UDP 4060

I-CSCF Control Layer/Core SIP/UDP 5060

S-CSCF Control and Application

Layers

SIP/UDP 6060

The above applies to the Open Source IMS Core with a

default configuration.

Fig. 2. IMS security architecture showing the relationship between

internal and external components, including their grouping.

IV. FUZZING

Fuzzing was chosen as the technique to be used for

vulnerability detection. Fuzzing is an important part of

secure development lifecycle, and also a popular method of

testing used by security researches and software developers.

[8]

This technique works by automating the generation of

random or unexpected data. For this to be successful

however, it should be at least partly compliant with the

protocol under investigation. The reason for this is that we

want the application (or server) under test to assume that the

data is valid and treat it as such. [7] For example, sending

random characters and integers, or even binary to a SIP

server will (or should) result in the traffic merely being

discarded as it is not intelligible. While this may yield some

results from a poor implementation, it is unlikely that this

traffic would make it past rudimentary validity checks.

A. Types of Fuzzers

Fuzzers are applicable in a number of different situations.

These include file, network, general and custom fuzzers.

These can be further divided into stateful and stateless

fuzzers. [8]

Stateful fuzzers attempt to intelligently traverse execution

paths by exploring the state-space of a given test-scenario. In

network fuzzers, this means exploring the state-tree of a

given protocol. This allows the fuzzer to locate bugs that

wouldn’t usually be triggered by invalid data alone, but

require previous steps to put the application under test into

the correct state to trigger the bug.

Further features such as process monitoring may also be

present. This means that the fuzzer is able to detect whether

the process under test has crashed or stopped responding,

and restart it as necessary. These occurrences are logged

(and possibly even a core dump is retained), and the process

continues without user interaction. [8]

B. Open Source Fuzzing Tools

There are many fuzzing utilities available, and a large

number are open source. For the experiments described in

this paper the VoIPER VoIP security testing toolkit [9] was

used. This consists of a number of SIP-specific fuzzing

utilities and auxiliary tools designed to test SIP

implementations. It makes heavy use of the Sulley fuzzer

development and testing framework. [10] Both are written in

python and designed to be extensible making them ideal for

IMS targeted testing.

Sulley features include state tracking, automated-data

generation features and built-in support for network fuzzing.

It also includes utilities to do process monitoring, which the

VoIPER tool has built on.

V. SIP FUZZING

The VoIPER suite includes a number of fuzzing utilities

designed to test different parts of the SIP protocol. These are

listed and detailed below.

A. SDP Fuzzer

This attempts to locate bugs related to SDP processing

within the SIP server by fuzzing various SDP parameters

within SIP requests.

B. SIP ACK Fuzzers

There are two fuzzers included which attempt to locate

bugs related to the way an implementation acknowledges

SIP requests and responses. One semi-stateful which

attempts to set up the session to the target in such a way that

it would expect an ACK. The second simply sends ACKs

without any regard for the target’s state. ACKs are sent

whether they are expected by the application or server under

test or not.

C. SIP CANCEL, REGISTER, NOTIFY and SUBSCRIBE

Fuzzers

These attempt to find bugs by sending each of the above

SIP requests with each field set to various oversized and

invalid values. The random data generation is performed by

the Sulley framework.

D. SIP INVITE Fuzzer

As SIP INVITE requests contain a large number of

attributes and may be processed in a number of ways, four

INVITE-specific fuzzers are included. The first two

manipulate various attributes, setting them to oversized and

invalid values. The third iterates through all possible

extended attributes applicable to the INVITE request. This is

referred to as the “Common Options” variant of the SIP

INVITE test in section VII. These appear on the first line of

any INVITE request. The last manipulates the structure of

the INVITE request by trying various non-standard and

invalid delimiters, and repeating blocks of the request.

VI. ATTACK METHODOLOGY

To perform the actual attacks, VoIPER was used to run

each of the above described attacks against the P-, I- and S-

CSCF components of the Open Source IMS. While the IMS

makes use of SIP on the interfaces described above, some

tools required modification to allow them to work

successfully with the OpenIMS components.

Most notably, the OpenIMS expects that the “digest-

username” attribute of the REGISTER request (when an UA

is authenticating itself) includes the domain of the user

identity used. The VoIPER source code was modified to

include this when registering. A small change to allow for

proper processing of ‘401 Unauthorised’ responses was also

made.

It is expected that a number of requests or SIP payloads

will cause a given component to fail in various ways. The

mode of failure will depict the consequence of the

vulnerability. For example, any crash automatically leads to

a Denial of Service (DoS) attack, as the component can no

longer service requests. The way in which the program

crashes could also lead to possible remote code execution.

The component may also not crash at all, but merely take an

extraneous amount of time to service a request. Again, this

could lead to a Denial of Service attack, but only while such

requests are being sent. ie: An “active” DoS.

VII. ATTACK FRAMEWORK

To perform the fuzzing attacks against the CSCF

components, an Open Source IMS Core deployment was

configured on a common Linux distribution.

Default configurations were used, but later it was found

that the debugging output was slowing down testing. The

configurations of the CSCF components were therefore

modified to disable debugging modes. This increased the

speed of request processing, and also more closely

resembles a production deployment.

All components except for the one under test were run with

the modified configurations. This included the HSS to allow

for authentication where testing required it. The process

monitoring utility was used to run the component under test,

which allowed for crash detection and restarting where

necessary.

For example, when testing the P-CSCF, the S- and I-CSCF

components were run without debugging enabled as

standalone servers, as well as the HSS. The P-CSCF was

then run under the process monitor, with the fuzzer

communicating with the process monitor and P-CSCF.

VIII. RESULTS

Under testing, numerous crashes were recorded as a result

of invalid data. While the number of crashes and exact data

that caused each crash was recorded, the way in which the

software under test failed was investigated in depth. Insight

into the mode of failure for each test allows one to

understand why the failure occurred and the consequences

thereof. The different failure modes encountered are

described below.

A. Segmentation Faults (Seg Fault)

A segmentation fault (or seg fault) generally occurs as a

result of trying to access memory that the CPU cannot

physically address [11]. Once a seg fault occurs, the process

will usually perform a ‘core dump’, meaning that working

memory is written to disk for later analysis as to why the

crash or seg fault occurred.

B. Exit with code 0

When running on a UNIX like operating system, a process

will exit with code 0 to indicate that it has completed

execution successfully. This in itself doesn’t indicate an

error, but the software under test should not have exited at

all. It was found that in some cases fatal errors were handled

gracefully by the process to allow for debugging output

before exiting. With debugging disabled, the same behaviour

was exhibited, but without any additional output. The fact

that the process exited however still indicates a failure, as

external invalid data should not cause a server process to

terminate.

C. Buffer Overflow

Buffer overflows generally occur when a program writes

more information into a buffer than the space it has allocated

for the buffer in memory. [12] This ‘overflows’ the buffer,

and the data is written to adjacent memory. This could

possibly allow the overwriting of a functions return address.

If this is the case, special data may be used to exploit this

condition, allowing an attack to place the address of the user

supplied data in the memory where the return address of the

function is stored. This could point to the supplied user data,

effectively allowing execution of user supplied code.

D. Results Summary

The table below summarises the results of each test against

each of the CSCF components.

TABLE II

FUZZING TEST RESULTS

Component Test No. of

Crashes Crash Type

S-CSCF SIP REGISTER 46 Seg Fault

S-CSCF SIP INVITE – Request

Line

11 Exit with code 0

S-CSCF SIP INVITE –

Common Options

5 Seg Fault

S-CSCF SIP INVITE –

Common options

7 Buffer Overflow

S-CSCF SIP INVITE -

Structure

3 Buffer Overflow

P-CSCF SIP REGISTER 13 Exit with code 0

I-CSCF SIP REGISTER 98 Seg Fault

IX. ANALYSIS OF RESULTS

Table II lists the ‘Crash Type’ for each of the tests and

components. This section will attempt to provide a further

analysis as to why each of the crashes occurred. Tests that

yielded no crashes were omitted.

To gain insight into the cause of each crash, the CSCF

I-CSCF S-SCSCFP-CSCF (Under Test)

Process Monitor and Fuzzing Software

HSS

Testing Partition Open IMS Core Deployment

Fig. 3. Layout of the attack framework, showing the separation

between components under test and the supporting IMS Core.

components were compiled with buffer checking turned off

and with debugging symbols enabled. This allowed gdb[13]

to be used to locate the exact cause of the crash.

A. Segmentation Fault Causes

When testing the S-CSCF, the process behaved in two

distinct ways when segmentation faults were observed. The

first merely resulted in the parent process crashing and all

children being terminated as a result. This was found to be

caused by an error in the ‘scscf.so’ module used by the SIP

Express Router process acting as the S-CSCF. These were a

result of attempting to reference a structure via a NULL

pointer within the ‘scscf.so’ module. Identical behaviour was

observed with the I-CSCF within the ‘icscf.so’ module.

The second type of behaviour observed was that all child

processes died as a result of the parent entering an infinite

loop and rising to 100% CPU usage. The parent process

itself then died too. This was specific to the S-CSCF. This

was discovered to be a result of the child threads dying, and

the parent attempting to yield control to the dead threads. A

timeout for the yield then expired, and the parent died

shortly after.

B. Buffer Overflow Causes

Errors were discovered in the ‘tm.so’ module, used by all

components. The source of the crash was discovered to be a

result of a buffer length variable being overwritten, and then

being read as a negative value. While labelled by the

operating systems built-in protection mechanism as a buffer

overflow, these were a result of invalid arguments being

passed to a function used to copy memory blocks from one

place to another.

C. Exit with Code 0 Causes

When the S-CSCF failed with this error, it was found to be

a result of the ‘scscf.so’ module attempting to free a block of

memory more than once. Identical behaviour was observed

when testing the P-SCSCF. This error was caught and

handled gracefully, allowing the process to exit and return a

0 status code.

X. CONCLUSION AND FUTURE WORK

The 3GPP has gone to great lengths to fully specify all

protocols used within the IMS, as well as implement

stringent security measures where necessary. These all work

towards a secure solution, but implementation is still left up

to the developers of a particular IMS distribution. While the

above has shown a number of vulnerabilities within the

Open Source IMS Core, the techniques outlined for the

discovery of such vulnerabilities is easily applicable to any

other implementation. The results presented make a strong

case for fuzzing as a part of any software testing process,

particularly in the case of production deployments where

significant amounts of profit are at stake.

The tools used to perform the testing required only minor

modifications to allow them to work with IMS SIP servers,

meaning that malicious users will not hesitate to perform

testing similar to the above with the intent of finding

exploitable vulnerabilities.

The results also suggest that internal components also pose

a security risk when not properly tested for errors. While this

is certainly less of a problem than with an external facing

interface, there are common conditions (as in the case of

roaming and 3rd

party services offered over a carrier’s

network) where these will be exposed to networks or

software not controlled by the core network operator.

Future work will further modify the existing fuzzing

software to allow for authentication and key agreement

(AKA) based authentication, and perform further state

tracking to allow greater code coverage when testing. In its

current form, only a few tests perform state tracking, and

only in a basic (one or two branches deep) form. Many tests

are also performed without first authenticating, meaning that

bugs may not be discovered due to requests being discarded

too early. A framework to perform testing for other

protocols would also be beneficial in locating bugs in other

components of a given deployment. In particular, RTP and

Diameter protocols should be considered.

XI. REFERENCES

[1] G. Bertrand, “The IP Multimedia Subsystem in Next Generation

Networks”, Whitepaper, 2007

[2] Ericsson, “IMS – IP Multimedia Subsystem: The value of using the

IMS architecture”, Whitepaper, October 2004

[3] 3GPP, GSM, and ETSI, “TS 23.002 Technical Specification Group

Services and System Aspects; Network architecture (Version 10.2.0,

Release 10)”

[4] 3GPP, GSM, and ETSI, “TS 23.228 IP Multimedia Subsystem

(IMS); Stage 2 (Version 11.0.0, Release 11)”

[5] I. Tirado, “IP Multimedia Subsystem (IMS) Signaling Core

Security”, Proceedings of the 5th annual conference on Information

security curriculum development, September 2008

[6] M. Hunter, R. Clark, F. Park, “Security Issues with the IP

Multimedia Subsystem (IMS): A White Paper”, Whitepaper,

September 2007

[7] I. van Sprundel, “Fuzzing: Breaking software in an automated

fashion”, 22nd Chaos Communication Congress, December 2005

[8] M. Eddington, “Demystifying Fuzzers”, Black Hat Europe, April

2009

[9] VoIPER, VoIP Exploit Research toolkit [Online]. Available:

http://sourceforge.net/projects/voiper/

[10] Sulley, “A Pure Python fully automated and unattended fuzzing

framework” [Online]. Available: http://code.google.com/p/sulley/

[11] P. Van der Linden, “Expert C programming: deep C secrets”,

Prentice Hall, June 1994

[12] M. Ogorkiewicz, P. Frej, “Analysis of Buffer Overflow Attacks”

[Online]. Available: http://www.WindowSecurity.com, November

2002

[13] GDB, “The GNU Project Debugger” [Online]. Available:

http://www.gnu.org/software/gdb/

Denver Abrey received his undergraduate B.Sc in Computer and

Electrical Engineering degree in 2009 from the University of Cape Town.

He is presently studying towards his Master of Science degree at the same

institution. His research interests include network security, VoIP and

Internet Multimedia Subsystems.