Mobile Application Testing

Technology is evolving faster by the day. Today, we see mobiles are no longer mobiles, they are small computers. The smartphones run powerful applications, providing everything to users at their fingertips. Users can use their mobiles for:

• Logging in to banks in order to transfer funds
• Purchasing or selling shares via trading portals
• Booking travel or movie tickets
• Tweeting or social networking
• Donating to charity

As money transactions move to mobiles, hackers also move their attention to it. Hence, as a precautionary measure, securing mobile applications becomes important. This article introduces you to the three key aspects of securing mobile applications.

Mobile applications may be a -

• web application accessed via a WAP browser.
• thick client application sending out an HTTP request or an SMS.

Security testers should broadly focus on the following categories while analyzing their test cases -

• Local Storage of Data
• Hard-coded Sensitive Data in the Source Code
• Data in Transition

Let us further discuss these categories in detail from a security tester’s perspective.

Local Storage of Data

The local storage of data can also be referred to as a “Handset Memory Analysis” for mobiles.

Mobile applications store data in the local memory of a handset. This data is stored by developers in files locally and is used by the application.

• The Android OS stores data in files at runtime, but due to its native sand-boxing mechanism, obtaining access to this data is difficult. It also stores some data in the SQLite database.
• The Apple iOS stores sensitive information like keystrokes, snapshots and other cached information in the iPhone local memory in the form of client-side SQLite databases or .plist files.
• The Java application in Nokia phones stores it in the form of RMS files. These RMS (Record Management System) files get stored permanently and are easily accessible. Sometimes, they are easily readable when connected to a PC via a data cable. These files have a history of containing sensitive information like bank account numbers, beneficiary details or registered biller(s) auto-pay details.

A security tester needs to conduct a Handset Memory Analysis to detect sensitive information stored in the device.

A mobile application should not store sensitive data in user handsets. If at all it is necessary to store some data, it should be stored in a secure manner using strong encryption algorithms. It can further be stored at non-reachable locations with strict permissions.

Hard-coded Sensitive Data in the Source Code

Applications are also known to comprise hard-coded data in the source code. We may come across various types of sensitive data like –

• payment gateways hard-coding the credentials
• applications hard-coding the server and application-specific details
• developer names & comments explaining the code pieces

Reverse-engineer the source code to obtain readable code files. This would ultimately help discover hard-coded data. It would also help reveal the application logic.

• Android packages the application in .apk files, which have to be reverse-engineered to .dex files and then to readable class files.
• Other .jar files can be simply renamed to .rar and extracted by WinRAR software. This results in decompiled class files that can be read using text editors.

A security tester has to decompile the application code in order to detect sensitive data or hard-coded information.

A mobile application should not hard-code sensitive data in the client-side code.

Data in Transition

Another aspect of mobile usage is the communication channel. Data in transit may be vulnerable to sniffing or manipulation. The data in transit can be tampered or stolen to –

• obtain access to other user accounts.
• transfer funds from other accounts.
• sell shares of other users in order to create a nuisance.
• conduct social engineering.

During a security test, the tester should analyze the data in transition. The HTTP traffic in mobile networks can be intercepted via a proxy editor tool. Here, the security tester can execute targeted manipulation attacks in order to test the application’s resilience against such attacks.

Mobile applications should thus implement server-side validation to prevent data manipulation in transit. Strong SSL encryption should also be implemented to protect data in transit.

Conclusion

There may be various dimensions to mobile application attacks. This article attempts to focus on three key aspects of the mobile security testing domain. Most of the tests revolve around these three aspects. OWASP and other known security forums periodically release guidelines for securing mobile applications. All these guidelines should be diligently followed by developers and included in the detection armory by a security tester.

Originally written by me for Palizine Magazine in 2011 

Mobile Security Best Practices

As mobile devices enter the work place, there is no denying their potential for improving and streamlining work processes. Companies are utilising enterprise apps that are unique to their businesses, and employees are taking full advantage of the benefits that accompany mobile business. However, with the conveniences of mobility comes the mounting threat of mobile security threats. The more that employees and contractors use mobile devices to access organizational systems, applications and data, the more important it is to protect such access.

Mobile Devices at Workplace

Traditionally, Organizations used to distribute Blackberry devices to their employees and setup the restrictions at Blackberry Enterprise Servers (BES).

Gone are those days; now Organizations are distributing high end SmartPhones to their Executives. Quite a good number of lower level Executives and Employees/Contractors bring their personal SmartPhones, which are connected to the Corporate Network.

These phones/tablets have different Operating Systems, like Android, iOS, Windows 7 or 8 etc. and have sufficient enough computation and capabilities to hack or cause nuisance.

Types of Applications

There can be multiple classifications of mobile applications-

1. Native v/s WAP v/s Hybrid apps.
2. Apps developed for inhouse employees v/s Apps developed for consumers.
3. Free v/s Commercial apps.

Threats to Enterprises

Data is the critical asset of Enterprises. Below threats pose risks related to data compromise via mobile devices-

1. Lost devices.
2. Temporarily unattended devices.
3. Malwares/Rouge Applications in devices.
4. Devices under control of remote attackers via internet, Bluetooth, NFC etc.
5. Jailbroken or Rooted devices.
6. Leaked Domain Credentials for WPA2-PEAP WiFi.
7. Lacking accountability or traceability for mobiles in enterprises.
8. Missing/Mis-configured encryption for data at rest and transit.

Mobile Application Development Security

Most vulnerability in the mobile applications, result from bad programming and can be avoided by following few quick tips, by all developers irrespective of their development platform:

1. Do not hardcode secrets like passwords, encryption key in the client side source code.
2. Do not store passwords or other sensitive data in the phone.
3. Use SSL for sensitive data transfer.
4. Use appropriately strong encryption for data at rest.
5. Authenticate users, sanitize inputs and manage sessions appropriately.
6. Do not print/store sensitive data in console, logs or cache.
7. Check security of 3rd party libraries in use.
8. Secure the backend components (web servers, web services and hosting).

Mobile Device Security

Here are the few tips for end users to keep the mobiles/tablets secured:

1. Set a password lock (numeric or graphical).
2. Set Device auto-lock.
3. Install a good anti-virus.
4. Keep the device firmware updated.
5. Pair only to trusted Bluetooth devices or NFC peers.
6. Always download applications from trusted App Stores.
7. Visit HTTPS secured and reputed websites only.
8. Do not jailbreak or root your device.
9. Connect to secure/trusted WiFi networks.

Additionally, few tips for enterprises to safeguard their employee mobiles and data:

1. Use Disk Encryption for mobile devices.
2. Employ Disk Encryption for SD cards too, if users store corporate date there.
3. Secure WiFi with strong WPA2 PEAP (Domain based) or Certificate based authentication.
4. Employ remote data wipe.
5. Use mobile device data backup solutions.
6. Maintain an inventory of user devices allowed to connect to corporate network.
7. Maintain an inventory of allowed mobile applications for work.
8. Have a fair usage policy and systems to control usage.
9. Enterprises having their private AppStores, must take care of distributing secure applications only.

BYOD as an opportunity for Enterprises

BYOD concept allows employees to use their devices at work and BYOD Solutions allows enterprises to control the Employee device security by building restrictions, controls and policies around it. Different BYOD Solutions offer variety of security features. Some useful ones are-

1. AppStore owned by Employers, for providing work related apps to employees.
2. Unified security policies enforcement across organization.
3. Access control and auditing.
4. Selective data wipe for corporate data.
5. Certificate Authority and Certificate based security.
6. Secure file sharing.
7. Device Registration mechanism.

Conclusion

A lot a have been spoken and written over time on mobile security. OWASP runs a mobile security project, NIST has released Mobile Device Security Guidelines for Enterprises, hacking and security companies have release free and paid tools for mobile app security assessments, apart from the commercial MDM solutions. Adaptation of all of these approaches in tandem is necessary to implement security by “defence in depth” approach.

Three final tips to Enterprise Mobile Security. Firstly, harden the mobile devices; encourage users for the same, go for forceful implementation if required. Secondly, ensure that mobile applications are secure via SAST and DAST approaches. Finally, implement a suitable BYOD solution and setup security policies for end users.

Setting up GoatDroid properly

GoatDroid is a vulnerable android application for mobile security enthusiasts to learn & practice. I used to face a lot of challenges using GoatDroid. Most of the times I had no clue as to what went wrong in my installation, which is giving me a particular error. This makes me write a blog documenting the correct steps for proper functioning of this application.

Most of the errors I got included "Something Weird Happened", "An unexpected error has occured", "Login Failed", "Unable to Register" and Blank/No error. So here are the steps to follow for a proper setup (ofcourse you will be using QuickStartGuide)-

• Make sure your MySQL database is properly set, with Login Name as "goatboy", Password as "goatdroid" and Limit Connectivity to Hosts Matching "localhost". Also "goatboy" needs to have insert, delete, update, select on fourgoats database.
• When you run the jar file first time, point the SDK Path to the SDK installation (....\android-sdk in Windows) and Virtual Devices Path to the avd directory (C:\Documents and Settings\<current-user>\.android\avd)
• Once your application is well installed in the emulator, you need to get the "Destination Info" correct. You can use 10.0.2.2 as the Destination IP with 8888 as the port number (Webservices is running on this port). Do not use 127.0.0.1. Emulator considers 127.0.0.1 as itself and 10.0.2.2 as the host machine. This is explained in details here.
• Register & Login, everything goes well now.

The above ones are those silly mistakes which result in the errors mentioned earlier. If these are done, properly you are set.

Now if anyone is not able to capture the traffic in a proxy, here are the steps-

Normally you set 10.0.2.2 & port 8888 in "Destination Info" in emulator. But for setting the Burp Proxy v1.4.01, 

• Run Burp Proxy on 7000 port, loopback should not be selected, "support invisible" should be enabled. Set the upstream proxy servers to host 127.0.0.1 and port 8888.
• Start the emulator with this command- emulator.exe -avd <name> -http-proxy 127.0.0.1:7000.
• Set 10.0.2.2 & port 7000 as "Destination Info" in the application running on emulator.

Ofcourse you can run Burp Proxy on your favorite port other that 8888, I preferred 7000.

Have Fun with Android and GoatDroid!

OWASP APAC 2012 Experience

This year OWASP APAC conference was held at Sydney from Apr 11 to 14. Paladion was invited yet again at the OWASP conference after Jaideep & Siddharth presented at Gold Coast in 2009.

This time Dinesh & myself were conducting a training class on “Mobile Applications & Security”, followed by a talk next day on “Advanced Mobile Application Code Review Techniques”.

About the Training: It was interesting to see some of the web/mobile app developers and the prospective mobile app developers in our class. We started with the mobile introductions and threat modeling. Rest of our session focused on Android & iOS. We taught Android architecture, development basics, security testing, demonstrated security vulnerability via a vulnerable application coded by our team. (The Android vulnerable application can be downloaded at Paladion Labs section at www.paladion.net). We did the same cycle for iOS applications. We concluded the class with a discussion on OWASP Mobile Top 10 Risks.

About the Talk:  We were discussing the mobile application vulnerabilities from the code base for half of the time, focusing on Android & iOS application vulnerabilities. Later we presented on automating the static analysis to discover these vulnerabilities at pace. We discussed the analysis logic & keywords for the vulnerabilities. We have developed a batch script for the Android, which we demonstrated during the talks. The same is also available for download at Paladion Labs.

We got some of the good feedbacks from attendees. This gives an enthusiastic & satisfactory feeling about the work we have been doing for a while. We met some of the well known security guys, hackers & security enthusiasts. It was good to be the part of a global conference & attend the best talks in the industry. I personally loved Mike Park’s “Mobile Security on iOS & Android”, Jason Haddix’s “Pentesting iOS Applications”, Christian Frichot on BeEF and Justin Searle discussing Grid Apps Pentest. Jeremiah Grossman presented some of the useful statistics during his keynote. OWASP Panel Discussion & the OWASP sponsored Dinner were also enjoyed by maximum.

All presentations should be available online in a week at OWASP wiki. Paladion Android vulnerable application & the script for static analysis are available for download here. We look forward to participate more at global conferences.

Setting up Proxy for Blackberry Simulators

Setting up Proxy for Blackberry Simulators:

1. Install MDS and email simulator

2. Install Device simulator

3. Open the rimpublic.property file. The rimpublic.property file can be found at \Program Files\Research In Motion\BlackBerry Email and MDS Services Simulators #.#.#\MDS\config

(Please note location differs if you are using a Blackberry JDE (Java Development Environment))

4. Under the [HTTP HANDLER] section, update the following:

application.handler.http.proxyEnabled = true

application.handler.http.proxyHost=hostname

application.handler.http.proxyPort=hostport

5. Use charles proxy as localhost at port 8888 for best results.

Interested Further: http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800738/800792/801079/How_To_-_Configure_the_BlackBerry_MDS_simulator_to_work_behind_a_proxy.html?nodeid=800740&vernum=0

This link suggests reverse proxy usage for SSL traffic interception: http://gursevkalra.blogspot.com/2011/06/intercepting-blackberry-application.html

Android 4.0 Face Unlock bypass

Google recently launched its latest Android version (4.0). One of the new features it has is Face Unlock. This is in news with some videos demonstrating how this feature can be fooled by simply showing it a digital image of the user.


A key learning for any developer/vendor is to make sure that they have tested their product for the basic test cases before launching. Think about the bypass vectors for your feature, frame test cases for these vectors, and finally test it to see the result. If you find the test case to fail, then fix the code.

A simple test case for a feature like Face Unlock is to "show it a printed photograph" or "show it a digital image". I am sure Google must have done their part well. Lets wait to listen some official announcement on this.

About IPT & 2FA

I read an article today which says-


MasterCard today became the latest company to employ Intel's Identity Protection Technology (IPT) -- which basically converts a laptop or client device into a second factor of authentication -- for online commerce.


Full details here: http://www.darkreading.com/authentication/167901072/security/client-security/231903013/baking-strong-authentication-into-client-devices.html


My thoughts-


Hardcoded Intel chip plays the role of software token, thus providing the token for Two Factor Authentication (2FA). Entire security lies on the fact that it is very very difficult to break into the hardcoded chip. This sounds promising for now.