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
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.

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

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

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.

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 PCSCF 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 P-SCSCF I-CSCF S-CSCF Attackable from External networks Control Layer/Core Control and Application Layers Protocol SIP/UDP SIP/UDP SIP/UDP Port 4060 5060 6060

Fig. 2. IMS security architecture showing the relationship between internal and external components, including their grouping.

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

The above applies to the Open Source IMS Core with a default configuration.

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 wouldnt 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 targets 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 SCSCF 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 digestusername 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.

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 doesnt 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 No. of Test Crashes SIP REGISTER 46 SIP INVITE Request 11 Line SIP INVITE 5 Common Options SIP INVITE 7 Common options SIP INVITE 3 Structure SIP REGISTER 13 SIP REGISTER 98

Testing Partition

Open IMS Core Deployment

Process Monitor and Fuzzing Software

HSS

P-CSCF (Under Test)

I-CSCF

S-SCSCF

Fig. 3. Layout of the attack framework, showing the separation between components under test and the supporting IMS Core.
Component

Crash Type Seg Fault Exit with code 0 Seg Fault Buffer Overflow Buffer Overflow Exit with code 0 Seg Fault

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.

S-CSCF S-CSCF S-CSCF S-CSCF S-CSCF P-CSCF I-CSCF

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

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 carriers 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] [2] [3] G. Bertrand, The IP Multimedia Subsystem in Next Generation Networks, Whitepaper, 2007 Ericsson, IMS IP Multimedia Subsystem: The value of using the IMS architecture, Whitepaper, October 2004 3GPP, GSM, and ETSI, TS 23.002 Technical Specification Group Services and System Aspects; Network architecture (Version 10.2.0, Release 10) 3GPP, GSM, and ETSI, TS 23.228 IP Multimedia Subsystem (IMS); Stage 2 (Version 11.0.0, Release 11) I. Tirado, IP Multimedia Subsystem (IMS) Signaling Core Security, Proceedings of the 5th annual conference on Information security curriculum development, September 2008 M. Hunter, R. Clark, F. Park, Security Issues with the IP Multimedia Subsystem (IMS): A White Paper, Whitepaper, September 2007 I. van Sprundel, Fuzzing: Breaking software in an automated fashion, 22nd Chaos Communication Congress, December 2005 M. Eddington, Demystifying Fuzzers, Black Hat Europe, April 2009 VoIPER, VoIP Exploit Research toolkit [Online]. Available: http://sourceforge.net/projects/voiper/ Sulley, A Pure Python fully automated and unattended fuzzing framework [Online]. Available: http://code.google.com/p/sulley/ P. Van der Linden, Expert C programming: deep C secrets, Prentice Hall, June 1994 M. Ogorkiewicz, P. Frej, Analysis of Buffer Overflow Attacks [Online]. Available: http://www.WindowSecurity.com, November 2002 GDB, The GNU Project Debugger [Online]. Available: http://www.gnu.org/software/gdb/

[4] [5]

[6]

[7] [8] [9] [10] [11] [12]

[13]

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.