Security of VoIP

SIP flooding and its Mitigation Xianglin Deng

University of Canterbury 90 Ilam road Christchurch, New Zealand

Chien-wei Lee
University of Canterbury 90 Ilam road Christchurch, New Zealand

xde13@student.canterbury.ac.nz

cwl20@student.canterbury.ac.nz
limitations with respect to new types of attacks, particularly at the upper layers of the architecture. Some malformed packets with spoofed IP addresses can pass through the firewall and damage the VoIP system. There are various types of attacks that can affect the performance of VoIP system. For example, SIP (Session Initiation Protocol)[1] request flooding, Registration hijacking, Sound injection, and so on. And the SIP request flooding is considered as the biggest threat to VoIP networks [2]. This project will examine the effect of flooding based DDoS attacks against SIP-based VoIP system, and propose a potential solution to this kind of attacks.

ABSTRACT
Voice over Internet Protocol (VoIP) is an emerging telecommunications technology that is already shaping the future of telephony. VoIP uses the Internet Protocol (IP) to transfer voice data in packets as opposed to the traditional circuit-switched network used by the Public Switched Telephone Network (PSTN). Since VoIP communications are based on an open environment such as the Internet, they are can be exposed to the attackers. Moreover, the strict performance requirements of VoIP have significant implications for security, particularly denial of service (DoS) issues. Due to the popularity and the wide deployment of the Session Initiation Protocol (SIP), one of the standard signalling protocols for VoIP, the project focuses on the SIP INVITE flooding attacks..

2. SIP operation
SIP is a plaintext-based signalling protocol; it provides its service through the request-respond model. Figure 1 shows the normal message flow in a SIP call setup process. When a caller wants to make a phone call, it sends an INVITE message to the VoIP proxy sever, and the SIP server finds the callee, and forwards the message to the callee. When the callee picks up the phone, an OK message is sent back to the caller, the caller then sends an ACK message to the callee, the call is then be setup.

Categories and Subject Descriptors

K.6.m [MANAGEMENT OF COMPUTING INFORMATION SYSTEMS]- Security AND

General Terms
Security, Performance, Measurement Experimentation, Verification,

Keywords
SIP, Security, Flooding attack, Firewall.

1. Introduction
VoIP is an important application and forms part of a suit of multimedia application services. The reasons for this are: VoIP has the potential to offer voice service at a lower price than current PSTN infrastructure. b) IP based networks provide a flexible infrastructure for multimedia application such as VoIP. c) VoIP can interoperate with the legacy telephony system. It is possible to deploy a mix of VoIP and conventional PSTN infrastructure. However, many telecommunication companies security implementations of VoIP are commonly only based on intranets protected by firewalls. As the security implementations of a firewall are based on known attack vectors, they have a)

This paper was published in the proceedings of the New Zealand Computer Science Research Student Conference 2008. Copyright is held by the author/owner(s).

Figure 1: INVITE process

NZCSRSC 2008, April 2008, Christchurch, New Zealand.

Security of VoIP: SIP Flooding and its Mitigation

205

2.1 How the SIP server handles INVITE message

Figure 2 shows how the INVITE message is handled in a normal SIP call setup process.

3.1 Flooding Tool

To take the advantage of potentially high processing time caused by INVITE requests, a tool called iFlood is developed to generate a flood of SIP/SDP INVITE messages, carried by UDP/IP packets, targeting a given SIP entity. The iFlood was written in C language under Linux environment. It incorporates a open-source library called LIBNET to allow low-level manipulation of IP packets to make custom packet generation easier. The iFlood also uses the library called HACK_LIBRARY [4]. The library contains a collection of functions that are used by iFlood to support IP address and string conversions as well as packet manipulations. To avoid the iFlood generated packets being detected as malicious or redundant by SIP proxies, Intrusion Detection Systems (IDS), or SIP-aware firewalls, the Cseq (Command sequence) header field value is incremented in each subsequent request and the new value is used to substitute the last ten characters of the following header field values: the Via branch tag, the From tag, and the Call-ID. A change in these field values influences the processing target to interpret each INVITE message as an independent call dialog initiation event. For each packet, the source IPv4 address and the Contact header field values are also spoofed. There are two flooding modes that iFlood supports. In a burst mode, all packets are sent out as quickly as possible, i.e., sending a stream of packets. A traffic profile that depicts the number of packets sent versus time is shown in Figure 4. In our testbed, iFlood is able to generate a flood 1,250 packets per second. The average packet size is 1100 bytes, so each flood generates traffic of average 11Mbits per second.

Figure 2: How INVITE message is handled by the SIP server When a client sends an INVITE message to the SIP server, the SIP server checks for a username and password (for the first INVITE message, there is no username and password included for authentication), stores the state of the session, and sends a 407 (AuthenticationRequired) message back to the client with a random nonce value. When the client receives a 407 message, it resends an INVITE message with the same session ID, nonce value, and its username and password. When the username and password is verified to be valid, the SIP server forwards the INVITE message to the target client.

2.2 Problem with the current VoIP system

As soon as the server receives an initial INVITE message, the server allocates some memory resource to store the state of the session. Normally it could take up to a few seconds to complete a call setup process, which makes the server vulnerable to SIP flooding attacks. Some servers use a timer to drop the sessions that are not responded within a certain period of time. However, this does not mitigate DDoS attacks when there are a large number of requests sent to the server in a short period of time. Figure 3 shows the SIP INVITE flooding attack.

Figure 4: The Flooding Traffic Profile in Burst Mode: A stream of total 10,000 packets was sent in 8 seconds. The other mode of flood sends packets out in chunks with a user-defined time delay between the chunks, thus called chunk mode. This special flooding mode is implemented to explore or exploit the vulnerability of some firewalls or IDS that are not able to detect or block the flooding traffic of this form. When running iFlood in chunk mode, a user will be prompted to specify the number of packets per chunk as well as the time delay between chunks. Figure 5 depicts the traffic profile of a flood sent in chunk mode.

Figure 3: INVITE flooding attack

3. Effect of INVITE flooding attacks

In order to examine the effect of INVITE flooding attacks on the performance of a VoIP server, an attack tool (iFlood) is developed based on an open source attack tool called INVITE_FLOOD[4], as described in the following secion. iFlood is used in our VoIP testbed to attack the VoIP proxy server, and the call setup delay is measured using Wireshark [3].

206

X. Deng and C. Lee

The firewall is not able to detect the packets generated by iFlood as spoofed, so all the INVITE requests can pass through. However, if the number of packets in a flood is greater than a certain threshold, the firewall will detect the DDoS attack and block the flood traffic, and yet, still allow legitimate traffic to Number Number of attack received sent 0 0 86 256 2661 1440 Call setup delay firewall reaction

0.018182s 0.1048s 0.1802s 6.9501s request timeout request timeout

N/A Nothing attack detected Attack detected Attack detected Block the traffic

Figure 5: The Flooding Traffic Profile in Chunk Mode: A total of 10,000 packets were sent in chunks. Each chunk of 1000 packets is separated by 1 second time delay.

100 1000 10000 50000

3.2 Testbed setup

The main components in the testbed are SIP clients, a SIP capable firewall from AlliedTelesis (AR450), SIP proxy server, and a malicious host that runs iFlood to generate flooding packets. A softphone, which is a SIP phone implemented in software, called X-Lite [5] is used to represent the SIP clients. Those clients are located in different domains and they are registered with a SIP proxy so that calls can be placed between them. The SIP proxy server used in the testbed is the Asterisk2 which is a Linux-based open source software implementation of a telephone private branch exchange (PBX). To test if the iFlood generated packets can bypass the detection or blocking of a firewall, a SIP capable firewall is placed between the SIP proxy and the untrusted network, as shown in Figure 6. Within the trusted domain, two legitimate SIP clients are registered to the proxy server with the client extension number 2001 and 2002. On the untrusted domain, an external legitimate SIP client, 2003, is also configured to utilize services through the proxy server.

110000 1100

Table 1, call setup delay with various numbers of attack packets go through. After a series of test floods, the threshold value was found to be approximately 11,000 packets, and this is a dynamic value, which may depend on traffic conditions and other factors. However, if the flood traffic is sent in chunk mode (eg, send a chunk of 10,000 invites at once, then stop for a second before sending the next chunk of 10,000), the firewall is not able to block the flooding traffic even though a DDoS is detected. Those chunks of flood packets overwhelmed the SIP proxy through the firewall, and significant DoS conditions, as described in previous attacks, were still achieved. Thus, chunk flooding has been found effective against this particular firewall and potentially some others as well. Furthermore, trying different combinations of chunk size and delay time can produce more subtle flood traffic, and they may influence the ability of firewalls or IDS to detect the attack. In general, increasing the delay time and decreasing the flood burst period makes the attack harder to detect, but can still be disruptive.

4. A proposed method to reduce the effect of the SIP flooding, by using stateless session authentication
Figure 6: SIP Testbed Setup with Firewall The other host on the untrusted domain represents an attacker, which runs iFlood to inject flood traffic into the network. The Asterisk PBX acts as a proxy server to forward request and respond between the two domains. All the client hosts, Asterisk PBX, and the attacker host are running on Intel Pentium 4 2.4GHz machines with 512MB RAM. There is a unique field (nonce) in the SIP 407 (Authentication Required) message which can be used to avoid replay attacks. A nonce is a server-specified data string which should be uniquely generated each time a 401(Unauthorized) or 407 response is made. Since most servers have a timer to mitigate replay attacks, the servers do not have to keep a record of the nonce. Thus, it is important for the firewall to performance the nonce checking. Figure 7 shows the call setup process with a firewall checking the nonce.

3.3 Test results

When the SIP testbed is subjected to a flooding attack its performance drops dramatically. If the number of spoofed SIP INVITE request packets exceeds 5000, the server is no longer able to serve a legit SIP request. Table 1 shows the call setup delay when the system is under flooding attacks in burst mode.

Security of VoIP: SIP Flooding and its Mitigation

207

Figure 7: Call setup process with firewall checking nonce Figure 8 illustrates how the INVITE message is handled in detail:

The firewall will then send back a 407/401 (AuthenticationRequired/Unauthorized) message back to the client, with the calculated nonce value and drop the session. After the client receive a 407/401 message, it resends an INVITE message with the same CallID, serverspecified nonce, username and password. When the firewall receives an INVITE with a nonce value, it will extract the nonce value, recalculate and compare it with the CallID and source IP address. If it matches, the request is passed to the server. For better attack mitigation, the cryptographic secret should be changed after a small period of time, e.g. 30 seconds. (time frame overlap for 2 successive secret should be allowed) This provides a stateless authentication as the firewall does not need to store multiple CallIDs and nonce entries in a database, and it can protect the server from Spoofed SIP flooding attacks.

5. Future work
Implement the nonce-checking function on a Linux firewall, and test the performance of this firewall. Try to make the attack tool cleverer, try to break the defense of the firewall.

6. ACKNOWLEDGMENTS
Assistance by Ray Hunt, Theuns Verwoerd, and Mark Mai are gratefully acknowledged. Figure 8: How an INVITE request is handled When an INVITE/REGISTER messages is received at port 5060, the firewall will check the SIP header, looking for a nonce value. If the incoming SIP request does not have a nonce value, the firewall generates a nonce value, which should be the result of a cryptographic secret function computed over the CallID and source IP address. This ensures that the nonce is unique for each session, as a new CallID is generated when a session is initiated. Figure 9 shows how the nonce is calculated.

7. REFERENCES
[1] The SIP protocol stack RFC 2543: SIP: Session Initiation Protocol; March 1999. [2] Hunter, P., 2002. VOIP the latest security concern: DoS attack the greatest threat. Network Security. Issue 11, page 5-7. [3] Wireshark, Gerald Combs, http://www.wireshark.org/ [4] HACK_LIBRARY, Endler D., Collier M., VoIP hacking exposed [5] X-Lite, CounterPath Corporation, http://www.counterpath.com/

Figure 9: The generation of the nonce