- Email: [email protected]
Collaborative scheme for VoIP traceback
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
available at www.sciencedirect.com
journal homepage: www.elsevier.com/locate/diin
Collaborative scheme for VoIP traceback Hsien-Ming Hsu a, Yeali S. Sun a, Meng Chang Chen a,b,* a b
Dept. of Information Management, National Taiwan University, Taipei, Taiwan Institute of Information Science, Academia Sinica, Taipei, Taiwan
article info
abstract
Article history:
While voice over IP (VoIP) services have brought many desirable communication features to
Received 16 September 2009
the general public, they have also become a medium through which criminals communi-
Received in revised form
cate and conduct illegal activities e.g., fraud and blackmail without being intercepted by
28 August 2010
law enforcement agencies (LEAs). Previous research on IP traceback focused on tracking IP
Accepted 25 October 2010
addresses on the network layer. The mechanisms developed thus far, however, require an inefficient and sometimes infeasibly large amount of router and network support.
Keywords:
In this paper, we propose a collaborative forensics mechanism that cooperates with related
VoIP
network operators (NWO) and service providers (SvP) in tracing back VoIP calls without
Traceback
depending on routers throughout the full trace path. We discuss the various kinds of
Collaborative forensics
attacks of VoIP services and the characteristics of VoIP service requests as they pertain to
Security
those attacks. Additionally, we propose a procedure for identifying forged header field
SIP
values (HFVs) on SIP requests, and introduce the concept of active forensics. This can lead to a reduction in the probability of important information being deleted by the time collaborative forensics is initiated, and thus assist law enforcement agencies in intercepting criminals. We also describe extended applications for traceback for attacks resulting in Distributed Denial of Service and those involving mobile phones. ª 2010 Elsevier Ltd. All rights reserved.
1.
Introduction
VoIP services have become widely available as the Internet has grown and may, one day; even replace the Public Switched Telephone Network (PSTN). While VoIP services have brought many desirable communication features to the general public, they have also become a medium through which criminals communicate and conduct illegal activities e.g., fraud and blackmail without being intercepted by law enforcement agencies (LEAs). As a SIP (Session Initiation Protocol) (Rosenberg et al., 2002) -based telephony system that uses packet-switched technology, VoIP shares the same major drawbacks as many services using Internet Protocol (IP) (Postel, 1981) including e-mail, particularly their vulnerability to security threats. In an effort to offer convenient and safe networking services, researchers have proposed various defensive
mechanisms over the past few years, including intrusion detection systems (IDSs) (Reynolds and Ghosal, 2003; Wu et al., 2004; Sengar et al., 2006a,b) and prevention mechanisms (PM) (Ferguson and Senie, 2000; Anat and Levy, 2005; Zhang et al., 2007; Ormazabal et al., 2008). These mechanisms however, are inadequate for today’s Internet. While they prevent illegal activity before or during criminal acts, both of these types of mechanisms require indications of the kind of attack taking place beforehand for proper security. Unfortunately, attacks are often conducted without any forewarning, so these defense mechanisms do not completely secure the network. Therefore, in light of the shortcomings of these aforementioned defensive mechanisms, we propose a new network forensics mechanisms (NFM) to enhance the detection and defensive ability of IPs to prevent attacks.
* Corresponding author. Institute of Information Science, Academia Sinica, Taipei 10617, Taiwan. E-mail addresses: [email protected] (H.-M. Hsu), [email protected] (Y.S. Sun), [email protected] (M.C. Chen). 1742-2876/$ e see front matter ª 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.diin.2010.10.003
186
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
NFMs serve as complements to the IDSs, PMs, and traceback mechanisms. While PMs prevent attacks, IDSs detect attacks, and traceback mechanisms trace the identities and geo-locations of the perpetrators, NFMs figure out how the attacks were conducted and recover the indications of the attacks. These attack indications may then be used by IDSs and PMs to enhance the detection and defense ability of the network. Research on traceback mechanisms thus far has only applied to the network layer and thus not the application layer, notably VoIP services. IP traceback mechanisms can be classified into three general types: probabilistic packet marking (e.g., Savage et al., 2000), router logging (e.g., Snoeren et al., 2001) and ICMP traceback (e.g., Bellovin, 2000). Each type of IP traceback mechanism has its own advantages, yet shares the same disadvantage: they must inefficiently cooperate with multiple routers and only work at the network layer. Support for traceback mechanisms, not only at the network layer but also at the application layer on VoIP services, is essential for emergency services such as “911” in the United States and “112” in parts of Europe. It is also essential for lawful interception, especially as the popularity of VoIP grows and more and more people use these services as a replacement for standard telephone service. This support at the application layer on VoIP services, as suggested by our previous work, comes in the way of NFMs. Serving as complements to IDSs, PMs, and traceback mechanisms, NFMs can correlate to related Local Events (LEvs)dthe required pieces of information collected from the NWO, SIP Registrar and SIP Proxy in an autonomous system (AS)dto perform traceback in the VoIP services environment without the support of routers on the trace path (Hsu et al., 2008). In addition, NFMs produce LEvs for potential forensic investigations without forging header field values (HFVs). Required cross layers are recorded using the components of SIP-based telephony. SIP-based VoIP telephony sets up, modifies, and terminates operations via SIP messages, which consist of a start-line, an optional message body, and one or more header fieldsdfields that play a big role in conducting forensic analysis. In this paper, we determine which header field values (HFVs) on request messages can be forged, and extract the required information to produce the characteristics for various requests. We also describe the required information recorded by the SIP Registrar and NWO (including Network Address Translation/Dynamic Host Configuration Protocol, NAT/ DHCP), which can be used to identify these forged HFVs by their characteristics and merge them with information from the SIP Registrar and NWO for forensic analysis. While conducting these memory consuming analyses, older information or information that has reached a certain expiration time limit is often deleted so that newer information may be stored. However, investigations by law enforcement agencies often are initiated after this information has been deleted. In order to prevent the deletion of potentially important information merely because of limited storage, we propose a collaborative forensics network that is based on the concept of active forensics and would reduce the probability of important information unnecessarily being lost. This network allows forensic analyses to be conducted on devices on which such analyses were previously unrealisticdmobile phones; furthermore, this network also allows for the
investigation of Distributed Denial of Service (DDoS) attacks in which multiple attackers target one victim simultaneously. The primary contributions of this paper are the follows: We discuss the characteristics of SIP-based requests and typical attacks for SIP-based VoIP services on which header field values can be forged. We explain how to identify the forged header field values and perform collaborative traceback by using the Local Events (LEvs) in single and multiple region collaborative forensics networks. We propose a distributed architecture for collaborative forensics without the information support of intermediate routers or marking on the packets/messages. We propose the concept of active forensics, which reduces the probability of potentially important information for investigation being deleted before law enforcement agencies can investigate. The remainder of this paper is organized as follows. Section 2 contains a review of related work. In Section 3, we describe the background of SIP-based VoIP services. In Section 4, we present the typical SIP-based signaling attacks and the characteristics of requests. In Section 5, we discuss how to identify the forged header field values by the components of SIP proxy and NWO. Then, in Section 6, we discuss the collaborative forensics of traceback on SIP-based VoIP service. Finally, in Section 7 we summarize our findings and indicate areas for future research.
2.
Related work
Traceback mechanisms at the IP layer can be classified into three types: probabilistic packet marking, router logging, and ICMP traceback. In probabilistic packet marking IP traceback (Savage et al., 2000; Song and Perrig, 2001; Dean et al., 2002; Yaar et al., 2003, 2005, 2006), routers randomly mark packets that pass through them with their entire address or a part of their address at a fixed probability. Systems that have been attacked can reconstruct the full address of the attacker using traceback mechanisms. These mechanisms traceback the attacker using various parts of the received address. In router logging IP traceback (Snoeren et al., 2001; Li et al., 2004), since routers keep a record of every packet that passes through them, router logging IP traceback mechanisms check these router logs and relay queries to upstream routers. After the course of this relay is complete, the packet’s true origin can be identified. Router logging IP traceback, however, has a major drawback e high storage demands. This drawback may be solved by using a Bloom Filter (Bloom, 1970). ICMP message traceback (Bellovin, 2000; Makin et al., 2001; Kim et al., 2005) learns the path that packets take through the Internet with the help of the routers along the path emitting ICMP messages at a probability of about 1:20,000, and identifies the correct path to the destination. Some IP traceback mechanisms combine two of the aforementioned approaches (Gong and Sarac, 2005). While these IP traceback mechanisms each have their own advantageous features, they all share the same two shortcomings that we aim to overcome in our mechanism. First, when packet information is recorded and relayed to routers
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
(or the ICMP messages are relayed in the case of ICMP traceback), each mechanism requires the cooperation of a slew of routers along the full trace path. Secondly, none of these mechanisms are able to traceback on the application layer and thus they do not work on VoIP services. Using recorded information on application, network and physical layers, our mechanism traces attackers’ identities and geo-locations and works on SIP-based VoIP services. In designing our technique, we drew upon the works of Shanmugasundaram et al. and Tang et al. on network forensics, who each proposed good forensics mechanisms (Shanmugasundaram et al., 2003; Tang and Daniels, 2005). Shanmugasundaram et al. proposed a distributed forensics network: ForNet. ForNet can automatically collect, store, and exchange the attack attributes by proxies but its data filter is based on a lightweight IDS (Shanmugasundaram et al., 2003). Since many attacks on today’s Internet cannot be detected by IDS, ForNet has a high probability of false-negatives. Tang et al. proposed a simpler framework for distributed forensics networks, but this framework lacks the capacity to identify useful network events and thus has to capture and store all the packets on the network for forensics analysis (Tang and Daniels, 2005). Therefore, despite Bloom filter processing, long-term data storage for the purposes of later investigation remains a big program. Our collaborative forensics mechanism not only automatically collects Local Events (LEvs) and shares this information with cooperating units, it also consults other systems for decisions and spares long-term storage concerns via active forensics. In our mechanism, the different parts of each LEv are linked to build a complete picture of an incident that can be used as evidence in a court of law. In addition, our mechanism can consult a panel of experts or other systems to determine what should be done. The Access Local Event Entity (ALEE) triggers active forensics procedures and thereby avoids the need to store information until law enforcement agencies have time to look at it.
3.
Fig. 1 e The SIP-based IP telephony. VoIP service providers, respectively. Before calling Bob, caller Alice needs to be authenticated by a SIP authentication mechanism and register through a REGISTER request with the Pacific SIP Registrar, shown as Fig. 2(a1ea4). Caller Alice first sends an INVITE request to the Atlantic SIP proxy. This proxy consults the location service database to find out the current location of callee Bob, and forwards the INVITE request to the Pacific SIP proxy and the callee to complete a three-way handshake (INVITE, OK, ACK) that establishes the SIP session, shown in Fig. 2(b1eb14). After exchanging a set of parameters through the Session Description Protocol (Handley and Jacobson, 1998) in the SIP message body, the bi-direction of the Real-time Transport Protocol (RTP) (Schulzrinne et al., 2003) based channel is established. Either caller Alice or callee Bob can terminate this session by sending a BYE request, shown in Fig. 2(c1ec6). The detail signaling of the SIP protocol is described in (Rosenberg et al., 2002).
SIP background
In this paper, we only consider SIP-based IP telephony as opposed to H.323 or PSTN telephony. Here, we provide a brief explanation of SIP signaling and how it works, describe the weaknesses of the SIP authentication mechanism, and discuss the required information of the header field values (HFVs) on request messages that NWO/SvP log collaboratively.
3.1.
SIP-based signaling
SIP is an application layer control protocol designed to establish, modify, and terminate multimedia sessions (conferences) and is used in such programs as SIP-based VoIP telephony services. The architecture of SIP-based IP telephony is shown in Fig. 1. Here, the registrars and proxies represent SIP servers. Registrars are responsible for registration, after which proxy servers relay the SIP-based signaling to the callee’s address and offer the VoIP service. In order to better illustrate how SIP signaling works, let us consider a hypothetical example involving caller “Alice” and callee “Bob”, who belong to the “Atlantic” and “Pacific” SIP
187
Fig. 2 e SIP signaling flow.
188
3.2.
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
Weaknesses of SIP services
For SIP-based VoIP services, authentication is executed with registration. Registration creates bindings in a location service for a particular domain that associates an URI address with one or more contact addresses. When the user agent wants to make or receive a call, he or she has to add or refresh bindings whenever the most recent registration expires. Based on this construction, SIP-based VoIP services have two major weaknesses that make them vulnerable to attack. First, they have a challenge-based authentication mechanism. Challenge-based mechanisms allow users to use a system continuously without further authentication within a set registration time period. Users only have to re-authenticate if the server suspects they are using the system without permission, and re-authentication then “challenges” the suspicious users. This type of authentication mechanism allows attackers to fairly often use the service for a long time without having to re-authenticate. If attackers had to reauthenticate more often, it would make it more difficult for them to carry out crimes. Secondly, SIP-based VoIP services allow users and servers to fill out or modify the information in SIP messages. Attackers readily exploit this weakness by forging messages when attacking VoIP devices, and commit such crimes as fraud, blackmail and DoS attacks.
3.3. The required information that NWO/SvP collaboratively logs The architecture of SIP-based IP telephony is shown in Fig. 1. The Registrars and Proxies are the SIP servers. Registrars are responsible for registration, after which the proxy servers relay the signaling to the callee’s address and commence the service. Although the clients can send malicious or forged messages, they can only forge the information on messages or packets. Some important personal information, including user account information, cannot be modified by users. User accounts are stored by the NWO and SvP, and are used to log-in for services and bill clients for call duration and type. Therefore, proper forensics investigations should extract the required information (information required to complete the three-way handshake), to form clues as to what attack took place. Tables 1 and 2 list the required information that the SIP Registrar Server and NWO (NAT/DHCP) require for traceback (Hsu et al., 2008).
4. Typical SIP-based signaling attacks and the characteristics of various requests In this section, we describe typical SIP-based signaling attacks, discuss which header field values (HFVs) on request messages are forged based on the type of attack, and propose extracting the required information for producing the characteristics for the various requests (e.g., INVITE, REGISTER).
4.1.
Typical SIP-based signaling attacks
SIP messages are either requests (REGISTER, INVITE, BYE, CANCEL, ACK and OPTION) from a client to a server, or responses from a server to a client. Table 3 shows the typical
Table 1 e The information recorded By SIP registrar server. Attributes Caller’s account Caller’s public IP/port Timestamp and expiration Caller’s account Caller’s public IP/port
Description Caller’s account of network-based phone Acquired from the caller’s registration message The time when register expires Caller’s account of network-based phone Acquired from the caller’s registration message
SIP-based signaling attacks using REGISTER, INVITE, CANCEL and BYE requests. Attackers manipulate these requests by forging the header field values (HFVs) on different requests depending on what the attacker wishes to achieve. These attacks may be classified into three groups: forged REGISTER, INVITE, and CANCEL/BYE requests.
4.1.1.
REGISTER requests
In the following two attacks, the attacker sends a forged REGISTER request to the SIP Registrar.
4.1.1.1. De-register attack. De-register attacks prevent the victim from receiving calls. In this attack, the attacker requests that the SIP Registrar remove the binding address of the victim. The attacker sends a spoofing message that sets the expiration interval to zero for that contact address through a REGISTER request (Anat et al., 2006). 4.1.1.2. Registration hijack attack. Registration hijack attacks direct all requests sent to the victim to the attacker’s device. The attacker then usually de-registers all existing contacts for that URI and registers their own device as the appropriate contact address (Rosenberg et al., 2002). 4.1.2.
INVITE requests
In the following four attacks, the attacker sends spoofing INVITE requests to the SIP proxy, which are then forwarded to the victim.
4.1.2.1. Fraud & blackmail. The attacker establishes a SIP session with the victim to scam or blackmail the victim. Once the three-way handshake between attacker and victim is completed, the attacker talks with victim. Attackers may send INVITE requests with anonymous or forged header field values in the “From” section.
Table 2 e The information recorded by NWO (NAT/DHCP). Attributes Caller’s account Caller’s private IP/port Caller’s public IP/port Caller’s public media IP/port Time: call Time: hang-up
Description User’s account of network-based phone The private IP/port with NAT The public IP/port assigned to NAT/DHCP The public IP/port assigned to NAT/DHCP The time when called by private IP The time when call by private IP is interrupted
189
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
4.1.3.
Table 3 e Typical SIP-based signaling attacks. Attacks
Requests
De-register Registration hijack Fraud & blackmail DoS e INVITE flooding DoS e NO ACK Call hijack BYE e session teardown CANCEL e session teardown
REGISTER REGISTER INVITE/ACK/BYE INVITE INVITE Re-INVITE BYE CANCEL
CANCEL and BYE requests
The attacker uses an SIP message to terminate an existing call.
Responses
4.1.3.1. BYE session teardown attack. BYE session teardown
OK OK OK NR OK 3xx/OK OK OK
attacks terminate ongoing calls. The attacker impersonates the caller (or callee) and sends a spoofing BYE request to terminate his session.
4.1.3.2. CANCEL session teardown attack. CANCEL session teardown attacks terminate ongoing calls. In contrast to other attacks that terminate ongoing calls, the attacker impersonates the caller (or callee) and sends a spoofing CANCEL request to terminate this session.
“NR” denotes no response. “x” denotes arbitrary number
4.1.2.2. INVITE request flooding attack. INVITE request flooding attacks prevent victims from receiving calls. IP phones can only place a limited number of calls at the same time. The attacker sends lots of INVITE requests such that they overwhelm the victim’s computer.
4.2. The characteristics of the various requests on SIPbased VoIP service The required information may be extracted using the various requests and responses on the SIP proxy to form the characteristics of requests, which are required not only to run operations but also identify attackers, on the application layer. Fig. 3 lists this information. SIP Proxy Servers record certain pieces of information to form the various characteristics of calls, including the sought-after answers to various special questionsdwho, whom, when, where, and what. Based on the request and response (R/R) messages that attackers forge, attacks may be classified into three types: REGISTER, INVITE/OK/BYE (BIO) and BYE/CANCEL (B/C).
4.1.2.3. NO-ACK denial of service attack. Normally, SIP sessions are established after the three-way handshake is completed. However, in this attack, the attacker does not send the ACK request when he/she receives the OK response sent by the victim, after the victim received the INVITE request and sent the OK response to the attacker. The victim then waits for a long period of time for the ACK request. However, since system resources are limited and can only support a few pending requests, the attacker sends multiple INVITE requests but does not send an ACK request, in order to prevent the victim from receiving calls.
4.2.1.
The characteristics of REGISTER
SIP Registrars assign dynamic IP addresses to User Agents. REGISTER requests register one or more contacts per User Agent. Seven HFVs, as shown in Fig. 3(a), compose the characteristics of REGISTER requests on SIP-based VoIP services. Registration Hijack and De-register attacks prevent victims from receiving incoming calls by reconfiguring
4.1.2.4. Call hijack attack. Call hijack attacks hijack an already ongoing call. The attacker impersonates the victim and sends a spoofing response with the response code 3xx to the caller. The attacker then sends a re-INVITE request to invite the victim to establish the session again.
True Header Field Values. Forged Header Field Values.
REG: REGISTER Service Type: REG
a
Time Stamp + Expires
Registrar’s IP
Caller’s Account (FROM)
Caller’s Public IP/Port
Callee’s Account (TO)
Callee’s Public IP/Port (Contact)
The Characteristic of Register with FORGED HFVs
INV: INVITE Service Type: INV
b
Time (Answer: Hang-up)
Caller’s Account (FROM)
Caller’s Signaling IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Callee’s Account (TO)
Callee’s Signaling IP/Port
The Characteristic of BIO with FORGED HFVs
CNL: Cancel Service Type: BYE/CNL
c
Caller’s Time Account (received) (FROM)
Caller’s Signaling IP/Port
Caller’s Private IP/Port
Callee’s Account (TO)
Callee’s Signaling IP/Port
The Characteristic of BYE/CANCEL with FORGED HFVs
Fig. 3 e The characteristics of requests on SIP-based VoIP services.
Callee’s Media IP/Port
190
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
registration. Attackers impersonate the victims and send REGISTER requests that modify the Contact header field values or forge De-register requests that set the expiration interval to “0” for that contact address in the REGISTER request, thereby disabling victims from receiving calls without their knowledge. Therefore, when attackers attack in these ways, as shown in Fig. 3(a), they forge the following header values: the FROM HFV and Caller’s Contact HFVs (Caller’s Public IP/Port).
In sum, specific HFV values on the R/Rs of the attacker are likely to be forged depending on which of the three types of characteristics of a call were manipulated i.e. REGISTER, BYE/ INVITE/OK (BIO) or BYE/CANCEL (B/C) R/Rs, but the victim’s HFVs should remain genuine in spite of attack. Forensics analysis thus aims to identify the forged HFVs and merge this information with the information from the NWO and the home SIP Registrar
4.2.2.
5.
The characteristics of BYE/INVITE/OK (BIO)
User agent can make calls (send INVITE request) without further authentication before the expiration time limit set by the initial REGISTER request. Nine HFVs form the characteristics of BIO on SIP-based VoIP services based on the HFVs of BIO R/Rs, as shown in Fig. 3(b). Attackers use BIO R/Rs to commit fraud and blackmail via anonymous calls to victims. In such cases, the HFVs on INVITE/ACK remain genuine but the FROM (attacker’s account) HFV is forged. Attackers use BIO R/Rs to commit DoS attacks (INVITE Flooding, INVITE without ACK) and Call Hijacks in which they block the victims from access to VoIP services. Attackers manipulate the requests to conceal their identities. Therefore, the FROM (caller’s account), and Caller’s Contact (signaling IP/ Port) HFVs and media IP/Port are typically forged, as shown in Fig. 3(b).
4.2.3.
The characteristics of BYE/CANCEL
BYE and CANCEL attacks, which terminate victims’ VoIP services prematurely, are unique in that attackers do not expect to receive responses from victims. With the exception of two HFVs, FROM (Caller’s account) and Caller’s Contact (signaling IP/Port) HFVs, are left forged, as shown in Fig. 3(c). Based on the HFVs on BYE and CANCEL requests, seven HFVs of B/C requests form the characteristics of BYE/CANCEL requests on SIP-based VoIP services. BYE requests are used to terminate sessions, and CANCEL requests are used to cancel any previous requests sent by client. So, unlike other kinds of attacks, only two out of seven HFVs, FROM and Caller’s Contact (signaling IP/Port) HFVs, are forged in BYE and CANCEL attacks since attackers are not concerned with response characteristics.
Identifying the forged header fields values
Forensics, in the general sense, aims to figure out how crimes were committed and reveal the identities and geo-locations of the perpetrators of those crimes. In order to solve and prevent future crimes involving VoIP services, proper forensics is dependent on Network Operators, Access Providers and Service Providers (NWO/AP/SvP) collaboratively recording the identities of parties using these services and other information required for identifying geo-locations. Forged HFVs of characteristics on SIP-based VoIP services must first be identified and then merged with information from SIP Registrars and NWOs for forensics analysis. As mentioned in the previous section, before sending attack requests, attackers have to first register with a home SIP Registrar using their true identity and public IP/Port. NWOs and SIP Registrars should record this information. These records may then be collected, extracted, and used to identify forged information on the characteristics of future requests and then merged with the characteristics of requests into a Local Event (LEv) that can be represented as an XML message and reported using the SEAL Protocol by an administrator, as shown in Table 4. The autonomous system number (ASN) of the autonomous system (AS) must be inserted at the beginning of every LEv for LEA classification and storage purposes, shown in Fig. 4 as well.
6. Collaborative forensics for SIP-based VoIP services In this section, we first present the key components of our design, outline the particulars of the Collaborative Forensics
Table 4 e Identifying forged header field values using the required information. The characteristics of requests on SIP proxy REGISTER Time stamp þ expires Registrar’s IP Caller’s account (FROM) Caller’s public IP/port
Callee’s account (TO) Callee’s public IP/port (contact)
Forged information can be identified by the required information recorded on
INVITE/OK/BYE Time (answer: hang-up)
BYE/CANCEL Time (received)
NWO Time (Answer: hang-up)
SvP (SIP registrar) Time stamp þ expires
Caller’s account (FROM) Caller’s signaling IP/port
Caller’s account (FROM) Caller’s signaling IP/port
Account Caller’s public IP/port
Account (FROM) Caller’s public IP/port (contact)
Caller’s media IP/port Caller’s private IP/port Callee’s account (TO) Callee’s signaling IP/Port
Caller’s private IP/port Callee’s account (TO) Callee’s signaling IP/port
Callee’s media IP/port
Caller’s media IP/port Caller’s private IP/port Account (TO) Callee’s public IP/port (contact)
191
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
a
NWO
Time (Call: Hang-up)
Caller’s Account
Caller’s Public IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
SvP (SIP Registrar)
Time Stamp + Expires
Caller’s Account (FROM)
Caller’s Public IP/Port (Contact)
Callee’s Account (TO)
Callee’s Public IP/Port (Contact)
Time Stamp + Expires
Account (FROM)
Caller’s Public IP/Port
Service Type: SIP-REG
SIP Proxy
Callee’s Public IP/Port (Contact)
Callee’s Account (TO)
Registrar’s Public IP
The Characteristic of REGISTER on SIP-based VoIP services Identify & Merge
REG: REGISTER $: forged flag
Local Event
b
NWO SvP (SIP Registrar)
Service Type: SIP-INV
SIP Proxy
Time Stamp + Expires
Service Type: SIPREG-$
ASN
Registrar’s Public IP
True Header Field Values. Forged Header Field Values. Caller’s Account (FROM)
Caller’s Public IP/Port
Time (Call: Hang-up)
Caller’s Account
Caller’s Public IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Time Stamp + Expires
Caller’s Account (FROM)
Caller’s Public IP/Port (Contact)
Account (TO)
Callee’s Public IP/Port (Contact)
Time (Answer : Hang-up)
Caller’s Account (From)
Caller’s Signaling IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Callee’s Account (TO)
Callee’s Account (To)
Callee’s Public IP/Port
Callee’s Signaling IP/Port
Callee’s Media IP/Port
The Characteristic of BIO for SIP-based VoIP services Identify & Merge
INV: INVITE $: forged flag
Local Event
ASN
Service Type: SIP-INV-$
c NWO SvP (SIP Registrar)
SIP Proxy
Service Type: SIP-B/C
Time (Answer : Hang-up)
Caller’s Account (From)
True Header Field Values. Forged Header Field Values.
Caller’s Signaling IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Callee’s Account (To)
Time (Call: Hang-up)
Caller’s Account
Caller’s Public IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Time Stamp + Expires
Caller’s Account (FROM)
Caller’s Public IP/Port (Contact)
Account (TO)
Callee’s Public IP/Port (Contact)
Time (received)
Caller’s Account (From)
Caller’s Signaling IP/Port
Caller’s Private IP/Port
Callee’s Account (To)
Callee’s Signalin g IP/Port
Callee’s Media IP/Port
Callee’s Signaling IP/Port
The Characteristic of BYE/CANCEL for SIP-based VoIP services
B/C: BYE/Cancel $: forged flag
Local Event
ASN
Service Type: SIP-B/C-$
Time (received)
Identify & Merge
Caller’s Account (From)
True Header Field Values. Forged Header Field Values. Caller’s Signaling IP/Port
Caller’s Private IP/Port
Callee’s Account (To)
Callee’s Signaling IP/Port
Fig. 4 e (a) Identifying forged field values on the characteristics of REGISTER requests. (b) Identifying forged field values on the characteristics of INVITE/OK/BYE requests. (c) Identifying forged field values on the characteristics of CANCEL/BYE requests.
Network, and then describe the procedure that comprising units of the Collaborative Forensics Network follow for SIPbased VoIP services. Finally, we discuss extending the usage of this network for traceback on Distributed Denial of Service and mobile phones.
6.1.
The collaborative forensics center, SKYEYE
NWOs and SvPs may not want to share certain pieces of information e.g., security intelligence and forensic information with other NWOs or SvPs for a variety of reasons,
192
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
including privacy concerns, commercial competition, company policies, culture differences, and implementation differences. NWOs and SvPs may be more inclined to share this information if the exchange of this information were supervised by an independent authority. This independent authority would have a mechanism that would aggregate, integrate, and correlate local information in the form of LEvs from operators and carry out traceback tasks without compromising any information participating NWOs and SvPs would not want to disclose. We have designed a collaborative framework that can serve as this mechanism for an independent authority, as shown in Fig. 5, that we call the SKYEYE (Hsu et al., 2008). The Collaborative Forensics Mechanism 1) Local events (LEvs) Local Event data are collected from the NWO (NAT/ DHCP), SIP Registrar and SIP Proxy in an AS by ALEE through the SKYEYE ALEE (SEAL) Protocol. During a VoIP call, the ALEE makes two copies of the Local Event, and stores one of them in the local operator’s (AS’) database for backup and the other is sent to SKYEYE for forensic analysis. 2) Access local event entity (ALEE) ALEE is the AS interface that connects and communicates with SKYEYE, which is independent of the AS realm. For each SIP-based phone call, the ALEE automatically collects the required information about the caller and callee from the NWO (NAT/DHCP), SIP Registrar, and SIP Proxy in the operating network (AS) and merges these pieces of information to produce a Local Event in XML format. 3) The flexible SKYEYE ALEE (SEAL) protocol The SEAL protocol is simple in design, and merely transports Local Events in XML format between ALEE and SKYEYE, so it can easily accommodate different access network technologies i.e. HTTP and Web servers. 4) The SKYEYE The SKYEYE is the kernel of the collaborative forensic network in that it executes all collaborative investigations. It is comprised of the following modules: aggregation, event
Internet
NWO/AP/SvP
4. Collaborative with CFRC
5a. Info. sharing FRTs 5b.Task dispatch 3. Query/
Existing Response Systems
correlation, event information mining, integration, and expertise repository. The details of the SKYEYE and the procedure outlining how its comprising units interact are described in (Hsu et al., 2008).
6.2.
The collaborative forensics work
The Collaborative Forensics Network, as it pertains to VoIP traceback, comprises multiple independent administrative Region Forensics Centers. These RFCs would act as independent administrative authorities, each being composed of one or more ASs on the Internet, as shown in Fig. 6. When User Agents send SIP requests, the ALEE produces LEvs. Traceback to a particular user agent would only require the LEvs of the callee and caller, making LEvs of the intermediate ASs unnecessary. The LEvs from the caller and callee may be checked to build a complete picture of any incident, and this information could be used as evidence in a court of law. Correlating related LEvs, from the caller and callee, help to determine how a network incident e.g., attack occurred and provides such details as the origin, the method(s) used, and identities of the perpetrators.
6.2.1.
Collaborative forensics work of SKYEYEs
In this section, we briefly describe the procedure that comprising units follow when conducting collaborative forensics, as shown in Fig. 5.
6.2.1.1. Step 1. The LEA sends commands to SKYEYE. Each command has two essential elements: the callee’s account and the calling time-parameter. The former serves as the starting point for traceback, while the latter serves as an identifier for the call. 6.2.1.2. Step 2. SKYEYE checks its Event Data Warehouse and sends a request to ALEE for a Local Event (LEv) search using the callee’s account and calling time-parameter.
6.2.1.3. Step 3. SKYEYE may have to consult the domain experts by way of hosting a virtual panel to determine if any information is missing or confusing, and request data or evidence from other systems. The results of this process are then relayed back to SKYEYE’s Control and Decision making Module to decide whether to take action. Collaborative Forensics Region Centers (CFRCs) Share information and Local Events with each other
1. CMD
LEAs
SKYEYE
CFRC-2
CFRC-1
6. Report
AS
2. SEAL database
AS
ALEE
VoIP Network (AS)
AS
AS
SKYEYE
AS
AS SKYEYE
AS AS
AS
AS AS
AS
SEAL: Sky Eye ALee protocol
Fig. 5 e Procedure for collaborative forensics with cooperating units and other region collaborative forensics centers.
Fig. 6 e The primary CFRC (pCFRC), the caller located, needs to communicate with the secondary CFRC (sCFRC) and request the LEv send from the callee’s AS to perform VoIP traceback.
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
193
Fig. 7 e An example of interpretation for fraud local events: A (attacker) attacks V (victim) by the forged account and public IP/port of B.
6.2.1.4. Step 4. When the ASs of the caller and callee are located in the same Collaborative Forensics Region (CFR), the two LEvs, sent by caller and callee’s ASs, are sent to the same CFR Center (CFRC) to execute VoIP traceback. Since caller and callee ASs are located in different CFR most of the time, the CFRCs receive only one LEv from either the caller or callee. In these cases, the primary CFRC (pCFRC), located near the caller, needs to communicate with the secondary CFRC (sCFRC) and request that the LEv of the callee be sent from the callee’s AS in order to perform forensics.
investigation. This is all done without the command of LEAs. Based on the information within the LEvs, the SKYEYE of pCFRC performs a preliminary VoIP traceback and interprets the incident. As shown in Fig. 7, for example, an interpretation of fraud may be assigned to both LEvs using an “A” for attacker and “V” for victim depending on which party’s account information and public IP/Port of “B” were forged. Collaborative forensics starts when law enforcement agencies (LEA) send commands to the SKYEYE of the CFR of the victim. Active forensics and collaborate forensics, when combined, serve as the best method for handling VoIP attacks.
6.2.1.5. Step 5. The LEv information is then shared with agencies such as the NWOs or SvPs to alert them about possible criminal activity, and these agencies can then report to Fast Response Teams (FRTs).
6.2.1.6. Step 6. All decisions made and the results of the incident are then relayed to the LEA.
6.2.2.
The trigger for active forensics
Even now, law enforcement agencies (LEA) often take quite some time to start collaborative forensics in networks/ computer systems. The stored data that they require for proper investigation often expires and has been deleted by the time they wish to have access to it. This is referred to as “passive forensics”, as it does not actively use networks/computer systems. We propose using active forensics in computer systems in order to eliminate the problems of data storage and time lag in investigation. Active forensics requires that systems share security information and send alerts to cooperating units when attacks seem to have occurred. Collaborative forensics can then be executed long before the stored data has expired and been deleted. Active forensics is much more efficient than passive forensics against criminal activities. Active forensics is triggered when ALEE detects that one of the caller’s HFVs, either their account or public IP/Port, have been forged. ALEE then flags the LEv with $ and sends it to the SKYEYE of the CFR of the caller or the pCFRC. When this SKYEYE receives the LEv with the forged flag, $, it then begins the active forensics procedure. The SKYEYE of the pCFRC communicates with the SKYEYE of the sCFRC and requests that the callee’s LEv be relayed back for subsequent forensics
6.3. Forensics investigation for distributed denial of service and mobile phone When it comes to attacks on VoIP services resulting in a distributed denial of service or attacks involving mobile phones, forensic practices in current use are completely ineffective. However, the methods proposed in this paper, active and collaborative forensics, can handle these attacks.
6.3.1.
Investigation for distributed denial of service (DDoS)
Distributed denials of service (DDoS) attacks are one other kind of denial of service attack wherein victims are attacked by several attackers simultaneously. In DDoS attacks, requests for the callee’s account and calling time-parameter receive multiple LEvs. Reconstructing a DDoS incident and performing traceback can be performed using the LEvs of the victim.
6.3.2.
Investigation of mobile phone VoIP service attacks
As mobile devices are moved across Access Point (AP) regions, APs execute handoff processes wherein the public IPs for the mobile devices are changed. Collaborative networks can be set up such that SKYEYEs receive LEvs from multiple ASs of APs and are reconstructed.
7.
Conclusion and future work
In this paper, we described the weaknesses of SIP Authentication mechanisms, weaknesses that attackers exploit when attacking victims and that provide clues as to how to conduct
194
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
proper forensics after attack. Attackers forge header field values (HFVs) on request messages depending on which kind of attack they wish to conduct. SIP Registrars and NWOs (including NAT/DHCP) record the required information contained within the various Requests as Characteristics for each SIP session. This required information may be extracted and used to identify forged HFVs on the Characteristics after it is merged with the information from SIP Registrars and NWOs. In this paper, we also presented the key components of our design and outlined a Collaborative Forensics network based on the concept of active forensics, a strategy which would reduce the probability of information essential to proper forensic investigation being deleted. Collaborative Forensics for SIP-based VoIP services may be extended to traceback on Distributed Denial of Service attacks and Mobile phone. Further research is necessary on other kinds of attacks, anonymous VoIP services, and data mining before our mechanism and proposed collaborative forensics can be broadly applied. Despite our successes in handling typical SIPbased signaling attacks, many SIP-based signaling attacks have not been considered, including malicious acts without SIP proxy services. Some VoIP services (e.g., skype) offer anonymous service to clients, services in which clients may sign on without use of a user name, and these must be considered in network forensics. The details of data mining for collaborative forensics mechanisms on multiple layers will help our mechanism become more versatile.
Acknowledgement This work was supported in part by the NSC of Taiwan under grant NSC98-2221-E-001-005-MY3.
references
Anat B-B, Levy H. In: Spoofing prevent method; 2005. Proc. of IEEE INFORCOM. Anat B-B, Ronit H-B, Jussi K. Unregister attacks in SIP; 2006. p. 32e37. Proc. of the 2nd IEEE Workshop on Secure Network Protocols. Bloom BH. Space/time trade-offs in hash coding with allowable errors. Communication of ACM July 1970;13:422e6. Bellovin S. ICMP traceback messages; March 2000. Internet draft: Draft-bellovin-itrace-00.txt. Dean D, Franklin M, Stubblefield A. An algebraic approach to IP traceback. ACM Transactions on Information and System Security; 2002. Ferguson P, Senie D. Network ingress filtering: defeating denial of service attacks which employ ip source address spoofing,” RFC 2827. IETF Network Working Group. Available from: http:// www.ietf.org/rfc/rfc2827.txt; May 2000. Gong C, Sarac K. IP traceback based on packet marking and logging. IEEE Communications Magazine May 2005;2: 1043e7. Handley M, Jacobson V. SDP: session description protocol,” RFC 2327. IETF Network Working Group. Available from: http:// www.ietf.org/rfc/rfc2327.txt; 1998. Hsu H-M, Sun YS, Chen M-C. Proc. of the IEEE ISI. In: A collaborative forensics framework for VoIP services in multi-
network environments, vol. 5075; 2008. p. 260e71. PAISI, PACCF, and SOCO international workshops on Intelligence and Security Informatics. Kim E, Massey D, Ray I. Global Internet routing forensics: validation of BGP paths using ICMP traceback, vol. 194. IFIP International Federation for Information Processing. Available from: http://www.springerlink.com/content/ 6120jm8530713408; 2005. p. 165e176. Li J, Sung M, Xu J, Li L. In: Large-scale IP traceback in highspeed internet: practical techniques and theoretical foundation; 2004. p. 115e129. Proc. of IEEE Symposium on Security and Privacy. Mankin A, Massey D, Wu C-L, Wu SF, Zhang L. On design and evaluation of ‘intention-driven’ ICMP traceback; 2001 p. 159e165. Proc. 10th International Conference on Computer Communications and Networks. Ormazabal G, Nagpal S, Yardeni E, Schulzrinne H. In: Secure SIP: a scalable prevention mechanism for DoS attacks on SIP based VoIP systems; 2008. Proc. of the 2nd international conference on Principles, systems and applications of IP telecommunications. Postel j. “IP: internet protocol,” RFC 0791. IETF Network Work Group. Available from: http://www.ietf.org/rfc/rfc0791.txt; 1981. Rosenberg J, Schulzrinne H, Camarillo G, Johnston A, Peterson J, Sparks R, Handley M, Schooler E. “SIP: session initiation protocol (SIP),” RFC 3261. IETF Network Working Group. Available from: http://www.ietf.org/rfc/rfc3261.txt; 2002. Reynolds B, Ghosal D. In: Secure IP telephony using multi-layered protection; February 2003. Proc. of the Network and Distributed System Security Symposium (NDSS). Savage S, Wetherall D, Karlin A, Anderson T. In: Practical network support for IP traceback; 2000. p. 295e306. Proc. of the ACM SIGCOMM Conference. Snoeren AC, Partridge C, Sanchez LA, Jones CE, Tchakountio F, Kent ST, Strayer WT. In: Hash-based IP traceback; 2001. p. 3e14. Proc. ACM SIGCOMM. Song D, Perrig A. In: Advanced and authenticated marking schemes for IP traceback; 2001. Proc. of IEEE INFOCOM. Shanmugasundaram K, Memon N, Savant A, Bronnimann H. ForNet: a distributed forensics network. St. Petersburg, Russia: The Second International Workshop on Mathematical Methods, Models and Architectures for Computer Networks Security. Available from: http://isis.poly.edu/projects/fornet/ docs/talks/mmm-acns-2003.pdf; 2003. Schulzrinne H, Casner S, Frederick R, Jacobson V. “RTP: a transport protocol for real-time applications,” RFC 3550. IETF Network Working Group. Available from: http://www.ietf.org/ rfc/rfc3550.txt; 2003. Sengar H, Wijesekera D, Wang H, Jajodia S. VoIP intrusion detection through inter-acting protocol state machines. IEEE Dependable Systems and Networks Conference; 2006a. p. 393e402. Sengar H, Wijesekera D, Wang H, Jajodia S. Fast detection of denialof-service attacks on IP telephony. 14th IEEE Internation Workshop on Quality of Service; 2006b. p. 199e208. Tang Y, Daniels TE. In: A simple framework for distributed forensics; 2005. p. 163e9. Proc. of the 25th IEEE international Conference on Distributed Computing Systems Workshops. Wu Y-S, Bagchi S, Garg S, Singh N, Tsai T. In: SCIDIVE: a stateful and cross protocol intrusion detection architecture for voiceover-IP environments. IEEE Dependable Systems and Networks Conference; 2004. p. 433e442. Yaar A, Perrig A, Song D. In: Pi: a path identification mechanism to defend against DDoS attacks. IEEE Symposium on Security and Privacy; 2003. p. 93e107. In Proc.. of IEEE Symposium on Security and Privacy.
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
Yaar A, Perrig A, Song D. In: FIT: fast internet traceback; 2005. Proc. of IEEE INFOCOM. Yaar A, Perrig A, Song D. StackPi: new packet marking and filtering mechanisms for DDoS and IP spoofing defense. IEEE Journal on Selected Areas in Communications Oct. 2006;24(No. 10).
Zhang G, Ehlert S, Magedanz T. In: Denial of service attack and prevention on SIP VoIP infrastructures using DNS flooding; 2007. Proc. of the 1st international conference on Principles, systems and applications of IP tele communications.
195
available at www.sciencedirect.com
journal homepage: www.elsevier.com/locate/diin
Collaborative scheme for VoIP traceback Hsien-Ming Hsu a, Yeali S. Sun a, Meng Chang Chen a,b,* a b
Dept. of Information Management, National Taiwan University, Taipei, Taiwan Institute of Information Science, Academia Sinica, Taipei, Taiwan
article info
abstract
Article history:
While voice over IP (VoIP) services have brought many desirable communication features to
Received 16 September 2009
the general public, they have also become a medium through which criminals communi-
Received in revised form
cate and conduct illegal activities e.g., fraud and blackmail without being intercepted by
28 August 2010
law enforcement agencies (LEAs). Previous research on IP traceback focused on tracking IP
Accepted 25 October 2010
addresses on the network layer. The mechanisms developed thus far, however, require an inefficient and sometimes infeasibly large amount of router and network support.
Keywords:
In this paper, we propose a collaborative forensics mechanism that cooperates with related
VoIP
network operators (NWO) and service providers (SvP) in tracing back VoIP calls without
Traceback
depending on routers throughout the full trace path. We discuss the various kinds of
Collaborative forensics
attacks of VoIP services and the characteristics of VoIP service requests as they pertain to
Security
those attacks. Additionally, we propose a procedure for identifying forged header field
SIP
values (HFVs) on SIP requests, and introduce the concept of active forensics. This can lead to a reduction in the probability of important information being deleted by the time collaborative forensics is initiated, and thus assist law enforcement agencies in intercepting criminals. We also describe extended applications for traceback for attacks resulting in Distributed Denial of Service and those involving mobile phones. ª 2010 Elsevier Ltd. All rights reserved.
1.
Introduction
VoIP services have become widely available as the Internet has grown and may, one day; even replace the Public Switched Telephone Network (PSTN). While VoIP services have brought many desirable communication features to the general public, they have also become a medium through which criminals communicate and conduct illegal activities e.g., fraud and blackmail without being intercepted by law enforcement agencies (LEAs). As a SIP (Session Initiation Protocol) (Rosenberg et al., 2002) -based telephony system that uses packet-switched technology, VoIP shares the same major drawbacks as many services using Internet Protocol (IP) (Postel, 1981) including e-mail, particularly their vulnerability to security threats. In an effort to offer convenient and safe networking services, researchers have proposed various defensive
mechanisms over the past few years, including intrusion detection systems (IDSs) (Reynolds and Ghosal, 2003; Wu et al., 2004; Sengar et al., 2006a,b) and prevention mechanisms (PM) (Ferguson and Senie, 2000; Anat and Levy, 2005; Zhang et al., 2007; Ormazabal et al., 2008). These mechanisms however, are inadequate for today’s Internet. While they prevent illegal activity before or during criminal acts, both of these types of mechanisms require indications of the kind of attack taking place beforehand for proper security. Unfortunately, attacks are often conducted without any forewarning, so these defense mechanisms do not completely secure the network. Therefore, in light of the shortcomings of these aforementioned defensive mechanisms, we propose a new network forensics mechanisms (NFM) to enhance the detection and defensive ability of IPs to prevent attacks.
* Corresponding author. Institute of Information Science, Academia Sinica, Taipei 10617, Taiwan. E-mail addresses: [email protected] (H.-M. Hsu), [email protected] (Y.S. Sun), [email protected] (M.C. Chen). 1742-2876/$ e see front matter ª 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.diin.2010.10.003
186
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
NFMs serve as complements to the IDSs, PMs, and traceback mechanisms. While PMs prevent attacks, IDSs detect attacks, and traceback mechanisms trace the identities and geo-locations of the perpetrators, NFMs figure out how the attacks were conducted and recover the indications of the attacks. These attack indications may then be used by IDSs and PMs to enhance the detection and defense ability of the network. Research on traceback mechanisms thus far has only applied to the network layer and thus not the application layer, notably VoIP services. IP traceback mechanisms can be classified into three general types: probabilistic packet marking (e.g., Savage et al., 2000), router logging (e.g., Snoeren et al., 2001) and ICMP traceback (e.g., Bellovin, 2000). Each type of IP traceback mechanism has its own advantages, yet shares the same disadvantage: they must inefficiently cooperate with multiple routers and only work at the network layer. Support for traceback mechanisms, not only at the network layer but also at the application layer on VoIP services, is essential for emergency services such as “911” in the United States and “112” in parts of Europe. It is also essential for lawful interception, especially as the popularity of VoIP grows and more and more people use these services as a replacement for standard telephone service. This support at the application layer on VoIP services, as suggested by our previous work, comes in the way of NFMs. Serving as complements to IDSs, PMs, and traceback mechanisms, NFMs can correlate to related Local Events (LEvs)dthe required pieces of information collected from the NWO, SIP Registrar and SIP Proxy in an autonomous system (AS)dto perform traceback in the VoIP services environment without the support of routers on the trace path (Hsu et al., 2008). In addition, NFMs produce LEvs for potential forensic investigations without forging header field values (HFVs). Required cross layers are recorded using the components of SIP-based telephony. SIP-based VoIP telephony sets up, modifies, and terminates operations via SIP messages, which consist of a start-line, an optional message body, and one or more header fieldsdfields that play a big role in conducting forensic analysis. In this paper, we determine which header field values (HFVs) on request messages can be forged, and extract the required information to produce the characteristics for various requests. We also describe the required information recorded by the SIP Registrar and NWO (including Network Address Translation/Dynamic Host Configuration Protocol, NAT/ DHCP), which can be used to identify these forged HFVs by their characteristics and merge them with information from the SIP Registrar and NWO for forensic analysis. While conducting these memory consuming analyses, older information or information that has reached a certain expiration time limit is often deleted so that newer information may be stored. However, investigations by law enforcement agencies often are initiated after this information has been deleted. In order to prevent the deletion of potentially important information merely because of limited storage, we propose a collaborative forensics network that is based on the concept of active forensics and would reduce the probability of important information unnecessarily being lost. This network allows forensic analyses to be conducted on devices on which such analyses were previously unrealisticdmobile phones; furthermore, this network also allows for the
investigation of Distributed Denial of Service (DDoS) attacks in which multiple attackers target one victim simultaneously. The primary contributions of this paper are the follows: We discuss the characteristics of SIP-based requests and typical attacks for SIP-based VoIP services on which header field values can be forged. We explain how to identify the forged header field values and perform collaborative traceback by using the Local Events (LEvs) in single and multiple region collaborative forensics networks. We propose a distributed architecture for collaborative forensics without the information support of intermediate routers or marking on the packets/messages. We propose the concept of active forensics, which reduces the probability of potentially important information for investigation being deleted before law enforcement agencies can investigate. The remainder of this paper is organized as follows. Section 2 contains a review of related work. In Section 3, we describe the background of SIP-based VoIP services. In Section 4, we present the typical SIP-based signaling attacks and the characteristics of requests. In Section 5, we discuss how to identify the forged header field values by the components of SIP proxy and NWO. Then, in Section 6, we discuss the collaborative forensics of traceback on SIP-based VoIP service. Finally, in Section 7 we summarize our findings and indicate areas for future research.
2.
Related work
Traceback mechanisms at the IP layer can be classified into three types: probabilistic packet marking, router logging, and ICMP traceback. In probabilistic packet marking IP traceback (Savage et al., 2000; Song and Perrig, 2001; Dean et al., 2002; Yaar et al., 2003, 2005, 2006), routers randomly mark packets that pass through them with their entire address or a part of their address at a fixed probability. Systems that have been attacked can reconstruct the full address of the attacker using traceback mechanisms. These mechanisms traceback the attacker using various parts of the received address. In router logging IP traceback (Snoeren et al., 2001; Li et al., 2004), since routers keep a record of every packet that passes through them, router logging IP traceback mechanisms check these router logs and relay queries to upstream routers. After the course of this relay is complete, the packet’s true origin can be identified. Router logging IP traceback, however, has a major drawback e high storage demands. This drawback may be solved by using a Bloom Filter (Bloom, 1970). ICMP message traceback (Bellovin, 2000; Makin et al., 2001; Kim et al., 2005) learns the path that packets take through the Internet with the help of the routers along the path emitting ICMP messages at a probability of about 1:20,000, and identifies the correct path to the destination. Some IP traceback mechanisms combine two of the aforementioned approaches (Gong and Sarac, 2005). While these IP traceback mechanisms each have their own advantageous features, they all share the same two shortcomings that we aim to overcome in our mechanism. First, when packet information is recorded and relayed to routers
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
(or the ICMP messages are relayed in the case of ICMP traceback), each mechanism requires the cooperation of a slew of routers along the full trace path. Secondly, none of these mechanisms are able to traceback on the application layer and thus they do not work on VoIP services. Using recorded information on application, network and physical layers, our mechanism traces attackers’ identities and geo-locations and works on SIP-based VoIP services. In designing our technique, we drew upon the works of Shanmugasundaram et al. and Tang et al. on network forensics, who each proposed good forensics mechanisms (Shanmugasundaram et al., 2003; Tang and Daniels, 2005). Shanmugasundaram et al. proposed a distributed forensics network: ForNet. ForNet can automatically collect, store, and exchange the attack attributes by proxies but its data filter is based on a lightweight IDS (Shanmugasundaram et al., 2003). Since many attacks on today’s Internet cannot be detected by IDS, ForNet has a high probability of false-negatives. Tang et al. proposed a simpler framework for distributed forensics networks, but this framework lacks the capacity to identify useful network events and thus has to capture and store all the packets on the network for forensics analysis (Tang and Daniels, 2005). Therefore, despite Bloom filter processing, long-term data storage for the purposes of later investigation remains a big program. Our collaborative forensics mechanism not only automatically collects Local Events (LEvs) and shares this information with cooperating units, it also consults other systems for decisions and spares long-term storage concerns via active forensics. In our mechanism, the different parts of each LEv are linked to build a complete picture of an incident that can be used as evidence in a court of law. In addition, our mechanism can consult a panel of experts or other systems to determine what should be done. The Access Local Event Entity (ALEE) triggers active forensics procedures and thereby avoids the need to store information until law enforcement agencies have time to look at it.
3.
Fig. 1 e The SIP-based IP telephony. VoIP service providers, respectively. Before calling Bob, caller Alice needs to be authenticated by a SIP authentication mechanism and register through a REGISTER request with the Pacific SIP Registrar, shown as Fig. 2(a1ea4). Caller Alice first sends an INVITE request to the Atlantic SIP proxy. This proxy consults the location service database to find out the current location of callee Bob, and forwards the INVITE request to the Pacific SIP proxy and the callee to complete a three-way handshake (INVITE, OK, ACK) that establishes the SIP session, shown in Fig. 2(b1eb14). After exchanging a set of parameters through the Session Description Protocol (Handley and Jacobson, 1998) in the SIP message body, the bi-direction of the Real-time Transport Protocol (RTP) (Schulzrinne et al., 2003) based channel is established. Either caller Alice or callee Bob can terminate this session by sending a BYE request, shown in Fig. 2(c1ec6). The detail signaling of the SIP protocol is described in (Rosenberg et al., 2002).
SIP background
In this paper, we only consider SIP-based IP telephony as opposed to H.323 or PSTN telephony. Here, we provide a brief explanation of SIP signaling and how it works, describe the weaknesses of the SIP authentication mechanism, and discuss the required information of the header field values (HFVs) on request messages that NWO/SvP log collaboratively.
3.1.
SIP-based signaling
SIP is an application layer control protocol designed to establish, modify, and terminate multimedia sessions (conferences) and is used in such programs as SIP-based VoIP telephony services. The architecture of SIP-based IP telephony is shown in Fig. 1. Here, the registrars and proxies represent SIP servers. Registrars are responsible for registration, after which proxy servers relay the SIP-based signaling to the callee’s address and offer the VoIP service. In order to better illustrate how SIP signaling works, let us consider a hypothetical example involving caller “Alice” and callee “Bob”, who belong to the “Atlantic” and “Pacific” SIP
187
Fig. 2 e SIP signaling flow.
188
3.2.
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
Weaknesses of SIP services
For SIP-based VoIP services, authentication is executed with registration. Registration creates bindings in a location service for a particular domain that associates an URI address with one or more contact addresses. When the user agent wants to make or receive a call, he or she has to add or refresh bindings whenever the most recent registration expires. Based on this construction, SIP-based VoIP services have two major weaknesses that make them vulnerable to attack. First, they have a challenge-based authentication mechanism. Challenge-based mechanisms allow users to use a system continuously without further authentication within a set registration time period. Users only have to re-authenticate if the server suspects they are using the system without permission, and re-authentication then “challenges” the suspicious users. This type of authentication mechanism allows attackers to fairly often use the service for a long time without having to re-authenticate. If attackers had to reauthenticate more often, it would make it more difficult for them to carry out crimes. Secondly, SIP-based VoIP services allow users and servers to fill out or modify the information in SIP messages. Attackers readily exploit this weakness by forging messages when attacking VoIP devices, and commit such crimes as fraud, blackmail and DoS attacks.
3.3. The required information that NWO/SvP collaboratively logs The architecture of SIP-based IP telephony is shown in Fig. 1. The Registrars and Proxies are the SIP servers. Registrars are responsible for registration, after which the proxy servers relay the signaling to the callee’s address and commence the service. Although the clients can send malicious or forged messages, they can only forge the information on messages or packets. Some important personal information, including user account information, cannot be modified by users. User accounts are stored by the NWO and SvP, and are used to log-in for services and bill clients for call duration and type. Therefore, proper forensics investigations should extract the required information (information required to complete the three-way handshake), to form clues as to what attack took place. Tables 1 and 2 list the required information that the SIP Registrar Server and NWO (NAT/DHCP) require for traceback (Hsu et al., 2008).
4. Typical SIP-based signaling attacks and the characteristics of various requests In this section, we describe typical SIP-based signaling attacks, discuss which header field values (HFVs) on request messages are forged based on the type of attack, and propose extracting the required information for producing the characteristics for the various requests (e.g., INVITE, REGISTER).
4.1.
Typical SIP-based signaling attacks
SIP messages are either requests (REGISTER, INVITE, BYE, CANCEL, ACK and OPTION) from a client to a server, or responses from a server to a client. Table 3 shows the typical
Table 1 e The information recorded By SIP registrar server. Attributes Caller’s account Caller’s public IP/port Timestamp and expiration Caller’s account Caller’s public IP/port
Description Caller’s account of network-based phone Acquired from the caller’s registration message The time when register expires Caller’s account of network-based phone Acquired from the caller’s registration message
SIP-based signaling attacks using REGISTER, INVITE, CANCEL and BYE requests. Attackers manipulate these requests by forging the header field values (HFVs) on different requests depending on what the attacker wishes to achieve. These attacks may be classified into three groups: forged REGISTER, INVITE, and CANCEL/BYE requests.
4.1.1.
REGISTER requests
In the following two attacks, the attacker sends a forged REGISTER request to the SIP Registrar.
4.1.1.1. De-register attack. De-register attacks prevent the victim from receiving calls. In this attack, the attacker requests that the SIP Registrar remove the binding address of the victim. The attacker sends a spoofing message that sets the expiration interval to zero for that contact address through a REGISTER request (Anat et al., 2006). 4.1.1.2. Registration hijack attack. Registration hijack attacks direct all requests sent to the victim to the attacker’s device. The attacker then usually de-registers all existing contacts for that URI and registers their own device as the appropriate contact address (Rosenberg et al., 2002). 4.1.2.
INVITE requests
In the following four attacks, the attacker sends spoofing INVITE requests to the SIP proxy, which are then forwarded to the victim.
4.1.2.1. Fraud & blackmail. The attacker establishes a SIP session with the victim to scam or blackmail the victim. Once the three-way handshake between attacker and victim is completed, the attacker talks with victim. Attackers may send INVITE requests with anonymous or forged header field values in the “From” section.
Table 2 e The information recorded by NWO (NAT/DHCP). Attributes Caller’s account Caller’s private IP/port Caller’s public IP/port Caller’s public media IP/port Time: call Time: hang-up
Description User’s account of network-based phone The private IP/port with NAT The public IP/port assigned to NAT/DHCP The public IP/port assigned to NAT/DHCP The time when called by private IP The time when call by private IP is interrupted
189
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
4.1.3.
Table 3 e Typical SIP-based signaling attacks. Attacks
Requests
De-register Registration hijack Fraud & blackmail DoS e INVITE flooding DoS e NO ACK Call hijack BYE e session teardown CANCEL e session teardown
REGISTER REGISTER INVITE/ACK/BYE INVITE INVITE Re-INVITE BYE CANCEL
CANCEL and BYE requests
The attacker uses an SIP message to terminate an existing call.
Responses
4.1.3.1. BYE session teardown attack. BYE session teardown
OK OK OK NR OK 3xx/OK OK OK
attacks terminate ongoing calls. The attacker impersonates the caller (or callee) and sends a spoofing BYE request to terminate his session.
4.1.3.2. CANCEL session teardown attack. CANCEL session teardown attacks terminate ongoing calls. In contrast to other attacks that terminate ongoing calls, the attacker impersonates the caller (or callee) and sends a spoofing CANCEL request to terminate this session.
“NR” denotes no response. “x” denotes arbitrary number
4.1.2.2. INVITE request flooding attack. INVITE request flooding attacks prevent victims from receiving calls. IP phones can only place a limited number of calls at the same time. The attacker sends lots of INVITE requests such that they overwhelm the victim’s computer.
4.2. The characteristics of the various requests on SIPbased VoIP service The required information may be extracted using the various requests and responses on the SIP proxy to form the characteristics of requests, which are required not only to run operations but also identify attackers, on the application layer. Fig. 3 lists this information. SIP Proxy Servers record certain pieces of information to form the various characteristics of calls, including the sought-after answers to various special questionsdwho, whom, when, where, and what. Based on the request and response (R/R) messages that attackers forge, attacks may be classified into three types: REGISTER, INVITE/OK/BYE (BIO) and BYE/CANCEL (B/C).
4.1.2.3. NO-ACK denial of service attack. Normally, SIP sessions are established after the three-way handshake is completed. However, in this attack, the attacker does not send the ACK request when he/she receives the OK response sent by the victim, after the victim received the INVITE request and sent the OK response to the attacker. The victim then waits for a long period of time for the ACK request. However, since system resources are limited and can only support a few pending requests, the attacker sends multiple INVITE requests but does not send an ACK request, in order to prevent the victim from receiving calls.
4.2.1.
The characteristics of REGISTER
SIP Registrars assign dynamic IP addresses to User Agents. REGISTER requests register one or more contacts per User Agent. Seven HFVs, as shown in Fig. 3(a), compose the characteristics of REGISTER requests on SIP-based VoIP services. Registration Hijack and De-register attacks prevent victims from receiving incoming calls by reconfiguring
4.1.2.4. Call hijack attack. Call hijack attacks hijack an already ongoing call. The attacker impersonates the victim and sends a spoofing response with the response code 3xx to the caller. The attacker then sends a re-INVITE request to invite the victim to establish the session again.
True Header Field Values. Forged Header Field Values.
REG: REGISTER Service Type: REG
a
Time Stamp + Expires
Registrar’s IP
Caller’s Account (FROM)
Caller’s Public IP/Port
Callee’s Account (TO)
Callee’s Public IP/Port (Contact)
The Characteristic of Register with FORGED HFVs
INV: INVITE Service Type: INV
b
Time (Answer: Hang-up)
Caller’s Account (FROM)
Caller’s Signaling IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Callee’s Account (TO)
Callee’s Signaling IP/Port
The Characteristic of BIO with FORGED HFVs
CNL: Cancel Service Type: BYE/CNL
c
Caller’s Time Account (received) (FROM)
Caller’s Signaling IP/Port
Caller’s Private IP/Port
Callee’s Account (TO)
Callee’s Signaling IP/Port
The Characteristic of BYE/CANCEL with FORGED HFVs
Fig. 3 e The characteristics of requests on SIP-based VoIP services.
Callee’s Media IP/Port
190
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
registration. Attackers impersonate the victims and send REGISTER requests that modify the Contact header field values or forge De-register requests that set the expiration interval to “0” for that contact address in the REGISTER request, thereby disabling victims from receiving calls without their knowledge. Therefore, when attackers attack in these ways, as shown in Fig. 3(a), they forge the following header values: the FROM HFV and Caller’s Contact HFVs (Caller’s Public IP/Port).
In sum, specific HFV values on the R/Rs of the attacker are likely to be forged depending on which of the three types of characteristics of a call were manipulated i.e. REGISTER, BYE/ INVITE/OK (BIO) or BYE/CANCEL (B/C) R/Rs, but the victim’s HFVs should remain genuine in spite of attack. Forensics analysis thus aims to identify the forged HFVs and merge this information with the information from the NWO and the home SIP Registrar
4.2.2.
5.
The characteristics of BYE/INVITE/OK (BIO)
User agent can make calls (send INVITE request) without further authentication before the expiration time limit set by the initial REGISTER request. Nine HFVs form the characteristics of BIO on SIP-based VoIP services based on the HFVs of BIO R/Rs, as shown in Fig. 3(b). Attackers use BIO R/Rs to commit fraud and blackmail via anonymous calls to victims. In such cases, the HFVs on INVITE/ACK remain genuine but the FROM (attacker’s account) HFV is forged. Attackers use BIO R/Rs to commit DoS attacks (INVITE Flooding, INVITE without ACK) and Call Hijacks in which they block the victims from access to VoIP services. Attackers manipulate the requests to conceal their identities. Therefore, the FROM (caller’s account), and Caller’s Contact (signaling IP/ Port) HFVs and media IP/Port are typically forged, as shown in Fig. 3(b).
4.2.3.
The characteristics of BYE/CANCEL
BYE and CANCEL attacks, which terminate victims’ VoIP services prematurely, are unique in that attackers do not expect to receive responses from victims. With the exception of two HFVs, FROM (Caller’s account) and Caller’s Contact (signaling IP/Port) HFVs, are left forged, as shown in Fig. 3(c). Based on the HFVs on BYE and CANCEL requests, seven HFVs of B/C requests form the characteristics of BYE/CANCEL requests on SIP-based VoIP services. BYE requests are used to terminate sessions, and CANCEL requests are used to cancel any previous requests sent by client. So, unlike other kinds of attacks, only two out of seven HFVs, FROM and Caller’s Contact (signaling IP/Port) HFVs, are forged in BYE and CANCEL attacks since attackers are not concerned with response characteristics.
Identifying the forged header fields values
Forensics, in the general sense, aims to figure out how crimes were committed and reveal the identities and geo-locations of the perpetrators of those crimes. In order to solve and prevent future crimes involving VoIP services, proper forensics is dependent on Network Operators, Access Providers and Service Providers (NWO/AP/SvP) collaboratively recording the identities of parties using these services and other information required for identifying geo-locations. Forged HFVs of characteristics on SIP-based VoIP services must first be identified and then merged with information from SIP Registrars and NWOs for forensics analysis. As mentioned in the previous section, before sending attack requests, attackers have to first register with a home SIP Registrar using their true identity and public IP/Port. NWOs and SIP Registrars should record this information. These records may then be collected, extracted, and used to identify forged information on the characteristics of future requests and then merged with the characteristics of requests into a Local Event (LEv) that can be represented as an XML message and reported using the SEAL Protocol by an administrator, as shown in Table 4. The autonomous system number (ASN) of the autonomous system (AS) must be inserted at the beginning of every LEv for LEA classification and storage purposes, shown in Fig. 4 as well.
6. Collaborative forensics for SIP-based VoIP services In this section, we first present the key components of our design, outline the particulars of the Collaborative Forensics
Table 4 e Identifying forged header field values using the required information. The characteristics of requests on SIP proxy REGISTER Time stamp þ expires Registrar’s IP Caller’s account (FROM) Caller’s public IP/port
Callee’s account (TO) Callee’s public IP/port (contact)
Forged information can be identified by the required information recorded on
INVITE/OK/BYE Time (answer: hang-up)
BYE/CANCEL Time (received)
NWO Time (Answer: hang-up)
SvP (SIP registrar) Time stamp þ expires
Caller’s account (FROM) Caller’s signaling IP/port
Caller’s account (FROM) Caller’s signaling IP/port
Account Caller’s public IP/port
Account (FROM) Caller’s public IP/port (contact)
Caller’s media IP/port Caller’s private IP/port Callee’s account (TO) Callee’s signaling IP/Port
Caller’s private IP/port Callee’s account (TO) Callee’s signaling IP/port
Callee’s media IP/port
Caller’s media IP/port Caller’s private IP/port Account (TO) Callee’s public IP/port (contact)
191
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
a
NWO
Time (Call: Hang-up)
Caller’s Account
Caller’s Public IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
SvP (SIP Registrar)
Time Stamp + Expires
Caller’s Account (FROM)
Caller’s Public IP/Port (Contact)
Callee’s Account (TO)
Callee’s Public IP/Port (Contact)
Time Stamp + Expires
Account (FROM)
Caller’s Public IP/Port
Service Type: SIP-REG
SIP Proxy
Callee’s Public IP/Port (Contact)
Callee’s Account (TO)
Registrar’s Public IP
The Characteristic of REGISTER on SIP-based VoIP services Identify & Merge
REG: REGISTER $: forged flag
Local Event
b
NWO SvP (SIP Registrar)
Service Type: SIP-INV
SIP Proxy
Time Stamp + Expires
Service Type: SIPREG-$
ASN
Registrar’s Public IP
True Header Field Values. Forged Header Field Values. Caller’s Account (FROM)
Caller’s Public IP/Port
Time (Call: Hang-up)
Caller’s Account
Caller’s Public IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Time Stamp + Expires
Caller’s Account (FROM)
Caller’s Public IP/Port (Contact)
Account (TO)
Callee’s Public IP/Port (Contact)
Time (Answer : Hang-up)
Caller’s Account (From)
Caller’s Signaling IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Callee’s Account (TO)
Callee’s Account (To)
Callee’s Public IP/Port
Callee’s Signaling IP/Port
Callee’s Media IP/Port
The Characteristic of BIO for SIP-based VoIP services Identify & Merge
INV: INVITE $: forged flag
Local Event
ASN
Service Type: SIP-INV-$
c NWO SvP (SIP Registrar)
SIP Proxy
Service Type: SIP-B/C
Time (Answer : Hang-up)
Caller’s Account (From)
True Header Field Values. Forged Header Field Values.
Caller’s Signaling IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Callee’s Account (To)
Time (Call: Hang-up)
Caller’s Account
Caller’s Public IP/Port
Caller’s Media IP/Port
Caller’s Private IP/Port
Time Stamp + Expires
Caller’s Account (FROM)
Caller’s Public IP/Port (Contact)
Account (TO)
Callee’s Public IP/Port (Contact)
Time (received)
Caller’s Account (From)
Caller’s Signaling IP/Port
Caller’s Private IP/Port
Callee’s Account (To)
Callee’s Signalin g IP/Port
Callee’s Media IP/Port
Callee’s Signaling IP/Port
The Characteristic of BYE/CANCEL for SIP-based VoIP services
B/C: BYE/Cancel $: forged flag
Local Event
ASN
Service Type: SIP-B/C-$
Time (received)
Identify & Merge
Caller’s Account (From)
True Header Field Values. Forged Header Field Values. Caller’s Signaling IP/Port
Caller’s Private IP/Port
Callee’s Account (To)
Callee’s Signaling IP/Port
Fig. 4 e (a) Identifying forged field values on the characteristics of REGISTER requests. (b) Identifying forged field values on the characteristics of INVITE/OK/BYE requests. (c) Identifying forged field values on the characteristics of CANCEL/BYE requests.
Network, and then describe the procedure that comprising units of the Collaborative Forensics Network follow for SIPbased VoIP services. Finally, we discuss extending the usage of this network for traceback on Distributed Denial of Service and mobile phones.
6.1.
The collaborative forensics center, SKYEYE
NWOs and SvPs may not want to share certain pieces of information e.g., security intelligence and forensic information with other NWOs or SvPs for a variety of reasons,
192
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
including privacy concerns, commercial competition, company policies, culture differences, and implementation differences. NWOs and SvPs may be more inclined to share this information if the exchange of this information were supervised by an independent authority. This independent authority would have a mechanism that would aggregate, integrate, and correlate local information in the form of LEvs from operators and carry out traceback tasks without compromising any information participating NWOs and SvPs would not want to disclose. We have designed a collaborative framework that can serve as this mechanism for an independent authority, as shown in Fig. 5, that we call the SKYEYE (Hsu et al., 2008). The Collaborative Forensics Mechanism 1) Local events (LEvs) Local Event data are collected from the NWO (NAT/ DHCP), SIP Registrar and SIP Proxy in an AS by ALEE through the SKYEYE ALEE (SEAL) Protocol. During a VoIP call, the ALEE makes two copies of the Local Event, and stores one of them in the local operator’s (AS’) database for backup and the other is sent to SKYEYE for forensic analysis. 2) Access local event entity (ALEE) ALEE is the AS interface that connects and communicates with SKYEYE, which is independent of the AS realm. For each SIP-based phone call, the ALEE automatically collects the required information about the caller and callee from the NWO (NAT/DHCP), SIP Registrar, and SIP Proxy in the operating network (AS) and merges these pieces of information to produce a Local Event in XML format. 3) The flexible SKYEYE ALEE (SEAL) protocol The SEAL protocol is simple in design, and merely transports Local Events in XML format between ALEE and SKYEYE, so it can easily accommodate different access network technologies i.e. HTTP and Web servers. 4) The SKYEYE The SKYEYE is the kernel of the collaborative forensic network in that it executes all collaborative investigations. It is comprised of the following modules: aggregation, event
Internet
NWO/AP/SvP
4. Collaborative with CFRC
5a. Info. sharing FRTs 5b.Task dispatch 3. Query/
Existing Response Systems
correlation, event information mining, integration, and expertise repository. The details of the SKYEYE and the procedure outlining how its comprising units interact are described in (Hsu et al., 2008).
6.2.
The collaborative forensics work
The Collaborative Forensics Network, as it pertains to VoIP traceback, comprises multiple independent administrative Region Forensics Centers. These RFCs would act as independent administrative authorities, each being composed of one or more ASs on the Internet, as shown in Fig. 6. When User Agents send SIP requests, the ALEE produces LEvs. Traceback to a particular user agent would only require the LEvs of the callee and caller, making LEvs of the intermediate ASs unnecessary. The LEvs from the caller and callee may be checked to build a complete picture of any incident, and this information could be used as evidence in a court of law. Correlating related LEvs, from the caller and callee, help to determine how a network incident e.g., attack occurred and provides such details as the origin, the method(s) used, and identities of the perpetrators.
6.2.1.
Collaborative forensics work of SKYEYEs
In this section, we briefly describe the procedure that comprising units follow when conducting collaborative forensics, as shown in Fig. 5.
6.2.1.1. Step 1. The LEA sends commands to SKYEYE. Each command has two essential elements: the callee’s account and the calling time-parameter. The former serves as the starting point for traceback, while the latter serves as an identifier for the call. 6.2.1.2. Step 2. SKYEYE checks its Event Data Warehouse and sends a request to ALEE for a Local Event (LEv) search using the callee’s account and calling time-parameter.
6.2.1.3. Step 3. SKYEYE may have to consult the domain experts by way of hosting a virtual panel to determine if any information is missing or confusing, and request data or evidence from other systems. The results of this process are then relayed back to SKYEYE’s Control and Decision making Module to decide whether to take action. Collaborative Forensics Region Centers (CFRCs) Share information and Local Events with each other
1. CMD
LEAs
SKYEYE
CFRC-2
CFRC-1
6. Report
AS
2. SEAL database
AS
ALEE
VoIP Network (AS)
AS
AS
SKYEYE
AS
AS SKYEYE
AS AS
AS
AS AS
AS
SEAL: Sky Eye ALee protocol
Fig. 5 e Procedure for collaborative forensics with cooperating units and other region collaborative forensics centers.
Fig. 6 e The primary CFRC (pCFRC), the caller located, needs to communicate with the secondary CFRC (sCFRC) and request the LEv send from the callee’s AS to perform VoIP traceback.
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
193
Fig. 7 e An example of interpretation for fraud local events: A (attacker) attacks V (victim) by the forged account and public IP/port of B.
6.2.1.4. Step 4. When the ASs of the caller and callee are located in the same Collaborative Forensics Region (CFR), the two LEvs, sent by caller and callee’s ASs, are sent to the same CFR Center (CFRC) to execute VoIP traceback. Since caller and callee ASs are located in different CFR most of the time, the CFRCs receive only one LEv from either the caller or callee. In these cases, the primary CFRC (pCFRC), located near the caller, needs to communicate with the secondary CFRC (sCFRC) and request that the LEv of the callee be sent from the callee’s AS in order to perform forensics.
investigation. This is all done without the command of LEAs. Based on the information within the LEvs, the SKYEYE of pCFRC performs a preliminary VoIP traceback and interprets the incident. As shown in Fig. 7, for example, an interpretation of fraud may be assigned to both LEvs using an “A” for attacker and “V” for victim depending on which party’s account information and public IP/Port of “B” were forged. Collaborative forensics starts when law enforcement agencies (LEA) send commands to the SKYEYE of the CFR of the victim. Active forensics and collaborate forensics, when combined, serve as the best method for handling VoIP attacks.
6.2.1.5. Step 5. The LEv information is then shared with agencies such as the NWOs or SvPs to alert them about possible criminal activity, and these agencies can then report to Fast Response Teams (FRTs).
6.2.1.6. Step 6. All decisions made and the results of the incident are then relayed to the LEA.
6.2.2.
The trigger for active forensics
Even now, law enforcement agencies (LEA) often take quite some time to start collaborative forensics in networks/ computer systems. The stored data that they require for proper investigation often expires and has been deleted by the time they wish to have access to it. This is referred to as “passive forensics”, as it does not actively use networks/computer systems. We propose using active forensics in computer systems in order to eliminate the problems of data storage and time lag in investigation. Active forensics requires that systems share security information and send alerts to cooperating units when attacks seem to have occurred. Collaborative forensics can then be executed long before the stored data has expired and been deleted. Active forensics is much more efficient than passive forensics against criminal activities. Active forensics is triggered when ALEE detects that one of the caller’s HFVs, either their account or public IP/Port, have been forged. ALEE then flags the LEv with $ and sends it to the SKYEYE of the CFR of the caller or the pCFRC. When this SKYEYE receives the LEv with the forged flag, $, it then begins the active forensics procedure. The SKYEYE of the pCFRC communicates with the SKYEYE of the sCFRC and requests that the callee’s LEv be relayed back for subsequent forensics
6.3. Forensics investigation for distributed denial of service and mobile phone When it comes to attacks on VoIP services resulting in a distributed denial of service or attacks involving mobile phones, forensic practices in current use are completely ineffective. However, the methods proposed in this paper, active and collaborative forensics, can handle these attacks.
6.3.1.
Investigation for distributed denial of service (DDoS)
Distributed denials of service (DDoS) attacks are one other kind of denial of service attack wherein victims are attacked by several attackers simultaneously. In DDoS attacks, requests for the callee’s account and calling time-parameter receive multiple LEvs. Reconstructing a DDoS incident and performing traceback can be performed using the LEvs of the victim.
6.3.2.
Investigation of mobile phone VoIP service attacks
As mobile devices are moved across Access Point (AP) regions, APs execute handoff processes wherein the public IPs for the mobile devices are changed. Collaborative networks can be set up such that SKYEYEs receive LEvs from multiple ASs of APs and are reconstructed.
7.
Conclusion and future work
In this paper, we described the weaknesses of SIP Authentication mechanisms, weaknesses that attackers exploit when attacking victims and that provide clues as to how to conduct
194
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
proper forensics after attack. Attackers forge header field values (HFVs) on request messages depending on which kind of attack they wish to conduct. SIP Registrars and NWOs (including NAT/DHCP) record the required information contained within the various Requests as Characteristics for each SIP session. This required information may be extracted and used to identify forged HFVs on the Characteristics after it is merged with the information from SIP Registrars and NWOs. In this paper, we also presented the key components of our design and outlined a Collaborative Forensics network based on the concept of active forensics, a strategy which would reduce the probability of information essential to proper forensic investigation being deleted. Collaborative Forensics for SIP-based VoIP services may be extended to traceback on Distributed Denial of Service attacks and Mobile phone. Further research is necessary on other kinds of attacks, anonymous VoIP services, and data mining before our mechanism and proposed collaborative forensics can be broadly applied. Despite our successes in handling typical SIPbased signaling attacks, many SIP-based signaling attacks have not been considered, including malicious acts without SIP proxy services. Some VoIP services (e.g., skype) offer anonymous service to clients, services in which clients may sign on without use of a user name, and these must be considered in network forensics. The details of data mining for collaborative forensics mechanisms on multiple layers will help our mechanism become more versatile.
Acknowledgement This work was supported in part by the NSC of Taiwan under grant NSC98-2221-E-001-005-MY3.
references
Anat B-B, Levy H. In: Spoofing prevent method; 2005. Proc. of IEEE INFORCOM. Anat B-B, Ronit H-B, Jussi K. Unregister attacks in SIP; 2006. p. 32e37. Proc. of the 2nd IEEE Workshop on Secure Network Protocols. Bloom BH. Space/time trade-offs in hash coding with allowable errors. Communication of ACM July 1970;13:422e6. Bellovin S. ICMP traceback messages; March 2000. Internet draft: Draft-bellovin-itrace-00.txt. Dean D, Franklin M, Stubblefield A. An algebraic approach to IP traceback. ACM Transactions on Information and System Security; 2002. Ferguson P, Senie D. Network ingress filtering: defeating denial of service attacks which employ ip source address spoofing,” RFC 2827. IETF Network Working Group. Available from: http:// www.ietf.org/rfc/rfc2827.txt; May 2000. Gong C, Sarac K. IP traceback based on packet marking and logging. IEEE Communications Magazine May 2005;2: 1043e7. Handley M, Jacobson V. SDP: session description protocol,” RFC 2327. IETF Network Working Group. Available from: http:// www.ietf.org/rfc/rfc2327.txt; 1998. Hsu H-M, Sun YS, Chen M-C. Proc. of the IEEE ISI. In: A collaborative forensics framework for VoIP services in multi-
network environments, vol. 5075; 2008. p. 260e71. PAISI, PACCF, and SOCO international workshops on Intelligence and Security Informatics. Kim E, Massey D, Ray I. Global Internet routing forensics: validation of BGP paths using ICMP traceback, vol. 194. IFIP International Federation for Information Processing. Available from: http://www.springerlink.com/content/ 6120jm8530713408; 2005. p. 165e176. Li J, Sung M, Xu J, Li L. In: Large-scale IP traceback in highspeed internet: practical techniques and theoretical foundation; 2004. p. 115e129. Proc. of IEEE Symposium on Security and Privacy. Mankin A, Massey D, Wu C-L, Wu SF, Zhang L. On design and evaluation of ‘intention-driven’ ICMP traceback; 2001 p. 159e165. Proc. 10th International Conference on Computer Communications and Networks. Ormazabal G, Nagpal S, Yardeni E, Schulzrinne H. In: Secure SIP: a scalable prevention mechanism for DoS attacks on SIP based VoIP systems; 2008. Proc. of the 2nd international conference on Principles, systems and applications of IP telecommunications. Postel j. “IP: internet protocol,” RFC 0791. IETF Network Work Group. Available from: http://www.ietf.org/rfc/rfc0791.txt; 1981. Rosenberg J, Schulzrinne H, Camarillo G, Johnston A, Peterson J, Sparks R, Handley M, Schooler E. “SIP: session initiation protocol (SIP),” RFC 3261. IETF Network Working Group. Available from: http://www.ietf.org/rfc/rfc3261.txt; 2002. Reynolds B, Ghosal D. In: Secure IP telephony using multi-layered protection; February 2003. Proc. of the Network and Distributed System Security Symposium (NDSS). Savage S, Wetherall D, Karlin A, Anderson T. In: Practical network support for IP traceback; 2000. p. 295e306. Proc. of the ACM SIGCOMM Conference. Snoeren AC, Partridge C, Sanchez LA, Jones CE, Tchakountio F, Kent ST, Strayer WT. In: Hash-based IP traceback; 2001. p. 3e14. Proc. ACM SIGCOMM. Song D, Perrig A. In: Advanced and authenticated marking schemes for IP traceback; 2001. Proc. of IEEE INFOCOM. Shanmugasundaram K, Memon N, Savant A, Bronnimann H. ForNet: a distributed forensics network. St. Petersburg, Russia: The Second International Workshop on Mathematical Methods, Models and Architectures for Computer Networks Security. Available from: http://isis.poly.edu/projects/fornet/ docs/talks/mmm-acns-2003.pdf; 2003. Schulzrinne H, Casner S, Frederick R, Jacobson V. “RTP: a transport protocol for real-time applications,” RFC 3550. IETF Network Working Group. Available from: http://www.ietf.org/ rfc/rfc3550.txt; 2003. Sengar H, Wijesekera D, Wang H, Jajodia S. VoIP intrusion detection through inter-acting protocol state machines. IEEE Dependable Systems and Networks Conference; 2006a. p. 393e402. Sengar H, Wijesekera D, Wang H, Jajodia S. Fast detection of denialof-service attacks on IP telephony. 14th IEEE Internation Workshop on Quality of Service; 2006b. p. 199e208. Tang Y, Daniels TE. In: A simple framework for distributed forensics; 2005. p. 163e9. Proc. of the 25th IEEE international Conference on Distributed Computing Systems Workshops. Wu Y-S, Bagchi S, Garg S, Singh N, Tsai T. In: SCIDIVE: a stateful and cross protocol intrusion detection architecture for voiceover-IP environments. IEEE Dependable Systems and Networks Conference; 2004. p. 433e442. Yaar A, Perrig A, Song D. In: Pi: a path identification mechanism to defend against DDoS attacks. IEEE Symposium on Security and Privacy; 2003. p. 93e107. In Proc.. of IEEE Symposium on Security and Privacy.
d i g i t a l i n v e s t i g a t i o n 7 ( 2 0 1 1 ) 1 8 5 e1 9 5
Yaar A, Perrig A, Song D. In: FIT: fast internet traceback; 2005. Proc. of IEEE INFOCOM. Yaar A, Perrig A, Song D. StackPi: new packet marking and filtering mechanisms for DDoS and IP spoofing defense. IEEE Journal on Selected Areas in Communications Oct. 2006;24(No. 10).
Zhang G, Ehlert S, Magedanz T. In: Denial of service attack and prevention on SIP VoIP infrastructures using DNS flooding; 2007. Proc. of the 1st international conference on Principles, systems and applications of IP tele communications.
195