MonAM (28-29.09.2006) at TUebingen Germany Security Threats and Solutions for Application Server of IP Multimedia Subsystem (IMS-AS) Muhammad Sher Technical University Berlin, Germany & Fraunhofer Institute for Open Communication Systems FOKUS Email: sher@fokus.fraunhofer.de www.av.tu-berlin.de www.fokus.fraunhofer.de/ngni 1
Overview IP Multimedia Subsystem (IMS) IMS Application Server Architecture IMS Security Solutions and Standards IMS Domain Security Attacks IMS-AS Two Tiers Security Solution High Level Design and Architecture of IMS-AS IDS Attacks Detection Methodology IMS-AS IDS Performance Conclusion and Q&A 2
IP Multimedia Subsystem (IMS) IMS is standardized by the 3rd Generation Partnership Project (3GPP) Europe: www.3gpp.org & Asia/America: www.3gpp2.org The IMS represents an overlay network on top of GPRS & UMTS Networks IMS provides all IP Service Delivery Environment for mobile multimedia service provisioning like VoIP, Video telephony, MM Conferencing, Mobile Content, etc. IMS is based on the IP world protocols: SIP (Session Initiation Protocol) for Session Control Diameter for AAA (Authentication, Authorization & Accounting) plus many others, i.e. SDP, RTP, RTCP, MGCP, etc. 3
Most Important IMS Components P-CSCF (Proxy Call State/ Session Control Function) Behaves like a proxy accepting requests and services I-CSCF (Interrogating Call State Control Function) Assigns S-CSCF to a user, performing SIP registration, charging and resource utilisation S-CSCF (Serving Call State Control Function) Performs the session control services for the endpoint MRF (Media Resource Function) Provides media stream processing like media mixing, media announcements, media analysis and media transcoding HSS (Home Subscription Function): Master database of IMS that stores IMS user profiles AS (Application Server): Provides service platform in IMS environment 4
IMS Application Server Architecture IMS Application Server provides value added services to IMS applications IMS Application Server based on SIP Servlet Container & HTTP Servlet Container SIP Servlet API developed to standardize the platform for development and deployment of SIP based services As the popularity of IMS increases, IMS AS facing different kinds of security threats and intrusions 1. AS suffering the HTTP-based threats as we know that it integrates the web application container 2. The text-based nature of SIP Messages faces attacks like spoofing, hijacking and message tampering because AS employ SIP for signalling 3. Denial of Service (DoS) attack can be launched against the AS 5
Research Areas in IMS/NGN FMC / NGN Applications Prototyping IMS Data Management HSS IMS Application Server & Client R&D Projects ComCase SIPComp Consulting for Operators & Vendors FMC / IMS Handover Open Source IMS Core IMS Benchmarking & Interoperability Tools Open IMS Playground IMS Security & Reliability IMS /DVB Integration Interoperablity Testing & Benchmarking 6
Overview of Secure IMS/NGN Architecture Applications Platform Security between IMS & App Platform Level 1: Standardized by 3GPP Level 2: Enhancement by IMS-AS IDS IMS Security between IMS & All IP Networks Level 1: Standardized by 3GPP Level 2: Enhancement by IMS-Core IDS All IP Networks 7
IMS Security Solutions & Standards (Level-1) 3GPP propose two Security Solutions for IMS Early IMS Security Solution Focus on Standardized in 3GPP Release 5 with limited security functionality Aiming to protect early IMS deployment and offer less security Provides authentication of subscribers for services access Provides identity confidentiality on the radio interface Provide radio interface encryption Complete IMS Security Solution Standardized in 3GPP Release 6 with full security functionality Build on the early security solutions and to improve it Offering new security features and will secure new services Aiming to protect network and terminals with data protection 8
IMS Security Architecture (Level-1) 1. Authentication & Key Agreement between IM subscriber and home network 2. Security Mechanism Agreement between IM client and visited network 3. Integrity Protection and Confidentiality 4. Network Domain Security between different Domains 5. Existing GPRS/UMTS Access Security 9
Limitations of Existing IMS Security Solution Existing Solutions are Inadequate to solve the security problems like Man-in the Middle, ISIM or USIM Cloning Attacks e.g. Identify theft, spoofing & session hijacking etc are not controlled by Firewalls, Antivirus and offline IDS Man-in-Middle and Call Theft are not coped with Authentication Process Authentication Process fail to cope with Active Attack in Corrupted Network No Intrusion Detection System yet developed for IP Multimedia System 10
Attacks are classified as: Security Threats & Attacks on IMS Time-Dependent Attacks (TDAs) & Time-Independent Attacks (TIDs) Internet Fraud Multi-billion Dollar Illegal Business Hackers uses Intelligent Techniques to obtain Personal and Confidential Data Fraud / Impersonation Attacks Man-in-the-Middle Call Theft ISIM Cloning Identity Theft Spoofing Phishing Denial of Service Prevention Overloading Servers with high traffic load Time-dependent attacks: Require time interval to effect or damage the victim e.g. flooding attacks. Time-independent attack: It effects instantly at the target e.g. QSL-Injection attack. 11
Time Dependent Attacks These attacks compose of large amount of data packets like flooding Most serious threat to IMS Application Server In case of IMS-AS, Flooding overwhelm the SIP Servlet Server No resources available to handle the legitimate SIP and HTTP messages We consider two type of Time Dependent Attacks 1. TCP SYN Flooding Attack/ IP Spoofing Attack Creating a half-open connection - Attacker sends a SYN-ACK message without own IP Address - Victim never receives an ACK message from the attacker - Attacker creates increasing number of pending connections - As a result it causes buffer to overflow 12
Time Dependent Attacks 2. SIP Message Flooding Attacks (four sub-types) Invite Flooding & Register Flooding Attacker sends a large amount of SIP Invite Messages (source IP address can be spoofed) to the Victim In Register Flooding, Register Method is utilized instead of Invite Method Invite Response Flooding & Register Response Flooding The objective of the Invite Response Flooding is to get the Authentication Data by using exhausted search A lot of Invite Messages are sent in order to crack the Password for the authentication. In case of Register Response Flooding the attacker sends REGISTER Messages with Wrong Credentials to SIP proxy 13
Time Independent Attacks We focus only two TIAs i.e. SQL Injection & Message Flow Allatcks 1. SQL Injection Attack It causes data modification, deletion & even downfall of database services SQL Injection is kind of Message Tampering Attack Text-based nature of SIP messages provides opportunity for message tampering attacks in SIP applications The utilization of Web Interfaces for the provision of value-added services in IMS-AS makes this attack more attractive to the attackers Attacker spoofs the SIP message and inserts the malicious SQL code in its Authorization header to launch the SQL Injection Attack As proxy receives a SIP message with an 'infected' Authorization header, it generates 'dangerous' SQL statement which may delete or modify data in the database. The attacker can also utilize the HTTP message to launch the SQL injection attacks, because the SIPSEE is integrated with a HTTP Servlet container 14
Time Independent Attacks 2. Message Flows Attacks (we consider two sub-types) a. The BYE Attack Attacker can use BYE Message to tear down established session immediately To launch the attack, attacker sends a faked BYE message to UA1 via SIP proxy UA1 assumes that it is from UA2 to tear down the connection UA1 stops the RTP flow immediately, while UA2 continues to send RTP packets To launch this kind of attack, the attacker needs to learn all necessary session parameters This can be accomplished either by Sniffing the network or Performing a man-in-the-middle attack to insert a BYE request into the session. 15
Time Independent Attacks b. The Re-INVITE Attack The INVITE request established both a dialog and a session The objective of the RE-INVITE method is to modify the actual session This modification can involve - changing of addresses or ports, - adding a media stream, - deleting a media stream, and so on. The attacker can launch a DoS attack by sending a forged RE-INVITE message to enforce any unauthorized modification 16
Proposed IMS-AS Security Solution Focus on protecting the IMS-AS from attacks contained in SIP messages Intruder uses two approaches to launch attacks relying on SIP messages To intercept and fake the SIP messages exchanged between legitimate UAs and the AS To send malicious SIP messages directly to AS, contain SQL-Injection Two Tiers Security Solution for IMS Application Environment TLS for SIP Massages Integrity IDS for SIP Messages Protection Tier 1: TLS tunnel assures the integrity of SIP messages TLS UA fa ke m e ssa g e ID S IM S -A S Intruder m alicious m essages Tier 2: IDS detects and prevents intrusion contained in SIP m essages 17
Proposed IMS-AS Security Solution First Tier utilizes TLS secure SIP signaling path in hopby-hop fashion between the UA and the AS The second tier is to deploy IDS for IMS AS to detect and prevent attacks which can not debarred by the first tier technique e.g. Bob is a legitimate as well as malicious user. As a malicious user, Bob intends to launch SQL-Injection attack to drop a table in the database of AS. SIP provides a challenge-based mechanism for authentication At the end of authentication, Bob can inject SQL statement into the Request with Credentials The authorization Header of the injected Request may look like: Authorization: Digest username="bob';drop table films;' ", realm="example.com", If AS has no IDS, the above Request drops table "films" in AS database 18
Existing IMS-AS Functional Architecture Existing IMS-AS Consists of a. SIPStack b. SIPServer SIPStack is the communication interface of IMS AS. It performs functionalities like: Provides Proprietary SIP Protocol Stack Provides Encryption & Decryption, if Secure Communication Channels are used (Optional) Logically, SIPServer is the Brain of IMS AS Process SIP Message on Behalf of IMS AS 19
Proposed Secure IMS-AS Functional Architecture Secure IMS-AS contains extra Intrusion Detection System (IDS) Objective is to detect & prevent attacks before they cause any damage to IMS-AS Within IMS-AS, each outgoing or incoming message is passed through the IDS Message will be blocked, if applies the defined Attack Rule Only secure messages can be passed through the IDS 20
Requirement Analysis SIPServer and SIPStack are actors of the IDS They exchange SIP messages with the IDS The communication interfaces are required for exchanging From User Point of View, the IDS should be capable of detecting and preventing attacks based SIP. The functionality requires: Defining Attacks Types Monitoring both the SIP Messages and the Relationship between messages Performance Requirement: Default Round-trip Time (T1) should be 500ms as recommended in RFC326. The issue of efficiency should be taken into account. 21
Flow Control Design of IDS When SIP message received, the IDS: Update the state of corresponding Partner or Generate new Partner based on the message In order to detect TI Attacks, IDS compares the message with defined Attack Rules: if matched, IDS turns to the procedure Attack Detected, that will announce the detection and block the message, etc otherwise the message is regarded as secure and being forwarded to the SIPServer In order to detect TD Attacks, the Partner has a timer to perform periodic checking As the timer is triggered, a comparison start between current state of Partner & the defined Attack Rules: if matched, the procedure Attack detected takes over the control. The further messages to or from the UA will be blocked otherwise the Partner being regarded as legitimate 22
Design Architecture of IDS IDSCenter is the Communication Interface which receives SIP Message sent by SIPStack or SIPServer A Partner is an Interior Agent which represents a UA being communicating with IMS-AS RuleCollection loads the defined Attacks Descriptions at Runtime Both SIP messages and State of Partners are compared by the IDSFilter with Attacks Descriptions stored in the RuleCollection The SIP URI of a Partner will be inserted into the Blacklist, if the State of the Partner matches with an Attack Pattern If a SIP Message matches with an Attack Pattern, adding the URI of corresponding Partner into Blacklist Blacklist, which is maintained by the IDSCenter saves the SIP-URI of the Detected Malicious UA 23
Implementation Prototype Design & Implementation of IDS for IMS-AS Implementation of Attacks Rules using XML to describe Attacks: Time-dependent: SIP Message flooding, e.g. Invite Flooding Time-independent: SQL-Injection Integration of IDS with Fokus IMS-Application Server SIPSEE (SIP Servlet Execution Environment) Real World Testing of IDS in IMS Testbed at Fokus 24
Testing & Performance Used SFTF (SIP Forum Test Framework) to verify whether the IDS fulfills the functionality requirements Each attack defined by IDS should be simulated with a test case of SFTF Using SFTF to launch test cases Software Environment Python V2.4 runtime environment; SFTF V0.9.3 is on behalf of an intruder Java V1.5 runtime environment Eclipse 3.0 25
Testing & Performance Performance metric: delay (ms) introduced by the IDS. Delay = D1 + D2 D1: time for checking incoming request D2: time for checking outgoing message responding 26
Performance Test Results 27
Conclusion & Acknowledgement This work is developed within the context of Secure Service Provisioning (SSP) Framework for IMS at Fokus Fraunhofer 3Gb & IMS Testbed This research work is funded and supported by BMBF (German Federal Ministry of Education and Research) under MAMS (Multi- Access, Modular-Services Framework) Project in article AP560 Security in Network Abstraction and Open IMS Future work includes the study of more Time Dependent & Time Independent Attacks on IMS AS 28
QUESTIONS & ANSWERS Muhammad Sher TU Berlin / Fraunhofer FOKUS Berlin Germany Email: sher@fokus.fraunhofer.de www.fokus.fraunhofer.de/ngni www.av.tu-berlin.de 29