Contractual Date of Delivery to the CEC: Actual Date of Delivery to the CEC:

Transcription

1 Project no.: COOP Project full title: Low Cost Tools for Secure and Highly Available VoIP Communication Services Project Acronym: SNOCER Deliverable no.: D2.2 Title of the deliverable: General Reliability and Security Framework for VoIP Infrastructures Contractual Date of Delivery to the CEC: Actual Date of Delivery to the CEC: Author(s): Work package contributing to the deliverable: WP2 Dissemination level: CO Total number of pages: 74 Tasos Dagiuklas (University of Aegean) Dimitris Geneiatakis (University of Aegean) George Kambourakis (University of Aegean) Dorgham Sisalem (Fraunhofer Fokus) Sven Ehlert (Fraunhofer Fokus) Jens Fiedler (Fraunhofer Fokus) Jiří Markl (Nextsoft) Michal Rokos (Nextsoft) Olivier Botron (Telip) Jesus Rodriguez (VozTelecom) Juntong Liu (Embiron) Abstract: In this document we present a general secure and high available software architecture for VoIP infrastructures. Security is achieved through the utilization of Intrusion detection systems enhanced for VoIP traffic plus extended VoIP servers that perform advanced traffic monitoring. Additionally, we propose to increase server throughput through the use of an advanced DNS caching solution. Reliability is achieved trough redundant backup systems that take over operation in case of failure. We also introduce a security testing tool with an according configuration language based on XML

2 Table of Contents 1 INTRODUCTION ARCHITECTURE OVERVIEW SECURITY GOALS FLOODING ATTACKS MESSAGE FLOWS ATTACKS The BYE Attack The CANCEL Attack The REFER Attack The Re-INVITE Attack The UPDATE Attack The INFO Attack Classification of SIP Vulnerabilities PARSER ATTACKS The Complexity of SIP Message Parsing Malformed Messages in SIP Mounting the Attack Discover Target s SIP Capabilities Construction of a Malformed Message Restrictions, Limitation and Possibilities of the Attack Countermeasures Detection Signatures DNS BLOCKING ATTACKS Scope DNS Attack Simulation TOOLS UTILIZED NETFILTER / IPTABLES SER SNORT Snort Overview Snort Utilization in VoIP / SIP Environments SNORT Drawbacks PRELUDE IDS Prelude Overview Prelude IDS Architecture Modules Extensibility for VoIP Environments EXISTING ATTACK TOOLS VoIP Vulnerability Scanner (SiVuS) SIP Forum Test Framework (SFTF) PROTOS Suite SIP Swiss Army Knife (SIPSAK) Limitations SECURITY ARCHITECTURE DESCRIPTION ATTACK DESCRIPTION LANGUAGE A SIP Attack Description Model Generally Used XML Attributes XML Elements to Describe a Single SIP Message XML Elements to Describe SIP Message Flows Example of Flooding Attacks

3 4.1.6 Example of Parser Attacks Example of SIP Application Attacks DEFENCE ARCHITECTURE DESCRIPTION Snort Bastion Host Extended SIP Proxy ATTACK ARCHITECTURE DESCRIPTION Attack Tool - General Requirements Platform Design Implementation Issues Restrictions, Limitations and Assumptions HIGH AVAILABILITY DESCRIPTION Doubling the RTP Relay Doubling the PSTN Gateway Doubling the Database Doubling the SIP Server IP Takeover POSSIBLE EXTENSION: LOAD BALANCING TESTING AND QUALITY ASSURANCE SCOPE OF QUALITY ASSURANCE AND EVALUATION PLAN MANAGEMENT GOALS QUALITY ASSURANCE AND EVALUATION METHODOLOGY GUIDELINES QUALITY ASSURANCE ORGANISATION EVALUATION PROCESS MODEL SNOCER MODEL QUALITY REQUIREMENT DEFINITION Identification of context of use Analysis of the Tools Assignment and Ranking of Quality Characteristics to Snocer Services SNOCER SYSTEM EVALUATION METRICS Metrics Templates Metrics Definition Primitive Metrics Definition Assessment Methodology Privacy SNOCER VIRTUAL COLLABORATIVE TEST BEDS TRADE MARK OF THE SNOCER COLLABORATIVE MODEL TEST BED SCENARIO SUMMARY REFERENCES

4 1 Introduction In the context of the SNOCER project a set of tools and solutions will be implemented aiming to protect the infrastructures of VoIP providers against malicious use and denial of service attacks on the one hand. On the other hand, we will be further aiming to provide solutions for increasing the availability and reliability of the used VoIP components. In the first deliverable D2.1 [1] we have described possible security threats that a VoIP provider has to face, including threats concerning the SIP proxy, and supporting services including DNS/ENUM, STUN or RTP proxies. We have compared current solutions to handle non-voip centric solutions to deal with Denial-of-Service attacks. We have also investigated reasons for VoIP network failure and presented an overview of server backup strategies that can be applied for SIP proxies, including possibilities to transfer authentication information between redundant servers. In this document we will present an overview of a security VoIP infrastructure to address the discussed problem space. For this we give an outline architecture based on established opens-source tools, with the necessary enhancements, refinements or other modifications needed for our goal. In case we have judged available solutions unfitted for our topic, we propose completely new solutions developed from scratch for our particular problem space. This document is structured as follows. In Chapter 2 we will give an overview of attack possibilities on a SIP architecture. This overview consists of malicious message flows with corresponding detection signatures and outlines possibilities of attacks using the DNS system. This chapter extends our previous attack description as provided in D2.1. Chapter 3 presents an overview of current open source tools which we will utilize to build our defence architecture. This includes firewall, IDS, and SIP server solutions. Furthermore we present a list of current attack tools as a building block for an attack tool which will be developed to test the SNOCER architecture. We present a general overview of our Denial-of-Service Architecture in Chapter 4. This includes the specification of an attack description language, the actual two-level-defence architecture consisting of a general Bastion host and a secured SIP server, and finally an attack testing tool. In Chapter 5 we specify a highly available SIP network architecture based on fail-over replication. In the last Chapter we provide general quality assurance rules which will be applied for testing of the SNOCER tools

5 1.1 Architecture Overview To secure the VoIP Infrastructure to be resilient against unsolicited traffic and minimize service downtime we propose an architecture as described in Figure 1. The design is based on five key concepts: Bastion host: This host acts as a gatekeeper of the operator s internal VoIP network. Its primary task is to detect basic attacks targeted at the VoIP system and deny access for unsolicited traffic. Enhanced SIP proxy: We propose to enhance a SIP proxy in two ways. An integrated IDS system will be able to detect more sophisticated SIP proxy attacks, which the bastion host might have missed. Further, we optimize the proxy s performance through the addition of a specialized DNS module in order to enhance the throughput capabilities. High availability network: Key components of the VoIP network will be secured through an internal high availability network providing failover capabilities to these components. Operator console: The status of the enhanced VoIP infrastructure will be controlled in a centralized way. Attack tools: A set of specially designed attack tools will be utilized to test and improve the defence capabilities of the architecture. Figure 1: Architecture Overview - 5 -

6 2 Security Goals 2.1 Flooding Attacks Flooding attacks has been described in [1], thus in this section no additional information is provided for these kind of attacks. 2.2 Message Flows Attacks The SIP protocol specification [2] describes methods to end or terminate a session, cancel an invitation, redirect a call and update session parameters. More specifically for each of the previous procedures the following SIP methods are utilized: (a) BYE, (b) CANCEL, (c) REFER and (d) INVITE-UPDATE. It is very likely that the attacker will try to exploit any security vulnerability in the aforementioned methods and cause DoS to the provided service. The main reason that an attacker can launch attacks by employing these messages is the utilization of an improper authentication mechanism. At the perils, current SIP specifications do not mandate authentication for all of the aforementioned methods. Moreover, as Internet telephony is considered as a service or application the attacker will try to discover possible security flaws in the applications or take advantage of existing protocol misconfigurations similar to attacks launched against Internet applications and services exploiting vulnerabilities at the signalling application level The BYE Attack The BYE request is used to terminate an established session as shown in Figure 2. An attacker possibly can utilize the BYE request to tear down a session, as depicted in Figure 3. To launch this kind of attack, the attacker needs to learn all necessary session parameters (e.g. Session-ID, RTP Port etc). This can be accomplished either by sniffing the network or performing a man-in-the-middle attack (MITM) to insert a BYE request into the session. The BYE method, as mentioned above, is used to terminate an established media session. However, this attack can be launched successfully only in the case that no authentication mechanism is in place, considering as well the attacker s ability to discover the current session parameters. user 1 proxy user 2 invite invite trying ringing OK ACK BYE MEDIA arp request arp response ringing OK ACK BYE Figure 2. Normal session termination - 6 -

7 Thus, the protection of the session s critical parameters regarding confidentiality must be considered as mandatory. As discussed already in [1], either TLS or IPSec can be employed to provide such kind of security services. Moreover, the authenticity of a BYE message must be ensured by utilizing either HTTP Digest or TLS. user 1 proxy user 2 invite invite attacker trying ringing OK ACK arp request arp response ringing OK ACK MEDIA BYE Figure 3. BYE attack The CANCEL Attack The CANCEL request, as its name implies, is used to cancel a previous request sent by a client. More specifically, it asks the corresponding server to cease processing the request and generate an error response designating that request. This procedure is shown in Figure 4. The attacker may utilize the CANCEL method to cancel an INVITE request generated by a legitimate user as illustrated in Figure 5. A CANCEL request must only be sent to cancel an INVITE request [2]. Thus, when a SIP-proxy receives a CANCEL request for any other message type (than INVITE), it must not process this message, but rather produce an appropriate error response. Moreover, incoming CANCEL requests must not be processed if the original request has already generated a final response. This is because CANCEL has no effect on requests that have already generated a final response. user 1 invite trying proxy arp request arp response invite user 2 ringing ringing CANCEL 200 OK NO MORE PENDINGS Figure 4. CANCEL request CANCEL requests are generated in a hop-by-hop fashion and can not be resubmitted. As a result, they can not be challenged by the server in order to get proper credentials in an Au

8 thorization header field. Thus, the utilization of any applicable, underlying security mechanism, such as IPSec or TLS, is considered mandatory. However, the processing of an incoming CANCEL message from a different administrative SIP domain is still an open and unresolved issue. Additionally, the monitoring of INVITE messages that have not already generated a final response could possibly help to identify any illegitimate CANCEL requests. user 1 proxy user 2 attacker invite trying ringing invite arp request arp response ringing CANCEL 200 OK NO MORE PENDINGS Figure 5. CANCEL attack The REFER Attack The REFER extension [3] provides a mechanism where one party (the referrer) provides a second party (the referrer) with an arbitrary URI to reference. Assuming that this URI is a SIP URI, the referee will send a SIP request (usually a SIP INVITE), to that URI (the refer target). As a result, REFER can be used to enable many applications, including call transfer. RFC 3892 [4] extends this method by allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. The refer target can use this information to decide whether to accept the reverenced request from the referee or not. This scheme enables the referee to act as an eavesdropper, giving him the ability to launch man-in-the-middle attacks. For example, the referee can forge the Referred-By header or/and eavesdrop on the referred-by information. The referee may also copy all the related information into future unrelated requests. Although the specification uses an S/MIME based mechanism to enable the refer target to detect possible manipulation of the Referred-By header data, this protection is completely optional The Re-INVITE Attack Once a dialog-session has been established by initial messaging, subsequent requests can be sent that attempt to modify the parameters of the dialog-session (e.g. address or port modification). Thus, any unauthorized modification with a forged re-invite (see Figure 6) of a dialog-session by a potential attacker may cause a DoS

9 user 1 proxy user 2 attacker invite invite trying ringing OK ACK arp request arp response ringing OK ACK MEDIA "re-invite" (invite) user 1 Figure 6. "Re-INVITE" Attack The UPDATE Attack The SIP UPDATE method [5] provides the end users with various capabilities such as muting or placing on hold incoming calls, identification of QoS parameters and negotiation for other session attributes like re-invite. The only difference is that the re-invite can utilized only after a session has been established, while UPDATE is utilized to modify session parameters before the final response to the initial invitation. So similar to the reinvite attack, an attacker may send a forged UPDATE message, as depicted in Figure 7 to modify the initial session parameters to cause a DoS changing parameters like QoS or initial addresses and ports. user 1 proxy user 2 attacker invite invite arp request arp response trying ringing OK update ringing OK update Figure 7. UPDATE attack The INFO Attack In many cases, VoIP networks can be used as a mediator to interconnect PSTN carrier. Under this circumstance, SIP for telephones (SIP-T) [6] is used in order to convey PSTN signalling from one PSTN carrier to another and vice versa. Figure 8 depicts an architecture in which a SIP network is the bridge between two different PSTN networks

10 Q.931/ISUP SG SIP NETWORK SIP-T SG Q.931/ISUP PSTN Phone A Figure 8. PSTN and SIP Interconnection PSTN Phone B The INFO method is described as a general mechanism to carry application level information along the SIP signalling path, to allow tunnelling mechanisms [6]. It has been proposed, and in fact used, for a wide variety of functions, including: 1. Carrying mid-call PSTN signalling messages between PSTN gateways. 2. Carrying DTMF digits generated during a SIP session. 3. Carrying account balance information. The message body of INFO message can be encrypted for privacy reasons. However there is no suggestion for any security mechanism to provide integrity and authenticity of INFO method. Thus, it is possible the malicious modification of the INFO method that can cause serious problem to the communication parties like unauthorized access to a call, DoS for the initial invitation, billing errors etc Classification of SIP Vulnerabilities The potential threats and attacks that a SIP-based network is facing can be divided into various categories. We categorize the aforementioned SIP attacks, as illustrated in Table 1, in the general following security categories: 1. Passive versus Active Attacks: Passive attacks include the passive monitoring of packets exchanged among the SIP elements. On the other hand, in the active attacks the attacker may disrupt the normal operation of the network by altering, deleting or retransmitting packets. 2. Internal versus External Attacks: The external attacks regard attacks that stem from nodes, which do not belong to the SIP network. On the other hand, internal attacks regard malicious nodes belonging to the network as legitimate entities. 3. Single versus Multi Source(s): Single source attack involves one malicious host (the attacker). On the other hand multi sources involve numerous of usually innocent Internet hosts that has been exploited by the attacker. 4. Affected Security Issues: The affected security service whenever an attack is launched are the followings: (1) (C)onfidetiality, (2) (I)ntegrity (3) (Av)ailability, (4) (R)eliability and (5) Authentication. 5. Consequences: This category differentiates the attacks based on the intentions of the intruder: a. DoS attacks intend to make servers unavailable to accomplish their tasks

11 Threat/ Attack b. Unauthorized Access (UnA) as its name implies, intends to give access in the provided service to non-authorized users. Activity Location Source (A)ctive/ (P)assive (I)nternal/ (E)xternal (S)ingle/ (M)ulti (D)irect / (I)ndirect Vulnerability REGISTRAR FLOODING PROXY FLOODING END USER A I-E S-M D-I Lack of authentication FLOODING ROUTE A I M I Lack of /RECORD (1) authentication, ROUTE (2) integr. checking ATTACK SIP PARSER A I-E S D Implementation ATTACK errors BYE AT- A I-E S D Lack of authentication TACK CANCEL A I-E S D Lack of authentication ATTACK REFER A I-E S D Lack of authentication ATTACK RE-INVITE A I-E S D Lack of authentication ATTACK UPDATE A I-E S D Lack of authentication ATTACK INFO Attack A-P I-E S D Lack of (1) authentication, (2) integr. checking (3)Confidentiality SQL INJEC- TION AT- TACK Table 1 SIP Attacks Classification Affected Security Issue Possible Consequences A I-E S-M D-I Av-R DoS A I-E S-M D-I Av-R DoS A I-E S D Lack of integrity checking Av-R I-Av-R Av-R Av Av C-I-Av Av-C-R Av-R Av-R-C-I I-Au-Av DoS DoS DoS, UnA DoS DoS UnA UnA, DoS DoS In contrast to PSTN, an attacker may easily gain access to VoIP subsystems and alter/deteriorate their operation. Thus he/she can easily discover any appropriate parameters (if an underlying security mechanism is not utilized) needed to launch an active or passive attack. All the described attacks are active but the attacker in some of them, like CANCEL, BYE need to utilize the passive mode to learn the appropriate parameters to execute the attack. Moreover, most of the attacks described here can be executed not only from the internal SIP network but from an external SIP network as well. For instance, the attacker can exploit a trusted SIP proxy to amplify the attack s hazardous outcomes. As regarding the attack sources the application level attacks and SIP parsers attacks are launched from a single host. This is not the case for flooding attacks that can have a distributed form and can utilize innocent hosts to launch the attacks (Indirect attacks). As described [1] one of the main security vulnerabilities that attackers possibly will exploit is the lack of a complete authentication scheme, which can protect SIP infrastructure against unauthorized access. One applicable solution to this problem is Peterson s suggestion [8] for the utilization of cryptographic tokens. This solution can be applied also in hop-by-hop fashioned messages like CANCEL, which could not be challenged, and utilize HTTP Digest authentication. The second major problem is the lack of integrity mecha- DoS, UnA UnA, DoS

12 nisms. This problem can be fixed with the use of the appropriate integrity schemas like S/MIME, TLS, etc. 2.3 Parser Attacks The Complexity of SIP Message Parsing A SIP message can be either a request or an acknowledgment to a corresponding request, consisting of the header fields and the message body. The overall structure of a typical SIP message is depicted in Figure 9. SIP messages are text-based and are very similar to the HTTP format, with a highly degree of freedom, thus, an efficient parser is needed which only parses messages up to the point the information is required. However, even a perfectly valid SIP message can be constructed in a way to hamper proper parsing. Here we give a list of possible scenarios that complicate message parsing. An attacker can create extra-long messages, with multiple header (like informative header fields, e.g. Supported) fields and of increased length, plus a big-sized message-body. All SIP messages may include bodies, even when they are not needed in every message. Instead of only depleting processor power, longer message also increase network utilization. However, only well-formed header fields require decoding power, a parser should ignore other header fields and a server can reject too long messages with a 413 (Request Entity Too Large) message. Also, a parser must only interpret message body with the size as indicated in the contentlength header. Proxies have to forward messages even if they do not understand some of the message s header fields, note that such headers need not to be parsed. Larger messages than 1300 bytes are additionally required to be sent over TCP, which will create additional state even in a stateless proxy. Additionally, RFC 3261 [2] mandates headers, which have multiple values, to be separated into individual header fields so that each only contains one value. If multiple message headers of the same field are included in a message where these headers are spread all over the message, this complicates parsing. Especially the following header fields can be distributed in SIP: Accept-Encoding, Accept-Language, Alert-Info, Allow, Authentication-Info, Call-Info, Contact, Content-Encoding, Content-Language, Error-Info, In-Reply-To, Proxy-Require, Record-Route, Require, Route, Supported, Unsupported, User-Agent, Via, and Warning. Some message headers are more vital for process than other. Vital header fields are all routing-specific fields, like To, Via, Route, etc. As an effect, messages which append these fields towards the end of the message are more difficult to parse. One way to accomplish this is by inserting multiple informative header fields before the routing fields, like e.g. Allow or Supported. Several header fields allow other URIs than SIP/SIPS. Using these URIs might also complicate processing. Even if a highly optimized parser could handle such attacks, the required processing power requirements would be missing for other SIP related tasks Malformed Messages in SIP According to RFC 3261 [2], all SIP stacks must be capable processing the following standard SIP method - messages: REGISTER INVITE ACK CANCEL

13 BYE OPTIONS. The HTTP-like ASCII presentation of the SIP messages may initially be more attractive to attackers for vulnerability assessment than the rival signalling protocols (e.g. H.323, MGCP, SKINNY) with complex encodings. As a result, a malicious user can take advantage of any of the aforementioned SIP method - messages to mount this attack against SIP targets, which can be end-users terminals or SIP Proxy Servers. Apart from the standard SIP methods/messages, there are also SIP extensions [9] - [11] for various SIP methods providing several complementary services that can be possibly utilized by potential attackers. SIP subsystems have been designed and developed for processing messages that are valid and conformant with the SIP protocol syntax, as described in RFC 3261 [2]. An example of a valid and typical INVITE message that the SIP protocol syntax must be able to generate and process successfully is depicted in Figure 9. However, due to implementation errors in some circumstances, taking as well under consideration the complexity of the SIP parser, well formed messages can potentially crash the corresponding SIP server. INVITE sip:dgen@aegean.gr SIP/2.0 To: Geneiataki Dimitri <dgen@aegean.gr> From: Karopoulos Georgios <sip:gkar@aegean.gr>;tag=76341 CSeq: 2 INVITE Authorization: Digest username="gkar", realm=" ", algorithm="md5", uri="sip: ", nonce="41352a56632c7b3d382b39e0179ca5f98b9fa03b", response="a6466dce70e7b098d cd57" Contact: <SIP: :9384>;> Content-Type: application/sdp SIP headers v=0 o=tesla IN IP4 lab.high-voltage.org c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Session Description (body) Figure 9. Well formed typical INVITE message Besides the implementation errors, it is highly likely that the attacker will try various malformed message combinations to discover a security problem/flaw towards the SIP-victim subsystem. For example, the INVITE message depicted in Figure 10 is invalid and cannot be generated by the standard SIP protocol syntax, due to the lack of a REQUEST-URI, which must follow the INVITE method [2]

14 INVITE (null) To: Geneiataki Dimitri From: Karopoulos Georgios CSeq: 2 INVITE Authorization: Digest username="gkar", realm=" ", algorithm="md5", uri="sip: ", nonce="41352a56632c7b3d382b39e0179ca5f98b9fa03b", response="a6466dce70e7b098d cd57" Contact: <SIP: :9384>;> Content-Type: application/sdp SIP header v=0 o=tesla IN IP4 lab.high-voltage.org c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Session Description Figure 10. Example of Malformed INVITE message Any message that either does not conform to or violate SIP s protocol specifications can cause security flaws in any SIP subsystem, but usually, it is very difficult to distinguish between all possible legal and illegal messages. In a nutshell, possibly there are inputs that might not have been considered properly when implementing the SIP stack installed in each SIP product Mounting the Attack Normally, the attacker does not have a standard method for launching an attack. Therefore, in a sense, the behaviour of an attack is unpredictable. This is also true for SIP malformed message type attacks. For example, the attacker may construct malformed messages utilizing a brute force attack method, exhaustively trying all possible SIP message combinations. Alternatively the attacker can follow a more general procedure, which could be expressed in the following, repeatedly executed, algorithmic steps: 1. Discover the target s SIP capabilities. 2. Construct the malformed message. 3. Test the derived crafty message against the SIP target. The main advantage of such an approach is that the assault cannot be easily identified in its prime stages, as the defence mechanisms in place are not usually able to promptly detect it Discover Target s SIP Capabilities The initial step before an attacker launches a malformed message attack is to discover the SIP capabilities of a particular SIP target/subsystem. REGISTER messages and OPTIONS responses can give information about any SIP User Agent s (UA) capabilities. This sensitive information is included in the Contact header in REGISTER message and Allow header in response of the OPTIONS request. In every case, these messages can be utilized from the attacker in two different ways aiming to discover the User Agent s (UA s) capabilities. In the first one, the attacker can simply sniff SIP packets (especially SIP REGISTER packets) while a registration to a SIP registrar server is taking place. The other one merely utilizes the OPTIONS message. Figure 11 depicts the message flow for this method. Under these circumstances, the attacker creates an OPTIONS message, which is sent to the SIP victim. The target responds to the OPTIONS message, so the attacker discovers the

15 SIP target s implemented methods/messages (capabilities). For instance, the returned capabilities may reveal, among other things, the vendor and the version of the potential SIP target product, which in turn, expose existing vulnerabilities. attacker OPTIONS 200 OK proxy OPTIONS 200 OK target Figure 11. Discovering User Agent Server Capabilities Construction of a Malformed Message The second step towards launching the attack is to construct an appropriate malformed message. Figure 10 presents the structure of a malformed INVITE that we were able to generate. A list of such INVITE malformed messages also exist in the test-suite PROTOS [12]. Moreover, it is very likely for the attacker to send non-implemented (invalid or nonstandard) messages provoking eventually the target to crash. Besides that, other implemented messages like REGISTER, BYE, CANCEL, and other non-standard messages can be also employed to have this attack compiled much in the same way Restrictions, Limitation and Possibilities of the Attack Any malicious user who is located (or not) in the same domain with the victim can launch this attack. There is no real restriction for the attacker to prevent him from launching a malformed message attack, in absence of any underlying security mechanism that protects message integrity, confidentiality and origin authentication. Even though, the existing underlying SIP security mechanisms (e.g. Transport Layer Security-TLS, IP Secure-IPsec, Secure MIME-S/MIME) are only able to protect against outsiders and not against insiders, who are normally the legitimate users. However, considering this situation, an outsider will endeavour to employ his SIP proxy in order to amplify the DoS effects of specially fabricated malformed, invalid or non-standard SIP messages towards the corresponding SIP target Countermeasures Input validation procedures must be considered vital for the security of VoIP services. The lack of any validation in data input process is responsible for security flaws caused by malformed messages. The employment of gateways to filter malicious input at the Internet application level has also been studied [13]. Current firewall technologies incorporate packet inspection [14] for validating input data. The same techniques can be applied in SIP architectures using the Middlebox Communication approach [15] Moreover, the utilization of underlying security mechanisms (e.g. TLS, IPsec, S/MIME) according to RFC 3261 can substantially restrict or prevent the origination of malformed messages. However, it is always possible for an attacker to utilize another SIP proxy to

16 amplify the hazardous effects of the malformed messages. Additionally, these mechanisms do not provide any real security against internal-authorized but malicious users. Another possible countermeasure that can restrain this attack is the authentication of the OPTIONS messages. Additionally, the utilization of underlying security mechanisms is considered mandatory to protect the confidentiality of the REGISTER and OPTIONS messages against eavesdroppers. The employment of these countermeasures does not mean that the aggressor cannot launch the attack, but things become more difficult for him Detection Signatures No matter how strong the existing security prevention mechanisms in VoIP Services are, there is always the possibility for a malicious user to manage to by-pass them. So, in case an internal user launches an intrusion attack, it is quite probable that none of the existing prevention mechanisms will trigger an alarm. For example, considering a legitimate SIP user who generates a malformed SIP message and then signs it with his private key. There is no doubt that this attack can be hardly defeated by the usual prevention mechanisms and awake the existing countermeasures. To avoid such situations, the employment of an Intrusion Detection System (IDS) for the provided VoIP services is considered mandatory. On the other hand, in some cases, it is more economical to prevent only the uppermost attacks and detect the rest, than trying to prevent everything in a much higher cost. In addition, a detection system can be considered quite sufficient for protecting VoIP against malformed message attacks. In these systems, any distinct attack is described through some specific static structure, known as the attack s signature. Malformed message attack in SIP architectures can be similarly confronted by identifying, categorizing and prototyping the corresponding signatures. The proposed signatures are based on the SIP message syntax, which is fully specified in RFC 3261 [2]. Since all SIP messages are based on this syntax, it will be attainable to embed a light SIP IDS mechanism in a slightly modified SIP protocol stack. The signatures developed are marked out mainly for the most utilized SIP messages that current SIP User Agents implement. The detection signatures are based in the structure depicted in Figure 12. Each signature is composed by the identified malformed message (SIP-MESSAGES) optionally followed by some additional rules. SIP-MESSAGE (based in SIP-GRAMMAR) additionall rules Figure 12. General Form of a Signature The basic idea is to construct a general identification-detection rule that can be easily applied to any SIP message, independently from the SIP-method (INVITE, REGISTER, BYE, etc) used. Figure 13 presents the structure of this general rule. The first line represents the SIP Method, the URI and the corresponding header. This detection rule capitalizes on the fact that any SIP message must have a SIP method with the appropriate destination address followed by one or more message headers. Note, that not all SIP messages are mandate to have a message body. Moreover, additional rules add an increased security level and can effectively characterize a message as malicious or not. For example in the depicted rule, both the SIP method and the message header are prohibited from having the NULL value

17 SIP_METHOD SIP-URI SIPS-URI MESSAGE HEADER+ [MESSAGE_BODY] additionall rules SIP_METHOD!=NULL MESSAGE_HEADER!=NULL size_of(sip_method)>%constant% e.g 50 bytes size_of(message_body)>%constant% Figure 13. General Detection Rule However, there are cases (some very well known malicious messages) that cannot be identified by this generally structured rule. Under these circumstances (exceptions), special rules must be formed for each distinct SIP-method. For example, INVITEs which do not have a specific header (e.g. Content-Type, Call-ID) must be characterized as invalid. Additionally a malicious user will try to evasion the detection system utilizing alternative encodings values to construct malformed messages. For example, he can utilize HEX values for INVITE (e.g. 0x49,0x4E, ) to construct the malformed message thus evading the detection system when appropriate signatures for alternative encodings in the IDS database are not in place. Figure 14 describes a detection signature framework for INVITE messages. Note, that this detection signature is very similar to a valid INVITE message. The main difference is that the message is characterized as malicious when any of the mandatory message headers is not in place or any of the additional rules triggers it. For instance, concerning this signature, there are two additional rules, which restrict the value of the Content-Length header. This value must be greater than zero and equal to the size of the MESSAGE_BODY expressed in bytes. If any of these rules is not satisfied or any mandatory header is missing, then the message must be discarded, perhaps giving some feed to the IDS too. INVITE_METHOD SIP-URI SIPS-URI MESSAGE HEADER+ MESSAGE HEADER =Via Max-Forwards From* To* Call-Id* CSeq* Contact* User-agent Authorization Event Content-Length* Content-type* Record-Route INVITE_METHOD="INVITE" %x49.4e MESSAGE_BODY additionall rules %Content-Length% >0 %Content-Length%==size_of(MESSAGE_BODY) (*)mandatory fields Figure 14. Detection Signature for INVITE messages Another reason that prevents the employment of general structured rules only, is that different SIP methods require different message headers. Thus, the combination of general and special targeted rules can establish a robust identification framework to protect from SIP malformed messages. In addition, the administrators of each domain are responsible to utilize the appropriate rules (what is permitted and what is not) depending on the security policy determined beforehand. In the following subsections we present malformed message signatures for the most known SIP implemented methods. The general structure of such signatures is similar to the de

18 scription of the aforementioned INVITE signature. For this reason we show only the corresponding signature without discussing it Signature for Malformed REGISTER REGISTER_METHOD SIP-URI SIPS-URI MESSAGE HEADER+ MESSAGE HEADER =Via Max-Forwards From* To* Call-Id* CSeq* Contact* User-agent Authorization Event Content-Length* REGISTER_METHOD ="REGISTER" %x additionall rules From!=To %Content-Length%!=0 exist message body (*)mandatory fields Figure 15: Signature for Malformed REGISTER Signature for Malformed BYE BYE_METHOD SIP-URI SIPS-URI MESSAGE HEADER+ MESSAGE HEADER =Via Max-Forwards* From* To* Call-Id* CSeq* User-agent Authorization Content-Length* BYE_METHOD ="BYE" %x additionall rules %Content-Length%!=0 exist message body (*)mandatory fields Figure 16: Signature for Malformed BYE Signature for Malformed CANCEL CANCEL_METHOD SIP-URI SIPS-URI MESSAGE HEADER+ MESSAGE HEADER =Via Max-Forwards* From* To* Call-Id* CSeq* User-agent Authorization Content-Length* CANCEL_METHOD ="CANCEL" %x e c additionall rules %Content-Length%!=0 exist message body (*)mandatory fields Figure 17: Signature for Malformed CANCEL Signature for Malformed ACK ACK_METHOD SIP-URI SIPS-URI MESSAGE HEADER+ MESSAGE HEADER =Via Max-Forwards* From* To* Call-Id* CSeq* User-agent Authorization Content-Length* ACK_METHOD ="ACK" %x b additionall rules %Content-Length%!=0 exist message body (*)mandatory fields Figure 18: Signature for Malformed ACK

19 Signature for Malformed SUBSCRIBE SUBSCRIBE_METHOD SIP-URI SIPS-URI MESSAGE HEADER+ MESSAGE HEADER =Via Max-Forwards* From* To* Call-Id* CSeq* Contact Expires User-agent Authorization Content-Length* SUBSCRIBE_METHOD ="SUBSCRIBE" %x additionall rules %Content-Length%!=0 exist message body (*)mandatory fields Figure 19: Signature for Malformed SUBSCRIBE Signature for Malformed NOTIFY NOTIFY_METHOD SIP-URI SIPS-URI MESSAGE HEADER+ MESSAGE HEADER =Via Max-Forwards* From* To* Call-Id* CSeq* Contact Record-Route Expires User-agent Authorization Content-Length* Content-Type NOTIFY_METHOD ="NOTIFY" %x4e.4f MESSAGE_BODY additionall rules %Content-Length% >0 %Content-Length% ==size_of(message_body) (*)mandatory fields Figure 20: Signature for Malformed NOTIFY 2.4 DNS Blocking Attacks As already mentioned in the previous deliverable D2.1 [1], SIP agents are vulnerable to DoS attacks through invalid DNS lookups. The basic concept is as follows: An attacker sends messages including irresolvable host names, forcing the underlying DNS service to perform time-consuming, but unsuccessful host lookups. Generally, while the SIP agent waits for the reply from the DNS subsystem, it cannot process other pending messages, which renders it at this moment highly vulnerable to flooding attacks Scope Applications contact the corresponding DNS system whenever the need arises to translate a Fully Qualified Domain Name (FQDN), e.g. into the corresponding IP Address (e.g ). The operation system provides an interface to this functionality, e.g. a Unix-based operating system generally provides the gethostbyname system call for this translation. Whenever the DNS subsystem receives the request, there are simplistically two possibilities how it can provide the answer. The DNS resolver is aware of the translation. This can be either through configuration, e.g. some translations are hard-coded into the system or through caching, and previous requests are stored for a certain amount of time at the DNS server in case another request for the same hostname arrives. The DNS resolver isn t aware of the answer. The DNS server then needs to contact other servers that might know the answer to this request. Because this process might include a recursive search among different servers, response times can be very long. For the second case it is not guaranteed that a successful translation can be detected. Misspelled names or non-existent hostnames intentionally provided will lead to an error re

20 sponse that this name doesn t exist. Because this process can take a reasonable amount of time in certain cases, implementations like the DNS subsystem on Linux restrict request processing to certain boundaries, which default to 5 s timeout and 3 possible retry possibilities. If after five seconds or three retries no reply is received, the system will assume that the requested address is irresolvable. To measure the impact of DNS resolving issues with a SIP proxy, we have conducted a DNS lookup attack simulation DNS Attack Simulation For simulation purposes we have created an attack tool and a target SIP proxy running on the Linux operating system. The attack tool can generate an arbitrary number of SIP IN- VITE messages with a configurable delay between them. The SIP messages contain randomly generated SIP URIs. Additionally, multiple message generators can be run in parallel to flood a target with such messages. The target was a simple SIP proxy that can handle incoming INVITE messages and resolve the embedded SIP URIs. The SIP proxy can fork multiple child processes for parallel incoming message handling to resemble operation provided by the SIP Express Router (SER). The target SIP proxy has three modes of operation to resolve DNS requests. Default synchronous mode. This mode resembles SER s operation, as it uses the gethostbyname system call with its default parameters (5 s timout, 3 retry limit). Operation is depicted in Figure 21. Optimized synchronous mode. This is a modification of the standard gesthostbyname system call with optimized limitation parameters. We have set the timeout value to 1 s and only allow one resolve attempt. Asynchronous mode. This mode uses the asynchronous ares DNS resolver library [16]. Asynchronous mode works as follows: The calling application issues a resolving request to the ares library. This request is acknowledged immediately, even if at this moment no DNS lookup is actually performed. The calling application can continue its work without delay, and will receive the final answer from the ares library through an established callback hook. While this method guarantees a faster processing speed, memory consumption increases, as with every lookup request additional state information has to be stored until the final answer arrives. For the simulation, we have run attacks on the SIP proxy in all three different operation modes. Attacks have been conducted with three different attacks suites with the following parameters: messages sent with a delay of 10 microseconds. The target proxy has 10 sub-processes messages sent with a delay of 1 microsecond. The target proxy has 20 sub-processes messages sent by 3 threads with a delay of 1 microsecond, repeated at every 20s for 10 times to a total of messages (flood scenario). The target proxy has 30 sub-processes

21 Initial process child 1 child 2 blocks up to 5 seconds child N read SIP msg read SIP msg read SIP msg gethost byname gethost byname gethost byname continue work continue work continue work Figure 21: Proxy target default synchronous operation mode Figure 22 show the message processing capabilities of the target proxy in its different operation modes. The Total line denotes the number of total messages sent by the attack tool, while the bars indicate the actual number of messages processed by the proxy. Two main observations can be made: In synchronous mode, the proxy can handle only a fraction of the incoming messages. In optimized synchronous mode this can only alleviated by a certain degree. In the first two testing-suites, the proxy was able to process all incoming requests in asynchronous mode; however this was not the case in the message flooding scenario in test suite 3. This is due to memory constraints of the server machine. While we ran tests on a well dimensioned test system with 8 GB of RAM, asynchronous mode needs for every fork some memory to keep its state information. After some time, the whole memory of the system was consumed (See Figure 23). All other simulations never exceeded a memory consumption of 400 MB. From this simulation have seen that message flooding with random domain names can exhaust the processing capabilities of a SIP proxy, no matter if the proxy resolves DNS request synchronously or asynchronously

22 # processed messages Default Sync Opt. Sync Async Total 0 Suite 1 Suite 2 Suite 3 Tests Suite Figure 22: Simulation processing capabilities Figure 23: Memory usage at the SIP proxy in asynchronous mode (Test suite 3)

23 3 Tools Utilized This section introduces several open source tools that will be employed by Snocer software architecture to deal with certain attacks. 3.1 Netfilter / Iptables Netfilter and iptables are building blocks of a framework inside the Linux 2.4.x and 2.6.x kernel. This framework enables packet filtering, Network Address Translation (NAT) and other packet mangling. Snocer software architecture will employ iptables/netfilter as filteraction-points to block malicious traffic. Once the source of an attack has been identified by Snocer software, specific filter rule(s) will be activated at some filter-action-points by Snocer software, so that the iptables/netfilter can act to prevent the following malicious packets from reach the SIP server by dropping or reject them. Netfilter and iptables are the re-designed and heavily improved successor of the previous Linux 2.2.x ipchains and Linux 2.0.x ipfwadm systems. Netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack. Iptables is a generic table structure for the definition of rule sets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target) [17]. Following figure illustrates the internal tables and chains and possible table traverse scenarios: Figure 24: iptabels overview

24 Netfilter and especially can be accessed trough a custom library, libiptc, which allows the same set of firewall control as the iptables user command. 3.2 SER The SIP Express Router (SER) [18] is an open-source SIP server, published under the GNU Public License. SER s architecture [19] has been designed for high scalability to serve thousands of calls per seconds, and flexibility due to a modular plugin-approach and a higly configurable routing language. SER is already in widespread use at many VoIP providers. Under Snocer software architecture, as last line of defence, security enhancement modules will be developed to let the SER itself have certain self-defence abilities to deal with certain attacks. A DNS enhancement will also be developed to improve the SER s DNS query ability so that the risk of service failure caused by DNS DoS attack can be minimized. The SER was designed in a highly modular manner as depicted in Figure 25, SER consists of a highly efficient core that is responsible for receiving, parsing SIP and forwarding messages. SER Core Modules Parsing Handler Maxfwd RR MySQL Jabber Script Interpreter SL Usrloc Registrar Authentication SIP/SMS CPL Figure 25: General Architecture of SER The core is also responsible for invoking certain procedures that are provided as extension modules. These modules are dedicated to providing certain features. Such modules include: Registration and user location: This part is responsible for handling registration requests and managing the user location database. Transaction management: When acting in a statefull mode SER must maintain per transaction state, generate replies, match replies to requests and deal with forking. User authentication: SIP utilizing HTTP digest for authenticating user requests. This part of SER interacts with the database, which maintains the user s identity and password and is responsible for checking the credentials of the users. SIP handling: While the core deal with the message processing, the transaction management deal with state handling and taking the appropriate SIP actions, this type of modules deals with additional processing logic such as handling of recordroute headers, loop detection or support for ENUM

25 Application modules: These modules provide some application level services such as SIP to Jabber translation.. Application programming modules: To enable external programmers to use the features of functionalities of this class of modules provides a clear and simple to use interface that allows the separation between the SER and the application code. Each module exports a set of functional procedures and utilizes procedures exported by other modules. The integration between the different modules and the core is realized through a configuration language. The SER Configuration Language (SCL) is a rich and flexible scripting language. In this context SCL is similar to shell languages with support for regular expressions and allowing the administrator to specify certain rules whenever a specific event occurs, in the manner of If (event) then (action); In the figure below, the administrator specifies that after receiving a registration request, the core should invoke the authentication module before handing the registration by the registration module If(method== REGISTER ) www_challenge( sip.org /*realm*/, 0 ); break; To enable the extension of the functionality of SER as well as experimenting with novel ideas and concepts, SER provides an open programming interface to utilize the current and novel functionalities of SER and add novel ones. This is achieved by implementing a new module that provides these new features. Such a new module would use the exported procedures of the other modules as well as functionalities of the core. The new module in its turn exports new procedures that could be invoked by the core and other modules as well. The SCL is then used for integrating the new functionalities in the general functionality of SER. Using SCL, the administrator of the SER platform can define the exact behaviour of the platform based on available modules and needed actions. 3.3 Snort Snort Overview Snort is a network-based Intrusion Detection System (IDS) distributed under the GPL license. It performs real-time analysis of packets on the network and triggers alarms when specified conditions are met. To detect attacks on the network, Snort is using a flexible set of rules. Its engine utilizes a modular plugin architecture. The Snort system provides the functionality for the detection of intruder s attacks covered by the Snort IDS and the functionality for attack prevention provided by Snort s Intrusion Prevention System (IPS). Besides additional functionalities provided like the Sniffer mode (reads packets from the network and displays them) and the Packet logger mode (logs packets directed from network to disk) Intrusion Detection System Snort intrusion detection is based on a simple lightweight description language. Snort identification is based on the analysis of incoming packets and the defined utilized rules. Many

26 of the fields (mainly in IP, TCP and UDP) can be used to test malicious packets. It examines among other source, destination IP addresses, ports, protocol type and other fields in packet headers. The Snort system also allows analyzing packet payloads and searching the content of a packet for given textual or binary patterns. Thousands of rules are currently included in Snort systems, many of them already covering various types of DoS attacks. Additional rules are available for LAND, teardrop, or smurf attacks. For a complete list of available rules can be found in [20]. Furthermore rules for specialized attacks on SIP, can be easily added Intrusion Prevention System The snort_inline tool provides snort s intrusion prevention functionality. Snort_inline obtains packets from iptables instead of the libpcap packet monitoring library [21] and controls iptables to pass or drop packets based on Snort rules. Thus, snort_inline provides the capability to detect and stop malicious packets generated by DoS attempts. There are three actions available to stop undesired traffic with snort_inline: drop: The drop rule type instructs iptables to drop the packet and log it via usual Snort means. reject: The reject rule type instructs iptables to drop the packet, log it via usual Snort means, and send a TCP reset if the protocol is of type TCP or an icmp port unreachable message if the protocol is of type UDP. sdrop: The sdrop rule type instructs iptables to drop the packetthe difference with drop action is that nothing is logged if this type is active Preprocessors The Snort system uses special modules called preprocessors. They allow Snort s functionality to be fairly easily extended by allowing users and programmers to include modular plugins into Snort. Preprocessor module is run before the detection engine is called, but after the packet has been decoded. The packet can be modified or analyzed in an out-ofband manner using this mechanism. For example a portscan detector, telnet decoder, RPC decoder, and HTTP inspector are some known preprocessors available with the existing version of Snort

27 3.3.2 Snort Utilization in VoIP / SIP Environments Snort s functionality based on the rules and preprocessors distributed today with the Snort system allows to detect known attacks. The following ready-to-use VoIP related signatures are currently included in the Snort signature database: 1:1814 Message WEB-MISC CISCO VoIP DOS ATTEMPT Summary This event is generated when an attempt is made to exploit a flaw on a Cisco VoIP telephone. Description Description: Certain versions of Cisco's VoIP phones are vulnerable to an attack that can cause them to reboot when they receive an http request such as where <value> is an integer value of arbitrary high value, typically a number greater than References bugtraq: 4794, cve: , nessus: Impact Message Rule Message Rule Denial of Service BLEEDINGEDGE Policy Skype VOIP Checking Version (Startup) alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"bleedingedge Policy Skype VOIP Checking Version (Startup)"; uricontent:"/ui/"; nocase; uricontent:"/getlatestversion?ver="; nocase; classtype:policyviolation; reference:url,www1.cs.columbia.edu/~library/trrepository/ reports/reports2004/ cucs pdf; flow:to_server,established; sid: ; rev:4;) BLEEDINGEDGE Policy Skype VOIP Reporting Install alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"bleedingedge Policy Skype VOIP Reporting Install"; uricontent:"/ui/"; nocase; uricontent:"/installed"; nocase; classtype:policyviolation; reference:url,www1.cs.columbia.edu/~library/trrepository/ reports/reports2004/ cucs pdf; sid: ; rev:3;) Table 2: Snort VoIP signatures The first one is specific to Cisco VoIP phones and the remaining address Skype VoIP clients. However, they do not apply to SIP infrastructures. Snort extensible architecture allows the inclusion of custom rules, allowing the development of proprietary rules for use in Snort to expand its functionality and to detect identified vulnerabilities in VoIP communication and SIP signalling. Further the development of specialized preprocessor modules for more complex testing of incoming traffic is supported through the use of snort_inline SNORT Drawbacks Snort can be used to monitor a SIP based infrastructure network for intrusion attempts, provided that rules for checking VoIP specific traffic are available. Unfortunately Snort does not accurately fit all needs relevant for the detection and prevention of attacks in a

28 SIP infrastructure. The matching infrastructure provided by Snort is versatile and has been proven to be very effective for dealing with most network based intrusions. However, for VoIP applications, there are some drawbacks to Snort directly: No reassembly functionality is available for grouping UDP packets that belong to a VoIP session. This means malicious patterns that are spread across UDP packets could elude the matching rule in Snort. (The stream4 reassembly module can only reassemble multiple TCP packets which belong to the same session and subsequently apply detection rules. Thus UDP streams, which can also be used for SIP signalization, cannot reliably be tested for malicious patterns, because these patterns can be spread across multiple packets). Snort s detection is basically session unaware. It does provide stateful detection for some TCP applications like HTTP and FTP. However, there are currently no infrastructures that can help in processing stateful VoIP sessions. This could pose a problem for the detection accuracy and efficiency of detection. Encrypted communication cannot be parsed and malicious patterns cannot be found. This is one of major problems of all network-based IDSs. Moreover Snort is unable to search for malicious events across different protocols (SIP, RTP,etc). Furthermore Snort, does not allow dynamic rule updates, as it only parses its rules during system startup. For this reason a VoIP security architecture can not rely only on Snort capabilities, instead, a more sophisticated application is needed for assistance. 3.4 Prelude IDS Prelude Overview Prelude [34] is an open source Hybrid IDS distributed under the GPL license. It provides a modular and distributed architecture with different sensors, each of them with different capabilities (e.g., network sensor, host based sensor). Figure 26 depicts the base architecture of the Prelude IDS. Figure 26: Prelude Architecture All sensors notify a Prelude manager about intrusion-sensitive events, which then are processed and reported. This allows the concentration of all network related events in one specialized place. This manager with its features (database management, human interaction) runs on dedicated host and thus frees resources the monitored and possibly attacked hosts

29 Simple and unified communication possibilities between entities in the Prelude architecture are provided by the LibPrelude library, which exchanges messages based on the IETF standardized Intrusion Detection Message Exchange Format (IDMEF)[22]. Communication between entities is secured through the use of TLS. LibPreludes enables the easy integration of enhancement sensors into the Prelude architecture. In addition there is the possibility to use libprelude library to obtain two way communications. This is not widely used, but it can be useful if we want to take control of countermeasure components from the Prelude Manager Prelude IDS Architecture Modules Prelude-NIDS Prelude s NIDS sensor provides classical capabilities of generic NIDS like a portscan plugin (for the detection of portscans), a Snort-rules plugin (for utilizing Snort signatures within the Prelude system), an IP defragmentation plugin (for reassembling IP fragments prior to signature lookup), and a TCP stream reassembly plugin (for reassembling TCP stream prior to signature lookup comprising several packets) Prelude-LML The Prelude-LML sensor provides the log analysis function. Logs on a local system, as well as logs received from remote hosts over the network (in case the system is configured to accept syslog messages from the network) are processed and analysed in order to discover security anomalies. Prelude-LML s capability to manage and analyze log messages is based on a plugin system, for example through a Perl Compatible Regular Expression (PCRE) engine called Simple Prelude Manager Prelude sensors send events to a central manager which is in charge of event processing and reporting. A correlation agent providing more detailed data and better understanding of signalled events complements the manager s function. Received messages can be stored in a database (MySQL plugin) or browsed and analyzed by a human operator through the Prewikka management console (Figure 27). Figure 27: Prewikka frontend for Prelude

30 3.4.3 Extensibility for VoIP Environments The highly distributed and modular designed of Prelude system provides good flexibility and scalability for different environments. The Prelude system uses the LibPrelude library to ensure communication between the sensors and the manager, a powerful tool for providing access to the managed information to the administrator. Making use of the distributed topology of the Prelude system and its hybrid-based IDS architecture can give additional benefits in comparison with the Snort IDS. It is, for example, possible, to develop billing fraud attack sensors (able to communicate with other sensors like Prelude-NIDS and Prelude-LML), which can be placed on the same device like the billing system. 3.5 Existing Attack Tools In this section we describe the most known utilized VoIP security testing tools or suites that allow users to assess the security of their VoIP infrastructure. The described tools focus mainly in the test of robustness of SIP server implementations. The tools that we describe are: 1. VoIP Vulnerability Scanner (SiVuS) 2. SIP Forum Test Framework (SFTF) 3. PROTOS suite 4. SIP Swiss Army Knife (SIPSAK) VoIP Vulnerability Scanner (SiVuS) Sip Vulnerability Scanner (SiVuS), [24] is used primarily by developers, administrators, network designers, managers and consultants to verify the robustness and security of their SIP implementations by generating the attacks that are included in the SiVuS database or by crafting their own SIP messages using the SIP Message generator. The SiVuS scanner provides powerful features that allow administrators, developers and consultants to verify the robustness and secure implementation of SIP components such as Proxies, Registrars or phones either hard or soft. The following paragraphs provide additional details on the SiVuS functionality and features: SIP Message generator: it can be used to send various types of messages to a SIP component including SDP content. This feature can be used to test specific issues with SIP or generate various attacks for demonstration purposes (e.g. DoS, registration masquerading). SIP component discovery: it scans a range of IP addresses to identify hosts which use the SIP protocol and can be used as targets for further analysis. Note, that there is an option in the configuration scanner which allows preliminary discovery of targets prior to an actual scan. The discovery interface is typically used as a precursor to a scan to ensure that the appropriate targets should be scanned. Other uses of this are possible. SIP vulnerability Scanner: The scanner provides flexible configuration of several options which can be used to verify the robustness and security of a SIP implementation The checks that are performed are as following: Analysis of the SIP message headers to identify vulnerabilities such as Buffer overflows or DoS attacks. These checks can be selected and configured with variable values, by the user

31 Authentication of signaling messages Inspection for secure communications (SIPS) and encryption capabilities At the moment the scanner provides a user friendly report using HTML. Later versions of the scanner will support multiple arrangements and views of the data collected after a scan including maintaining a history of scanning sessions. The user is also provided with the ability to save messages from the activity log that are generated during a scanning session for later analysis SIP Forum Test Framework (SFTF) As cited in SFTF s web page [25], SIP Forum Test Framework (SFTF) can be utilized to allow SIP device vendors to test their SIP devices for conformance and interoperability with the SIP protocol specifications. More specifically, this test tool has been designed having in mind to identify various SIP interoperability shortcomings, which often appear in immature or hasty developed SIP User Agents (UAs), causing severe problems in existing SIP deployments. However, SFTF has not been used for exhaustive verification of compliance with SIP specifications. This test-suite may be additionally employed to identify behaviours, which although conform to SIP specifications, are considered sub-optimal implementation practices. SFTF is written in Python. Consequently, it allows everyone having little programming knowledge, to write his own tests for SIP devices PROTOS Suite PROTOS describes a method to assess the robustness of SIP implementation by describing a general test suite to find vulnerabilities. The test suite set a baseline to determine vulnerabilities in SIP products focusing on SIP parser abilities, and can be used during in-house testing or as part of regression testing. The framework for creating robustness test suites has been based in the PROTOS project [35]. The PROTOS have proven to be efficient in testing for software vulnerabilities by using a black-box testing method based on syntax testing. In syntax testing, test cases are generated from the corresponding input specification. In the case of SIP had been constructed approximately 4527 malformed SIP-INVITE to test various implementation of SIP servers. The test suite is written in Java and is freely available in [36]. A detailed description about SIP PROTOS testing suite can be founded in [12] SIP Swiss Army Knife (SIPSAK) SIPSAK [26] is a tool focusing on developers and administrators of SIP application and servers and can be used as a SIP stress and diagnostic utility. As a stress utility can be utilized to create either register or invite messages at high pace against to the corresponding SIP network element (registrar or proxy). On the other hand, regarding the behaviour of the tool as a diagnostic tool, a SIP message is sent to the destination in SIP-URI and the reply status is displayed. Generally, the tests that are implemented in the current version are the following: (1) sending OPTIONS request, (2) sending text files (which should contain SIP requests), (3) traceroute (see section 11 in RFC3261), (4) user location test, (5) flooding test, (6) random character trashed test, (7) interpret and react on response, (9) authentication with qop supported, (10) short notation supported for receiving (not for sending), (11) string replacement in files, (12) can simulate calls in usrloc mode (13) uses symmetric signalling and thus should work behind NAT, (14) can upload any given contact to a registrar, (15) send messages to any SIP destination, (16) search for strings in reply with regular expression,

32 (17) use multiple processes to create more server load and (18) read SIP message from STDIN. A detailed description about SIPSAK can be found in [26] Limitations The main limitation of the tools presented in the previous paragraphs is that they mainly perform testing based on PROTOS suite focusing on assessment of SIP implementations. Although these tools are GPL licensed, a complete documentation to clearly explain the full capabilities of those tools and how they can be extended does not exist. As a result, the utilization of the source code of the aforementioned tools is an extremely hard procedure. Besides that, existing tools fail to cover existing vulnerabilities as described earlier in the previous section and are mainly based on pre-defined tests. Moreover, due to the lack of serious documentation the users are not able to test all the functionalities that the tools provide, as sometimes these suites do not perform what they claim to

33 4 Security Architecture Description 4.1 Attack Description Language The difficulty in developing a meta-model for simulation is founded in the different style, categories and implementations of the attacks that can be exist. It is seems to be necessary the definition of an abstract description for the SIP attacks in a computer readable way independent for any platform restrictions. The abstract description defines the parameters for the security test simulation. In these simulation scenarios we will describe among other, source, target and a description of the simulated attack. The purpose of this structure is to provide a common attack description in a computer readable way, corresponding in a set of message exchanges between an attacker and a Proxy server or an end user device. A properly define structure will be able to handle the attacks which has been described in Section 2. Detailed analysis of the scenario structure is presented in the following paragraphs A SIP Attack Description Model We suggest the utilization of XML to build these scenarios. XML has been used in previous works [30] [31] to describe SIP message flows, and its use simplifies adding new kinds of security-conformance tests without any modification of the general structure. Our attack description model basically consists of a two-level hierarchy. At the basic level we present XML elements to describe a single SIP message. The elements at this level are relevant parts of the SIP message for unique identification of the corresponding SIP message and can be utilized for later reference. Additionally, elements will be introduced to describe a message flow of basic SIP messages that will describe a certain kind of attack. Furthermore, to simplify testing, an XML attack description should include all the information needed, so that from its content the SIP IDS is able to detect this attack, and an attack generator can generate this attack. The attack description will be slightly different depending on whether it is utilized by the attack generator or by the IDS. This distinction is needed because of different points of view between defence and attack Generally Used XML Attributes SIP message have a certain structure. Each message contains different header fields and corresponding header values. These header values have to be encoded in predefined ways, e.g. a value might represent a SIP URL or a numeric value. We will introduce special XML attributes and corresponding attribute values for different cases. For example, the attacker needs to declare the range of different URI sources used for the attack while the defender requires a mechanism to associate URLs obtained from different messages with a certain threat. Attribute Content type Purpose SIP value types. Possible values are uri, address, int, string Type of SIP message. Can be request or response ANY Value Purpose Indicates any possible value. For the scanner this means that

34 PREVIOUS EMPTY for a certain Header every possible value should be considered. For the generator this generally means that this value should be generated randomly with respect t the generated field Indicates that the value should match to the previous received message header field value Describes an unspecified value XML Elements to Describe a Single SIP Message We will present SIP Headers that are relevant for distinguishing SIP attack messages. These are the headers that need to be stored in the IDS state machine for further reference and comparison to previous occurrences. Element Purpose <message> A SIP message. The type attribute defines if it is a request or a response <Name of a SIP Header> Elements to describe relevant headers of the message have the same name as the header. For example, elements will have the name <contact>, <from>, <to>. We derive these names from the long SIP header names in an all-lowercase spelling. <Name of a SIP header parameter> As above. Example: in a <from> element there can be a <tag> element embedded to describe the SIP tag attribute XML Elements to Describe SIP Message Flows In this section we describe the proposed elements which will be utilized to describe SIP message flows. As outlined in section 4.1.1, these elements (tags) will be used by Attacker and IDS to describe the attack. In the following table defined elements are described. Element <security_test> <target> <Request-Line> <headers> <body> <send> <message> <receive> <configuration> <source> <parser> <dialog> <trigger> <loop> Purpose The proposed document describes SIP attacks Defines the target of the attack SIP request line that will be utilized in the attack The headers that will be utilized in the attack The message that will be utilized in the attack Send a SIP message The SIP message, specified by a type attribute Receive a request or a response The configuration of the attack Defines the source of the attack Description of the Parser attack Unique representation of the relationship between SIP user agents This is the initial message which is possibly the beginning of an attack Indicates that inside elements need to occur multiple times (parameters e.g. infinity loops, threshold, this could de

35 <lifetime> scribe a flooding attack Timeout of an attack after this time a suspicious flow is declared to be legal Example of Flooding Attacks In this scenario we describe a multi-source flood attack, the duration of such attack is 100 sec and the attack messages are sent with an interval time distance 1 msec Description for the attacker <security_test> <configuration> <source> </source> <source> </source> <target> </target> </configuration> <trigger> <loop duration= 100sec interval= 1msec > <send> <message type= request > INVITE <from content = url > dgen@aegean.gr</from> <to content= url > someone@ </to> </message> </send> <receive> <message type= resposne > </message> </receive> </loop> </trigger> </security_test> Description for the IDS From the IDS perspective a possible description for the identification of a flooding attack could be the following <loop threshold= 100 msg per second > <trigger> <message type= request > INVITE <from content= uri >ANY</from> </message> </trigger> </loop>

36 Another example for a message flow: <trigger> <message type= request > INVITE <from content= uri > ANY <tag content= int > ANY </tag> </from> message> <trigger> <timeout time=20s /> Example of Parser Attacks In this scenario the attacker constructs a malformed message in which the Request URI is missing Description for the attacker <security_test> <configuration> <source> </source> <target> </target> </configuration> <trigger> <send> <message type= request > EMPTY <from content= uri > dgen@aegean.gr/> </from> <to content= uri > someone@ </to> </message> </send> </trigger> </security_test> Example of SIP Application Attacks In this scenario the attacker constructs a CANCEL message for canceling previous legal INVITE messages Description for the attacker <security_test> <configuration> <source> </source> <target> ></target> </configuration> <dialog id= > <send> <message type= request > CANCEL <from content= uri >dgen@aegean.gr</from> <to content= uri > someone@ </to>

37 </message </send> </dialog> </security_test> 4.2 Defence Architecture Description The defence architecture is responsible for detecting attacks on the VoIP infrastructure, alerting the network operator of possible attacks and eventually prohibiting these attacks. The main components in this scenario are the Bastion host and the extended SIP proxy (See Figure 28). The main reason to split attack detection between two entities lies in the complexity of SIP attacks. A bastion host is only able to detect attacks based on a simple pattern, albeit with a very low processing overhead. In this case, we can filter already a certain amount of unsolicited messages with a low processing overhead. More advanced attacks also require an increase in processing overhead, so the input flow to the second defence entity should be as small as possible. The Bastion host can also host the network s firewall solution. However, depending on network load it will also be possible to deploy a remotely controlled firewall host which will be remote controlled (e.g. for Snort through the SnortSam plugin [28] ) depending on the attacks detected. Inside the network we will use the Prelude framework as a basis to establish communication between the individual defence entities and the management console. Figure 28: Security Architecture The architecture will allow a system administrator to secure its own network sufficiently to prevent the majority of attacks; however this will in general not be the case for the remainder of other networks constituting the Internet. With the ubiquitous availability of internet access more and more hosts reveal a severe lack of proper security mechanisms. Simply, proper security application usually requires knowledge which the average user rarely has