USING CAPTCHAs TO MITIGATE THE VoIP SPAM PROBLEM

Second International Conference on Computer Research and Development USING CAPTCHAs TO MITIGATE THE VoIP SPAM PROBLEM Ismail Ahmedy Department of Computer System and Communication Faculty of Computer Science and Information System Universiti Teknologi Malaysia Johor, Malaysia ismailahmedy@um.edu.my Marius Portmann School of Information Technology and Electrical Engineering University of Queensland Queensland, Australia marius@itee.uq.edu.au Abstract Voice over Internet Protocol (VoIP) is one of the emerging technologies today. This application offers the user a service by which one can call another person at a low cost as compare with traditional phone services. One drawback to the Internet is spam, which are unsolicited or unwanted objects which often appear as unwanted messages in various email applications. For VoIP, spam refers to unsolicited and unwanted calls by the VoIP user. In this paper, we have purposed a solution to prevent the spam in VoIP. The CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Human Apart) method aims to determine whether the call is coming from a human or a machine. The key contribution of this paper is a proof-of-concept implementation of a CAPTCHA mechanism to prevent VoIP Spam. Keywords-component; CAPTCHA, VoIP, SPAM, VoIP user, integrate, VoIP client software I. INTRODUCTION Voice over Internet Protocol (VoIP) is a technology which uses packet switched networks to transmit real voices via the Internet. This technology also can be referred as IP telephony, Voice over broadband or Internet Telephony. The traditional telephony service which is PSTN (Public Switched Telephone Network) is circuit-switched, but VoIP uses packet networks since it uses Internet Protocol (IP) to transmit the voice packet. The VoIP application uses the Session Initiation Protocol (SIP) to establish calls between two VoIP users. Spam or unsolicited messages is one of the major problems for e-mail services. Since e-mail uses the Internet as a medium for communication, the problem of spam can be a major problem for VoIP as well since it is provides a similar service to e-mail. VoIP offers a low cost beneficial on telephony services [1]. This advantage attracts the spammer to send spam message using VoIP application since it offers a cheaper services rather than tradition telephony services. As far as we are concerned, the spam message in VoIP can be annoying the VoIP user since the message is playing automatically by itself. There are different types of VoIP spam [2]: i. Call Spam: Number of calls to attempt user VoIP. If user answers the call, the user hears a recorded message and the call ends when the message finishes. This type is used by spammers on PSTN for marketing and is used widely by telemarketers as well. This type of spam is also known as Spam over Internet Telephony (SPIT). ii. IM Spam: This type, which is similar to email spam, describes the bulk of unsolicited messages where the spammer uses Instant Messaging (IM) to send spam to the VoIP user. This type of spam is also known as Spam over Instant Messaging (SPIM) iii. Presence Spam: This is similar to IM Spam since it consists of a large number of unsolicited set of presence requests. It means that the message is trying to get authenticated or white listed by the VoIP user. This is also known as Spam over Presence Protocol (SPPP). In this paper, we are focusing on the call spam or SPIT problem in VoIP applications. As we know, most of spam in VoIP is in the form of automatic voice play which is a SPIT. SPIT is sending to the large number of user and when user accepts the call from the machine that sends the SPIT, the voice message is automatically play. The scenario is quite different with the email spam since the VoIP application is synchronous communication and email application is asynchronous. VoIP is synchronous since the communication initiates at the same time when the sender wants to communicate with the receiver. The receiver and sender must be connected at the same time. In contrast, email is asynchronous since the receiver does not have to be connected with the sender to establish communication. When the sender sends a message, the message is stored on a specific server and is unveiled by the receiver at a time of his choosing. Hence, this communication is asynchronous since the receiver does not connect with the sender at the same time. 978-0-7695-4043-6/10 $26.00 2010 IEEE DOI 10.1109/ICCRD.2010.85 136

Next section will describe on the Session Initiation Protocol (SIP) environment. Later on, the framework of the proposed method will be shown. A. Session Inititation Protocol (SIP) SIP is one of the protocols for the VoIP application which has been standardized by the Internet Engineering Task Force (IETF) [3]. It is used for the signaling process in the telephony application to initiate, establish and terminate calls. There are two general components for SIP in the VoIP application environment: User Agent (UA) and SIP proxy. UA acts as a VoIP client while UA can be referred to as a client in SIP architecture. The call establishment starts on the UA side before it through to the other user. The SIP proxy is responsible to establish calls when a call request has been made by the UA. According to [3], there are four logical components which make up the basic SIP architecture: UAs, registrars, proxy and redirect servers. UA acts as a client basis where it is responsible to initiate the SIP request to another UA which is also a client. The registrars are responsible to manage all the UAs in the same domain so it knows the SIP domain to which each client belongs. The proxy server acts as a router to forward the SIP request from UA to the UA destination. Redirect servers are responsible to redirect the SIP request to another SIP network where the destination UA might be. II. RELATED WORKS There are number of method which has been implemented to prevent the VoIP spam problem. In method [8], the author uses a decoying system to block the SPIT senders. To block these unwanted calls, the author suggests a decoy be used to detect legitimate calls to the user. The decoy should be a non-existing user in the same proxy. This decoy should have an address and the address should be posted on the Internet where the address can be detected as a decoy by humans but not by machines. When the caller attempts to send to the decoys address two or more times, the user is automatically blocked. When the decoy receives or is hit by spammers, it automatically stores the information regarding the spammers and informs all other users about this sender s information. The users can put the sender information received from the decoys into their black lists account. Unfortunately, this technique is not foolproof as it is dependent on the decoy s address. If the spammer learns that a decoy has been set up, the spammer can change his information each time he sends spam. Signal analysis method has been suggested by [9] where it uses a signal in the voice message to detect all SPIT messages coming through the Gateway or SIP. The problem addressed here is that the caller recipient does not know the caller s identity and, of course, the caller could be a spammer. The author shows three ways to detect a pattern from spammers. One of the detection methods used to identify the majority of spammers sending SPIT over the network employs a unidirectional process [9]. The spammers use the FROM: header field which targets the VoIP network proxy. As usual, all users are registered in the SIP proxy. From the SIP proxy, the message can be spread inside the proxy or to another proxy. This technique is not applicable to the VoIP spam problem since the specific technique involves observation of the SPIT attack pattern. It also requires the VoIP user to observe all calls from any caller, which makes the technique quite inefficient and inconvenient for the user. In research paper [10], the author used a grey level as a threshold to determine whether the caller is a spammer or not. The term grey indicates its position on a level between the white and black lists [10]. The white and black lists are commonly used in the email system to prevent spam in email applications. All calls are analyzed by the PMG algorithm to determine whether they are VoIP spam or not. The result has a grey level value to be determined at a certain threshold. If the grey level value is higher than the threshold value, the call is identified as spam and blocked. The grey level of the caller is not permanent which means that it can change anytime regardless of the analysis of the calls. The black list approach dictates that the caller is permanently blocked as the caller is unable to remove himself from the user black lists. PMG analyses call patterns when a user intends to establish calls. The grey level of the caller is determined by analysing the way users make the calls over time [10]. The user s calls are blocked when the grey level reaches the limits of the given threshold. As previously mentioned, the PMG method is not permanent like the black list approach, as the caller stops sending spam within a certain time [10]. This scenario makes the grey level decrease and the caller is permitted to make calls again. III. CAPTCHA METHOD CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Human Apart) uses the Turing Test approach to determine whether the user or caller is human or machine [4]. Email is one application that uses the CAPTCHA method to prevent spam entering the user s mailbox. The strength of this method and its success in preventing spam in email made it appealing as a means of preventing spam in VoIP applications. Figure 1 shows an example of CAPTCHA image. Fig. 1: Example of CAPTCHA image The basic idea of this method is to implement a challengeresponse application for call establishment in VoIP application. As shown on figure 2, Alice is trying to establish a call with Bob and Bob challenge Alice with CAPTCHA images to prove Alice is a human rather than a machine. Alice needs to response with the correct answer of the CAPTCHA in order to establish calls with Bob. The main purpose of using the challenge-response is to prevent the spammer from establishing call with the VoIP users. In order to implement this approach, the CAPTCHA 137

application needs to be integrates with the existing UA clients. The CAPTCHA application has been implemented as a pop-up application in the existing UA client. In the next section, the implementation on this method will be described. Fig. 2: Challenge-Response Scenario for CAPTCHA Method IV. IMPLEMENTATION Basically, the UA functionality is to establish a call between the UA and another UA. All the processes for establishing a call, initiating a call, and sending the SIP message request and response are done in the UA client software. The approach solution using a single independent window program to shows a CAPTCHA image and to receive an input which is the answer from the user. The window program has been implemented as a pop-up window application in the UA client where the pop-up window only executes when the UA intends to initiate a call with another UA. The pop-up window is not executed if the UA receives a call from the other UA. The preliminary research on this approach is to find a suitable way to fit the pop-up window program into the existing UA client to ensure all the processes mentioned above execute correctly. While most CAPTCHA applications are used in an Internet based environments, the proposed solution has been implemented in the UA client applications. This application has used only one CAPTCHA image which is shown in the CAPTCHA window application. This image is identified by a URL (Uniform Resource Locator). For example, the URL for the CAPTCHA image is http://10.1.1.2/try/images/captcha1.jpg where this URL points to the location of the CAPTCHA image. In order to send the URL to the CAPTCHA pop-up window application, the TCP connection has been used for this purpose. The TCP port is open when the user starts the call establishment process. When the user starts the call, the recipient is acknowledge it with the URL message of the CAPTCHA. Once the user has answered the CAPTCHA correctly, the call is established. A. MjUA SIP UA Most VoIP applications are open source at the present time. As mentioned before, the approach for spam solution in VoIP is to be used in the VoIP client application software. One of the open source has been selected to implement this research to see whether this approach is suitable on each open source VoIP client. For this research, we have selected MjUA [11] from MjSIP application as a VoIP client for implementing the approach and integrate it. The main outcome of this project research is: the program is able to block spam calls without user interference. The program automatically blocks any attempted call that is suspected to be spam with a challenge program embedded in the VoIP client. Each call that attempts the VoIP client is not permitted to establish or request a call unless the sender provides the correct CAPTCHA answer when challenged. Figure 3 shows the connection to Alice finally established after Bob answer the CAPTCHA correctly. In contrast to Figure 3, Figure 4 shows the VoIP client is blocked from establishing a call with Alice because the answer to the CAPTCHA is not correct. A pop-up window has appeared to alert the user that the call is not authorized. Bob enters the correct answer Fig. 3: MjUA client establishes call after correctly answering the CAPTCHA Fig. 4: MjUA client is not permitted for established calls The approach method employed in this VoIP client has proved that it can block any unsolicited calls without interrupting the user. The program is able to prevent spam while hiding the process from the user itself. The pop-up 138

window application makes it more interactive for the user who intended to call somebody. The method approach guarantees the calls can only be made by legitimate users since the pop-up application is embedded into the VoIP client and only a user permitted to use the VoIP client can make a call. This proves that a machine cannot send spam to the VoIP client who used the program as it will challenge any incoming request who intends to establish a call. The used of URL approach for showing the CAPTCHA has shown that it can manage the image perfectly. The CAPTCHA image itself does not need to be sent through the network since the image size can slow the whole process. Instead of sending the CAPTCHA image through the network, only a URL is sent; this approach is faster and more efficient. V. DISCUSSION AND FUTURE WORK The SPAM prevention method has proved that it can block any unsolicited calls without interrupt the user. The program itself has the ability to do the prevention with hiding the process from the user itself. The pop-up window application makes it more interactively to the user who intended to calls somebody. The solution also can guarantee the calls can be made from the legitimate user since the popup application is embedded into the UA client and only the user who permitted to use the UA client can makes a call. This proof that a machine can t send a SPAM to the UA client who used the program since it will challenge any incoming request who intended to establish a call. This solution is mainly focus to block or denied any SPAM in VoIP and has been implemented without changing any structure in the SIP protocol program in the MjUA client application. As mentioned before, SIP protocol is used to establish a connection between two users in VoIP application. The solution ability was to challenge any intended calls makes from any users before the SIP establishment can be executed. The CAPTCHA URL approach has shown that it can manage the image in perfect way. The CAPTCHA image it self doesn t need to being send through the network since it can slow the whole process because the image size it self. The only thing that has been done is a URL is being sent through the network instead of the CAPTCHA image. This approach can utilize the whole timing process and a lot faster if sends the image through the network. The pop-up application just needs to use the URL for showing the CAPTCHA image. The pop-up application has been enabled in the program to showing the image using an URL. The user doesn t have to wait for the image to be appearing since it doesn t take a long time for the URL to locate the image. The only problem in this approach is only one CAPTCHA image is being used for CAPTCHA challenge. To overcome this problem, the CAPTCHA handler should select randomly CAPTCHA image from the CAPTCHA location. The answer that has been received is being checked within the CAPTCHA program. The approach doesn t seem well because it checked in the program itself. If the user can extract the program, all the answer can be seen and the attacker can used all the answer to be programmed for guessing every CAPTCHA image. Even though the extraction of program seems to be impossible, but the attacker can learn the answer in many ways since that s the attribute of the attacker. This weakness seems the only flaws in the solution implementation. In the CAPTCHA URL sending process, the only thing that has a drawback is that the particular process is not entirely in the SIP protocol itself. As mentioned before, the sending process used TCP connection to sends the CAPTCHA URL before the call establishment process can be executed. This should have a problem when two different UA clients want to communicate to each other since the implementation on each UA has a different way of doing it. Call establishment in SIP is a standard in the VoIP application. If the SIP call establishment process can be restructured to implementing the CAPTCHA challenge method, it should not be a problem if two different UA clients want to communicate since every UA clients need to follow the standard for call establishment in SIP. The restructure process need a quite of time since the protocol for the call establishment has been implemented using the SIP standard. To restructure it, the SIP call establishment needs to be reorganized with some challenge procedure since the CAPTCHA method needs to be implemented in the call establishment process. The proposed solution outcome also has made the user more comfortably since the challenge didn t involve the user entirely. The user only knew there is a call request when the CAPTCHA challenge has been finished. The call initiation process can t be executed unless the CAPTCHA challenge is successfully done. The program that has been embedded has been shown that it will deny any call initiation process until the challenge is done. VI. CONCLUSION The key contribution of this paper is a proof-of-concept implementation of a CAPTCHA mechanism to prevent VoIP spam. The spam prevention in VoIP that has been implemented on this project provides an advantage especially from the user s point of view. We have demonstrated that the CAPTCHA method can be applied in the VoIP applications. The method also has been adapted to fit in with the selected VoIP client during the execution of the entire process. As mentioned before, there are some limitations in our implementations. The purposed solution that we ve come out has shown the successful for preventing spam in VoIP. This solution can be expend to integrate with the SIP protocol to make the solution approach been acceptable by all the VoIP client application since the SIP protocol is a standard for the VoIP application. REFERENCES [1] So Young Park; Jeong Tae Kim; Shin Gak Kang, "Analysis of applicability of traditional spam regulations to VoIP spam," Advanced Communication Technology, 2006. ICACT 2006. The 8th International Conference, vol.2, no., pp. 3 pp.-, 20-22 Feb.2006. [2] Rosenberg, J., Jennings, C., The Session Initiation Protocol (SIP) and Spam, RFC 5039, January 2008. 139

[3] Schulzrinne, H.; Rosenberg, J., "The Session Initiation Protocol: Internet-centric signalling," Communications Magazine, IEEE, vol.38, no.10, pp.134-141, Oct 2000. [4] Luis von Ahn, Manuel Blum and John Langford, How Lazy Cryptographers do AI In Communications of the ACM, Feb. 2004. [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, SIP: Session Initiation Protocol, RFC 3261, June 2002. [6] Shirali-Shahreza, S.; Movaghar, A., "A New Anti-Spam Protocol Using CAPTCHA," Networking, Sensing and Control, 2007 IEEE International Conference on, vol., no., pp.234-238, 15-17 April 2007. [7] Hoanca, B., "How good are our weapons in the spam wars?," Technology and Society Magazine, IEEE, vol.25, no.1, pp. 22-30, Spring 2006. [8] Salehin, S.M.A.; Ventura, N., "Blocking Unsolicited Voice Calls Using Decoys for the IMS," Communications, 2007. ICC '07. IEEE International Conference on, vol., no., pp.1961-1966, 24-28 June 2007. [9] MacIntosh, R.; Vinokurov, D., "Detection and mitigation of spam in IP telephony networks using signalling protocol analysis," Advances in Wired and Wireless Communication, 2005 IEEE/Sarnoff Symposium on, vol., no., pp.49-52, 18-19 April 2005. [10] Dongwook Shin; Ahn, J.; Choon Shim, "Progressive multi gray-leveling: a voice spam protection algorithm," Network, IEEE, vol.20, no.5, pp.18-24, Sept.-Oct. 2006. [11] MjSIP VoIP Client http://www.mjsip.org/mjua.html 140