JOURNAL OF ELECTRONIC SCIENCE AND TECHNOLOGY, VOL. 10, NO.

3, SEPTEMBER 2012

215

Wireless Application Protocol for Potential Threats to Mobile Agent Network Security
M. Indra Sena Reddy, K. Subba Reddy, P. J. Bhatt, and Rajeev Chetwani
AbstractThe wireless application protocol (WAP) protocol is now the leading standard for information services on wireless terminals like digital mobile phones. By the use of WAP, wireless devices, like mobile phones, are possibly infected with virus and worms. Though up to now there is no such attack, as the usage of script languages increases, there is a chance of malicious code injection. This paper discusses the threats with current WAP protocol, and how changes in the protocol and the increase in its usage will enable entry of real viruses. Future threat scenarios are presented along with suggestions to avoid these problems. Index TermsMobile agent, wireless application protocol. security, threats, mobile agent, its life cycle, components and system architecture can found in more detail in [5][8]. Security of mobile agent is essential in any mobile agent based applications. Besides, the security of agent platform is also important. To discuss the security aspects of a mobile agent system, we consider the following security services: confidentiality, integrity, authentication, authorization, and non-repudiation. Confidentiality. Confidentiality ensures that data and code carried by an agent are not accessible by unauthorized parties (unauthorized agent or unauthorized agent server). Integrity. Integrity guarantees that agents code and baggage cannot be altered or modified. Authentication. Authentication enables a mobile agent to verify its identity to an agent server as well as an agent server to a mobile agent. Without authenticity an attacker could masquerade an agents identity and could gain access to resources and sensitive information. Authorization. Authorization ensures that an agent who is allowed can access the resource or information. Non-repudiation. Non-repudiation assures that the agent-server or the mobile agent cannot repudiate the actions it has performed. Threats in a mobile agent system can be categorized as in [8]: Threats from mobile agent to agent server. Threats from agent server to mobile agent. Threats from mobile agent to mobile agent. Potential threats from a mobile agent to an agent server can be listed as: illegal access to services and resources of agent server, steal or reveal of secret information from server, denial of service, damage of software and data, penetrate virus/worms, and finally action repudiation[8]. Similarly, an agent might face some threats from an agent server, such as illegally accessing to mobile agents resources, stealing the code and valuable information carried by agent, revealing the private or sensitive action performed by mobile agent, damaging the code and baggage, executing agents code incorrectly, sending an agent to unintended destination, and cheating an agent with false information, and information or action repudiation[8]. Finally, an agent could face the threats from another agent. These threats are stealing agent information, conveying the false information, rendering extra messages, repudiating service or action of information, and unauthorized access[8].

1. Introduction
A mobile agent is an independent piece of code with autonomy and mobility features[1]. A mobile agent can migrate from one host to another autonomously to resume its execution[2]. Here autonomy means to take decision and to execute an action without direct user or human interaction. One of the main advantages of using mobile agent is that it reduces network traffic load noticeably as it does not require any continuous connection or communication between the server and the client[3]. Besides, the use of mobile agent makes access of remote resource more efficient and flexible. Agent can adapt dynamically to an environment and can operate in heterogeneous environments. It is robust and fault tolerant. Though origin of the term agent was in the field of artificial intelligence, it has gained a lot of potential in the field of network monitoring, analysis, and intrusion detection/ prevention system[1]. Besides these, the mobile agent can also be used for information retrieval, server configuration backup, dynamic software deployment, etc.[4] The use of
Manuscript received May 24, 2012; revised July 23, 2012. M. I. S. Reddy, K. S. Reddy are with the Department of Computer Science & Engineering, RGM College of Engineering and Technology, Nandyal (e-mail: Mir555mittapalli@gmail.com; mrsubbareddy@ yahoo.com). P. J. Bhatt and R. Chetwani are with the ISRO Satellite Centre, Banglore (e-mail: bhat@isac.gov.in; rajeev@gmail.com). Digital Object Identifier: 10.3969/j.issn.1674-862X.2012.03.005

216 Encoded request

JOURNAL OF ELECTRONIC SCIENCE AND TECHNOLOGY, VOL. 10, NO. 3, SEPTEMBER 2012

Client WAE user agent

WAP gateway TTP request Original server Translator Web server HTTP response

WML gateway. Here is an example of a sample WML file or deck. <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/ wml_1.1.xml"> <wml> <card id="card1" ontimer="#card2" title="Multiple Card Demo"> <timer value="100"/> <p align="center"> Card 1 </p> </card> <card id="card2" title="Multiple Card Demo"> <p align="center"> Card 2 </p> </card> </wml>

Encoded response

Encoder Decoder

Fig. 1. WAP model.

2. WAP Model
Wireless application protocol (WAP) programming model is similar to the current HTTP model. WAP consists of a client, gateway, and origin server [9][12], as shown in Fig. 1, and works as follows. The user makes a request for content. The wireless application environment (WAE) user agent encodes the request. The WAE user agent sends the request to the gateway. The gateway decodes the request. The gateway translates the request (to HTTP) and sends it to the origin server. The origin server passes back the appropriate content. If necessary the gateway translates the content (HTML to WML). The gateway encodes the content. The gateway sends the encoded content to the client. The WAE user agent interprets the encoded content and presents it to the user.

4. Wireless Markup Language Script

Wireless markup language script is an extended subset of JavaScript. WML script allows scripting ability with the WAP framework. The purpose of WML script is to extend the capabilities of WML. WML is static and thus, there is no way to modify or extend WML without modifying the source itself. For example, WML script could be utilized to check the validity of user input locally, eliminating a round-trip to the WML gateway[15]. In addition, in the future, WML script may be utilized to access facilities of the device, such as making phone calls, sending messages, and accessing the address book or SIM card. WML script provides the framework. WML script Standard Libraries provide the extended functionality. The current version of WML script is version 1.2 and its standard libraries are version 1.3. Here is an example of a sample WML script file. extern function foobar(foo,bar) { if (foo == bar) { Dialogs.alert("Foo is equal to bar!"); } else { Dialogs.alert("Foo does not equal bar!"); } }

3. Wireless Markup Language

Wireless markup language (WML) is an XML (extended markup language) language. WML adheres to the Universal Character Set, ISO/IEC-10646 specification. WML syntactic constructs are inherited from XML. For this reason, WML appears similar to HTML and the conversion from HTML to WML may be trivial in many cases. WML is a static language and thus provides limited properties to form malicious contents[14]. The current version of WML is version 1.3. WML content is often addressed as WML decks and cards. A deck is analogous to a book in which there are many pages, or cards. On the origin server, a single file represents a deck and may contain multiple cards. Cards are designated with card tag eliminators: <card id=first> <!-First Card Content Here </card> <card id=second> <!- Second Card Content Here </card> A request for content generally returns the whole file and thus the deck. This allows the user agent to request and more importantly re-request cards without re-contacting the

5. WAP Code Threats

By the strictest definitions, there cannot be WAP viruses. WAP is simply the protocol like SMTP (email). However, there potentially could be WML or WML script viruses or related malware.

REDDY et al.: Wireless Application Protocol for Potential Threats to Mobile Agent Network Security

217

5.1 WML The latest specifications of WML rule is out the possibility of a virus. However, there is the possibility for joke or Trojan type content[15]. For example, a WML card named X could auto-load another WML card named Y. The WML card Y could in return auto-load X leaving one in an infinite loop. This type of trick depending on the device can be canceled or one can quit browsing. Upon restart of the browser, one can start back at the home page and then avoid visiting WML cards X or Y. If the device resources become overloaded or if cancel or quit features are unavailable, one may have to reset the device. Another example could be a WML page that appears to contain legitimate information. Unexpectedly, the page could redirect one to a screen, which prompts one for their PIN code, which appears to be generated from the phone. However, this screen instead is a form that sends the PIN code to an anonymous web site. In the two scenarios, while possibilities are extremely at low risk, both scenarios require the user to specifically visit the pages and the resultant imposition is negligible. Future revisions of WML probably will remain generally un-exploitable. WML by nature is static limiting the possibility for replicating malicious codes. Currently, there is no HTML virus and thus, WML virus is highly unlikely. 5.2 WML Script The latest specifications of WML script rule out the possibility of viruses. However, similar to WML, there is the possibility of joke or Trojan type content. Both previous examples of infinite loops or fake content can be performed with WML script. Future specifications alluded to by current documentation of WML script may allow viruses or more specifically worms and potentially more dangerous Trojans. The documentation clearly states. The following list contains some capabilities that are not supported by WML: Access to facilities of the device, for example, on a phone, allow the programmer to make phone calls, send messages, add phone numbers to the address book, and access the SIM card, etc. WML script is designed to overcome these limitations and to provide programmable functionality that can be used over narrowband communication links in clients with limited capabilities. Having programmable access to the device raises the possibility for worms. For example, one may view WML content that secretly sends an SMS with the URL to all of your contacts. They, in turn, believing you have sent the URL, view the page and likewise unknowingly send all their contacts the URL. In addition, having access to information on the phone may allow Trojans to gather

information by contacting phone numbers and names and sending them to anonymous websites[15]. 5.3 Injectors There is a possibility of an injector. Most WML files are stored on a traditional web server. This web server could be infected with malware, which injects malicious code into WML (script) files. This allows the malicious WML (script) code to spread to many WML (script) hosting sites via a traditional virus. For example, a Windows worm could be constructed to inject the above code examples into any WML (script) files that are found. This would allow the malicious code to spread via the Windows virus. However, a true cross infector cannot be possible. That is, the modified WML (script) files can not be able to recreate the Windows virus.

6. WAP Push
The WAP specification defines a push architecture, which allows information to be transmitted to a device without an explicit request from the device. Fig. 2 illustrates the WAP push architecture.
Client Push over-the-air protocol Push proxy gateway Push access protocol Push Initiator

Fig. 2. WAP push architecture.

A real-life example may be a real-time new mail indicator. The push initiator may be an e-mail server. The e-mail server via PAP (push access protocol) notifies the PPG (push proxy gateway) that there is new mail for the client[13]. The PPG verifies the identity of the e-mail server and the client requested such services. Then, via push OTA (push over-the-air protocol), the PPG passes a service indicator or other contents to the client. The client then processes the service indicator (which may include ignorance and identity verification) and potentially launches a service, such as a request for e-mail. The WAP Push architecture allows for any content-type delivery, although the client and PPG may limit the acceptable content-type. Clearly, the acceptance of executable content that may be malicious provides a potential vector of delivery. However, today the majority of push implementations are limited to service indicators described below. 6.1 Push Proxy Gateway The PPG is responsible for authentication of the push initiator including verification that the client requests such services. This prevents potential spamming and denial-of-service attempts on the client. In addition, this reduces a vector of delivery of potentially malicious codes to the client. Should there be a bug in the verification

218

JOURNAL OF ELECTRONIC SCIENCE AND TECHNOLOGY, VOL. 10, NO. 3, SEPTEMBER 2012

scheme of the PPG, clearly this presents a major vector of delivery to the client. A rogue push initiator could transmit malicious code be a client unknown to the client user[11]. 6.2 Push Content and Service Indicators The WAP push architecture allows for any content to be passed. However, current implementations generally restrict contents to service indicators. A service indicator is an application of XML 1.0. A service indicator itself cannot hold a virus. A service indicator provides a small amount of information to the client such as notification that new mail has arrived. In addition, the service indicator may provide additional information such as the mail server to contact for receipt of the new mail. 6.3 Client Interaction The client may also ignore push content even if already authenticated by the PPG. Service indicators are generally the majority of push content. In addition to providing notification, a service indicator can request the client invoke a service such as a mail reader. Being able to remotely activate services on a client obviously provides for potential abuse. However, in addition to the authentication of the push initiator, any invocation of client services must be preceded by user interaction, according to the specification. This eliminates the possibility of rogue push initiators executing code remotely via WAP push. Obviously, any bugs in this scheme could lead to potential abuse.

administrator could assure his systems are free from malicious content, the end user could not be assured any origin server visited is free from malicious content. 7.3 WAP Gateway Solution A solution at the WAP gateway seems ideal. All WAP content must pass through a WAP gateway before reaching the device providing for a single point of protection. At the gateway, a scanner could be placed in multiple places. A scanner could be placed after the receipt of WML or HTML content from the origin server or after the conversion of WML or HTML to binary representation. Fig. 3 represents the potential placement locations at the gateway.
Gateway Client S c a n n e r
Encoder Scanner

HTML translator

S c a n n e r

Original server

Fig. 3. Gateway location.

Most anti-virus products currently have the technology to detect WML or WML script threats. These engines would simply need to be wrapped to interact with the WAP gateway components.

8. Conclusions
Currently, WML (script) does not pose a great threat for malicious contents, it may do in the future. Before such threats become possible, the WML (script) specifications must provide more robust functionality. Once the functionality is possible, WML (script) malware still may not be a large threat. Other environmental factors from market penetration to social engineering play a role in the ability of threats to spread. The role of these factors is outside the scope of this document. In general, security vendors should already have the technology to detect such threats. Security product engines need to be wrapped to interact with the appropriate components or run on the appropriate operating systems. Finally, users should extend their safe computing practices to such devices and avoid questionable executable content.

7. Solution Placement
This section does not discuss the technical solutions of how to detect such threats, but only discusses the advantages and disadvantages of solution placement. 7.1 On-Device Solution Placing a scanner on the device can be effective in blocking content, but may be resource intensive and difficult in regards to development. WAP devices vary from phones to personal digital assistants (PDAs) and each of the devices may be running on non-updatable and proprietary operating systems. One could not create a single solution that could be placed on all devices. In addition, updating the firmware or software may be problematic. While possible, on-device solutions do not seem practically viable. 7.2 Origin Server Solution Origin servers are generally run on popular operating systems such as Unix or NT. Existing products can scan these servers. The existing products would need to be updated with new signature files to detect malicious WML (script) code, but this would be trivial for any scanner that can currently handle JavaScript or visual basic script threats. However, limiting the solution to the origin server does not adequately protect the end user. While the origin server

References
[1]
N. Borselius, Mobile agent security, Electronics & Communication Engineering Journal, vol. 14, no. 5, pp. 211218, 2002. T. M. Ahmed, Using secure-image mechanism to protect mobile agent against malicious hosts, World Academy of Science, Engineering & Technology, vol. 59, pp. 439444, Nov. 2009. M. K. Denko and Q. H. Mahmoud, Mobile agents for

[2.]

[3]

REDDY et al.: Wireless Application Protocol for Potential Threats to Mobile Agent Network Security

219

[4] [5]

[6]

[7]

[8]

[9] [10] [11] [12] [13] [14]

clustering and routing in mobile ad hoc networks, in Proc. of the 2nd Int. Conf. on Ad Hoc Networks and Wireless, Montreal, 2003, pp. 271276. Wikipedia the free encyclopedia. Mobile agent. [Online]. Available: http://en.wikipedia.org/wiki/Mobile_agent Y. Zhang, L. Zhu, and L. Feng, Key Management and authentication in ad hoc network based on mobile agent, Journal of Networks, vol. 4, no. 6, pp. 487494, 2009. J. Dale and D. C. DeRoure, A mobile agent architecture fordistributed information management, presented at the International Workshop on the Virtual Multicomputer, 1997. D. Kotz and R. S. Gray, Mobile agents and the future of the Internet, ACM Operating Systems Review, vol. 33, no. 3, pp 713, 1999. W. Jansen and T. Karygiannis, Mobile Agent Security, NIST Special Publication 800-19, Washington: U.S. Government Printing Office, 1999. WAP Architecture, Version 30-Apr-1998, Wireless Application Protocol Forum, Ltd., 1998. WAP Service Indication, Version 08-Nov-1999, Wireless Application Protocol Forum, Ltd., 1999. WAP Push Architectural Overview, Version 08-Nov-1999, Wireless Application Protocol Forum, Ltd., 1999. WAP PPG Service, Version 16-August-1999, Wireless Application Protocol Forum, Ltd., 1999. WAP Push Access Protocol, Version 08-Nov-1999, Wireless Application Protocol Forum, Ltd., 1999. WML Reference, Version 1.1, Nokia, 1999.

[15] WMLScript Reference, Version 1.1, Nokia.

M. Indrasena Reddy received the M.Tech degree in computer science & engineering from Jawaharlal Nehru Technological University, Anantapur in 2011. He is currently doing research on network security with the Department of Computer Science & Engineering, RGM College of Engineering and Technology. His research interests include information security and computer networks. K. Subba Reddy received the M.Tech. degree in computer science & engineering from Jawaharlal Nehru Technological University, Anantapur. He is currently doing research on wireless networks with the Department of Computer Science & Engineering, RGM College of Engineering and Technology. His research interests include information security and computer networks. P. J. Bhatt, photograph and biography not available at the time of publication. Rajeev Chetwani, photograph and biography not available at the time of publication.