Testing Mobile Applications for Security Vulnerabilities

By balaji

April 14, 2009

"Time is money" is the mantra for modern day banking. Banks are competing with each other to attract and retain customers. Innovative and more user friendly banking solutions are being introduced as a result. Mobile Banking is just one of them.


"Time is money" is the mantra for modern day banking. Banks are competing with each other to attract and retain customers. Innovative and more user friendly banking solutions are being introduced as a result. Mobile Banking is just one of them.

Mobile applications - an Overview

More and more consumers are using mobile / smart phones - so mobile applications are a great way to directly connect with customers. They connect with consumers in real-time and therefore provide services anytime anywhere.

Mobile applications can be categorized under communications, games, utilities, multimedia, productivity and travel based on their functionality. However, for security testing our focus is mainly on applications from Banking / Finance domain under the productivity category.

From a technical point of view, mobile applications can be differentiated by the runtime environment they run in:

  1. Operating systems such as Symbian, Windows Mobile and Linux
  2. Platforms and virtual machines such as .Net Mobile, Java/J2ME, BREW, Flash Lite and Silverlight

Note: This article discusses testing of JAVA/J2ME based mobile applications. Although, similar approach may be followed for testing mobile applications based on other platforms.

Prerequisites for a Mobile Application Security Assessment

  1. Installation file for the application : Generic / device specific
    A mobile application is usually distributed as either a jar/jad file. The application jad/jar file may be different for different mobile model/make and operating system.
  2. Emulator: Generic / device specific
    An emulator is a software application which allows a computer to run programs written for Mobile devices.
    Fig 1. J2ME Emulator

    You may use J2ME emulator which is generic. Many device specific emulators are also freely downloadable.

    If the jar / jad file doesn't run on the generic emulator then it means it searches for device specifications, which are not present in generic emulators. It is then a good idea to try emulating the application on device specific emulators.


Mobile application security assessment also follows the same step by step procedure as a normal application security assessment such as:

  1. Threat Profiling
  2. Test Planning
  3. Test execution
  4. Reporting

Categories of Applicable Tests

All the tests relevant to a thick client application can be applicable to mobile applications.

  1. Authentication checks
  2. Input Validation checks
  3. Session Management checks
  4. Encryption checks
  5. Application checks
  6. SQL injection checks
  7. LDAP injection checks
  8. XPATH injection checks

Relevant Tools

  1. Web Proxy editor / thick client proxy
    Usually the mobile applications communicate with server using SMS or GPRS.

    Special tools are required to intercept the SMS traffic which may not be freely available. Further more; sending SMS to a server via emulator is not possible as of now. Thus that may not be a viable option. It is easier to intercept GPRS traffic as GPRS uses http. Thus GPRS requests and responses can be captured in any web proxy tool.

    Fig 2. Burp Web Proxy

    In an emulator you can set the http proxy in preferences > network settings or in settings etc.

    If in the emulator there is no such option then if the manifest / .ini /.config file has the server URL, which can be replaced with [can also try web scarab as reverse proxy]

    You could also try hooking echo mirage to the emulator.exe by injecting into process. [Try using sysinternals to find the actual executable name.]

  2. Memory reader like winhex to read the executable's memory for sensitive information such as User Id, Mpin etc.
  3. Network protocol analyzer like ethereal for sniffing packets
  4. Process monitor [for files, registry, processes]
  5. Registry key reading utility like user assist
  6. DI hell [for listing out the .dll files called by the application]
  7. Disassembler like softice
  8. Decompiler [decompiling .class files to .java files]
  9. JADmaker [converts jar file to jad file]
    Fig 3. JADMaker
  10. IDE for JAVA development like eclipse with eclipseME plug-in

Alternative Tests

In absence of an emulated environment, it might not be possible to capture requests in proxy. Then as an alternative, architecture review and reverse engineering can be carried out.

Architecture Review

[Source: Discussion with vendor and supporting documents]

  1. Study of Network architecture.
  2. Identifying each component and its role during end to end communication.
  3. Reviewing the encryption mechanism used and its implementation.
  4. Channels used for communication.
  5. Communication packet architecture and content.
  6. Configuration of a client.
  7. Information stored locally in [.db, .ini, .config, .dll, .rms, etc] files.
  8. Read / Modify information from locally stored files.

Reverse Engineering

  1. Extract from the Jar file the constituent class files.
  2. Decompile the class files to obtain the source code.
  3. From the obtained source code remove obfuscation, if present.
  4. Study the code for hard coded sensitive information.
  5. Write/modify code to defeat the validations/encryption.
  6. Compile the modified code of the classes in to jar file.
  7. Now try to emulate the application on the computer, using new jar file.
  8. If this succeeds then make a test plan according to the captured requests.
  9. Execute the test plan.

Future Improvement

Being able to achieve the following would overcome many of the obstacles faced while testing mobile applications:

  1. Capturing SMS via a proxy tool
  2. Bypassing SMS
  3. Sending SMS to server from emulator


Tags: Technical