The Second International Conference on Emerging Security Information, Systems and Technologies Scalable Detection of SIP Fuzzing Attacks Eric Y. Chen Mitsutaka Itoh NTT Information Sharing Platform Laboratories {eric.chen, itoh.mitsutaka}@lab.ntt.co.jp Abstract rules. Section 6 evaluates this prototype in terms of detection effectiveness and processing performance. The VoIP technology has been increasingly popular and the number of its users has surged in the past 2. SIP Fuzzing Attacks years, because of its economical advantage over the traditional PSTN services. As a side effect, various The word fuzzing is conventionally used to refer to VoIP servers and clients are becoming attractive a black-box software testing method that provides targets of malicious attacks. This paper outlines the random data to the inputs of a program in an attempt to detection rules we have formulated to detect fuzzing fail the program and find bugs [3]. Bugs found using attacks, which attempt to crash a VoIP device by fuzz testing can be exploited by an attacker to crash or sending it invalid SIP messages. This paper also hijack the program. SIP fuzzing refers to such proposes a system architecture that utilizes multi-core technique designed to test programs or devices that processors in order to scale up the performance of implement SIP. detection using these rules. An alarming number of security incidents discovered through SIP fuzzing have been reported 1. Introduction over the past years. In 2003, the US-CERT issued a vulnerability note [4] based on a discovery by the Oulu The VoIP technology has been increasingly popular University Secure Programming Group (OUSPG). and the number of its users has surged in the past According to the note, a significant number of SIP years, because of its economical advantage over the implementations contain vulnerabilities that can be traditional PSTN services. However, this trend has triggered by malformed SIP messages. The impacts also made various VoIP devices attractive targets of range from unexpected system behaviour and denial of various attacks, since these devices are often deployed service to execution of arbitrary code by buffer on the Internet. VoIP Security Alliance (VOIPSA) [1] overflow. Despite of this warning, a number of was launched in 2005 to invite professionals in the vulnerabilities caused by malformed SIP messages are related fields to address the security issues surrounding still discovered later in products such as Cisco Firewall the VoIP technology. A white paper that enumerates Services Module [5], Apple Macintosh OS X most possible threats to VoIP has been made publicly VideoConference [6], Linksys VoIP router [7] and available by VOIPSA. Asterisk [8]. This paper focuses on attacks that involve sending An attack that exploits such bugs can be launched in malformed messages to a SIP device. In particular, we two ways. First, the attacker tries to identify the exact focus on detecting malformed SIP [2] messages, since implementation of the target device (vendor and SIP is rapidly replacing other VoIP signalling version etc) and then send known malformed packets protocols and becoming the de facto standard. In this specific to that implementation. Second, the attacker paper, we use the term SIP fuzzing attacks to refer to can flood the target with different patterns of this type of attacks. malformed packets (live fuzzing) and hope that at least The remainder of this paper is structured as follows. one of them would trigger a bug in the target. The first Section 2 briefly introduces SIP fuzzing attacks. way is obviously more efficient while the second way Section 3 surveys the related work that attempts to is powerful due to its brute-force nature. address this problem. Section 4 outlines the rules we use to detect SIP fuzzing attacks. Section 5 describes how we have implemented a prototype using these 978-0-7695-3329-2/08 $25.00 © 2008 IEEE 114 DOI 10.1109/SECURWARE.2008.11 Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 06:27 from IEEE Xplore. Restrictions apply. 3. Related Work 25 in RFC3261. For example, the Call-ID field is defined as the following in ABNF: Approaches to the SIP fuzzing attack problem can Call-ID=(“Call-ID”/”i”) HCOLON callid be generalized into two categories: prevention with callid = word [“@”word] extensive fuzz testing before product release, and detection of attacks against online devices. In other words, a SIP stack should expect a Call ID to PROTOS [9] and Asteroid [10] are two well-known be one string or two strings separated by a “@”. The tools that are freely available for the purposes of fuzz following illustrates two possible invalid structures. testing. Codenomicon [11] is the commercial version of PROTOS and provides 10 times more test cases. Valid While preventive measures using these tools are Call-ID: a84b4c7 perhaps the most effective way in eliminating software Invalid 1 Call-ID: a84b4c7@ bugs exploitable by a fuzzing attacker, not all Invalid 2 developers are willing to make the efforts due to the Call-ID: a84b4c7, a84b4c7, a84b4c7 additional costs incurred. Moreover, users can never be certain if the products they use are free from such Invalid structures can be easily detected as the vulnerabilities. grammar of SIP is concisely defined in RFC3261. Geneiatakis et al. [12] emphasised the importance Detection rules in this category can be derived from the of having a detection mechanism for SIP fuzzing ABNF. attacks. They explained the effectiveness of signature- based detection and suggested an example of 4.2 Oversized Field Values inspecting INVITE messages. However, this literature offers little details about how one should design the An overflow can occur in a well-formed SIP detection rules and implement a detection system for message when any field has a larger integer or a longer fuzzing attacks. string than normally expected. The following is a We agree with Geneiatakis’s work in general and simple example in which the invalid header field value see the importance of detecting SIP fuzzing attacks. has an oversized SIP version number. We had previously presented a preliminary report [18] (in Japanese) that describes our work-in-progress Valid toward designing rules to detect fuzzing attacks. This INVITE [email protected] SIP/2.0 paper outlines in detail the rules we have formulated Invalid and demonstrates the comprehensiveness of these rules INVITE [email protected] SIP/122214.0 by testing them against a commercial fuzzing tool used for software testing. This paper also proposes a system Exception handling of such messages can be architecture that is capable of utilizing modern multi- difficult since the upper limit or the maximum length core processors to scale up the detection performance. of each header field value is not always clearly defined in RFC3261. We have created rules in this category 4. Detection Rules based on a number of SIP devices we have worked with. However, rules in this category are implementation-specific and should be adjusted We propose to use the following five categories of accordingly. rules to detect malformed SIP packets. • Incorrect Grammar 4.3 Invalid Message or Field Name • Oversized Field Values • Invalid Message or Field Name Rules in this category simply look for method • Redundant or Repetitive Header Field names, response code or header field names not • Invalid Semantic defined in RFC3261. These include messages with In a paper of this length, we are unable to enumeration mismatched response codes. For example: all rules in each category. Instead, we describe in detail the general objectives of rules in each category. Valid SIP/2.0 200 OK 4.1. Incorrect Grammar Invalid SIP/2.0 200 Trying Rules in this category examine the grammatical structure of each SIP message as defined under Section 115 Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 06:27 from IEEE Xplore. Restrictions apply. Such messages are fairly easy to detect. However, it is 1. This prototype currently supports only SIP over commonly known that a number of so-called dialects UDP. exist in SIP and vendors sometimes extend SIP by Modules in a grey box are collectively executed as adding proprietary header fields no defined in an individual detection process. For each RFC3261. Rules in this category should be able to core/processor detected in the underlying platform, the incorporate such extensions. Parallel Processing Controller launches a detection process, or more precisely, a Packet Hander, which in 4.4 Missing or Repetitive Header Field our design is an entry object that initiates a new process. Modules in each grey box have a similar The following five headers must be present in any architecture as Snort [14], a popular open-source IDS SIP message: From, To, Via, Call-ID and CSeq. A SIP (intrusion detection system). message that does not contain any of these headers From the underlying libpcap [15] library, a Packet should be considered malformed. Handler retrieves packets that match some pre- It is also possible to fuzz a SIP device by sending a determined filter rule. Each Packet Handler should message with repetitive headers. We have created retrieve a different set of packets in order to effectively rules that look for repetitive headers, with the distribute the workload. Each packet received is then exception for headers such as Contact, Via, Call-Info passed to the Decoder that decodes layer-3 and layer-4 and Route, since multiple entries of these headers are headers and prepares the data in an expedient manner allowed. However, since the maximum number of for the detection engine. entries for these headers is not defined, the upper limit The detection engine implements all rules that we for each SIP device may be implementation-specific have defined in Section 4.