Portal de Periódicos da CAPES

iVisher: Real-Time Detection of Caller ID Spoofing

2014; Electronics and Telecommunications Research Institute; Volume: 36; Issue: 5 Linguagem: Inglês

10.4218/etrij.14.0113.0798

2233-7326

JaeSeung Song, Hyoungshick Kim, Athanasios Gkelias,

Spam and Phishing Detection

ETRI JournalVolume 36, Issue 5 p. 865-875 ArticleFree Access iVisher: Real-Time Detection of Caller ID Spoofing Jaeseung Song, Jaeseung Song jaeseung.song@neclab.eu Jaeseung Song (jssong@sejong.ac.kr) is with the Network Research Division, Sejong University, Seoul, Rep. of Korea.Search for more papers by this authorHyoungshick Kim, Corresponding Author Hyoungshick Kim hyoung@skku.edu Hyoungshick Kim (corresponding author, hyoung@skku.edu) is with the Department of Computer Science and Engineering, Sungkyunkwan University, Suwon, Rep. of Korea.Corresponding Author hyoung@skku.eduSearch for more papers by this authorAthanasios Gkelias, Athanasios Gkelias a.gkelias@imperial.ac.uk Athanasios Gkelias (a.gkelias@imperial.ac.uk) is with the Department of Electrical and Electronic Engineering, Imperial College London, UK.Search for more papers by this author Jaeseung Song, Jaeseung Song jaeseung.song@neclab.eu Jaeseung Song (jssong@sejong.ac.kr) is with the Network Research Division, Sejong University, Seoul, Rep. of Korea.Search for more papers by this authorHyoungshick Kim, Corresponding Author Hyoungshick Kim hyoung@skku.edu Hyoungshick Kim (corresponding author, hyoung@skku.edu) is with the Department of Computer Science and Engineering, Sungkyunkwan University, Suwon, Rep. of Korea.Corresponding Author hyoung@skku.eduSearch for more papers by this authorAthanasios Gkelias, Athanasios Gkelias a.gkelias@imperial.ac.uk Athanasios Gkelias (a.gkelias@imperial.ac.uk) is with the Department of Electrical and Electronic Engineering, Imperial College London, UK.Search for more papers by this author First published: 01 October 2014 https://doi.org/10.4218/etrij.14.0113.0798Citations: 8 This research was supported by MSIP (Ministry of Science, ICT & Future Planning), Korea, under the ITRC (Information Technology Research Center) support program (NIPA-2014-H0301-14-1010) supervised by the NIPA (National IT Industry Promotion Agency) AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinked InRedditWechat Abstract Voice phishing (vishing) uses social engineering, based on people's trust in telephone services, to trick people into divulging financial data or transferring money to a scammer. In a vishing attack, a scammer often modifies the telephone number that appears on the victim's phone to mislead the victim into believing that the phone call is coming from a trusted source, since people typically judge a caller's legitimacy by the displayed phone number. We propose a system named iVisher for detecting a concealed incoming number (that is, caller ID) in Session Initiation Protocol–based Voice-over-Internet Protocol initiated phone calls. Our results demonstrate that iVisher is capable of detecting a concealed caller ID without significantly impacting upon the overall call setup time. I. Introduction Voice phishing (vishing) is a variant of phishing. Scammers, called vishers, use phone calls to deceive victims into disclosing confidential information or transferring money, by masquerading as a trusted authority (for example, a government agency, bank, etc). As legitimate callers also often ask for such confidential information over the phone, it's not easy for people to distinguish between a visher and a legitimate caller. Moreover, the use of the telephone itself means that certain population groups, such as the elderly, are more vulnerable to vishing. Such factors have led to an increase in vishing attacks [1]. In 2011, for example, the damage due to vishing in Korea was estimated to be about USD 90 million, which was roughly double that of 2010 [2]. To avoid vishing attacks, the call recipient needs to check whether the caller is a trusted entity. However, the incoming number (that is, caller ID) displayed on the phone screen is not sufficient to detect vishing attacks since vishers can modify the displayed number on the phone by using a technique called "caller ID spoofing"; therefore, the recipient cannot be certain, from the displayed number alone, that the phone call is coming from a trusted sender. Rather than the displayed number, the recipient can use the phone caller's voice characteristics, such as pitch, accent, and pronunciation, to effectively detect vishers [3]. For the time being, the best option is to try to educate users about these attacks and the associated risks — however, many security researchers have warned that the effectiveness of such education is inherently limited [4]–[5]. Motivated by the lack of automated solutions to detect vishing [6], we propose iVisher, a system to mitigate vishing attacks by detecting whether a given number displayed on a phone screen has been modified by means of spoofing. iVisher authenticates the caller ID of an incoming call and blocks previously reported caller IDs by performing reachability analysis to the display name of a suspicious incoming call (that is, a display name suspected of caller ID spoofing). This analysis uses a gateway (that knows the actual caller ID of the call) in the handling of reachability analysis messages that are attempting to corroborate the actual caller ID and the display name. To evaluate the performance of iVisher, we analyze the signaling message overhead incurred in the iVisher system. The analysis shows that the proposed method is fast enough to be used at runtime. Moreover we simulate the proposed mechanism in a real-world environment and provide effective simulation results showing that iVisher does not introduce any significant impact upon the overall call setup time while detecting caller ID spoofing. In summary, we make the following contributions: • We introduce a framework that is able to detect a possible vishing attack through checking the verification of the display name of an incoming call during runtime. • We present the methods used for the initialization of a request for caller ID authentication and the delivering of its result. Such methods are applicable to various terminal types that include not only the latest smartphones but also legacy phones. • We demonstrate the feasibility of the proposed method by evaluating its performance through numerical analyses and simulation, as well as discussing the potential implementation issues of iVisher and incentives for various stakeholders. The next section gives an overview and analysis of the current state of vishing attacks to illustrate just how attackers hide their real caller ID. This is followed by a discussion of related works in Section III. We then propose a system named iVisher capable of detecting vishing attacks in real-time in Section IV. A way of implementing the proposed system is described in Section V. Section VI shows that iVisher is capable of detecting vishing attacks without a significant overhead through a simulation and a mathematical performance analysis. The paper finishes with conclusions in Section VII. II. Background of Caller ID Spoofing Caller ID spoofing is a technique that modifies the displayed number of an incoming call. This is crucial in vishing attacks since most people rely on the displayed number to authenticate the caller. Unfortunately, caller ID spoofing can be easily implemented in Voice-over-Internet Protocol (VoIP) networks. Here, we focus on caller ID spoofing in VoIP services based on Session Initiation Protocol (SIP) architectures, since most vishing attacks are initiated through SIP architecture [7]–[8]. 1. What is Caller ID? According to RFC 3261 [7], a caller ID is provided by the "From" header of an SIP message. The "From" header contains two pieces of information: the display name and the uniform resource identifier (URI), which is a string of characters similar in form to an e-mail address and typically containing a username and host name. The format of a typical SIP message is as follows: [Format] From : "display name" sip:URI [Example] From : "+1-666-666-6666" 2. Ways of VoIP Spoofing Caller ID spoofing techniques modify the display name rather than the URI. This is because the URI is needed in the actual communication process to identify the caller's phone. If an attacker can change the display name of a caller ID into the number of a trusted institution, such as the phone number of the bank that the recipient commonly uses, the phone recipient might think that this call is from a trusted institution. Thus, the attacker can attempt to deceive the recipient by making use of such relationships that rely on trust. There are many ways to falsify a caller ID depending on how the caller ID is modified, such as using a softphone [9], controlling a telephone private branch exchange (PBX) [10]–[11], or using an online service (for example, http://www.spoofcard.com). 3. VoIP Spoofing Mechanism Signaling System No. 7 (SS7) [12] has been standardized for signaling in a telecommunication environment and became the backbone of all worldwide telephony networks. For the seamless integration of the Internet Protocol (IP) network with the public switched telephone network (PSTN), it is important to retain the SS7 ISDN User Part (ISUP) information at the points of interconnection and to use this information for the purpose of call establishment [12]. To understand caller ID spoofing techniques at the system level, we explain how a VoIP phone call takes place in a telecommunication network comprising a PSTN circuit switching (CS) network and an IP network. The architecture of such a network is depicted in Fig. 1. More specifically, a VoIP phone initiates a phone call based on SIP signaling and that is destined to a PSTN/CS number. The SIP messages contain the calling party's identity; that is, its caller ID (see Section II-1). In the example in Fig. 1, the URI and the display name of the caller ID are "victor@hack.com" and "+1-666-666-6666," respectively. The SIP messages access the IP network through a PBX. An SIP/ISUP interworking gateway (GW) is then used to bridge SIP and ISUP networks so that calls originating in the IP can reach ISUP [13] telephone endpoints, and vice versa [14]. In other words, the GW translates SIP messages into ISUP messages. After the translation, the URI (victor@hack.com) is kept behind the GW and only the display name (+1-666-666-6666) is shown to the recipient. Unfortunately, an attacker (the caller) can easily modify the display name of their own caller ID at the PBX. In the example in Fig. 1, the original number +1-666-666-6666 is spoofed to +1-800-432-1000, which could be the number of a recipient's bank. Since any modification that took place before the GW translation remains behind the GW, only the spoofed display name +1-800-432-1000 is now shown to the recipient. Therefore, it is almost certain that the recipient will think that this call is from their bank rather than from a stranger. Figure 1Open in figure viewerPowerPoint VoIP call flow with "caller ID spoofing." As we already mentioned in Section II-2, in vishing attacks, attackers can only change the display name that appears on the screen of the recipient's phone since the URI part should be used for the SIP/ISUP endpoint communication. We should also emphasize that caller ID spoofing is usually performed at the PBX, before the mapping between SIP and ISUP takes place via the GW, since it's hard to compromise a GW in practice. Thus, in this paper, we assume that the GW has not been compromised. III. Related Work Griffin and Rackley [15] introduced general issues relating to vishing attacks. Maggi [16] analyzed typical characteristics of vishing attacks with a collection of detailed reports submitted by victims. Despite the enormous financial loss incurred by vishing attacks, there is little research examining countermeasures to mitigate these attacks. There are some websites that maintain spoofed caller IDs based on reports from victims. However, the numbers in these websites are the display name, thereby the attackers can still perform VoIP spoofing without being affected by systems that filter reported fake phone numbers. In contrast, the proposed system provides an on-demand runtime verification based on a vishers' URI as opposed to their display name. In the case of spam e-mails, which cause the bulk of e-mail traffic, the Spam over Internet Telephony (SPIT) [17] system uses blacklists and whitelists to filter undesired e-mails — this is considered an adequate solution to the problem. Since similar threats are expected to occur in large-scale networks that are based on the IP Multimedia Subsystem (IMS), the 3rd Generation Partnership Project (3GPP) has been working on the standardization of SPIT-similar solutions, so-called protection against unsolicited communication over IMS (PUCI) [18]. However, for time-critical communication (that is, VoIP), systems akin to SPIT limit the use of its filtering mechanism because of the processing time needed for matching each incoming call to the stored lists and the time a user needs to react to the call. Other privacy-preserving solutions for SIP, such as [18]–[20], hide the caller and callee IDs. These solutions have been introduced to address vulnerabilities in protocols used for accounting and charging, as well as to provide a way to protect the service provider and the callee against accounting frauds. These approaches can prevent attackers from using spoofed caller IDs because they hide the caller and callee IDs. Compared to these solutions, the proposed system performs actual ID verification (in collaboration with stakeholders such as internet service providers and network operators); therefore, it provides an additional level of security to the callees. A biologically-inspired vishing attacks detection scheme is introduced in [6]. This scheme analyses the codec parameters from mobile communications and discriminates suspicious calls from others. However, the algorithm proposed in [6] causes performance degradation since all analysis and decisions should be made on the side of the callee. In the iVisher system, a callee initiates the verification process and decides whether the call is suspicious. In addition, in iVisher, most of the verification workload is placed on the core network. Finally, Wang and others [21] analyzed trust issues in VoIP systems and provided evidence that real-world VoIP services are vulnerable to unauthorized call diversion, which could lead to other attacks, such as the redirection of incoming calls to bogus entities. They suggested the use of Secure Sockets Layer (SSL) or Transport Layer Security (TLS) between a callee and the callee's corresponding VoIP server, so as to mitigate VoIP attacks. However, their proposed methods are unable to detect caller ID spoofing attacks. As [22] stated, there is no effective solution to mitigate caller ID spoofing attacks compared to other VoIP security issues IV. iVisher System Having explained the ID spoofing procedure, in this section we introduce a scheme called iVisher, which performs caller ID verification (CIV) to detect if ID spoofing has taken place. 1. Overview iVisher traces back a call through the interworking GW to the PBX that manages the actual caller ID associated with the display name of a given incoming call. In other words, iVisher checks if the user associated with the display name on a recipient's phone is really the one making the phone call. The CIV result is delivered to the recipient to warn them of any suspicious incoming phone calls. In e-mail phishing, it is not easy to interact with the e-mail sender, whereas in vishing, it is possible to communicate with the phone caller since the communication happens in real-time. We take advantage of this real-time interaction to detect whether the caller is a visher. Figure 2 depicts the key elements of the CIV procedure. For a caller ID X, we use Xuri and Xname to denote the URI and the display name of X, respectively. When a visher V initiates a call to a user U with Vuri and Bankname (label ①), the interworking GW stores the Vuri and Bankname and uses this information to translate the SIP messages from V into ISUP messages toward U, and vice versa. The information is also used to derive Vuri and to forward a CIV request (CIVR) to PBX2 (which uses Bankname as display name). Since the GW maintains a list of actual URIs and their corresponding display names for calls having a different display name, deriving the URI from the list is not a trivial task. The translation from a tel URI, which describes resources identified by telephone numbers, in an SIP message to an ISUP format is simple and is described in RFC3398 [13]. The GW fills in the Nature of Address (NOA) for the international telephone number format and the numbering plan indicator (NPI) for the actual value of a telephone number (recommendation E.164) based on the given SIP message header. Figure 2Open in figure viewerPowerPoint Procedure for Caller ID Reachability Analysis (CIV). Depending on user U's network, the ISUP messages are delivered in two different ways, as follows (In the PSTN/CS, only the Bankname is delivered to U (label ②): • In the CS network of Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS), a GW mobile switching center (GMSC) identifies the location of U via an internal database that stores subscribers' information (that is, the visitor location register (VLR)/home location register (HLR) and home subscriber server (HSS)), and delivers the call to U through the serving mobile switching center of U (SMSC-U). • If the user U is located in PSTN, the call is routed through PSTN until it reaches the correct switch that can deliver the call to U. The purpose of the CIV is to help U to decide whether to trust the caller of an incoming call. Since there exist many legitimate reasons to use caller ID spoofing, as described in Section II-2, a simple caller ID deviation check on a GW might not be an effective solution. Therefore, if U is suspicious of the connected call, he/she can initiate a CIVR via GW to PBX2 that manages the Bankname (labels ③–④). Since PBX2 controls the entities using the Bankname, it checks that U is now connected to one of its entities and returns the reports back to U (labels ⑤–⑥). In the subsequent sections, we will describe this procedure in more detail. 2. CIV Procedure Once a VoIP call is converted into a PSTN/CS call at the GW, all intermediate nodes between the GW and the recipient only hold the caller's display name. However, the caller's URI is known at the corresponding interworking GW alone, since this information is needed to perform the SIP-ISUP signal mapping. The iVisher scheme uses the interworking GW to perform CIV, which checks if the caller is using a spoofed caller ID. The CRV process consists of the following three steps: 1) Initiation. Typically, a verification process can be performed either as a part of the call setup procedure or after the call has been established. In the first case, the verification process can be initiated automatically based on a user's (that is, a callee's) service subscription. However, integrating CIV into the call setup process incurs call setup delays. In the second case, only selected calls are subject to the CIV process, which results in lower network loads. iVisher supports both options for initiating the CIV procedure, and they are called network-initiated CIV and user-initiated CIV, respectively. - Network-initiated CIV. This step can also be performed as a supplementary service for every incoming call without the need for U to initiate the CIV process. In this method, the CIV service is only provided to users who subscribe to the service. Therefore, when there is a call destined to a subscriber of the CIV service, the GW automatically initiates the service. For this, the GW first checks that Vuri is equal to Bankname. If the GW detects any deviation and U subscribes to the CIV supplementary service, then it invokes CIV procedures without human intervention. - User-initiated CIV. If U suspects that the incoming call, with display name Bankname, is a fake one, U will initiate the CIV process by asking the corresponding GW to test whether the actual subscriber corresponding to the display name Bankname is calling U (label ③). Dual-tone multi-frequency signaling (DTMF) [23] or user-to-user signaling (UUS) [24] can be used for the initiation of CIV. Note that PSTN terminals can only use DTMF for the initiation. 2) Verification Request. Upon receiving a verification request for Bankname (label ③), the corresponding GW will take the following actions: a. It finds the stored URI (Vuri) that corresponds to the Bankname used to initiate the call between V and U. Since this request is performed as part of the call establishment (for network-initiated CIV) or additional signaling over existing telephone lines (for user-initiated CIV), the GW can easily derive URI Vuri from the request. b. It generates a CIVR message consisting of Vuri and Bankname (detailed examples and behaviors of the GW are described in Sections V-1 and V-2). c. It forwards the CIV message to the PBX (PBX2 in Fig. 2) that corresponds to the actual subscriber (they will have Bankname as their display name) to check whether this subscriber is now calling to U (label ④). It is safe here to assume that major enterprises, such as banks and government agencies, use PBX systems to allow internal users to switch between calls placed on local lines and calls placed on external lines. The PBX is owned and operated by the enterprise rather than a telephone company or service provider. Such enterprises can protect their customers from vishing attacks by deploying the iVisher system at their PBX. The existence of an iVisher-compatible PBX is a fundamental requirement of the iVisher system. 3) CIV processing and response. Upon receiving the CIV message (label ④), the PBX2 acts as follows: a. It creates a Bankuri list (note that more than one Xuri may correspond to the same Xname) of its registered subscribers that share the Bankname and that are currently online. b. It checks whether any Bankuri in the list is the same as Vuri in the CIVR. In many typical telecom systems, there is a PBX in a company that manages all outgoing calls for the purpose of the calling line identification presentation (CLIP) service, which provides the information of the calling party. Such PBXs authenticate the calling party and insert a common display name into all outgoing calls made by their registered subscribers. This allows the PBXs to track all active call-related information (such as the caller ID and callee ID of a call). In the CIV procedure, such information is used to generate verification results. PBX2 reports the verification results to the corresponding GW (label ⑤), and then GW forwards the results to U (label ⑥). As addressed previously, the CIV results for a call can be delivered to the recipient using various implementation technologies. For example, the SMS message can contain relevant information about the spoofed call, such as the caller ID, display name, and the caller's location, so that if the caller ID is not identical to the display name or the call has originated from a foreign country, the recipient can be in doubt about the validity of the call. 3. Implicit Spoofing As explained earlier, one of the fundamental requirements of the proposed methodology is the availability and use of an iVisher-compatible PBX system by the involved enterprise. This is because the PBX is responsible for acknowledging receipt of a CIVR and reporting the ID verification result. If the displayed name is an invalid number or corresponds to any random PSTN/CS number, the request will not be routed to any iVisher-compatible PBX and the GW will not receive any response for the request. Such a lack of response can be used as an implicit indication of spoofing. In this case, a timeout can be applied to identify these calls. The duration for the timeout should be long enough so that the GW has to receive all responses (should they exist). However, since the CIV process is performed independently from the call setup procedure, it does not incur any call setup delay. V. Suggested Implementation It is clear from the above that a series of modifications are required in existing systems and protocols to accommodate the iVisher system and its functions. Fortunately, all these modifications and the required signaling exchange can be easily implemented at the application layer. Now, we outline the entities involved in the proposed CIV process and the expected changes required of them. 1. User Terminal First of all, if the CIV process is triggered by the network as a supplementary service, no modification is required on the end user's terminal. The terminal only needs to receive the result of the CIV process, which can be provided easily at the application layer by existing services. Various technologies, such as Short Messaging Service (SMS) or background audible tones, can be used to deliver the CIV result to the recipient U, according to the capability of terminals. For the scenario where the end user initiates the CIV process, the application that provides the voice-call functionality at the end user's terminal should be modified to allow the exchange of a CIVR during a phone call. In this case, UUS or DTFM can be used to initiate the CIVR. Figure 3 illustrates an example of a CIV initiation message using the UUS protocol — UUS is a service that allows the end users' terminals to exchange information for up to 128 octets during a call. In this figure, the "CIV discriminator" and "Message type" fields indicate that this is indeed a CIVR message (lines 1–2). The following fields (lines 3–5) illustrate the information (that is, type, length, and content) about the display name Bankname. Figure 3Open in figure viewerPowerPoint Example of CIVR message using UUS. 2. GW A GW converting SIP to ISUP plays a key role in the CIV check. Since the GW behaves as a proxy on behalf of the recipient terminal, it requires functions to handle CIV messages, such as being able to modify and forward a request. In other words, when the GW receives a CIVR, it should check the actual caller ID of the call, add the caller ID into the request, and then forward the request to the number addressed in the display name of the call. A function must also be implemented in the GW to deliver the CIV results of the request to the recipient terminal using, for example, SMS or audible tones. While this is a significant and challenging change, operator-sponsored forums like Open Mobile Terminal Platform (OMTP) are working with key mobile operators to discuss and recommend mobile terminal requirements to help protect against threats such as malware and fraud attacks. As incidents of vishing continue to rise, it seems likely that having the availability to selectively filter such a fraudulent offence will, in time, persuade operators to upgrade their systems. Note that the CIV message processing can be implemented only in software on the GW without incurring unacceptable costs; therefore, no extra hardware is introduced. An attacker can use the proposed iVisher countermeasure scheme to launch a denial-of-service (DoS) attack on a GW. To prevent such attacks, an intrusion detection system (IDS) [25] recognizing deviations from expected verification procedures can be integrated into the iVisher system. 3. PBX of Concerned Enterprises Furthermore, the PBXs of involved enterprises need to be modified to process the CIVR messages and forward the CIV check results to the corresponding GW. These PBXs have to maintain a list of caller IDs of registered subscribers who use the same display name. When these PBXs receive a CIVR, they check whether the caller ID in the request is on the list of registered caller IDs. If the caller ID is not on the list, then they reply to the GW with detailed information. This checking process on the PBXs could allow an imposter to retrieve sensitive information (for example, the presence of an employee at a company); therefore, it poses concerns over privacy. For such a concern, we could add a network behavior analysis function on the GW to detect suspicious activities among network traffic. Intrusion detection techniques [26]–[27] can be effectively used to implement this functional component. We note that a lightweight IDS [25] (for example, using rule-based misuse detection) might perform well enough since there are only a few attack patterns for the CIVR protocol (for example, a high rate of CIVRs from the same source), unlike complex rules for a typical host machine. Since the PBX systems belong to enterprises that are willing to protect their customers from vishing attacks by deploying the iVisher system, such modifications can be easily implemented. VI. Performance Evaluation There are two important criterions for evaluating the signaling performance of protocols for SIP and PSTN/CS interworking: signaling load and call setup delay [28]. Here, we discuss the signaling overhead incurred by the CIV process through numerical analysis (Section VI-1) and simulation on a real VoIP service (Section VI-2). More specifically, our numerical analysis focuses on the SIP-ISUP call setup signa